2005 interview with Marcus Brinkmann
Below is an automated transformation of the Nerdshift (Wikinerds Portal) March 2005 interview of Hurd developer Marcus Brinkmann with Nikolaos S. Karastathis. This page will have to be wikified. Please edit it only to help formatting it, and never never never change any of the actual words here. -- NSK 17:56, 7 October 2007 (MDT)
Marcus Brinkmann is a 29-year old free software developer working on the Hurd and Hurd/L4 projects. On 3 February Wikinerds Portal published an article giving details about the first program executed on Hurd/L4 thanks to Brinkmann's recent work on the process initialisation code. After the article got slashdotted, NSK contacted Mr. Brinkmann and asked him to provide an interview for the Wikinerds Portal.
An introduction to the Hurd
Hurd is part of the GNU Project, which is sponsored by the Free Software Foundation. Its name is actually a pair of mutually recursive acronyms: Hurd means "Hird of Unix-Replacing Daemons", while Hird expands to "Hurd of Interfaces Representing Depth".
The GNU Project was started by Richard M. Stallman in 1980s and was successful in creating a completely free Unix-like operating system. Many commercial distributors combined GNU with the Linux kernel, thus creating what we today know by the name GNU/Linux.
Hurd is a collection of servers running on top of a microkernel, i.e. a minimalistic kernel. Hurd servers implement functionality commonly found in other operating systems, such as file system access, network protocols, et cetera. The first functional protorype of Hurd used the GNU Mach microkernel, and there is a binary distribution which uses it: Debian GNU/Hurd.
Nikolaos S. Karastathis: Please introduce yourself and describe the software projects you are currently working on.
Marcus Brinkmann: I am Marcus Brinkmann, and was born and live in Germany, in an area called "Ruhrgebiet", because it the area around a river called Ruhr. It's an area with a history of coal mining and steel production, but this has changed rapidly and keeps changing. So, instead of melting iron ore, I work with computers.
Currently, I am the maintainer of GPGME, as I work part-time for g10 Code, the free software company of Werner Koch. In my spare time, I work on the Hurd, in particular the port to the L4 microkernel architecture.
The first steps
Nikolaos S. Karastathis: How did you learn programming and when did you use a computer for the first time? Do you enjoy programming, and why?
Marcus Brinkmann: I first learned how to use a computer, then to program. In 1982, when I was 7 years young, I had access to a Commodore 64. I became instantly addicted. I played games, of course, but at that time there were a wealth of interesting computer magazines, which had program listings which you could type into the computer. For some time, this was my primary source of new programs. I would buy the computer magazines, and typed in the programs that were printed in them.
Sometimes I made typing errors. I couldn't stop wondering how the computer knew where I made a mistake (obviously it didn't always - but most typing mistakes lead to syntax errors, which it could point out to me). So, between wondering how the computer worked, and reading about how you could teach it to do what you want (the computer magazines not only had ready programs, but also contained courses how to program yourself), I become a computer literate. These were the time of the home computers.
I enjoyed programming as an intellectual challenge, and as a way to achieve a certain result (like, printing a picture of the Mandelbrot set or whatever). I like programming because it is a totally predictable and controlled environment. Aside from hardware faults and randomness of input events, there are no uncertainties. On the downside, pure programming is void of any of the complexities of human life, and thus can be pretty dull.
However, things changed dramatically when I started to use the internet and got in touch with the free software community. Today, programming free software is just as much an intellectual quest as a political struggle. Programming is now a tool for social change, and this makes me very happy.
The first program
Nikolaos S. Karastathis: Do you remember the first non-trivial program you created by yourself? What was it?
Marcus Brinkmann: I am not sure, but I remember writing a small mathematical trainer program on the Commodore 64, where you had an ASCII Art mountain scape in the background and a skier sprite in the foreground, and everytime you answered a simple math question correctly (like, 7+5) the driver would go through one of the slalom goals. That must have been when I was in elementary school.
The Free software philosophy
Nikolaos S. Karastathis: The achievements of the free software community are impressive and, as you said, programming is now a tool for social change. Could you please describe the Free software philosophy and what it means for you? What is your personal opinion on software patents, and how they can affect free software developers?
Marcus Brinkmann: Free software is a moral obligation for me. As the founder of the Free Software Foundation, Richard Stallman, formulated, it is based on three rights: The right to use and distribute a program, the right to modify it, and the right to distribute your modifications. Without these fundamental rights, progress is inhibited, and the development of our culture is impaired.
A restrictive copyright does withhold these rights from you, the rights are "reserved". Software patents go one step further: They withhold all forms of expressions of a particular idea from you. This is why software patents are potentially so much more harmful to our culture than copyright: We all can find different ways of expression, but we all share the same fundamental ideas.
By all accounts, software patents are absurd. Just about all of them are trivial in nature, they have no moral, economic, legal or democratic justification whatsoever, and their consequences are absurd. No sane person would want to live in a world where all ideas can be patented and used as an exclusive monopoly by individual parties.
As long as only big corporations had to struggle with this, it is not so much of a problem to most people. Big corporations have the resources to carry out economic warfare in many ways, including sending groups of lawyers in clashing battles against each other. But the threat is on the table: It will increasingly be attempted to use software patents to fight free software, to exclude it from compatibility and to ruin distributors and creators, which are mostly individuals or small companies.
The existance of software patents in the EU is a reality that was created by lawyers and corporations behind the back of the people, originally mostly for their own purposes: Lawyers have an interest in creating more work for lawyers, and the patent system is under complete self-control of the group that profits the most from it. But if software patents are institutionalized and become an effective tool of power against free software depends solely on our will to fight the political struggle against them.
Involvement in the Hurd
Nikolaos S. Karastathis: How did you become involved in the Hurd project? What attracted you to it and what motivated you to contribute code?
Marcus Brinkmann: In 1996, I found a SuSE distribution in a book store which was advertised with havin TeX on it. I knew TeX, I had a DOS version of it years before, and studied the TeX and Metafont book (I am also a mathematician). I didn't know zip about anything else that was said on the SuSE CDs, but I knew I wanted TeX. Only slowly I realized that what I had in my hands was a fully alternative operating system.
Somebody in a computer store told me using GNU/Linux without being connected on the internet would not make much sense. I found that to be true. Apparently, there were new versions of the software "out there", and also more material. So I bought a modem and got connected, and found myself in a new world. Until then, I only had magazines and old library books to teach me about computers and programming. Suddenly I had access to state-of-the-art real world programming, and a huge community around it.
After getting a bit more familiar about my options, I ditched SuSE in favor for the community-built Debian GNU/Linux distribution. I liked the free software guidelines, and this step also relieved me from paying for updates. After a couple of months being a user, I started to give back by participating in the mailing lists and later becoming a Debian maintainer myself.
One year later, in 1997, I had a deeper background, and started to get interested in the GNU project and the free software foundation. I agreed with the political stance of the Free Software Foundation. GNU was a guarantee for quality. All important GNU projects were of very high quality, and I was looking for more information about it. It was at that time when I stumbled upon the GNU Hurd website.
Again I didn't know what to expect. I understood it was yet another alternative operating system. It was free software. It was done by the GNU project. It sounded interesting, and I wanted to explore it. So I made that hefty 70 MB download through three long nights and digged into it.
I was not disappointed. Although the system was full of bugs, it's design was intrigueing. I started to find and report bugs, later fixed them myself. What made me contribute was my interest in it coupled with the need and opportunity: The system needed work, but nobody was doing it, and I was interested.
I also read in the TODO file that GNU was looking for a packaging system, and with my Debian background I thought that I was the right person for the job. So I started the Debian GNU/Hurd binary distribution in 1998. Most things I worked on in that time were focussed in getting a working binary distribution of Debian GNU/Hurd.
Only gradually I did more and more work on the Hurd source code than on porting packages. This was usually out of necessity to get some application running, but the more I learned, and the deeper my understanding was, the more I realized what was missing in the Hurd and that some fundamental design problems (also in Mach) could not be fixed by some small changes here or there. I started to look at the bigger picture, and found that the fundamentals needed to be re-evaluated.
One blink later, I found myself together with others in an effort to redesign the lower layers of the Hurd from scratch, employing cutting-edge operating system design. This is what I am working on today.
The Hurd architecture
Nikolaos S. Karastathis: Please describe the Hurd system, its architecture and its main features. How the Hurd project and its L4 port started? What are the advantages of the L4 microkernel architecture in comparison with the GNU Mach microkernel and the traditional monolithic kernel approach?
Marcus Brinkmann: The Hurd is a multi-server system, running on top of a microkernel. This means that separate features of the kernel, like the network stack, authentication, or the filesystem, are implemented in different user-space processes, and not in the kernel. There are only few real multi-server systems out there, most other microkernel based systems you have heard about actually only run a single server on top of the kernel and thus are very similar to a monolithical kernel like the Unix kernel and its imitations.
The Hurd design goes one step further ahead of other multi-server systems and puts an emphasis on the user's freedom to extend and enhance the operating system with new features. There is no mutual trust required for the individual components to cooperate. So, for example, the user can start their own filesystem services and attach ("mount") them to the system's file system hierarchy. Or a user can ignore the process servers services and start their own process management facilities, that is dissimilar to POSIX.
The original motivation of the Hurd was to write an operating system for the tools of the GNU project, which was already a very complete tool set at the beginning of the 1990s. Thomas Bushnell, the lead architect, developed the above Hurd design, and implemented it based on the Mach microkernel. Roland McGrath wrote the GNU C library, which is today also used on GNU/Linux. But the multi-server design proved to be difficult to realize. Bugs were hard to track down. At the time the system became accessible and usable, the conceptually simpler Linux kernel had already many mor features and was more mature, and that is what is widely used to run the GNU tools today.
Today, the GNU Hurd on Mach is a functional prototype. There is a maintained binary distribution, Debian GNU/Hurd, which I started in 1998, and which provides thousands of programs out of the box. However, if you run this version of the Hurd, you will miss a lot of hardware support, and it is pretty slow, even by microkernel standards. It has reached a stage where we are able to take a step back and reevaluate the system as a whole.
This is what Neal Walfield has done, incorporating the results of operating system research that has happened since Mach. He identified several fundamental flaws in Mach's design that were limiting the effectiveness of the Hurd. The actual problem is that although many components like filesystems where removed from Mach, some were not, like the IPC (Inter-Process Communication) system with its message buffering in the kernel and the virtual memory management. The problem with Mach's IPC system is that you always pay the extra cost of parsing messages in the kernel, and copying them in and out of the kernel, even if you don't need these features (and we don't, usually). The problem with the virtual memory management is that Mach doesn't have enough heuristical information about how the memory is used to make smart paging decisions. A monolithical kernel knows how memory is used because it can associate it with filesystems, the network, pipes, etc. But the Mach kernel is blind to these distinctions, it has to treat all memory equal, and that leads to more wrong decisions that affect performance badly.
This is why we started to look for alternatives, and the L4 microkernel developed by Prof. Liedtke in Karlsruhe was the obvious choice. It puts the principle that the kernel only should provide mechanisms to the extreme. But this means that we had to redesign our virtual memory management and IPC system. Neal started this redesign in summer 2002, focussing particularly on the memory management, while I developed his basic ideas about user space RPC management. The basic idea is that all decisions are now made by the user tasks individually, which have the most local information at hand. For example, every task gets a contingent of physical memory, and maintains the virtual memory space itself. All paging decisions are made locally in the task. You can easily use your own paging algorithms which are fine-tuned for your application.
The higher level parts of the system will pretty much stay the same. Our changes to the IPC and memory management system are pretty radical, but as the Hurd was well-designed from the start, it only requires comparatively small changes to port it to the new base. Of course, we will take the opportunity to fix a couple of minor flaws and make some enhancements as well.
Contributions to the Hurd
Nikolaos S. Karastathis: What are your primary contributions to the Hurd and Hurd/L4 and what tools were important during the development?
Marcus Brinkmann: I have started out with creating and maintaining the Debian GNU/Hurd distribution, which involved a lot of bug hunting and fixing in the Hurd source code. After that, my focus shifted more and more to the Hurd and adding features beside fixing bugs. My biggest individual contributions are the FAT filesystem server and the console system, which implements a plugin-based console client on the basis of a UTF-8 capable detach/multi-attach console server with multiple virtual screens.
By now, I am focussing on the development of the Hurd on L4. So far I have written the capability server library and the bootstrap code. I have also started a glibc port and added some missing features to the L4 microkernel (for example, for Thread Local Storage (TLS) support). The great thing is that so much code already exists that we can draw from. We only write from scratch what is new, and port what we can take from the existing Hurd on Mach or the GNU C library. Of course, there is still substantial work involved in understanding and porting existing source code, and we always try to make it better, but we don't have to start from scratch.
Development happens in the Savannah project, using CVS as the source repository. I use Emacs to write code and manage the repository, gdb for debugging, and QEMU for testing the system. QEMU is a fast system simulator by Fabrice Bellard, I can't overstate how useful it is, even though it's debugging features are limited compared to other simulators out there. I also use the L4 kernel debugger with great success. Of course, I also use all the other tools we all use everyday, like binutils (objdump in particular). Soon you should be able to just debug your Hurd-L4 programs at the user-level via gdb over a serial line.
Size of the Hurd's codebase
Nikolaos S. Karastathis: How many lines of code the Hurd/L4 actually has?
Marcus Brinkmann: sloccount (from David A. Wheeler) says for the hurd-l4 CVS Repository:
Totals grouped by language (dominant language first): ansic: 34737 (72.90%) sh: 12815 (26.90%) asm: 96 (0.20%)
For the hurd CVS Repository:
Totals grouped by language (dominant language first): ansic: 208441 (97.01%) sh: 3937 (1.83%) asm: 2153 (1.00%) awk: 183 (0.09%) perl: 158 (0.07%)
There is also some substantial amount of Hurd related code in the GNU C library.
libc/hurd: Totals grouped by language (dominant language first): ansic: 6600 (100.00%) libc/sysdeps/mach/hurd/ Totals grouped by language (dominant language first): ansic: 14139 (98.34%) awk: 132 (0.92%) asm: 107 (0.74%)
Do those numbers say anything? Not to me at least ;)
Nikolaos S. Karastathis: For me, it means that you have done hard work ;)
Nikolaos S. Karastathis: Could you please explain whether microkernels have inherently slower performace, in general, when compared to monolithic kernels? How fast Hurd on L4 is, in comparison with GNU/Linux and Hurd on Mach?
Marcus Brinkmann: I don't even think it is true that microkernel based systems have inherently slower performance in general. As usual, it all depends on what you are doing and how. Now, it is true that if you take a traditional operating system, say, the Linux kernel, and port it as a single server on top of a microkernel (like MkLinux, L4Linux), that you suffer an overall performance penalty. In the case of L4Linux, this is 5%-10%. So, if that is what is proposed, it is obviously non-sensical.
There is also a theoretical argument that you can put all optimizations you use for microkernel based systems into monolithical systems, and that thus minolithical systems can always perform as good or better than microkernel-based systems. This is only true however if you have a certain trust model in mind, and if you only look at raw performance and and not at all the other costs involved.
Microkernels are interesting, because they offer additional features over monolithical kernels, at a better over-all cost. You exchange a bit of performance against reduced development cost, for example. Consider security: Is it feasible to suggest that a monolithical kernel can be proven to be correct? Unlikely. But it is at least feasible to make an attempt to prove a microkernel to be correct, and maybe a subset of the operating system built on top of it (this is what the Coyotos project is about).
In the Hurd, our motivation is flexibility. We want to soften the hard distinction between system and user code that exists in Unix, without compromising security as you do in totally open systems. The additional security features of a microkernel-based multi-system are a lever to user freedom for us. For this, we are developing protocols between components that do not rely on mutual trust.
So, if you look only at raw performance of monolithical systems, and only consider what monolithical systems can do for you, all microkernel based systems look bad. But if you look at what microkernel based systems can do for you, monolithical systems look even _worse_ because some things you can do in microkernel based systems you can not do at all in monolithical systems, and for other things the costs to attempt to do so are prohibitive.
So, what about the Hurd on L4? We have no idea, as we don't even have a complete system yet. We know that some operations will be slower than the same operation on a monolithical kernel. But then, we will provide features that you just don't have on a monolithical kernel. For example, tasks will make their own paging decisions. To take full advantage of these features, modifications to the application may be necessary. Still, the beauty of the Hurd is that it found ways to allow for such modifications as enhancements in the context of a POSIX compatible operating system. But I just don't have any numbers at this point.
Security in the Hurd
Nikolaos S. Karastathis: Computer users are more and more concerned about security and stability. Was inherent security a priority during the development of the Hurd and its port to the L4 microkernel? How stable the Hurd and Hurd/L4 are? How the system responds to crashes and deadlock situations, does it use garbage collection or semaphore techniques?
Marcus Brinkmann: Security and stability are tightly related issues, and they are major motivations for any microkernel based system. However, we feel that security does not need to translate to loss of freedom. With a bit of extra trouble, you can be secure and even increase the freedom of the user. This is what we want to do.
In the Hurd, the operating system is implemented as a set of servers, and each runs in its own address space. Of course there are some essential system services which better not crash, or the system will reboot immediately as a last attempt to salvage the situation. But for many other services, a crash is not fatal. If a filesystem server crashes (except for the root filesystem), you can just restart it (or it is restarted automatically by the system). Dead-locks require manual interaction, and you will have to kill the hanging server to remove it from the system and release associated resources.
The Hurd achieves its stability and security by protocols between components that require no mutual trust. So, although a user can add their own filesystem to the filesystem hierarchy, and the parent filesystem will redirect accesses through such a mount point to the user's filesystem, there is nothing the user's filesystem can do that can affect the rest of the system in a bad way. The Hurd servers are written in a way to assume the worst from a communication partner, namely that it is malicious, as an implication you get fault-tolerance for free.
Of course, the real world is always a bit different from the theory. The current code base still has many bugs, and some minor design flaws that make the system suspectible to attacks, especially denial of service attacks. Some of them will be fixed with the port to the L4 microkernel as part of the redesign. One thing we may not get right from the start are resource quotas - they are not a very interesting problem, but a lot of extra work. IMO, that can be added later if the fundamentals are right.
About hardware drivers
Nikolaos S. Karastathis: Please describe how a programmer can write a hardware driver for the Hurd and its L4 port. What do driver developers need to know about Hurd internals? Is it possible to port GNU/Linux drivers on the Hurd and Hurd/L4?
Marcus Brinkmann: We consider hardware drivers to be somewhat outside the scope of the project. In particular, we consider hardware drivers to be trusted system code. So, we do not have theories about "Hurdish drivers", or orthogonal ideas like direct hardware access from applications a la exo-kernels. So, we have started a second project for a device driver framework, but that has not yet advanced very far. There is a device access server which will wrap up the device driver framework in a Hurdish manner. This allows you, at least in theory, to plug different driver frameworks into the Hurd/L4 system.
The reason is not that there is nothing interesting to do with device drivers these days. In fact, using L4 primitives for driver development seems to lead to great simplification of the code, and it is also a lot of fun. But there is a lot of diverse hardware out there, and realistically you need to prepare to be able to just glue in existing drivers into the system via some controlled mechanism, and so it doesn't make sense to provide huge abstractions for them.
However, we are careful to get the most out of the driver framework. In particular, our container mechanism will allow zero copying transport of data between the driver and the user.
So, driver development is pretty much independent of the Hurd, unless you want to write the glue code. There are a couple of interesting projects to glue Linux drivers into an L4 environment, but we have not really investigated those yet.
Advice for new programmers
Nikolaos S. Karastathis: I am sure that many of the people who read this interview are considering becoming programmers. Could you please provide some advice for aspiring software developers? Do you think it is better to learn many programming languages at once, or just stick with one language and learn it extensively? What are the most important qualities that programmers should possess?
Marcus Brinkmann: You should have a look at as many different languages as you can get hold on (and as you have time). Also for all other tools. You can not get proficient in all of them, or even any substantial number, but you should know your way around them and expose yourself to as many ideas as possible. However, note that a language is merely a tool of expressing your ideas programmatically. As every other tool, you need to learn when and how to apply it to a given problem. And as with every other tool, it can help you or be in your way.
To become an expert programmer, you need to know what tools are available, but you also need to pick some tools that suit your needs particularly well and become good at them. So, for some languages you will want to learn them really, really well. Unfortunately, as so often in life when you leave the plane of abstraction and get down to the details of the implementation of an idea, tools like compilers cease to be black boxes. When you become a better programmer, you will be exposed to implementation details about your tools, including the hardware of your computer, that you never wanted to know. For example, you will start to worry about things like in which pattern your program will access memory, and how that interacts with the CPU's memory cache. You won't find this knowledge in most books. The best way of learning this is by doing and experiencing it.
Here is an example from the real world. Many years ago I bought a PDA with GNU/Linux on it, the Agenda VR3. The device had many problems and was not very successful. One particular problem was that the calendar function was very slow. Somebody profiled the code and found out why. It happens that the calendar used the bits in an integer field as flags, that's a standard idiom. But instead using the shift operation "1 << n" to access the individual bits, the programmer used the math function "pow (2, x)", and on that architecture, all floating point arithmetic was just painfully slow. We don't know what the author of that code thought. Clearly, the code was "correct" in that it achieved the goal. Maybe the programmer thought of pow() as a black box. Maybe he knew that he was using floating point arithmetic, but thought that the compiler could optimize it to a shift operation. In this case, the author didn't know the language and his compiler good enough (if I recall correctly, the type casting rules prevented such an optimization).
This illustrates that the most important quality of a programmer is to visualize in your mind what the computer is doing when you give it certain instructions. This is important both to be confident that your code is correct, and at a greater level of detail to give a good estimation of your code's performance when it is actually compiled into a program and run. Most programmers are notoriously bad at predicting the efficiency of their code. The better you know your tools, and the more experience you got, the better will be your ability to say with confidence what the computer will actually do with your code, and you will be able to fine tune your program to make the system behave more the way you want it. Of course, on a global scale, you will need profilers and debuggers to help you with this.
I want to add one more thing: You program for a machine, but you also program for human beings. Never forget that. Even the best performing code can be useless if no human can figure out what it is doing and why it is doing it the way it does. So, another important quality is that you can write documentation and good comments into your source code, and that you can structure your source code in a way that it is accessible to your fellow developers. Most of the important programming in the world today is a team effort. Read high quality source code to pick up common idioms and follow coding style guidelines.
Participating in Hurd development
Nikolaos S. Karastathis: How can a developer join the Hurd and Hurd/L4 projects? How open the Hurd development process is? Please provide any information you deem necessary for free software developers who would like to participate in the project.
Marcus Brinkmann: You do not "join" the Hurd like you join a club. You just take part in it. Only few people have access right to the CVS tree, and we do not add every contributor, but instead review patches and add them to the tree when we are happy with them. This is a high barrier, but many patches get first applied to the Debian GNU/Hurd package of the Hurd, where they are tested. Our FAQ describes how we would like patches to be formally. I would suggest you join the mailing lists and announce what you want to work on.
We do require that contributors assign the copyright for their changes to the FSF. You will see that more and more free software projects will make this requirement. The FSF has always cared about defending the copyright and integrity of its source code base, but other groups and people will start to realize how important it is as more and more license violations occure by integrating free software into proprietary systems, and as free software comes under attack by fraudulent copyright claims.
That said, the Hurd has a steep learning curve, because of its multi-threaded multi-server design. So, you have to expect to do a couple of months of studying and learning until you can take on bigger projects. But even that can be fun, especially if you combine it with simpler tasks like bug hunting. But for competent programmers it is also an opportunity to pick up a lot of knowledge that is not available in many other projects.
Nikolaos S. Karastathis: What the future holds for the Hurd and its L4 port? Especially for Hurd/L4, where will the development effort be directed now? What are your own personal plans for the future, outside Hurd development?
Marcus Brinkmann: On the Hurd port to L4, we are really turning everything upside down and try to fix the fundamental issues that have cropped up in the Hurd on Mach. We are taking the "do-things-in-untrusted-user-space" design paradigm to new extremes, and try to find new solutions to old problems, like proper resource allocation. For example, on GNU/Linux, if you start to burn a CD, and then try to play an audio file, the audio file skips and jumps. Although the audio file only requires a little bandwidth, it needs it at the right time. The CD burning process interferes with that. This is a problem as old as operating systems, and there are no known proven solutions, just research and some ideas that we will try out because they fit into our overall design.
Because we are building a capability based system, we are also facing the same issue as every other capability system: How to implement secure capabilities in a microkernel in an efficient way? This is also a question to which there is no definite answer yet.
These are the fundamental issues we are facing. On top of the right primitives, we can then port the POSIX personality of the Hurd with only few changes.
Nikolaos S. Karastathis: Thank you very much for your time. Please keep up your good work on Hurd/L4!
The text of this article is Copyright (C) 2005 by Marcus Brinkmann and Nikolaos S. Karastathis. Verbatim copying and redistribution of the entire text of this article are permitted provided this notice is preserved and a reference to its original location http://portal.wikinerds.org/brinkmann-interview-mar2005 is provided.
(The notice above does not apply to images)
- French translation of the interview
- Marcus Brinkmann Home Page
- FOSDEM 2005
- Free Software Foundation
- Free Software Foundation Europe
- Richard M. Stallman Home Page
- The GNU Project
- The Hurd Project
- The Hurd on L4 Project
- The L4Ka Project
- Jochen Liedtke
- In Memoriam Jochen Liedtke
- The Hurd Wiki
- Gnuppix (downloadable bootable CD image of Hurd/L4)
- OSNews.com story and discussion (thank you, Eugenia Loli-Queru)
- Kuro5hin.org story and discussion
- Slashdot.org story and discussion
- Colour Hurd logo (hurd-logo-sm.jpg): Made by Teddy Hogeborn, found at gnu.org. In a private email to NSK, Teddy Hogeborn indicated that this image is in the public domain (download source files).
- Debian logo (banner_64.gif): Made by someone at linux.com, found at debian.org.
- FSF unofficial logo (fsf-wh.png): Made by Shawn Ewald, found at gnu.org.
- Colour GNU head (reiss-head-sm.jpg): Made by Joseph W. Reiss, found at gnu.org.
- Monochrome Hurd logo (hurd_sm_mf.jpg): Made by Stephen McCamant, found at gnu.org.
Notice: Links and images embedded inline in this article's page were selected by Nikolaos S. Karastathis. All images are Copyright (C) by their creators. This publication was not endorsed/approved by the Free Software Foundation or any other organisation referenced in the article. Linux is a trade mark of Linus Torvalds. All other trade marks are the properties of their owners.
Don't forget to check the home page of our site, Wikinerds Portal, where you can find more articles like this!