Slashdot Mirror
Unix To Beef Up Longhorn
An anonymous reader writes "VNUnet has a story about Longhorn having the ability to run unix or linux code via SFU." Microsoft's site has a lot more information about SFU itself. Regardless of ideological bent, it's an interesting piece o' technology.
that microsoft will have Linux code in it? (like SCO supposedly did to enable Linux compatibility).
Anyways there is no way to know without access to the source code.
Seriously, why dont they just dump the windows kernel and run longhorn on top of unix? It would be good for them and good for Linux cause we would have full driver support at last.
This is interesting.
For a while now I have used some OSS-community applications on my Windows 2000 Office desktop by running binaries compiled under the Cygwin Linux environment on Windows.
the concept of having a Linux application which could be compiled under Windows from the same codebase (subject to dependencies and X-server requirements being met) may be very appealing to the Opensource groups who have been issuing software tor Mac OSX by this method for some time.
I also wonder if this is intended to give Windows more access to certain Scientific/Media computing markets which are dominated by *nix systems (industrial renderfarms, for instance). Either way, I can only see this as a good thing.
I have been a user for about 10 years. This ends Feb 2014. The site's been ruined. I'm off. Dice, FU
Unix to beef up Longhorn
Microsoft's Services for Unix facility is poised to take a more prominent role in the next edition of Windows
Roger Howorth, IT Week 12 Jul 2004
Microsoft is set to include its Services for Unix (SFU) add-on for Windows as an integral part of the next major release of the Windows server operating system, codenamed Longhorn and expected in 2008. Some analysts said the move could eventually sideline conventional Linux and Unix operating systems.
A growing number of firms are using SFU, currently a free add-on for Windows 2000, 2003 and XP Professional, because it enables a single system to run Windows, Linux and Unix software.
Systems running SFU provide an excellent environment for integrating applications - for example, to add Active Directory support to a Unix application.
Jason Zions, a solutions architect at Microsoft, said there are development versions of SFU that enable a single process to run code both from Windows and Unix libraries. Currently this feature, which would dramatically ease integration tasks, is not available in SFU. Zions said, "We've been working on research versions that would solve that particular problem. It wouldn't surprise me to see that capability appear in a future release of Windows."
Dan Kusnetzky of analyst firm IDC said SFU was one of Microsoft's hidden jewels. "It's a very powerful capability that Microsoft very seldom speaks about," he said. "Rather than hide this product behind Windows they should lead with it. Many firms might be much more interested in Windows if it worked in the way they are used to doing things."
By including SFU in Windows, Microsoft could rapidly become the biggest supplier of Unix software if Longhorn proves a success, undermining traditional Unix vendors such as Sun, HP and IBM, as well as Linux vendors' enterprise offerings.
Microsoft has already confirmed that Longhorn will include a technology called "server roles" to make it easier for IT staff to build Windows servers suited to a particular task, such as file serving. Experts said SFU could surface as a new server role in Longhorn.
SFU is not shipped with Windows because SFU currently contains open-source software, such as the GNU C compiler, which cannot be distributed with commercial software. Zions confirmed that Microsoft is working to replace all open-source code in SFU with commercially licensed alternatives. Last year it licensed Unix software from SCO.
Microsoft may also release a 64bit version of SFU this year. Zions suggested that Microsoft would soon support 64bit x86 processors such as the AMD Opteron and Intel Xeon EM64T chips, saying, "SFU 3.5 today does not run on Windows 64bit platforms, but when I get home I am putting in an order for a 64bit AMD laptop because I have to demo this stuff."
- "When you want something with all your heart, the entire universe conspires to give it to you" -Paulo Coelho
Does this mean Windows Longhorn will now be able to execute ELF binaries? How is this different from Cygwin?
And you can tell they don't want to admit it because it's named Windows Services for UNIX. UNIX Services for Windows is more correct, but they want you to believe that Windows is empowering UNIX instead of the other way around.
In fact, Microsoft's move is aimed at two things primarily: Linux and Mac OS X
Actually, SFU enables you to do things like run an NFS server on Windows. Basically it is meant to enable PHBs to replace Unix servers with cheap Dell boxes running Windows admined by MCSEs. It has nothing to do with desktop linux or OS X.
Has anyone actually compared SFU and Cygwin in terms of speed and *NIX/POSIX compatibility? If not, I guess I have to do it myself.
Right now Interix is based on an enhanced POSIX subsystem. It's outside of Win32 and Interix applications are only indirectly subject to the "features" of the Win32 subsystem.
Jason Zions, a solutions architect at Microsoft, said there are development versions of SFU that enable a single process to run code both from Windows and Unix libraries. Currently this feature, which would dramatically ease integration tasks, is not available in SFU.
This would almost certainly require much more closer integration of the Interix and Win32 subsystems. Oh my ears and whiskers, this can't be good.
This is good, real good. This means if you write your code to work on a unix system, you have complete cross platform compatability. Whether it's Windows, MacOSX, or Linux.
We're going to be seeing Photoshop for Linux any day now.
"That's so plausible, I can't believe it!" - Leela
This includes servers. There are now over 12 million Mac OS X systems in use (source: 23:40 of WWDC keynote). This by far eclipses shipments by all other UNIX/UNIX-like system vendors. Apple is the single largest vendor of UNIX-based systems in the world, bar none.
Your statement is a half-truth. You are actually running *Windows* code. From the point of view of binary distribution, yes I totally agree that Cygwin is a very useful set of tools.
Source code, however, is another matter entirely. You can't just take some random package off the net, do a and expect it to work. Yes, on some occasions it does, but often not.
Many times developers use in their build system, and if they don't expect 'CYGWIN_NT-5.0', the build breaks. Unless you have a good idea how autconf/make works, you could be up the creek.
std::disclaimer<std::legalese> sig=new std::disclaimer; sig->dump(); delete sig;
SFU is not shipped with Windows because SFU currently contains open-source software, such as the GNU C compiler, which cannot be distributed with commercial software. Zions confirmed that Microsoft is working to replace all open-source code in SFU with commercially licensed alternatives.
Sheesh...
...and have the browser running in a lightweight linux virtual machine from within longhorn. In the beginning they will dump all the malware crap that targets IE running on win32. Shortly after all the scumware merchants have rewritten for the new linux target, MS may be able to make Linux look every bit as insecure as they have made win32 platforms look.
How long do you think that it will take to replace all the open-source code with commercially licensed alternatives? This isn't a trivial excercise by any means.
It would get a lot easier if a friendly business could 'acquire' commercial rights to open source software through legal means. Suppose for a second that the impossible happened and linux was shown to be a derivative work of SCO's. Would gcc be the next target?
an application...
running on user mode linux...
running on a host linux...
running on VMWare...
running on Windows.
So, what's the "platform"? (Extra Credit: If the application is a web-services solution, what's the "platform" then?)
Generally, bash is superior to python in those environments where python is not installed.
They'll be able to deflect attention from OSX and Linux by saying they provide a unix...
SFU wont be as good as unix, so people will still think of unix as difficult.
PHB's will believe it as usual...
M$ have a funny logic - whatever makes them think people will pay $$$ for a Windows box/licence/BSOD's to run GPL 'free' OSS like GNU/Linux on it???
Jason has not posted lately on his blog . But here was an earlier post that referenced the January Slashdot article on SFU.
Have you Meta Moderated t
You know how all the Slashbots complain about WINE, saying that it's going to marginalize native Linux applications like OS/2's Windows compatibility layer did?
Well, it cuts both ways, folks.
If an ISV can write POSIX code that builds on Windows, Linux, and Mac OS, where's the motivation to write Win32 (or even WinFX) native code?
Thank you Microsoft, for providing standard API's for a change. Between that and Mono, things are looking good for cross-platform software. Good to see Microsoft doing the right thing. (Now, we know they'll deliberately make this difficult, because it's just not Bill's nature to play nicely, but we'll work around that.)
Tired of FB/Google censorship? Visit UNCENSORED!
Seeing as the only difference between Windows and Linux that MS cannot erase (assuming they want to make money) is the fact that Linux is free and Windows is not, every other difference they erase brings it one step closer to that being the *only* difference, at which point predictable things happen (this is also why I think Mono isn't a bad idea). In this case, it'll likely cause more people to develop for *nix, knowing that it will still be compatible with Windows (as long as they release the source or provide a binary), which means more applications available for Linux, which means more Linux users, which means less people caring about Windows compatibility, and so on. Vicious cycle, it is.
Work is punishment for failing to procrastinate effectively.
I would love to run SFU, since it's no doubt far more stable and reliable than Cygwin, with which I've had no end of problems over the years. Unfortunately, Microsoft forces you to sign up for thier execrable Passport ID "service" before you can download SFU, so it looks like many potential users will never even get to try it.
It *would* be nice to have a *real* functional Unix layer for XP - right now, the closest thing I've seen is David Korn's U/Win: At least U/Win's real Korn shell (ksh) can at least correctly perform basic math operations, unlike Cygwin's bash. Still, U/Win lacks even basic integration - the Interix-based SFU solution should be far superior, blending real Unix capabilities natively into XP. (I haven't seen or used SFU in five years, but it worked nearly as well as MKS toolkit at that time, which is to say, pretty well.)
Why MS didn't include SFU as a standard part of Windows from Win2K on is beyond me...
"The future's good and the present is nothing to sneeze at." - Roblimo's last
And you can tell they don't want to admit it because it's named Windows Services for UNIX. UNIX Services for Windows is more correct, but they want you to believe that Windows is empowering UNIX instead of the other way around.
It's true, they market the thing for migrating from UNIX to Windows but I've only ever used it to migrate from Windows to UNIX.
Someone must have a pretty fancy crystal ball to tell us what is and isn't going to "sidelined" four years in the future.
No kidding. I know what Microsoft is thinking on this one, and I think that four years is probably too late. It simply comes down to offering a low cost migration path from UNIX. Note that this only affects the server though.
I don't think that it will sideline different Linux vendors, though it most certainly will continue to sideline Sun, if they are still around. Of course Sun is effectively sidelined at the moment, so....
Microsoft's hope here is that they can be the vendor that runs successful UNIX server software and also supports Windows desktops exclusively. It is also aimed at preventing customers from switching to Linux just because they want to run an Apache server.
Of course in 4 years, the computing landscape could be very different than it is now. I suspect that we will be in the middle of a huge conflict the likes of which the industry has never seen. I don't think that most analysts or most managers at MS count on it being as intense as it will.
When I left MS, the prevailing view was that OSS was a pipe dream which could not work in the real world (completely ignoring the success of Apache, BIND, Sendmail, GCC, etc). I don't think that they are conscious of how their pricing model effectively eliminates them from certain markets, such as the ISP market either.
LedgerSMB: Open source Accounting/ERP
GNU software has been shipped with commertal software for a very long time and is still done today.
What you can't do is use open source code in a product that will be shipped binary only.
So far so good... excepting spelling, of course
If the commertal parts of SFU contain open source code then Microsoft can't ship.
I think you're confused. SFU, until the most recent version, was a commercial product that MS sold for many years, with GPL code included. They have always given access to the GPL code, and included it in a commercial product. Remember, binary-only and commercial are not the same thing.
However this begs the question why did Microsoft use GCC and not Microsoft C++?
Hmmm?
Because Microsoft C++ doesn't have any need for the GCC extensions and other factors that would complicate MS C++ while only adding minor benefits. Additionally, SFU was not originally developed by Microsoft. Using GCC makes porting Unix applications easier, since most of the applications being ported were originally developed under GCC. The idea is that you could do very little work to get an application running under Interix (now SFU), and then eventually spend the extra time writing the application as a native Windows app. The article also points out that they may be working on a way to allow Windows and Unix code to work together (which they can't do currently outside of some external communication system), which would most likely be done under MS C++, especially given the increased standards-compliance of MS C++ over the last couple of releases (though, again, they may have to add some GNU extensions).
Maybe it has something to do with the commertal product being absolut garbage.
That's just the vodka you've been drinking.
-PainKilleR-[CE]
God lord, Apple isn't even a certified UNIX. Are we going to count debian downloads now also? You Apple zealots really know how to twist your arguments.
"The more *nix software you can get running on Windows computers, the more likely those Windows users can make a seemless migration to *nix without any angst or gnashing of teeth."
Windows' strength isn't in what it can run, it's in how easy it is to set up and maintain. *nix has some developing to do to catch up with that. It's one thing when you're already experienced in the *nix world, but Windows --> *nix is like watching Star Trek 2, then watching Star Trek 1.
"Derp de derp."
"giving Microsoft a competitive edge in the server market...by allowing them to run...software applications that may only be available for the Unix/Linux platform"
Yes, because I would like to add the overhead of running MS Windows Server to my LAMP solution. It runs too fast now; I need to slow it down.
This could backfire badly as well. What is the incentive for companies to port to MS Windows with this? There isn't one. Instead, it makes sense for a company which expects a 50/50 MS Windows Server/*nix market to develop for *nix so that their code runs on both platforms. In other words, it makes it easier to be a *nix developer.
Will open source projects like Apache, MySQL, and PHP drop their MS Windows ports if this occurs? At the very least, I would expect interest to diminish.
1. Ask any 10 geeks about the GNU license -- even those that have read it -- and you'll get at least 3 different answers as to what that license binds you to do (or not do) in some issues. Something this murky would just confuse developers further. (Microsoft's main focus for many products is developers not users.)
2. Where the SFU stuff ends (regardless of which parts are GNU-covered) and the OS begins can confuse people and cause litigation. i.e. SFU API 1 calls API 2 calls API 3 (GNU layer!) calls API 4 calls some OS thing. Even if these "APIs" are separate "programs". Why even introduce the confusion? Show a working OS, show an Add-On package which adds more functionality, and they're demonstrably different. This is the reverse of the IE-bonded-to-Windows contraversy that they're still mired in.
3. The GNU licenses are still mostly untested in court in front of a judge. Would you place the family jewels next to a creepy-crawly misunderstood Consumer of Intellectual Property whose limits aren't firmly established?
4. Microsoft is just crawling out of the Java/Sun nightmare. To a casual observer, this smells the same. Distribution of a toolkit to allow non-MS stuff to run under MS operating systems... Ouch!
5. Don't get developers used to having the SFU handy for all of their needs as part of the OS, then they'll rely on it. Better to keep it separate in case it fails, needs to be spun off, or becomes a support and legal nightmare. Everyone developing gets used to the idea that this is just an add-on.
Get off my lawn.
What about LINE?
From the homepage:
LINE Is Not an Emulator
LINE executes unmodified Linux applications on Windows by intercepting Linux system calls. The Linux applications themselves are not emulated. They run directly on the CPU just like all other Windows applications.
Erik Dalén
Sorry folks, hit submit instead of the preview on one of my revisions. Here's the other part, about OS/2.
Even before the events I have described in the parent post, when MS pulled out abruptly out of the OS/2 deals, the OS/2 developers realized the tremendous potential of the Windows marketing and upcoming installed base, as well as the multitude of applications gearing up for Windows (it was Windows 2 then! I believe Windows 3.0 was the 1st revision MS put out after they dumped the OS/2 partnership).
So the OS/2 team tried their own version of "embrace and extend". They put up a slogan that (sorry for not remembering the exact wording) said that OS/2 runs Windows applications better than Windows (and this was true in a lot of ways, but we won't digress). Their hope was that a lot of developers would thus switch to OS/2, and for those who had some legacy Windows products to use, or Windows-based product lines to continue shipping, the Windows API support from OS/2 would suffice. Eventually, developers would prefer the richer OS/2 API and Windows would become a gone thing.
Reality, as we know, was a bit different. OS/2 lost, and Windows won. The prevalent attitude among the developers and the management back then was "if OS/2 supports alias emulates Windows (architectural issues of the real thing aside), and Windows is just that - native Windows, why don't we develop only for Windows - instead of doing cross-platform design, or supporting two product lines, we'll reduce the costs this way. We'll also reduce the costs by never buying OS/2 at all - whoever wants to run it, can buy it and it will run our apps anyhow."
So with the Longhorn/UNIX compatibility it can swing both ways towards Windows. One way (the way MS prefers it to go) would be mass switching into Windows from Unix. Just like the OS/2 folks dreamt of the future swinging towards them. The other way would be for Windows to be on the receiving end of the killing machine that killed OS/2 back then.
Windows, of course, has *much* better chances now than OS/2 then. Larger codebase written over Windows - centuries and millenia of man-hours. Orders of magnitude more users. Yet this alone won't help IMHO unless Windows rides the open source wave the way Mac OS X does. But in that case, they will have to contribute back to the open source. The ugly future would be MS succeeding into convincing people that open source is bad, by FUD or litigation or whatever else, and/or luring people into seemingly open source development on Longhorn with hidden strings attached.
Time will tell.
VKh
About the only 'modern' component of SFU as it stands today is gcc 3.3 (in sfu 3.0 it was gcc 2.x).
In an era when source development is highly linux-centric and Unix[TM]es now having to adapt to 'linux standards' to ease source code migration this seems like a serious case of 'too little too late'.
Sure, some interesting and useful stuff has been ported to SFU, but many things mormally taken for granted (e.g. emacs, ssh) are marked 'alpha' and even the packages hosted by the SFU team don't 'just build' from their own patched sources. *all of these sources* have already been ported to the native win32 API anyway.
Anyhow if it's not going to be a 'part' of ms's os until the '08 release of Longhorn, I can't see how it's going to be relevant.
Linux is Linux, if One need clarify their dist: <Dist>/GNU Linux
bsds are of course just BSD
Once again, a misleading and sensationalist article on slashdot. Microsoft have no plans to make windows "compatible" with linux in the general sense of the word. Nope, they are just planning to include SFU (Services for unix) which has been available free for some time. SFU is literally just that; adds support for linus/unix services enabling *nix style printer queues and general network interoperability tools. It does not for example allow you to run KDE or GIMP or anything fancy like that. It is preposterous to even suggest like these so called "Industry Analysts" are that this is a move my microsoft to enable Linux software to run on windows, and that it is planning on becoming the worlds biggest unix software provider. For the very word "Linux" to be associated with "Windows" is enough to make Bill Gates turn in his grave (if he was dead that is!)
...
nick
Electronic Music Made Using Linux http://soundcloud.com/polyp
GREAT Now I can have the ease-of-use of Linux apps combined with the operational stability of Windows!!
LOL that's a great point, but seriously... does microsoft actually suppose that people are moving to linux because of all those great apps? (snigger) such naivete is amusing... there are already all sorts of apps for windows, and I don't know of anybody, myself included, who has ever moved from windows to linux for the apps - no, the killer app of linux is linux itself, on the bare metal!
I talked with microsoft pr drones at linuxworld, where they were showing their unix emulator, watched their demo and asked their guys some easy questions:
No, it can't run X windows apps, let alone OpenGL apps.
No, it can't run native linux binaries - they have to be specifically compiled for this weird flavor of quasi-unix.
No, even basic unix commands such as "ifconfig" don't work, but the peecee equivalent "ipconfig" was substituted for it. (I forgot to ask them about drive letters, LOL)
If I can develop UNIX apps which will run on Windows, why would I bother developing Windows Apps?
I fear that the reality of the situation will be that Microsoft's SFU will work well enough to sell Longhorn, but not well enough that existing UNIX apps can be seamlessly moved to a Windows box.
Besides, this is a dumb move by Microsoft. Remember what happened to OS/2 when IBM announced that it would run Windows apps? That's right - developers flocked to Windows (3.1) because they new that regardless of OS/2's success, they'd still be able to sell their applications. As a consequence, OS/2 bombed, where Windows took off. Seems to me like Microsoft is shooting themselves in the foot with this one.
And incidentally, I believe the same thing about WINE - I think it hindered the adoption of Linux by developers.
The society for a thought-free internet welcomes you.
http://www.google.com/press/zeitgeist.html
that says it all, really. mac is 3%, and steve jobs said quite clearly at the 2004 WWDC that mac os x is in use by 50% of ma cusers. half of 3 is at least 1.5%, which is definitely above linux.
if you're targeting desktop unix, os x is more popular.
- tristan
What you don't mention is that Microsoft caused this. Unlike with NT 4, Microsoft refused to grant a reasonable license to the Win2k source. The little company was thus doomed, making them cheap for the big predatory company to aquire.
Hate to break it to yall, but there have been some VERY nice UNIX(tm) layers for Windows since NT 4.0 The same people that made Exceed X11 for Windows also made a kernel add-in with full POSIX support. All the UNIX goddies where there and it even seemed to increase stability. Microsoft purchased the company after they failed to get their software to run well on Windows 2k (they ran out of money and couldn't afford to redevlope). If they get this stuff working again in Longhorn, I'll be first in line to buy it when its released.
Just a couple of corrections.
The UNIX support in WindowsNT is not a 'layer' but a subsystem, i.e. just like Win32 is a subsystem. (This is part of the what makes the NT architecture unique)
Also NT had a POSIX subsystem, and even third party UNIX subsystem support since 3.1 when it was released in 1993, not NT 4.0.
With the subsystem technology of the NT architecture, Microsoft could actually implement a binary level subsystem that is fully Linux compaitble, and sit on top of the NT kernel, with full intertaction with the other subsystems that sit on NT. (i.e. Win32, etc) Just in case Linux or other *nix overtakes the desktop, Microsoft could put out a NT kernel based version that could in theory be even more solid than a generic Linux implementation itself.
Why? Well, First of all, IBM's move meant that customers were taking Windows more seriously. But, why run OS/2 if you can run Windows? I think the same this is about to happen here. This move my Microsoft is going to cause customers to really take Linux seriously, I mean, why else would you want a Linux emulation layer if Linux isn't a serious OS?
Once that happens, the customers are going to wonder why they even bother running Windows in the first place. Hell, with Linux I can run the application native, AND it's cheaper!
This is just one of the indications we're getting that Microsoft is getting desperate. This will get interesting.
"Microsoft is working to replace all open-source code in SFU with commercially licensed alternatives. Last year it licensed Unix software from SCO."
If I remember correctly, Novell disputed SCO's right to sell Microsoft that license, especially since the Novell-SCO contract says Novell gets 95%, and Novell hasn't seen a penny of that particular sale.
I'm curious to see how this will all turn out. Microsoft might argue that they paid millions for a license so they should get a license and Novell should just beat it out of SCO. And I'd expect Novell to argue that they would never have been willing to grant such a broad license for as little as Microsoft was charged. Maybe Novell will get a medium sized payoff to settle things like Sun did.
The limit of my own experience with SFU has been downloading it and finding that it would refuse to install because I was using FAT32, and rather than repartition my disk or convert to NTFS and accept slower disk performance than if I started fresh, I decided to just accept that I wouldn't be trying it on my current Windows PC. Cygwin works good enough for all my GNU/Windows needs, and has much better Windows compatibility than SFU.
"SFU is not shipped with Windows because SFU currently contains open-source software, such as the GNU C compiler, which cannot be distributed with commercial software."
This doesn't sound right to me...
Sun distributes, bash and other GNU software with their OS, why can't MS?