Microsoft to Stop Releasing Services for Unix 296
lilrowdy18 writes "According to a recent article, Microsoft will stop releasing any new versions of Services for Unix. SFU 3.5 will continue to be supported until 2011 and will have extended support until 2014. From what the article hints at, Microsoft wants Unix interoperability integrated into the OS. Microsoft says that this integration couldn't be done with past architectures."
I love SFU 3.5! (Score:5, Interesting)
What happened to ten years? (Score:3, Interesting)
Ten Year [technologywizards.com] support on all products.
Umm 2011.... sounds a bit closer than ten years.
Sub-standard integration? (Score:3, Interesting)
Re:Heard that Before (Score:5, Interesting)
I know, I worked for Microsoft Federal at the time. The only reason POSIX compliance was ever mentioned by a customer was to keep Microsoft out of a bid. So we put in POSIX. No one ever userd it or intended to use it, but it shut up the excuse to not buy Windows in the federal marketplace.
Maybe POSIX is something more today. If it's not I can certainly see why Microsoft would drop it.
Services for Linux on the other hand is useful and used in quite a number of places, and Microsoft might as well throw it in there, if nothing else just to make it easier to install. I can't see where the overhead is significant if it isnt being used.
Aimed at Unix and Linux...copying Apple (Score:3, Interesting)
They have been targetting Unix for a while, and this is aimed squarely at killing off Unix as a viable alternative inside of 5 years, as Win for Workgroups was aimed at Novell. Their other target are the switchers from Unix who tend to gravitate towards BSD or Linux. Doing this will give an option that will be quite tempting, given their installed base.
Off course, could be a bit more smoke and mirrors designed to bait switchers....
Just my two cents.
fork() and pipe() (Score:5, Interesting)
Oftentimes in security code, you want to know which process is speaking to you on the other end of a pipe. Under Linux, this is very easy. Under Windows, it is a huge bear, not the least reason for which is that Windows lacks the concept of a named pipe, so you have to make something up based on shared memory or some other such garbage.
And fork()... well, as anyone who has written a fork()-based program (i.e., one that doesn't just exec() right after forking) knows, this entirely changes the structure of the application. Yukk.
Last I head, pipe() and fork() are both POSIX, so I hope these system calls appear when Microsoft takes the plunge and replaces their crappy kernel and API with something closer to UNIX. Given how long UNIX has been around and how much important software exists for it and is being developed daily (mostly on Linux and MacOS these days), I can't wait until we can finally declare system API "victory" and move the fight to something that causes much less irritation for developers.
Many a true word spoken in jest. (Score:5, Interesting)
Strengths:
1. Marketing == Massive propaganda machine.
2. Proprietary == Huge market penetration.
3. Rich applications == User lock-in.
Weaknesses:
1. Bloated and frankly god-awful code-base
2. Expensive to maintain, insecure etc
3. Cant really afford to start from scratch
4. Cant steal Linux due to GPL
Opportunities:
1. Use BSD
2. Convert some UNIX/Linux/BSD sites
3. Remove some barriers to entry at UNIX shops
Threats:
1. Linux
2. IBM
3. Open Sourcerors
The logical BUSINESS APPROACH is this:
1. Grab BSD.
2. Break the interfaces.
3. Call it "WinBSD".
4. Creat compatibility layer: "WinBSD-API"
5. Patent "WinBSD-API" so you now own WinBSD
6. Trivial porting exercise
7. Brand it like youve never branded before
What does this give you?
-It gives you something that looks like Windows and works like Windows, but is better than it.
-It leaves you with all your existing apps and protocols still working at minimal update cost.
-It means your customers expensively bought/developed apps will still work.
-It give UNIX shops one less reason to reject windows as a solution.
-It locks out OS/3rd party developers due to the broken (and patented) WinBSD interface.
-It offloads a large amount of knackered code.
Now add all this up and it gives MS EXACTLY what they have always strived for: Continuing user lock-in to the Windows monopoly while maintaining a very painful barrier to anyone else who wants to write for the platform.
Disclaimer: I am not an OS guru so there will be some technical issues with my analysis. Im just looking at it from a business point of view.
Re:BSD isn't dying! (Score:2, Interesting)
The more BSD code Microsoft lift, the better Windows will become
Re:Microsoft's answer to UNIX (Score:3, Interesting)
Re:SFU was only good for one thing (Score:5, Interesting)
What are you even talking about? What startup times? A poor Unix environment next to useless? Cygwin is better how?
What this sounds like to me is a person realizing that he's not familiar with SFU (read: BSD), says it sucks, and retreats to the nice, warm, Cygwin (read: Linux) blanky and sticks his thumb in his mouth.
SFU is a much cleaner implementation that Cygwin, and it sits directly on top of the NT kernel rather than bringing its own layer of abstraction to the party. This makes SFU perform much better than Cygwin. Also, pkgsrc has support for SFU, which means that SFU has a proper package management system and Cygwin does not.
The *only* thing lacking from SFU is a POSIX-compatible mapping from the X11 api to the DirectX api. Cygwin has this, to its credit. Everything else about SFU is superior.
Re:Windows POSIX implementation (Score:5, Interesting)
Originally, WinNT was a Microkernel, with OS2 and POSIX support. Both of the latter were bare minimums, to satisfy contractual obligations (IBM and OS/2) or checklists for new contracts (POSIX). Neither worked well. As tiem went on, more and more things ended up in the kernel (graphics, apps and servers) it would be hard to call it a microkernel anymore, more like some kind of hybrid.
Re:Microsoft's answer to UNIX (Score:2, Interesting)
Re:SFU was only good for one thing (Score:3, Interesting)
Let's look at the webpage www.cygwin.com:Let's look at the page it www.cygwin.com points to:
http://www.redhat.com/software/cygwin/ [redhat.com] which even has this sentence:It may not be 'pureblood' Linux, but it comes from the package sources. Thanks for playing.
SFU is better (and FASTER) because it's a real subsystem talking to the kernel instead of a futzing emulation layer on top of Windows. You might call it a better kernel than Cygwin.
What makes Cygwin better is the ample userland where wider and better supported range of 3rd party program packages built into the default install than SFU.
Now if pkgsrc fixes that issue, I might switch over more. I'm using it for speedier NFS vs Samba file access due to better metadata caching.
For those of you whom has tried WinCVS over Samba and declared it unusable, you haven't tried it through NFS. Night and day.
Re:Microsoft's answer to UNIX (Score:3, Interesting)
I was going to respond citing lines of code for Windows and Linux, but the fucking stupid
Anyway, the lines of code for Windows XP is supposedly 40-50 million lines of code, whereas for the Linux kernel, it is 6 million, and for a Linux distro like Red Hat or Debian (presumably including the two desktops and the utilities, and perhaps even the included apps), the figures range from 30 million to 213 million.
The most useful figure, though, is the Coverity study that showed Linux had five times fewer bugs than commercial products of the same size.
Given that Windows XP was released with, what, 65,000 bugs or whatever the figure was, supposedly, according to a Microsoft memo at the time, that's pretty good news.