Hacker News Reader

When I first started at Microsoft, I once told a coworker something like, "Hey, I've heard NT revolutionarily elegant, but so far, I've just seen features that, while fairly nicely implemented, are universal across operating systems." He replied by reminding me that other operating systems have caught up, while NT was pretty close to its present design even in the early 90s --- it was like a modern operating system had travelled through time back to 1992. It was revolutionary.

(I spoke to someone else who was utterly amazed that NT allowed driver development without requiring that the whole kernel be relinked from object files.)

> In the time since that comment was written (just under 5 years), Linux replaced most graphics drivers with ones based on in-kernel modesetting and the DRI2 interface. This was done without breaking applications. So, the assertion that changing the video driver model would be disruptive is kind of disproven by reality.

mjg59, I could not disagree more. Without working drivers what good are working apps? I can run my Radeon x1900 under Windows 7/8 with Windows Vista drivers. Runs StarCraft2 and newer FPS games just fine.

The Linux kernel devs are so determined to break binary compatibility, I haven't been able to run with ATI's proprietary binary drivers for years. While AMD was a good open source citizen and released the specs, the open source drivers for my card are useless for anything other than 2D. That's about as disruptive as it gets.

"The Linux kernel devs are so determined to break binary compatibility...."

Well, of course. As long as no one else can use their drivers, they won't get a serious competitor in open source land. Pity about the rot in official drivers, though (e.g. for me, the latest is USB 1.x sound dongles in debian lenny -> squeeze).

Which suggests to me that if I wanted to write a OS that could become really popular I should use Windows device drivers in a microkernel approach where each lives in its own address space and process. Hmmm.

>other operating systems have caught up, while NT was pretty close to its present design even in the early 90s

The one thing you will find almost as a theme with Linux design is that there is minimum of "future" it. That applies to most of the Linux user space as well. This is a good thing and a bad thing.

For example multi-gpu systems with multiple outputs were not taken into consideration when both the Kernel and Xorg parts were designed. They took the most common usecase of single GPU, probably made some assumptions around it and coded something that works for that usecase.

Microsoft, on the other hand (almost out of necessity) had to actually design the NT Kernel while making no assumptions - multi GPUs may not have existed when XP was released but none the less MS had to design for the eventual reality when some OEM will stuff 2 GPUs and will have to write drivers for it without Microsoft being able to change the XP kernel design or even implementation in any way. I am sure the same can be said about scalability - when massively multicore CPUs weren't around NT kernel was mostly up for task of supporting them, whereas Linux adopted with lot of scalability related work that followed after the fact. (Remember the early NT vs Linux benchmarks?)

Designing for future is bad because it comes with certain baggage and to an extent added upfront costs. It is good for future compatibility, code maturity and obviously saves rewrite efforts - you don't have to rip off all the code and start over and take care not to break existing software etc. There is less code churn in Windows world I am sure than there is in the Linux world where people are constantly adopting to new realities. This creates an environment ripe for new bugs, instability and only with the amount of volunteer effort the cost factor can be lesser than prohibitively expensive.

> The one thing you will find almost as a theme with Linux design is that there is minimum of "future" it. That applies to most of the Linux user space as well. This is a good thing and a bad thing.

Maybe because it is mostly about the "past", bringing enterprise UNIX and mainframe designs into Linux?

That applies for the core kernel. But drivers/hardware support on the other hand is pure Linux way of doing - don't think any mainframes or enterprise UNIXes had to bother with multi-GPU systems, so what you see in that area of Linux design is pure, quick to market hackery aided by delay-design-until-it-no-longer-works-without-it.

It's depressing in a way but that's the best we got when it comes to a hackable Open Source OS that you can somehow run on your hardware and even patch things you don't like.

IRIX?

Yes, but still, how much of IRIX's GPU stack did SGI contribute to Linux? How much of the current DRI/DRM/GPU Driver infrastructure is inspired from old UNIX designs? The point I am trying to make is that core kernel code is influenced by old, tried and trusted UNIX designs even if it wasn't up to the snuff in the scalability area for a long time. But the rest (incl. GPUs, USB stack, V4L2, driver support code (kobject) etc.) is a different story altogether - where old designs were either inaccessible or largely inapplicable due to different requirements and that's not an area of the Linux kernel anybody is proud of.

It is still replicating the past.

What new ideas in operating system design has Linux brought, other than being a UNIX clone at zero cost?

SGI, Sun, HP, even NeXT supported multiple displays, frame buffers, and GPUs.

You could put 2 or 3 NeXTdimension cards in a NeXT Turbo Cube, for example - each with its own i860 running Display PostScript and something like 32MB of RAM - and use a display attached to each.

And the other workstation vendors had even fancier graphics subsystems and options. You could get real time stereo (LCD shutter) 3D with full Z-buffer and overlay planes for UI use (requiring a few dozen MB of VRAM) for the cost of a sports car. And with some systems use several at once.

Find some old copies of UNIX World or Personal Workstation or BYTE from the era...

May be GPUs are a bad example - for USB, FireWire and most of the other driver code and supporting infrastructure that constitutes the Linux kernel, the point (that its design is mostly uninfluenced by older UNIX) still stands. Besides the old UNIX vendors did not seem to have contributed much in terms of Linux GPU stack, maybe because that's not where the money was/is. SGI contributions for e.g. are in the area of FS and scalability predominantly. (I am aware that some places use Linux workstations for Graphics - but Nvidia essentially ships there own Xorg replacement stack along with highly kludgy properietary driver - nothing remotely related to great design there.)

Filesystems, TCP/IP stack, Multi core scalability etc are the areas that most benefited from old UNIX design. (Questionable in case of TCP/IP - Alan Cox rewrote it and I am not sure if he was influenced by any older UNIX implementation or not.)

IDK, from what I've just read NT looks like someone took Minix (released in 1992) and worked on it to make it useful. Plus adding a subsystem layer.

Frankly, I'm still more impressed by a monolithic kernel that did it better, before: Plan 9 (released in 1991). What use is for NT to be object-oriented, if it can't share its objects through a network like Plan?

> IDK, from what I've just read NT looks like someone took Minix (released in 1992) and worked on it to make it useful. Plus adding a subsystem layer.

VMS.

> Frankly, I'm still more impressed by a monolithic kernel that did it better, before: Plan 9 (released in 1991). What use is for NT to be object-oriented, if it can't share its objects through a network like Plan?

Sadly the UNIX crowd decided it was not worth it adopting it.

Minix wasn't released in 1992, the first version was from 1987.

I don't think you were implying that all other operating systems were catching up, just most of them.

For example, Solaris has had a stable driver DDI (Device Driver Interface) for years. This is what allowed ISVs to write drivers for ancient versions of Solaris that still work today (assuming the base hardware platform is still supported).

That's also what allows the latest versions of the nVidia driver to generally just work on different releases of Solaris.

The article describes the elegance of NT compared to Linux. It claims that this elegance has some benefits, but it is probably unfeasible to verify that.

Object-oriented? Linux is partially object-oriented (e.g. file systems). Modularity? Linux does have modules and you can put substantial amounts of functionality in them. If you need or want to is another question. Client-Server? The discussion of micro- vs monolithic kernel is not completely settled, but so far Linux does pretty well despite theoretical and academic arguments against its architecture.

Elegance is nice, but at the end of the day it is the features and the performance which matter to the user. NT claims better flexibility, however it is Linux, which can be used from Cloud to Cluster to Desktop to Mobile to Small-embedded devices.

Because it costs nothing, which is very important to those companies.

So do BSDs.

True, but somehow *BSD seem to have lost the enterprise train, as IBM and others decided to invest on Linux distributions instead.

Many think that's because BSD and UC Berkeley took the bullet for open source, USL v. BSDi, http://en.wikipedia.org/wiki/USL_v._BSDi

Even though it got settled in a couple of years, the agreement was then secret and BSD was still under a legal cloud. And legitimately so, the settlement was eventually made public and had this gem:

"7. Further Participation in Litigation. The University agrees that it will not actively assist or support BSDI's defenses or counterclaims in the Federal Action or the efforts of any other party who asserts in any action the right to copy, use, or disclose to non-licensees of USL any of the material contained in the Restricted Files or the invalidity of USL's proprietary rights in the UNIX System. However, nothing in this provision shall prohibit the University from responding to any discovery permitted a third party under federal or state law or from defending any claim that may be asserted against the University or the Individual Regents." (http://www.groklaw.net/article.php?story=20041126130302760).

(In retrospect it turns out SCO was never a real threat, for they didn't have the copyright to UNIX(TM), only the duty to collect fees for a 5% vig, and they knew before the lawsuits that they didn't have it (!!!).)

NT claims better flexibility, however it is Linux, which can be used from Cloud to Cluster to Desktop to Mobile to Small-embedded devices

NT is deployed in all these cases too.

Putting it in embedded devices only became possible about two years ago, no?

No; NT Embedded existed based on NT 4, in the late 1990s.

Those versions did not run on embedded devices (in the common usage), but rather PCs that needed reduced functionality, such as ATMs.

> Object-oriented? Linux is partially object-oriented

NT's OO is actually very pragmatic. Things such as files, pipes, processes and locks are objects that, because they are global, can be shared across processes and worked on by many different APIs.

Every object has ACLs that are managed by the kernel itself, so you can create a named pipe that is accessible by users with a given role, for example.

You can use synchronization APIs with heterogenous collections of object handles; for example, you can tel the kernel to wake up on the next mutex, file activity or process exit simply by giving those objects to the appropriate wait API. Unix' select() pales in comparison.

Feature wise, there isn't much difference anymore. Thats because Linux is not a community driven effort with volunteers sending patches. IIRC tehre was an article about how 75% of the code being contributed was by paid developers. That has caused most feature gaps to be minimized.

The primary difference that remains is that Linux has "evolved" where as NT was "designed". The reason for this is that modern linux has had to work around several shortcomings of the UNIX model. (for e.g. non-async I/O, suid crap, non pre-emptive kernel syscalls etc)

So, what that means is that NT (in design) has specific interface boundaries in the kernel. For e.g. the device driver design has specific interfaces for the I/O Manager, the Power Manager , PnP manager etc. and communication is achieved via I/O request packets in a highly structured way. Linux is much more monolithic in this way (even though both get the job done in the end) I don't have access to the source so I can't say how much this modularity exists in practice. But atleast in theory it means that major changes to the kernel become much more easier.

>Thats because Linux is not a community driven effort with volunteers sending patches. Of course it is. Find something broken and submit your fix. Try that for NT Kernel. Also it is true that a lot of GNU/Linux devs (it's not limited to the kernel) are paid by big companies. But there are a lot of volunteers who do this in their spare time and if they do a good job they may be hired by someone who pays them to do it full time. thats how I got my job.

My point was that commercial investment has resulted in minimizing any gap that existed between the two. If the majority of the work on Linux was done by unpaid volunteers working in their free time then Linux would have remained an obscure hobbyist OS. So yes, Linux is not community driven. Its totally commercial-interest driven. There is nothing wrong with that.

The company I work at employs a few open source devs and we usually hire people who are already doing things we want, but we just want more of, or to have our use case a bit better supported.

We don't really get to dictate what they code,we just pick people who are already, to scratch their own itch, coding what we need.

So yes, there is a lot of paid work, but it's got a very individual character to it compared to my job where theoretically I could be coding anything a customer had convinced sales we needed.

> Linux is not a community driven effort... 75% of the code being contributed was by paid developers.

Altough, yes, your point was taken, you have a weard definition of community that excludes profit motivated people.

This might be wrong, but from what I've heard, multiple GPU (nVidia Optimus) issue has more to do with GPL than the Kernel itself. I had saved this quote but I forgot the source.

> ...won't let closed source drivers use shared memory with open source code or somesuch out of their belief that it would violate the GPL.

I believe you're referring to:

http://linux.slashdot.org/story/12/10/11/1918251/alan-cox-to...

http://www.phoronix.com/scan.php?page=news_item&px=MTIwO...

Footnote: I don't believe I first read it on slashdot. That was just the first hit when I googled and it seems to summarize the debate fairly well.

While I'm not aware of an "in-depth comparison" of the two systems, if you read the Microsoft Press "Windows Internals" book and some of the important books on Unix architecture, you should be able to draw your own conclusions fairly easily.

"You call BSD a kernel, it technically is a set of APIs" If you read that in context of the Mac Os X operating system, then it would be true, as there is a BSD "layer" or "part" in the XNU kernel. So if it had been written in that aspect/context, it would have been correct.

On your first paragraph: Linux (the kernel, who cares about applications if the driver doesn't work?) has the luxury of not caring about binary compatibility. Windows can't do that.

> "This isn't it. Is there one?"

I don't think there can be one. Even if one existed, its value would be questionable since the rest of us are unable to prove or disprove the claims therein, seen as we don't have access to the nt kernel code. We're stuck with uninformed rants by microsoft's evangelists, unfortunately.

Wasn't NT kernel code widely leaked at some point?

A large portion (but not all) of the Windows 2000 source code was leaked a few years back.

The XP Professional x64/2003 Server SP1 kernel is available to those involved in teaching/research at higher education institutions. The license (https://www.facultyresourcecenter.com/curriculum/Eula4.aspx?...) would appear to permit such a comparison.