Question about Microsoft

I had a discussion with a friend about which path Microsoft may take with Windows in the future and I had this idea: couldn't MS take an *nix kernel and build the os from ground up on top of it or use general stuff like gnome and kde or even create their own desktop manager to mirror the default win interface and use some kind of wine-like layer so that regular win apps could run on it but also other linux compatible apps? Wouldn't that play perfectly with what they said about selling modules for win in the future and wouldn't that reduce development cost too?
What do you think?

 

It would kill *nix......

 

How? Could you develop your point a little bit?

 

Well, MS would add alot of bloat to add backwards compatibility, and will be slower if it tries to work to much like Windows.

 

No. Just... no. Why would MS want to take a free OS, and desktop, and start to sell it as their own? Why would they want to piss about trying to add Windows compatibility to a non-Windows OS? Their apps wouldn't run at the same speed they would under a pukka Windows OS. They'd have a heap more support issues, all hardware drivers would have to be scrapped and re-written.

End goal - they'd have a better(IMO) base for their OS, but adding everything they'd need to do what their current OS does would be a nightmare. And their end-product... it'd be a bloated *nix distribution - users could get a better experience using a proper *nix solution, and they could obtain it for free.

Microsoft need people to be tied-down to their retail products. No retail OS = no profit.

There is some good arguments for MS to ship *nix-compatible software, and they're good from all corners. A good industry-standard server control-panel would be one. Same would go for their Office packages.

It'll never happen though. Smile sweetly whilst for each person in this forum using Linux, there are probably 1000 others who don't have that luxury. Let them stick with what works for them - a familiar interface, good(?) hardware compatibility, and a product cycle which involves paying for their OS every 3-4 years, and a computer refresh at the same time. And the need for firewalls, anti-virus software, anti-phishing nonsense, and the "Damn, my computer is slow. Time to visit PC World and buy a new one" mentality.

Let them get on with their mess. They'll do whatever they want, because they have a good idea what will work for them financially, and what their moron-users will be happy to pay for products revolving around a revenue-cycle rather than something made for the good of the users.

 

While perfectly true, that's still harsh...

 

Building an OS atop of GPL licensed software and trying to sell it is illegal, so it is not possible for MS... nor is it possible to modify the software as it is still copyrighted; the only difference is that GPL software authors say: "this software is copyrighted, but we still give you permission to modify it for your own purposes." GPL software costs zero dollars, and is free in the sense that you can do things with it that benefit the community. Selling GPL material violates the license.

 

What about Xandros/Redhat then?

 

mmmh? Redhat is not free, mandrake powerpack is not free either... And isn't doesn't using lgpl in this case protect you from disclosing your sources?

 

:yes: :GEEK:

 

Aren't they selling it as "technical support" ?

 

Software licensed under the GPL must be free but only free as in "free speech", not as in "free beer". It is quite legal to sell GPLed software but it is illegal to not make the source code available. As others pointed out, RedHat sells their system and it is based on GPLed code. That's legal. It would be illegal for them to not provide the source code to people they sell it to. It would also be illegal for them to prevent the people they sell it to from redistributing the software. These clauses are in the GPL but there is no clause that says you cannot charge for it.

The problem of course is that once software is GPLed and the source code is out there, any fees must be justified by something else than mere access to the software.

 

^^^ Ah, OK. Thanks for the correction. I never understood the "free beer" clarification. What the hell does that mean?

 

Free beer argument: It's economically free, you don't have to pay for it.
Free speech argument: You may or may not have to pay for it, but you can do whatever the hell you want with the code.

 

Couldn't Microsoft use Unix instead of Linux?

 

Basically that is what Apple did with OSX. I don't see why MS would want to do that, though. They can afford to develop everything, and MS is a company that wants to control everything.

 

Why should they? They have a solid platform that has been adopted by much of the industry. Most developers are very familiar with the platform and it makes it easy and simple to make custom drivers and software for it.

Honestly, Windows server is really not all that bad. And most companies will tell ya the same. We use 2003 here at work and it work great. The only issues we have with it stem from trying to balance user's needs with security needs. Users are always asking for more privileges and we are always wanting to take away privileges for security. That won't change a bit regarding which operating system you use.

Your access points will always be your most vulnerable spots. Yet your users need access otherwise your system is useless. It's the eternal struggle. Security and red tape versus ease of use and privileges.

 

I reckon that their Server OS are good; I tried server 2008 through their Hero program and it works great...

 

Since XP I believe MS has been using some elements of the old VMS operating system. Although my experience with VMS is a far cry from MS Vista or XP. Lots of command line use.

 

Couple of problems with it.
- Legal issues. Closed-source and *nix doesn't play that well together.
- Lack of control. What if (when) Gnome or KDE decides to rewrite their code, change their API, add features Microsoft doesn't want, or refuse to add one Microsoft *does* want? What if they change the license? What if they drop backwards compatibility?
- What exactly would they gain by using Wine? You may not have noticed this, but Windows *already* has the ability to run Windows applications. Microsoft has quite a lot of code to ensure this.
- Development costs? What is cheaper, do you think? Building on top of your own codebase, which already works, does pretty much what you need, and which you can control? Or throw it all away, start completely from scratch with a fundamentally incompatible architecture and then attempt to write new software to emulate all you already had?

Linux (and to my knowledge, other *nix variants too) keep changing their API's. Which means that yes, they can more easily make changes, but also that applications have to be continually updated, recompiled, fixed and hacked in order to keep working.

Microsoft has chosen some 25 years ago to *never* change existing API's. A program that's built against the Win3.1 API will still run on Vista.
Now, how exactly would Microsoft maintain that guarantee, if they're building on a foundation that's constantly it's API's?

And then there's a much more fundamental one. *nix sucks. No, really. It's not some wonderful gift from the future. It's a bloated monstrosity, and it has plenty of design flaws on its own. You'd be surprised at how many fundamental features have literally been bolted on over time.
What would Windows gain by being built on top of that?
The NT kernel is actually pretty well designed. You might argue about a lot of what's built on top of it, but the kernel itself is pretty sound.
(No, I won't go into which kernel is "better". They're both built around the same time, the NT kernel being a couple of years younger, but not as much as people think, and they both have their shortcomings)

And finally, of course, there's no need. Windows is already (mostly) POSIX compliant. It can already run quite a lot of Linux apps without any more changes to the code than you'll need to port between *nix variants anyway. (Of course, it gets a bit funky once you start wanting X support. But for command line stuff, and all the basic API's expected by *nix apps, like berkeley sockets or pthreads, those are there. Not widely advertised, and yes, there are a small number of minor naming changes, but Windows *is* more or less *nix compatible.
Bet you didn't know that.

That part of the NT architecture is actually pretty clever. Even the bit you consider to be "Windows" is essentially an emulator (running in usermode). Which means that they can (and have done so) stick in other such "personalities" in there next to it as well, without changing the kernel. There used t obe an OS/2 "personality" sitting next to the Windows one, and the POSIX/*NIX "personality" comes and goes a bit. They used to have a POSIX subsystem, but I *think* it was replaced by a separate Unix subsystem addon. I haven't checked, but I assume they've implemented their 32- and 64-bit environments in a similar way. Simply as different "personalities" that the application can talk to.
In any case, they've got a pretty clever design there. Unix was never designed to allow you to run anything more than one environment (Unix).
We saw the problems this caused pretty clearly with the transition from 32- to 64 bit. Windows managed to provide both 32- and 64 bit support at the same time.
Linux was pretty much forced to pick one or the other. I know there are a couple of libraries to provide partial 32-bit support in some 64-bit distros, but last I checked, at least, that part was pretty incomplete. (Yes, of course Linux neatly sidesteps a large part of the problem because *nix apps are not set in stone, and tend to get ported pretty quickly so everything *can* be run 64 bit natively. But it still showed off a flaw in the *nix architecture - its designers had never *imagined* that the default Unix environment might not be enough, that you might want to present *multiple* different "personalities" to the application.

 

Nonsense. Apple built OS X on a *nix infrastructure. They have no problem keeping closed whatever they want to keep closed. There are also several flavors of *nix which use licenses that allow you to take the code and close it if you want to (e.g. the BSD license).

There are several other misconceptions in your post. I'll leave it to others to deal with them if they so wish.

 

Fair enough, I didn't say it was impossible. Just that it's something they have to tread carefully with.
Of course, it depends on which particular *nix flavor they want to use.
Something widely used that a lot of people are working hard to improve, like Linux? Then they get the legal problems, in addition to losing control over the kernel.
They could build it on top of some flavor of BSD, which might fare a bit better legally, but would still be hard to control.

Or they could build a kernel themselves, based on a *nix-like design... Which would be a lot of work, and a step backwards from what they have. (Actually, that's loosely what they did when they came up with the NT kernel. Why would they throw it away and do the same again?)

 

Argh! Wall of text! I said wine-like compatibility layer since the underlying os architecture is quite a departure from the traditional part.

 

OMG WALL!!!!!!!!!

Seriously, it's a good read even though it's long. Makes me want to go through the history of Unix on Wikipedia or something.

Apple's real speedbump to world domination is at the server level. The consumer/ end user market is crap. Once you hit the enterprise level and start managing hundreds and thousands of users will you realize what will hold back Apple.

Apple are friggin Facists. In the Windows market, if you want to write and develop a piece of software to automate some tasks, you can do it. drivers? No problem. GPIB? Sure thing. If you want to do the same thing on an Apple, well, it starts to become a pain in the rear.

Apple does a great job because it seamlessly integrates the software and hardware layers, but at a cost. When you can do that yourself, with your own engineers, with your own software developers, you realize that premium you pay to Apple makes no sense. When we, the developers and engineers feel we can make a better piece of software for our needs, why pay for Apple's "bloatware" that we will just overwrite with our own software?

 

They've already got this though. They achieve Windows-compatibility through just such a compatibility layer even today. (Of course, it works a bit differently than Wine, but the idea is the same)

The "Windows" layer is in fact a special compatibility layer built on top of the kernel. In user-mode, outside the kernel. It works by translating all system calls into the kernel's own API (which is *not* compatible with Windows applications)

Microsoft is some 20 years ahead of Wine in this respect.
They've already isolated all the "Windows compatibility cruft" in one single layer, kept cleanly separated from the kernel, which is then free to work with a much more sensible design.

 

But hypothetically speaking if they followed the idea I propose wouldn't they have to rewrite that layer from scratch?