Slashdot Mirror
Microsoft Trying To Appeal to the Unix Crowd?
DigDuality writes "With the news that Windows 2008 (recently discussed on Slashdot) will have GUI-less installs and be fully scriptable, that they've opened up their communication protocols for non-commercial usage and are providing a patent covenant (Redhat Responds), and now finally an interesting rumor floating around that Microsoft will be taking on GNU directly. Has Microsoft totally switched gears in how it is approaching the Unix and FOSS sector for direct competition? According to an anonymous email leaked from a Microsoft employee, it seems Microsoft will be developing a framework that will be completely GNU compatible. Microsoft CEO, Steve Ballmer, said on Friday (23 February) that they are aiming to restore a Unix-like environment to its former proprietary glory, at the same time proving that Microsoft is committed to interoperability. Ballmer emphasized that Microsoft's new strategy is to provide users with a complete package, and this includes users who like Unix environments. According to the supposedly leaked email, UNG, which stands for UNG's not GNU, is set to be released late 2009."
And what is the difference between this and Windows Services for Unix? Sounds like rebranding to me.
"When life gives you lemons, don't make lemonade. Make life take the lemons back!" -- Cave Johnson
You insensitive clod! I'm an Eskimo and I love the sweet tasty goodness of a cool, sugary sno-cone.
Also, you left one other difference out:
Satan engages in questionable business practices.
Oh wait....
My whole point of investing my time into Linux is because FOSS is a cultural phenomon that is completely new. Nobody, at least, not a single entity, owns Linux, and for that reason, it belongs to everyone. If you make some sort of a contribution to it, free of charge, it is almost like making a contribution directly to humanity.
I can't possibly see how Microsoft could pull off a similar thing.
No amount of being nice or slick marketing posters could make me think that writing for free on platform with a track record of sickening self interest could even remotely equate to the grand social experiment that is Linux.
But that's really not the worst of it. If anything, the slick marketing posters that come with Windows are a part of the problem. To a large extent, I view the drive for Linux as a push for a newer set of ethics for consulting firms.
We need to at some examine the relationship consulting firms have with large concerns like Microsoft. I always though that in the ideal case, a consultant was somewhat akin to a doctor, supposedly free of any sort of taint from any particular vendor's solution. But that's not what we have today. We have consulting firms that are "Junior, Gold", and more with Microsoft. It's an unholy alliance, where, consultants invest in MCSD's and other certifications, pay through the nose to get a product logo'd as compatible. In exchange, Microsoft gives those companies preferred listings and free development tools and operating systems. So basically, Microsoft is using artificial prices for copying to induce consultants to support their platform for free, and those consultants, in turn, are going to always be biased towards push their clients to Microsoft products. Indeed, higher levels of Microsoft partnership require sales of Microsoft products to achieve Gold or some other channel status.
If doctors did that, they would be barred from practice, and I think this comingling of a vendor with a solution provider is flat out wrong. In other lines of business, if you were paid by a vendor to advocate a particular product, selling everything from nuts and bolts to window frames, you would wind up in jail. But this practice of "partnering" is mysteriously ok in IT.
Adopting Linux removes this disgust. Because the software is free, there's no incentive to copy it, and ultimately, the customer is going to wind up with a solution that is genuinely more right sized for their needs. With Microsoft, you'll always have consultants pushing Biztalk and Enterprise this or Enterprise that, because, well, they are getting paid to do it.
The bottom line is this. If Microsoft genuinely wants to promote an open source environment, then yes, it has to make open source software, but it also has to work to promote the idea of a consultant as an independent advocate for his or her clients. We are not some salesman on the cheap motivated by free licensing for products similar to what Linux gives you for free.
This is my sig.
Microsoft would have to do a complete make-over on BSD the way Apple did with OSX. It's not that they couldn't do it, it's that they wouldn't. It would upset all of their development users to no end. There are so many developers making their products and living based on the Windows API that to move to something GNU "compatible" would simply be catastrophic in so many ways that I'd prefer not to put brain power into imagining the details. It would be ugly though... very ugly.
And in the end, it's not only that the Windows platform isn't and will never be efficient and reliable, it's that people who aren't using Microsoft as their basis for development or operations aren't doing so because they haven't heard or or tried Microsoft's stuff, it's because they have! Microsoft's reputation remains fresh in the minds of those who have rejected them.
To pull this off would require a lot. The first thing they would need to do is assure their developers that all the work, the time and resources devoted to Microsoft's platforms will not be wasted. To keep those developers would be no easy task. A large portion of them are 'worshipers' but many more are simply very invested in the current API and only take changes in small increments.
So such a move would take a long time -- even more than 5 years, possibly more than 10 -- to accomplish and even then, people are already burned on Microsoft's name, brand, style and attitude that it would take a long time to 'heal.' But 10 years is a long time to heal those memories, but why should the industry wait 10 years for what it has available to it now just so it could get something from a company that has a general strangle-hold on the IT market? People will figure it out eventually.
And since so much of today's business mentality is short-term anyway what with having to give in to short-term investors' demands or fear being sued, any planning more than 2 or 3 years out is just unimaginable.
Can they do it? Should they do it? Yes and yes! I have been saying it all along that if Microsoft wants to restore its former glory, it will have to dump the Windows API and either create a new, more stable and secure basis or adopt BSD and tweak it the way Apple did and hen create a WindowsAPI compatibility layer that actually works. Apple did it with their "Classic" mode (it's not perfect, but it worked well enough for many, and from what I hear Vista is a 'resounding success' even with its declining level of backward compatibility). Microsoft can do it too.
But will they? Not while present management is currently in control of things. If Microsoft wants another shot at being fresh, new and what's hip the way they were quite a few years ago, they'll have to dump their 80's-mentality leadership and fast! Only then will spurned anti-Microsoft people give a second look at Microsoft now or in the future.
That POSIX layer isn't. It's POSIX only in name, ...
Actually, the proper term is WEIRDNIX.
For those not familiar with the term, WEIRDNIX was the POSIX crew's term for a hypothetical implementation that was technically compliant with all the POSIX standard, but implemented everything in the worst possible way. The idea was to find bugs in the POSIX standard that would allow implementers to claim compliance while violating the intent of the standard.
Mostly, people just sent in specs for a component that followed the standard but would in some way sabotage software that expected the obvious behavior. When NT came out, there were a number of discussions of its POSIX implementation, and a lot of people explained it by saying that Microsoft had done a full implementation of WEIRDNIX. Hardly anyone's POSIX software would run sanely on NT, and that was a simple, elegant explanation of why.
Is there any reason to expect things to be different this time around?
Those who do study history are doomed to stand helplessly by while everyone else repeats it.
And say you're a company maintaining existing cross-platform software. Why pay the costs of maintaining Windows and Unix versions; just drop support for the Windows version, and let UNG pick up the slack. But once a few companies start doing that, the negative marketing consequences (not a real technical issue, just the *appearance* of loss of Windows support) will probably cause Microsoft to scuttle the whole idea and screw over everyone who had banked on it.
A better strategic approach would be the inverse - a Windows-compatible subsystem that runs on *nix. Then companies could drop support for their *nix versions, and let this subsystem pick up the cross-platform slack. This gives superior marketing optics - the major packages only appear to run on Windows. In reality, of course, it would mean that everything runs on *nix, but marketing trumps reality, so it would be a pyrrhic victory for the *nixers.
[Whew, long post. If your reaction is 'TL;DR' I don't feel bad.]
/. and other places. And yes, this is a big problem. But there is another kind of diversity, which is that Windows is the only major OS that isn't Unixy. Solaris is Unix. BSD is Unix. Linux is Unixy. It's only when you start talking about either research OSes (Mach, L4, Singularity) and old Oses (OS/2, BeOS
The NT kernel... is an interesting beast. There are a lot of things I really like about the architecture it presents. In many ways it has a lot of things that are more modern and better-designed than Unix-descendents (including Linux). At the same time MS seems to have made it more complicated than it "needs" to be, in part to satisfy backwards compatibility and in part because they just seemed to make some decisions I don't agree with.
Some of the good points:
1. Security. Yes, security. This is often brought up as a Windows problem, but that is largely because of policy decisions such as running as admin. (There are also a number of bugs caused by just plain bad coding that lead to buffer overflows. The biggest problem here in some sense is some of the abilities such as sending messages to other processes, which are probably too ingrained to pull out without some very clever modifications.) The security manager in NT provides a lot of very fine-grained control. Related, you don't need explicit file system support and a separate mechanism to do more than RWX on files. (ACLs are absolutely vital in some environments, and things like an "append only" or "create files but no delete" are useful for some applications.) In Unix, sometimes you use chmod, sometimes you use fsacl or whatever it is; the framework isn't unified.
2. Flexibility, in some sense. MS (in theory) can change the system calls that the NT kernel accepts on a whim. This is because all programs are dynamically linked to the Windows subsystem DLLs. These DLLs translate Windows API calls into whatever actual system calls they need. (One API call may generate zero, one, or more syscalls.) It's only the rare, "misbehaving" program that uses the syscall interface directly, and MS doesn't mind breaking them too much. (There are some mostly-legitimate reasons why you need to do this.) By contrast, statically linking code is a bigger tradition in Unix. (Then again, so is having source, so you can recompile if you change your syscall interface.) The idea of having various subsystems that provide different API views is pretty neat, though it's not a fundamental idea. (It's hard to say how it differs from just dynamically linking against just some shared lib.)
3. Not really a good advantage, but interesting and one of the rare examples of where Windows is actually simpler is in the read/write interface. In Unix, my impression is that if you are writing a driver, you "have" to implement to entry points for each: synchronous and asynchronous read, and synchronous and asynchronous write. In Windows, you only implement the asynchronous interface. If a synchronous request is issued, it is handled at a higher level and translated to an async call. (Upside: simpler driver code. Downside: inability to implement just the synchronous version.)
4. It's actually possible to use extended attributes on Windows, though admittedly only because of a huge hack introduced for a related but not-quite-the-same reason. (In Unix, opening a file with an extended attribute in Vi or Emacs, modifying it, and saving it is enough to kill the extended attributes. This makes them next to useless, when I at least can imagine a TON of very useful and neat things you could do with them if you could use them reliably.)
5. The registry gets a lot of hate, but I think a modified version could be better. There are a lot of very nice things it provides over config files. (Transactional access, fine-grained access controls (often nice for a corporate environment, at least in some sense),
6. Diversity. Yes, diversity. People often talk about the "Windows monoculture" on