The Free Software Foundation objected to UDI for various reasons. Mostly, I think, it was because they were afraid that people who are not them would choose to use drivers that were non-free. As I’ve written about before here, there are people who think that forcing people to use free software is somehow freedom—and I will not go into it in any great depth here, because I have done that in the past. Suffice it to say that forcing anything is not freedom; it cannot be freedom. So, the Free Software Foundation, I think, was really afraid that they would have to do more work to be able to stick to their own requirement of using 100% free software on their own computer systems. (And hey, Roy, if you’re reading—I’m not saying that the FSF is wrong, and I’m not putting myself in a position opposite of that of the FSF. I suspect you think so anyway, but hey, I just figured I would point that out.)

Even if the free software operating systems did not adopt the UDI specification, why didn’t proprietary operating systems? This is perhaps the most puzzling thing to me. It seems that in this event, none of the operating systems—free or proprietary—did what would have made sense. After all, even if only Apple and Microsoft adopted a common device driver specification, that would save a lot of time, effort, and improve user experience all the way around. Apple users would be able to use all the hardware that Microsoft users could use—and the inverse would also be true. The amount of time that device driver authors would have to spend writing and debugging driver code would go way down—free software driver authors would be able to write a driver once, for example, and all systems (including free software systems that chose to support the specification) would benefit.

I could see an objection of a driver specification that was binary-only. However, UDI was not—it mandated an ABI so that drivers that are built for a particular platform were binary-compatible with operating systems on the same platform, but it also mandated an API, so that drivers would be source compatible to any operating system that implemented the specification, on any platform. That by itself would seem to me to be positive motivation to hardware manufacturers to release the source code to drivers so that they can support operating systems that are on platforms that do not exist yet, or have not been considered (or have been considered to be nonviable or unsupported platforms).

So, I have to wonder why a common device driver specification was never implemented in various operating systems. It would seem to be a common sense thing, especially given that there are so many operating systems. It would make the coexistence of operating systems a lot easier, and it would promote choice. It might encourage bits of proprietary code on free software operating systems, but it would also enable people to drop the excuse that “free operating system x does not support device y”, and would as a result potentially increase the number of free software programs and operating systems in use, even if there is a minor cost in terms of certain drivers. And those drivers could always be replaced—a common driver specification would make it easier to understand the structure of drivers generally, and make it easier for lawful, clean-room reverse engineering to be done on those drivers.

Imagine, for example, if drivers for graphics cards, TV tuner cards, video and audio encoding/decoding cards, modems, storage chipsets, motherboard chipsets, USB chipsets, IEEE-1394 chipsets, graphics tablet devices, touch screens, debugging interfaces, network devices, and so forth were all written to a common specification, it would reduce the amount of code which needed testing. It would increase user choice in both hardware and operating systems—something which I still hold is quite likely the most valuable freedom we have. It would increase reliability, since the users of Windows, OS X, Linux, the various BSD systems, and other, not-so-mainstream operating systems would be able to run the same driver code and collectively supply debugging information and perform testing in a multitude of environments. It would increase security, because then common code that is well-known could be used on all platforms and not just the one it was written for. It would do for device drivers what POSIX has done for user-mode application software. I do not believe that I could be convinced that this would be anything other than a good thing.

Also, it could bring back old operating systems.  Imagine what life could be like, for example, if OS/2 had a “UDI driver” written for it, and it could then take advantage of newer drivers never intended for it. Or any other very old operating system which is no longer supported and could still be useful, for any of a number of reasons…

Question 1: What is an operating system?

Here is a (very partial, heavy on the Unix-like systems) list of operating systems:  GNU, FreeBSD, OpenBSD, NetBSD, Microsoft Windows, Mac OS, XENIX, AIX, OS/2, MS-DOS, PC-DOS, FreeDOS.  All of these are full operating systems, though some are more compartmentalized than others.  I hear some saying already, "But GNU is not an operating system!"  Incorrect.  When using the Hurd and a GNU userland operating system stack, that is the GNU system.  I hear others saying, "But you left Linux out!"  Correct, I did: Linux is not an operating system by itself.  Many people are under the impression that the kernel is the operating system, and this is simply incorrect.  A kernel is the core of an operating system, but it is not the operating system itself.

If the kernel is not the operating system itself, what is?  An operating system consists of a kernel and software that is used to make that kernel useful—software that provides the user (or the programmer) with an interface to the kernel.  An operating system in the modern sense comprises a kernel and software that surrounds the kernel.  In the case of POSIX, UNIX and UNIX-like operating systems, this includes the C library, a set of utilities (kill, ps, ls, cp, mv, rm, sh, and so forth), and more.  To compare to Windows, the Windows operating system is not just NTOSKRNL.EXE.  That’s the kernel, but there are a suite of executables and libraries that surround it and provide interfaces to it which make the kernel useful.  While it is technically possible to do, law prevents the creation of a "GNU/Windows" or "GNU/NTOS".  It would not be as straightforward as it is to run GNU on a Unix-like system, but it would be possible (Cygwin is as close as it can lawfully get).

So, when we talk about the FreeBSD operating system, we are referring both to the FreeBSD kernel and the utilities and software that make it useful.  "FreeBSD" includes utilities and libraries and all of that, just like the NetBSD or Windows operating systems do.  But, Linux does not.  When we say "Linux", we are necessarily talking about only a kernel, the project that is the brainchild of a man named Linus Torvalds and the army of programmers around him.

Question 2: What is an OS kernel?

An operating system kernel is the core of the operating system.  However, without the rest of the components that build an operating system, a kernel is useless.  To make matters more interesting, a single kernel can be used as a component in several different operating systems.  This is actually the case for many systems, though it is most prominent in the case of systems that are built around the Linux kernel because there are so many of them.

The lifecycle of a kernel is generally something like this:  Set up and initialize itself, load and initialize basic hardware drivers, kick off one (or more) processes that are required to make the system useful, and then loop, handling things like hardware interrupts and system calls from software.  In the case of a Unix-like system, the kernel attempts to run a program called "init" (usually on modern systems, this is found in /sbin/init), which initializes userland and starts running services that make the system useful.  So a Unix-like operating system provides at least a kernel and an init process, as well as programs for logging in from TTYs (or virtual terminals), manipulating files, processes, and the kernel’s state, and so forth.  If a Unix-like system cannot find an init program, it will halt (panic) or return to firmware where a user could tell the kernel to use an alternate program for init (for example, you can pass "init=/bin/bash" to the Linux kernel, and it will start a single program: bash).

Question 3: Where is the line between an OS and the rest?

To answer this question, we must look at several operating systems, and we must be able to know what the difference is between core software and application software.  The line can be blurred, of course, especially when the core software depends on certain application software.  So in order to more accurately tell the difference, we need to know exactly what the core system uses.  A classic example in the UNIX world: some software is used as system software, and is also available for use as application software.  A system cannot be called a Unix without some of it, and a system certainly isn’t Unix-like without it (and remember: Unix is an operating system definition).

For non-technical people, an operating system is a distribution.  That is, Microsoft Windows is an operating system as it is installed; Ubuntu, Debian, and Red Hat Enterprise Linux are also operating systems.  For those who are more technical, though, the line isn’t there:  the line is somewhere between what is shipped for installation and what is the core system.

Let’s compare FreeBSD with Linux.  A typical FreeBSD system contains the FreeBSD kernel, FreeBSD’s C library, FreeBSD’s kernel management utilities, an implementation of init, and implementations of the Unix utilities (ls, ps, cp, kill, etc.).

However, a typical Linux system contains the Linux kernel, the Linux kernel utilities, the GNU C Library, GNU coreutils, GNU findutils, GNU bash, filesystem-specific utiltiies, an implementation of init (could be sysvinit, Upstart, or any number of other ones), and others.

Question 4: When is it GNU/Linux?  When is it not?  When is any system GNU/anything?

The simple answer: most systems aren’t GNU/anything, but they could be.  Take as an example the project to use the FreeBSD kernel (but not the FreeBSD userland).  The system cannot simply be called FreeBSD any longer: a significant portion of the FreeBSD operating system is removed when its userland is replaced.  The project’s operating system is called "GNU/kFreeBSD", not "GNU/FreeBSD" because FreeBSD was a complete operating system before its utilities were removed and GNU implementations dropped in.  This would include the GNU C library and the typical things you see in a Linux installation.  This also means that it’s a different operating system entirely!  Any piece of software that expects to be built on FreeBSD and assumes a complete FreeBSD system might not even build when using the FreeBSD kernel and the GNU userland.

In the case of Linux:  When you’re using the GNU utilities and core system, it’s GNU/Linux.  When you’re not, then it’s not.  For example, Android is a distinct operating system from Ubuntu.  They both use the Linux kernel, but that’s where the similarities stop.  Android is one example of a distinctly different operating system that shares a kernel with another operating system.  Aside from the fact that Ubuntu is most commonly run on x86 or x86-64 systems and Android is most commonly run on ARM systems, if you sat the two side-by-side on the same platform you’d still have different operating systems that do things differently.  This is because Android doesn’t even use the same C library as Ubuntu; many pieces of software that are stated to work on a Unix-like system such as GNU/Linux or FreeBSD assume a richer environment (closer to that specified by operating system standards).  They would have to be ported to Android to run on Android successfully; that’s a major red flag that says "Oh, that’s a different operating system."

Question 5: Does that mean I can create my own operating system?

Yes.  You can.  And you can even re-use the kernel from any other operating system that is licensed in such as way as to permit you to do so.

Let’s think about this in terms of OS X and what Microsoft could potentially do for Windows, as an example.  Apple used to have its own operating system called "System", which was then called "MacOS", and today we call it "Mac OS Classic".  This system was a cooperatively multitasking operating system that ran software specially built for it.  It was very popular, and it was also not as robust as modern operating systems.  It was pretty interesting, though: it did not have a command-line interface.  Nearly everything that was in the System Folder was the operating system itself, aside from installed fonts, extensions, and system enablers (though often extensions and enablers would patch the operating system in memory, or hook into it in some way so as to attach itself to it).  Apple abandoned that system years ago for OS X.  They took a BSD kernel and wrote a stack around it, reusing some components but using a very different architecture to put things together.  The kernel for OS X is called Darwin, and it’s a very important—in fact, the central—piece of the OS X operating system stack.  But it is not OS X; it is but a component.

How could Microsoft do something like this?  Let’s say that Microsoft went and did something similar, taking the BSD kernel and porting Windows’ software stack to run around it.  They also call it Windows.  Let’s say that they modified the kernel to load Microsoft’s old drivers and that they had incorporated a PE loader and ported their software to this new operating system (but retained API and binary compatibility with their legacy operating system that used a very different composition of kernel and userland, by necessity).  Would this mean that they were running FreeBSD?  No.  It would mean that their operating system were based on (at the very least) the FreeBSD kernel.  Though they could keep the FreeBSD stack and package it as a set of extensions to their new operating system, and claim the ability to run FreeBSD (and in a limited fashion, some Linux, if they retain the Linux compatibility mode of the FreeBSD kernel and system) software.  Now that would be an interesting market position for Microsoft to be in, wouldn’t it?  Microsoft could even make their new system compliant in some way with POSIX and the SUS and get branded as a UNIX® system.  But the new system would be more like Windows than it would be FreeBSD if they didn’t keep FreeBSD as-it-were, since they’d likely replace the core stack to fit their desires and needs, like Apple did.

Conclusion

I hope that this has clarified things a bit.  However, if it has not, a good place to start reading is the Wikipedia articles for "operating system" and "Kernel (computer science)".  They are a long articles, but they make for a great starting point for research and clarification of just what an operating system is.  Both articles look at different operating systems (and their kernels).  As to whether or not you can determine what an operating system is, you will want to become intimately familiar with many different operating systems (and types of operating systems; there are families of them as people create more and more systems both original and reimplementations of others) before you start trying to figure it out.  Look at native code and managed code operating systems—also realize that the distinction of what is the operating system can sometimes be relatively hard to determine accurately.

If you want to see what a bare operating system looks like, though, check out one of these operating systems’ source code:  FreeBSD, NetBSD, OpenBSD.  Each of them in their version control systems has the complete operating system, which is much more than just a kernel.  You can then, should you want, figure out exactly what packages on a typical GNU/Linux system take the place of the remainder of the operating system.  It’d be an interesting exercise in learning—if learning is truly what you’re after, and not just argument.

When we explain a system to its users, we ought to talk about the operating system as what it is named; we need to not bore them with the technical details of the system. They don’t care if it’s GNU’s operating system utilities being used with the Linux operating system kernel, or if it’s the Microsoft Win32 API running on top of the Microsoft Windows kernel. It could be a hamster in a ball running around, and as long as it worked for them, they truly wouldn’t care, because they do not often want to know the details of how their computer works—they just want to know that it works, and they want to use it for whatever reason it is they have a computer in the first place.

There is more of a reason than just the Free Software Foundation’s desire to be accredited for their hard work in creating GCC, the GNU coreutils, the GNU C Library, etc. to call a GNU/Linux system a GNU/Linux system, and not just a Linux one. For one, if we’re talking about a Linux-based system that is running GNU, we should say that—because there are many possible configurations, both involving and not involving GNU software. For example, embedded systems rarely carry the entire weight of GNU with them—often, something like Busybox is used in such systems, along with a non-GNU C library. Certainly, if someone wanted to take the Linux kernel and make it a part of a proprietary system, they could do so—all they’d need to do is write (or port) their compiler and libraries to the Linux kernel, and they could create a system that is (like GNU/Linux) Linux-based, but (unlike GNU/Linux) not based on any work from GNU. Microsoft could do such a thing, if they wanted. They would then only be compelled to release their operating system kernel’s modifications, and not any of the other code. Then, we’d have the Microsoft/Linux variant to talk about. (Which, I think, would be very interesting—Microsoft could easily put PE support in the Linux kernel, and then port their APIs and various other things over, including the windowing system, and they’d gain an awful lot out of the deal, too.)

Stepping away from theory a little bit more, there are already GNU systems that are in varying degrees of operation on other operating systems. There is the GNU/kFreeBSD Project, for example. The importance of the “GNU/” identifier is heightened there, because FreeBSD does include its own native utilities, and “FreeBSD” is the name of the kernel and the associated userland utilities that live in /bin and so forth. FreeBSD has its own C library, too.

That having been said, the only operating system that would not need the “GNU/” prefix on it is probably the Hurd. Why? Because the GNU operating system userland is, in fact, native to the Hurd, which is also part of the GNU project. Linux may be thought of that way in many people’s eyes today, but it’s really not—the Linux operating system kernel was developed independently of the GNU software base, and the GNU software base was started long before the Linux operating system kernel was even thought of. The fact that they work together as well as they do is more of a force of inertia than anything else, because GNU didn’t have Linux in mind as the system they’d be running on when they had started it.

My reasoning for using the “GNU/” prefix when talking about GNU/Linux systems is more out of my desire to actually identify the system I am talking about. 99% of the time, I’m not talking to end-users about GNU/Linux anyway—I’m telling them about Ubuntu, which just happens to be a Debian variant, which itself happens to be a GNU/Linux variant. The details are best left to people that want them, and they should probably be stated correctly and unambiguously when they’re stated at all.

Just my 2¢ on the issue.