Slashdot Mirror
Microsoft to Stop Releasing Services for Unix
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."
"Microsoft says that this integration couldn't be done with past architectures." seldom i heard them being so true about themselves.
free 880 megs file hosting - www.FTPZ.US - best
And if you really need a real Unix / Linux on XP then colinux can provide it running at near-native performance.
Those who do not understand Unix are condemned to reinvent it, poorly.
Hmmm, when Windows NT was still new, there were great plans to implement not only the win32 API, but also the DOS and win16 APIs, and even POSIX! All of these were implemented to some extent, but the POSIX personality never reached a state where it was really usable.
Knowing that, and knowing all the announcements that Microsoft has been making about great new features that were going to be in Longhorn, and the subsequent withdrawal of nearly all of those features, I find it hard to believe that Microsoft will be providing POSIX compliance in Windows.
Of course, there's always Cygwin. And BTW, what came of CoLinux?
Please correct me if I got my facts wrong.
The negative spin is right there in the headline - makes it sound like MS is dropping Unix interop support, when in fact they're integrating it more tightly into the Windows core to improve it.
Yes. Don't listen to people in irc channels. :)
Just goes to show ya, the old koan is finally coming true.
Given enough time and money, eventually Microsoft will re-invent Unix
Why, o why must the sky fall when I've learned to fly?
"the POSIX personality never reached a state where it was really usable"
;)
Wasn't this needed in order for Windows to be used by certain US governmental agencies that stipulated that all OSs they used must have POSIX compliance. If I'm right in thinking that they must have been accredited with being POSIX compliant from someone so it can't have been all that bad...
You're right that Cygwin's the way to go though. I'm hoping that one day Microsoft will resurrect Xenix and port the Win32 API to it
Part of the problem is that Unix's directory and authentication systems are 30+ years old. PAM and NSS are attempts to fix some of the problems and cruft, but they really aren't all that nice, either. It's amazing that things like Samba's winbind work at all, and even then, there are serious flaws. For example, searching for a particular user account is a straight table scan, order O(n), when using the getpwent API. If your Unix box is a member of an Active Directory domain with lots of accounts (where "lots of" is "more than 1,000"), that user lookup takes forever. Guess what: every time you do an "ls -l", that lookup happens for each line. Now, the newest version of winbind tries to do some caching and whatnot (as do the tools that use account information), but since they are restricted to the 70s-era UNIX get*ent APIs that assume your password file is a flat, unindexed, small, and locally available file, the Samba team cannot make the actual searches faster than O(n).
One would think that by now, someone would have modernized the Unix authentication infrastructure beyond PAM and NSS, but that would break a lot of old code. And not to rant, but it's stupid crap like not being able to log into a cached non-local account that keeps Unix and friends off the enterprise desktops and laptops. Apple probably gets closest, and they still are missing many of the enterprise-class features Windows, I am sad to say, has had for years.
I'm proud of my Northern Tibetian Heritage
``I don't know about now, but at the time Microsofot did the POSIX implementation it wasn't so much that MS version of it was useless, it was more that the spec itself was useless. It did not have things like printing and network access, so in all reality not one single useful application in the world could say it was POSIX compliant.''
Wow, slow down for a bit. You're saying three different things here and presenting them as a single argument.
First, your argument that POSIX is useless. Certainly, POSIX does not standardize everything under the sun. That wouldn't be possible, and it wouldn't be a good idea either. That doesn't make it "useless". It standardizes the interface to a lot of system functionality, from basic file I/O to sockets, threads and shared memory. This facilitates porting of applications between conformant systems - for many applications, the core functionality would not need to be rewritten for a new system. POSIX-compliance is what causes most open-source software to quickly spread to all alternative operating systems, whereas it takes a long time to get ported to Windows.
Then, the point about the Microsoft POSIX implementation being useless. Last I read about it, it said that the POSIX personality and the win32 personality were basically completely isolated from one another. POSIX process ids are separate from win32 process ids, POSIX processes cannot start win32 processes, and communication between the two types of processes is difficult. In addition, large parts of POSIX were unimplemented, which means that many POSIX apps simply wouldn't work on NT.
And then the claim that no single application in the world can claim to be POSIX-compliant. Well, just because not everything in an application is also specified in POSIX doesn't make it not POSIX compliant. As long as everything that is in POSIX is also done the POSIX way in the application, it can be called POSIX-compliant. And for the record, there are hordes of applications that are purely POSIX; basically any Unix command-line program or daemon is a good candidate.
Finally, an interesting bit of knowledge: although POSIX is typically associated with Unix-like systems, there are other systems that are POSIX-compliant, too. IBM's MVS and VMS are two examples.
Please correct me if I got my facts wrong.
Say Windows is fully POSIX-compatible. No major applications claim "POSIX" compatibility -- developers still write for Unix dialects, and the Linux dialect has become the dominant Unix API dialect format. Windows will still have to develop seperately for Windows.
Honestly, in the 15 years that I've been forced to work with Windows, I've never met anybody that actually used this (yes I know the service isn't that old...you know what I mean).
Will it really be missed?
I don't see it as having any sort of hampering effect whatsoever.
If there was ever a necessary evil that remained evil, it's Samba. Not that I'm slagging the dedicated guys that keep trying to figure out MS's ever-changing mutilation of LANServer, but it is a sonofabitch to get working right.
The world's burning. Moped Jesus spotted on I50. Details at 11.
"Windows only UNIX code so you have to run Windows to get the "full experience of UNIX","
You mean like those evil linusfollowing monopolists that depends on glibc extensions not in the bsd c library? And those assholes that don't test their c ode on various versions of solaris, aix, hpux, and all the other operating systems the auther really doesnt care about?
If you write it, you're under no obligation to make it portable. Most stuff just isnt worth the effort of even testing let alone fixing for other operating systems.
Pain lasts, kid. Its how you know you're alive. Sometimes I think this growing up thing is just pain management-TheMaxx
In theory, I think this should be a good thing. If Windows would feature a NFS client, a good Posix personality including a complete Posix commandline toolset, and a bunch of interoperability tools for printing, user authentication, etc out of the box, it would be great.
But what this probably means is that they are dropping SFU and integrating a few incomplete crumbs from it into the server versions of Windows.
Try out fish, the friendly interactive shell.
If they really want to break the compatibility with Unix, they have to start adding e to creat()... =)
Why would you want MS to embrace another platform than Win32(/64)? If I want U*ix, I'll use U*ix. I don't need to wait around for MS. Saying that Win32 is inherently unfunctional is pretty wild, though. I think it's functional enough. At least, on the desktop... although I think Linux/FreeBSD is getting there, and I feel more and more like switching to that for my desktop needs. I already run a professional server and also a "media" server at home on Linux.
But you know, the main strategy of MS has not been exactly interoperability per se. They don't care to interoperate, unless the interoperability gives them that many more customers. I think their whole success is based on having had the "wisdom" to always be compatible on some level with the old technologies, whereas most of its competitors strove to market strong innovations. Innovation has always been last on MS's list, compatibility, first. That explains, amongst other things, why it's a lot more successful commercially than Apple. So, if some compatibility level with U*ix, maybe built in the next Windows version (and not as an add-on of some kind) proves to be able to attract a new, significant user base, then MS will do it. Not because they want to interoperate with others for the technological beauty of it, but to gain market.
Really?
Let's just say that I admire how much resources it takes under NT to spawn one new process. In fact I'm positively astonished. A good thing? I think not.
I'm also in awe of the way the NT kernel is virtualized and compartimentalized. Wait, it's not. You do know, don't you, that a Sun E15k with an arbitrary number of CPUs under Solaris can be split any which way (dynamically even) as virtual computers?
Is it the TCP/IP stack that you admire? Hmm, where was that taken from again?
The directory system then? Novell anyone?
NUMA perhaps? no, NT doesn't have that.
In fact what's so special about NT, with or without win32, that is so good? Is there a single piece that no one else has?
1969 AT&T Unix V.1 has nothing to do with current versions of Solaris, BSD or even Linux other than that they are their common ancestor.
According to K&R 1st edition, the complete V1 of Unix was about 10,000 lines of codes in C plus about 1000 in assembly, whereas Win2000 is reportedly 25 million LoC.
How about a fairly consistant graphics API that can be used for applications, and is backward compatible accross 95% of all computers in the market... you can't even rely on any *nix system to *HAVE* a gui api, let alone *WHICH* gui api is available on even 50% of *nix installs.
This may seem like a troll, but having a consistant gui api structure, and can reliably have a base of software on *nix (linux or bsd) systems to build from that one can build applications that will run on >90% of linux/bsd desktops, it won't take over the desktop market.
It isn't so much the underlying technology, it's the developer capability, and the fairly consistant API.
Michael J. Ryan - tracker1.info
One big advantage fork() has over threads:
Fault isolation.
There are between 10 and 50 people who have had some hand in most of the systems. So, let's face reality: there are going to be bugs. And while I've done my best to develop engineering paradigms that avoid the sorts of bugs that lead to segfaults, it's virtually impossible to guarantee correctness in these types of systems.
To add an additional layer of protection between the main program and the various crappy libraries I have to interface with, I use fork(). A library has some fatal bug that causes my program to crash? No problem, because it's a child process! The main program is still running, serving other requests.
[ home ]