Linux has been with us for 20 years now. Although I am not a linux user myself (as you may have read elsewhere on this blog, I am a FreeBSD user), I do follow the linux world from the sidelines. I also try to support linux in any platform-independent/open source software that I develop. Today I read an article on another site about 20 years of linux, and it included a link to the documentary Revolution OS. I watched it, it was interesting to see what some of the big names in the linux/open source/free software world had to say. So I would like to share it with you:
I would also like to add a few thoughts of my own, regarding free/open software and linux:
Why not Windows?
The FSF started the GNU project because they wanted a free, open source version of the UNIX operating system. This is understandable, because at the time, UNIX was the most popular OS. However, over time, two things happened. Firstly, after the BSD lawsuit, a lot of the UNIX code became free and open source, under the BSD license, which is less restrictive than the GNU license. So in a way, isn’t it strange that the more restricted copy remains more popular than the real thing, with a less restrictive license? (As a FreeBSD user, I think it’s a shame… linux seems to get all the attention. As nice as FreeBSD already is, imagine what it could be like if it had all the attention and developers that linux gets. Now you find that it is often just ignored by the smaller projects, and you need to patch some code since it is written as linux/GNU-only where it could easily be made to work on BSD as well… which is ironic anyway, since BSD/UNIX is what they were trying to copy in the first place).
Secondly, UNIX was a time-shared system for minicomputers. In the late 80s to early 90s, personal computers took over the world of computing. Other OSes were used for these personal computers, the most popular being Windows. So it would be logical to have a reaction from the same movement to develop a free, open source version of Windows as well. While there is a project for this (ReactOS), it is a much smaller project than the linux kernel or the GNU toolchain, and as such, there basically aren’t enough developers to make the project into a success.
It seems that people prefer to run linux, and instead use a Windows simulator on top of that, known as Wine. Yes I call it a simulator, for two reasons:
- Historically the terms of ’emulator’ and ‘simulator’ got mixed up. An emulator was originally a piece of hardware that duplicates the functionality of another piece of hardware. A simulator is the software-equivalent of that. For some reason, people started calling software simulators ’emulators’ as well, and the name stuck.
- Even though Wine claims it “Is Not an Emulator”, they are not talking about the confusion of emulator/simulator, but rather, they are trying to deny that they are in fact a simulator (or emulator if you like). The reason why they try to deny it is simple: historically software simulation was fairly slow, because they were mostly aimed at simulating systems that also had different hardware. This boiled down to each instruction of the foreign system being interpreted one-at-a-time, which meant that they had notoriously poor performance. These days however, the technology has advanced, and the code can be recompiled to your native system’s instructionset, making it almost as fast as native code. But this still leaves the problem of translating hardware access and library/kernel calls. Which is what Wine does. It still fits the definition of a simulator/emulator.
This project is larger and more successful than ReactOS. What is sad however, is that there is little cooperation between the two, even though they could share a whole lot of work, since for the most part, their goal is the same: a free, open source implementation of the Windows API.
I think it would be very productive if the Wine project would be refactored into a few layers. Analogous to the Gallium3D project for display drivers. Namely, you can divide Wine into a few layers:
- The Windows API layer (basic DLLs etc implementing the functionality that applications use)
- The kernel subsystem layer
- The Windows-to-linux translation layer
The Windows API layer and kernel subsystem layer can be shared by ReactOS directly (and theoretically they should also be able to run on the real Windows kernel). The Windows-to-linux translation layer would be the only part that is specific to Wine. It basically translates the Windows kernel messages to linux kernel messages. ReactOS would not require this translation, and instead provides a Windows-compatible kernel, so it can run the subsystem directly.
The Cathedral and the Bazaar
Eric S. Raymond’s famous essay on the success of open source raised some questions with me. As Eric explains in the documentary, he was amazed by the success of linux and the GNU project. Projects on such a large scale should be bound to fail, yet it worked. It defied all the textbook knowledge of project management, software development and planning.
Well, I think the explanation why it worked is relatively simple: Most of this textbook knowledge assumes that we are dealing with new projects. But as we’ve already established above, neither GNU nor linux were really new projects. They aim to clone UNIX. Most other successful open source projects are also clones of earlier software. It is a lot easier to develop software when you already have a working, finished example that you merely need to copy. It makes project management a lot easier: all the GNU people already implicitly know what they are working on: they already have experience with working UNIX systems. That saves a lot of communication, documentation and other project overhead.