×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Microsoft to Stop Releasing Services for Unix

CowboyNeal posted more than 8 years ago | from the end-of-the-road dept.

Windows 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."

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

296 comments

This should be interesting. (0, Flamebait)

ninja_assault_kitten (883141) | more than 8 years ago | (#13462854)

I can't wait to see what kind of negative spin Slashdot will put on this.

negative spin (3, Insightful)

Anonymous Coward | more than 8 years ago | (#13462912)

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.

Re:This should be interesting. (2, Insightful)

MightyMartian (840721) | more than 8 years ago | (#13463380)

Negative spin? I'd love it if integration with *nix systems was more tightly bound to Windows. Hell, I'd love it if Microsoft would put in something like NFS support, so I wouldn't have to use that hideous Samba.

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.

Microsoft's answer to UNIX (5, Funny)

It doesn't come easy (695416) | more than 8 years ago | (#13462855)

Embrace and extend! UNIX is doomed! Mwahahahahaha!

Re:Microsoft's answer to UNIX (2, Funny)

alexandreracine (859693) | more than 8 years ago | (#13462981)

"From what the article hints at, Microsoft wants Unix interoperability integrated into the OS."


I am sure this was ment to be :"WE WANT TO CONTROLL ALL COMMUNICATION PROTOCOLS HAHAHAHA, MONEY MONEY MONEY". Yep, more like that.

Re:Microsoft's answer to UNIX (5, Insightful)

dubious9 (580994) | more than 8 years ago | (#13462997)

Just goes to show ya, the old koan is finally coming true.

Given enough time and money, eventually Microsoft will re-invent Unix

Re:Microsoft's answer to UNIX (1)

gbjbaanb (229885) | more than 8 years ago | (#13463188)

Given enough time and money, eventually Microsoft will re-invent Unix

Surely you mean Apple.

And I thought the old koan is: what Apple does, Microsoft will copy

Re:Microsoft's answer to UNIX (0)

Anonymous Coward | more than 8 years ago | (#13463115)

What would they call it?
WinDix?
Winux?

I'll be here all week. Try the dog-meat.

Re:Microsoft's answer to UNIX (0)

Anonymous Coward | more than 8 years ago | (#13463132)

Embrace and extend Unix? Just another example of Microsoft ripping off Apple.

Re:Microsoft's answer to UNIX (3, Funny)

EvilSS (557649) | more than 8 years ago | (#13463241)

Nah. If Microsoft wanted to kill UNIX, all they need to do is release Visual Basic 6 for Unix.

BSD isn't dying! (4, Funny)

Anonymous Coward | more than 8 years ago | (#13462856)

Microsoft are moving to it as well as Apple!

Integrated (5, Funny)

n9uxu8 (729360) | more than 8 years ago | (#13462860)

Imagine...what a novel concept...the ability to interact with a Unix system...they should patent that!

Dave

Re:Integrated (5, Funny)

It doesn't come easy (695416) | more than 8 years ago | (#13462893)

No no no...not interact...Microsoft plans to integrate UNIX into Window's code base. In the next five years, they will swap more and more Windows code for UNIX code. Eventually, there will be more UNIX code than legacy Windows code. At which point Microsoft will 1) claim ownership of UNIX, 2) begin to release Windows only UNIX code so you have to run Windows to get the "full experience of UNIX", and 3) hire analysts to compare the TCO of Windows vs. other UNIX systems.

It's about time UNIX benefitted from Microsoft's years of marketing experience...

Re:Integrated (1)

Nimloth (704789) | more than 8 years ago | (#13463066)

That's good news for Darl, this means many more 799$ licenses for him if Windows users qualify...

Many a true word spoken in jest. (5, Interesting)

carldot67 (678632) | more than 8 years ago | (#13463403)

Bill Gates' SWOT ANALYSIS:
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:Integrated (1)

Mostly a lurker (634878) | more than 8 years ago | (#13462914)

the ability to interact with a Unix system...they should patent that!

I know you were trying to be funny, but if they do produce some Unix integration feature in the OS, I fully expect them to try to get some patents around it (and probably succeed).

Re:Integrated (0)

dsginter (104154) | more than 8 years ago | (#13462917)

What I don't get is why the OSS community hasn't made a Windows client for unix. Novell proved that this could be done with their "Client For Netware" that integrated nicely into all versions of Windows.

A client for unix/linux would be the beginning of the end for Microsoft. You could integrate all sorts of nice OSS stuff into it. Microsoft wouldn't control it, either.

Bueller? Anyone? Anyone?

Re:Integrated (3, Informative)

b100dian (771163) | more than 8 years ago | (#13462934)

You can use PAM LDAP for login against an AD.
And, of course, samba.

Is this enough "Client for Microsoft Networks"? :)

Re:Integrated (1)

richlv (778496) | more than 8 years ago | (#13463023)

i think he meant it the other way (though at first i also though about samba).

like a client for windows that would allow windows to use nfs and other thingies.

about why not...
probably it was seen that easier would be to develop something that would communicate with windows as remote protovols would be harder to change than internals of windows (i remember talks about ms breaking novell client with some version of windows).

also it gives the chance to interoperate with bare windows systems instead of requiring installation of additional software, so there is bigger acceptance of solutions like that.

Re:Integrated (0)

Anonymous Coward | more than 8 years ago | (#13463162)

This is something that can be done with NFSv4, Fedora Directory Server, and kerberos.

NFSv3 and OpenLDAP has been two weak points until now.

Re:Integrated (2, Insightful)

Xenophon Fenderson, (1469) | more than 8 years ago | (#13463018)

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 [irtnog.org] 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.

Re:Integrated (4, Informative)

Tony Hoyle (11698) | more than 8 years ago | (#13463175)

If 'ls -l' is doing a lookup for each line then your nscd is not running or broken.

All user information (and host) on Unix is cached - and the cache is *not* a linear lookup.

Username/PAM lookup is *not* linear. If I call getpwnam for example it goes to pam -> active directory -> username lookup. There's no searching involved.

Re:Integrated (5, Informative)

HairyCanary (688865) | more than 8 years ago | (#13463295)

I have a gaggle of Solaris boxes that authenticate to LDAP (which AD is) and I do not see any appreciable delay due to the username lookups. And yes, our LDAP directory has thousands upon thousands of users.

Re:Integrated (1)

NickFortune (613926) | more than 8 years ago | (#13463312)

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.

Surely that's just a bug in the ls implementation. It's trivial to cache the user details. And since it already knows the output format it doesn't even have to cache the whole of struct passwd. In fact for modern architectures it should be possible to hold /etc/passwd in memory. Admitedly, it's going to cause problems with old machines, but old machines are going to have to expect a performance hit dealing with systems with 10k users or so.

Still, I take your point. getpwent and its kin are optimised for systems that run a relatively small number of users. Still good for desktop use and most SMEs, but it may not scale gracefully to large Enterprises.

So: what's the problems with NIS and PAM?

Re:Integrated (5, Informative)

Dolda2000 (759023) | more than 8 years ago | (#13463320)

I don't know what Unix system you use, but on my GNU/Linux system (which uses the same APIs), based on GNU libc, the get*ent APIs are implemented using nameswitch modules, which can do lookups in LDAP, NIS, /etc/passwd, /etc/passwd.db, a MySQL database, or anything else. And indeed, it will be on the complexity order of whatever that algorithm chooses -- it's not a flat search.

I will agree that there are a lot of things that should be done with the Unix "directory services", but not that which you describe. The greatest problem is that Unix still uses numeric UIDs, whereas it should be using symbolic UIDs (such as Kerberos principles).

m$ agnizing their weakness... once again (2, Insightful)

leckmi (911151) | more than 8 years ago | (#13462864)

"Microsoft says that this integration couldn't be done with past architectures." seldom i heard them being so true about themselves.

Re:m$ agnizing their weakness... once again (0)

Anonymous Coward | more than 8 years ago | (#13463253)

An interesting statement, given that the integration offered by such products as Cygwin [cygwin.com] is pretty good, and it even works as far back as win95 (mind you, with some limitations, and even in win2k and winXP there are still limitations).

Re:m$ agnizing their weakness... once again (1)

WIAKywbfatw (307557) | more than 8 years ago | (#13463355)

This is exactly the sort of thing that we hear from Microsoft when it's selling us its Next Big Thing: "Old Thing couldn't do _____ but Next Big Thing handles it in its sleep."

Microsoft's PR machine often does a good job of telling the truth (or, at least, part of the truth) about old issues when they have a new solution but, until that time, they are usually in full "la-la-la-la, we're not listening" mode.

To be honest, this sort of selective spin isn't just something that's unique to Microsoft but they are by far the best at it.

SFU was only good for one thing (5, Insightful)

DrXym (126579) | more than 8 years ago | (#13462870)

Free NFS. Other than that it was a pigs ear. It was just various Unix bits and pieces slapped together and massively intrusive to install, requiring reboots and services to be running all the time. I tried it for a bit, noticed the huge slowdown in startup times, the poor Unix environment which was next useless and uninstalled it. Cygwin is miles better.


And if you really need a real Unix / Linux on XP then colinux can provide it running at near-native performance.

Re:SFU was only good for one thing (0)

Anonymous Coward | more than 8 years ago | (#13462936)

mmmmmmm... pigs ears....
(drool)

Re:SFU was only good for one thing (1)

Karma_fucker_sucker (898393) | more than 8 years ago | (#13462954)

Other than that it was a pigs ear

I've installed it too and I would have chosen a part of the anatomy that's more towards the end of the animal. :-0

Re:SFU was only good for one thing (0)

Anonymous Coward | more than 8 years ago | (#13463063)

it was just various Unix bits and pieces slapped together and massively intrusive to install, requiring reboots and services to be running all the time

Services For Unix requires Windows to run services? No . . .

Re:SFU was only good for one thing (1)

VC (89143) | more than 8 years ago | (#13463097)

I second your comment about colinux, ive tried SFU and cygwin as well but when it comes to the crunch you just cant beat colinux running debian.

"apt-get update" just works
"apt-get install mozilla" just works

And if you want to make a back up before you try somthing dangerous, just make a copy of the image of the root file system.

Re:SFU was only good for one thing (1)

Sparkle (131911) | more than 8 years ago | (#13463108)

Some time ago micro$oft sent me a copy of SFU. Install this! Right. Expires in 60 days. Hung it on the wall and invited anyone to take it.

Some time later they sent another "does not expire!" Sorry no time. Hung that on the wall too. No takers.

What do I want with this when I can have stuff like putty, UWIN, and Reflections? Better yet, I just formatted my NTFS partition and use it today for /home/

Re:SFU was only good for one thing (1)

IGnatius T Foobar (4328) | more than 8 years ago | (#13463122)

Free NFS. Other than that it was a pigs ear.

Definitely agreed there, but I'd also add that the free NIS implementation is a big help as well. The NFS/NIS implementation contained in SFU is a great alternative to installing Samba on your servers. If you can dispense with CIFS altogether, it's a big win.

(Not as big a win as ditching desktop Windows altogether, but sometimes we have to compromise.)

Re:SFU was only good for one thing (1)

dysprosia (661648) | more than 8 years ago | (#13463252)

Apparently bits of it are free; not only is GPL software such as gcc, gdb software in SFU, but some of the utilities are taken from OpenBSD.

I love SFU 3.5! (5, Interesting)

georgeha (43752) | more than 8 years ago | (#13462882)

I support a Solaris based printer, and with SFU 3.5 I can make the customer's Windows server host the jobs, and make them responsible for the NFS server, while all I have to do is add one line to vfstab. This is one good thing Microsoft has done (and Slashdot, I first read of them freeing it here).

Heard that Before (4, Insightful)

RAMMS+EIN (578166) | more than 8 years ago | (#13462889)

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?

Re:Heard that Before (5, Interesting)

Spiked_Three (626260) | more than 8 years ago | (#13462949)

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.

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.

Re:Heard that Before (0)

Anonymous Coward | more than 8 years ago | (#13463007)

So you're saying that Microsoft created the absolute minimum implementation of something so that they wouldn't be excluded from bids. Sounds like the kind of company I trust to work on interoperability between systems...

Holy Confusion Batman (4, Insightful)

RAMMS+EIN (578166) | more than 8 years ago | (#13463044)

``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.

Re:Holy Confusion Batman (1)

NutscrapeSucks (446616) | more than 8 years ago | (#13463350)

To be fair, the modern Single UNIX Specifications cover much more ground (and are more "useful" for application writers) than the original POSIX.1 spec that WinNT went through the motions with.

I think the GP's point was more along the lines of it being useless as a RFP requirement -- federal customers didn't actually care if it was there or not, and if they did, they wouldn't be shopping for Windows to begin with.

Windows POSIX implementation (4, Insightful)

nickos (91443) | more than 8 years ago | (#13463005)

"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 ;)

WINE on Xenix (1)

RAMMS+EIN (578166) | more than 8 years ago | (#13463055)

`` I'm hoping that one day Microsoft will resurrect Xenix and port the Win32 API to it ;)''

They can just use the (old) BSD-licensed WINE code and "embrace and extend". After all, that's what Cedega did.

Couldn't be done? (0, Troll)

Alt_Cognito (462081) | more than 8 years ago | (#13462899)

Is this similar to the way that Internet Explorer just simply couldn't have been removed from previous versions of windows?

SFU...a carefully organized code. (-1, Troll)

Anonymous Coward | more than 8 years ago | (#13462901)

Micrsoft's way of saying..."So? Fuck yoU!"

i didn't know about these unix services (2)

Adult film producer (866485) | more than 8 years ago | (#13462911)

A while ago I asked a few people on irc if there was a way to access nfs shares in windows and was told no.... would these unix services let me do that ?

Re:i didn't know about these unix services (0)

Anonymous Coward | more than 8 years ago | (#13462943)

Er, couldn't Samba help with that?

Re:i didn't know about these unix services (0)

Anonymous Coward | more than 8 years ago | (#13462985)

No. Samba is for unix boxes, not windows boxes and has nothing to do with NFS at that.

SFU has a NFS client and would be suitable for what he wants to do.

Re:i didn't know about these unix services (1)

kabz (770151) | more than 8 years ago | (#13462948)

Use PCNFS to make Windows see the NFS shares as if they were S(a)MB(a). This worked 10 years ago just fine, so I'd be surprised if it didn't still work.

I think there also used to be a client for NFS that you could install, but my copy of XP Pro appears to be missing it.

Re:i didn't know about these unix services (1)

jweage (472545) | more than 8 years ago | (#13462991)

Why bother with NFS? Just use Samba on the server and you won't need any additional software on the clients.

Microsoft's bait and switch (1)

Tontoman (737489) | more than 8 years ago | (#13462924)

I pity the poor admins who had made SFU an integral part of their enterprise installation. Those ads run by Microsoft in Linux magazines for free SFU trials turned out to be "too good to be true," as many of us suspected.

Re:Microsoft's bait and switch (3, Informative)

Bluey (27101) | more than 8 years ago | (#13462965)

Why pity them? They will still be supported for another 6 years (9 if they want extended support). They just aren't releasing any new versions of it.

Even still, some of the next-gen SFU functionality is being integrated [microsoft-watch.com] into Windows Server 2003 R2. It's not the end of unix interoperability from Microsoft, just this derivation of it.

Re:Microsoft's bait and switch (0, Troll)

Tontoman (737489) | more than 8 years ago | (#13463014)

Management will know it's been discontinued, and the enterprise installation is at the mercy of whatever derivative Microsoft's Marketing department wants to release.

What happened to ten years? (2, Interesting)

MosesJones (55544) | more than 8 years ago | (#13462926)

At last years TechEd Microsoft announced
Ten Year [technologywizards.com] support on all products.

Umm 2011.... sounds a bit closer than ten years.

Re:What happened to ten years? (3, Informative)

Bluey (27101) | more than 8 years ago | (#13462988)

It was released in January of 2004, so mainstream support should end 2009, extended support ends 2014. Sounds like they decided to extend mainstream support 2 years to 2011 and still end extended support in 2014. No conspiracy to see here.

Sub-standard integration? (3, Interesting)

Anonymous Coward | more than 8 years ago | (#13462937)

Will this mean poorer unix services? In the pre-OS X days, Apple File Services (AFS) for Windows was always years out-of-date, making Windows clients perform better than Apple clients on networks with Windows servers. The result was that poor-performing Mac clients soon disappeared. The truly paranoid might think MS did this on purpose or that MS had something to gain by keeping AFS out-of-date. ...but it was just business and allocation of resources, Right? Just happened to work out that way.

Perhaps they should change the name now, too? (5, Funny)

Shoten (260439) | more than 8 years ago | (#13462938)

Instead of Microsoft SFU, perhaps it would be better known as Microsoft STFU?

Re:Perhaps they should change the name now, too? (0)

Anonymous Coward | more than 8 years ago | (#13463171)

No, Brian, it's a foreign acronym, the 'T' is silent.

Probably a good thing (3, Funny)

Tim C (15259) | more than 8 years ago | (#13462940)

Everytime I read "SFU", my brain tried to parse it as "STFU"...

Re:Probably a good thing (1)

Genrou (600910) | more than 8 years ago | (#13463238)

Everytime I read "SFU", my brain tried to parse it as "STFU"...

I read it "SIFU". It doesn't mean anything in English, but in Brazilian Portuguese (my language), it is an acronym to "you're screwed".

In the other eweek news.. (1, Offtopic)

b100dian (771163) | more than 8 years ago | (#13462947)

"Windows Vista feature protects data from reboots" shows us how, by not supporting "unlink when in use" filesystem feature (all unices do), Windows offers to save our unsaved documents upon upgrade-required reboot..
...

Not really discontinuing SFU... (3, Informative)

RhettLivingston (544140) | more than 8 years ago | (#13462956)

but reinventing it. By moving this capability into the OS instead of hosting it as a parallel OS on the same kernel, they will gain performance and increase integration.

This is actually just one more example of an acceleration of rumors of Longhorn features. The rumors were that Longhorn would be able to run Unix applications and, specifically, x86 Linux binaries without recompilation. It looks now like at least a portion of that capability will appear in SP2 for Win 2003 Server a full year before Vista release.

Re:Not really discontinuing SFU... (2, Informative)

brajesh (847246) | more than 8 years ago | (#13463297)

Exactly, as Bill Hilf, MS's linux lab manager pointed out [slashdot.org] on recently on /.

"I can confirm that the next-generation of several components of Services for Unix are being integrated into Windows Server 2003 R2. The Network File System (NFS) client, NFS Server, User/Name Mapping, Telnet Server & Client, Password Sync and NIS Server components of Services for Unix are all present in the Windows Server 2003 R2 builds[...]In addition, a revamped POSIX subsystem, the 'Subsystem for Unix-based Applications' or 'SUA' is also available as an optional install in R2."

WTF does this mean? (0, Flamebait)

KrisCowboy (776288) | more than 8 years ago | (#13462970)

Microsoft says that this integration couldn't be done with past architectures
Past architectures? M$'s been developing this SFU thing for PDPs or what? I bet Vista isn't shit different from XP.

Unix on Dohs (0)

Elitist_Phoenix (808424) | more than 8 years ago | (#13462994)

"designed to allow the recompiling of Unix applications on both 32-bit and 64-bit Windows releases"
One Question, why? If you've got the best why use the rest? Maybe they're scared of the all the open source movement code that is being written for *nix

New kernel (4, Funny)

marcantonio (895721) | more than 8 years ago | (#13463001)

Microsoft says that this integration couldn't be done with past architectures.

Because, unbeknownced to the world, Microsoft is using a BSD kernel in Vista.

Use Cygwin.

Re:New kernel (0)

Anonymous Coward | more than 8 years ago | (#13463051)

Because, unbeknownced to the world, Microsoft is using a BSD kernel in Vista.

You mean Darwin [opendarwin.org]?

You could be right. Vista already does look like a badly themed OSX....

The trouble with cygwin (2, Informative)

petermgreen (876956) | more than 8 years ago | (#13463278)

is its posix on win32 rather than posix on NT

This makes certain things (most notablly select) rather difficult to implement and slow.

Aimed at Unix and Linux...copying Apple (3, Interesting)

darealpat (826858) | more than 8 years ago | (#13463024)

I think that Microsft has looked at how well Apple has used BSD in their OS offering, and the wheel began turning.

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.

Re:Aimed at Unix and Linux...copying Apple (1)

NutscrapeSucks (446616) | more than 8 years ago | (#13463226)

Well, I think you somewhat have a point, but Microsoft is playing an entirely different ballgame than Apple. MS is really looking at all of the enterprise server systems migrating to Linux instead of Windows.

On a technical level, "Unix" was important for Mac users because it gave them the robust, modern kernel that Apple had failed to develop in-house. Only a tiny minority of Mac users actually care about running awk or vi - they're just happy they can copy files without the machine grinding to a crawl.

Microsoft already has the underlying OS technology, so SFU is more of a bolted-on-top thing for program compatibility. From a system-administration standpoint, it's still Windows, not Unix.

Although the one thing that Mac OS X has shown is that there's a certain class of desktop users that don't want the full-meal-deal Unix environment like Linux or Solaris, but like to have sh or perl handy next to their MS Office install. I can't see why it would hurt Microsoft to appease these folks.

Another bastardized Unix (2, Insightful)

t482 (193197) | more than 8 years ago | (#13463046)

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.

That's OK - I quit supporting Microsoft Services! (0)

Anonymous Coward | more than 8 years ago | (#13463065)

- i mean, fair's fair, right? :-)

But will it be missed? (2, Insightful)

3CRanch (804861) | more than 8 years ago | (#13463073)

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.

Kill Interoperability? (1)

RAMMS+EIN (578166) | more than 8 years ago | (#13463138)

I seem to recall that Microsoft recently bought SFU from some company, or acquired the whole company, or somesuch. I can't remember clearly. But if that is the case, and now they are announcing that the product will be discontinued, isn't that another nice instance of Microsoft killing interoperability with Unix?

Yes, they say they will keep supporting it and that the features will be integrated...but I for one don't believe that's going to make things better in any way.

SFU 3.5 (0)

Anonymous Coward | more than 8 years ago | (#13463298)

MS makes a product named "shut the fuck up" ?

Re:SFU 3.5 (1)

rdoger6424 (879843) | more than 8 years ago | (#13463433)

No, the product's name is SFU, or Services For Unix (apparently, Macrosoft makes more user friendly acronyms that actual stuff). The open source-loving, Starbucks-drinking, windows-hating Slashdotters (myself included) on this site just call is STFU or SIFU (used by Genro, short for "you're screwed" in brazilian portugês).

fork() and pipe() (4, Interesting)

squarooticus (5092) | more than 8 years ago | (#13463365)

As a mostly-Linux developer who has done his share of Linux->Windows porting, the lack of fork() and pipe() are easily the most irritating aspects of programming for Windows.

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.

Why does this matter? (0)

Anonymous Coward | more than 8 years ago | (#13463379)

Given the corporate focus on creating Web-distributed applications and repositories, any implementation of NFS (or any other Unix-centric protocol) for Windows is becoming irrelevant except in a LAN setting. Back ends supporting such repositories tend to be deployed on specific platforms, so interoperability there is a non-issue.

Perhaps they're ackowledging that Samba does SMB better than they can do NFS ;-P

Who cares about Microsoft anymore? (-1, Troll)

Anonymous Coward | more than 8 years ago | (#13463418)

Microsoft might be still a large company but their proprietory virus and spyware laden insecure and crappy Windows OS is going downhill very quickly.

Linux is already the dominant player in the server market and now it has started to become a major player on the corporate and home desktops. By next year Microsoft will be mostly associated with their XBox360 if anything.

As a BSD User, I wonder (1)

putko (753330) | more than 8 years ago | (#13463423)

As a BSD user, I understand the attractiveness of Unix. I can see M$ was trying to get people like me to feel a bit better about their software.

But I don't get the real consequences of this -- what are the Unix-lovers going to do, now that this product is officially dead?

E.g. switch entirely to NetBSD/FreeBSD/OpenBSD? Port the Unix userland they need to NT? Buy other crap from other people? Run Windows and a BSD on the same machine under some weird emulation?

How will this change impact actual (power) users?
Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...