On Jul 24, 2008, Marko Vojinovic <vvmarko@xxxxxxxxxxx> wrote: > As far as I know, the purpose of a kernel is to abstract the hardware layer > from the userspace software (this is of course an oversimplification, but I > believe it is sufficient for making the parallel). Yup. In fact, there are several layers of abstraction at work here. I don't see anything that makes this particular layer of abstraction any more special or relevant than others. So that remains to be justified, especially in the light of: > the kernel "does the essential work" (actually, it communicates > further to the hardware that does the actual work, but that is > abstracted out). Nevermind that what you "essential work" here is hardly perceived as such by users. What do they care that there are multiple CPUs there that need a task scheduler, or how files or even filesystems are laid out on disk, or how interrupts and DMA are handled? They just want to browse the web, read their e-mail, play their movies and songs, write their texts, prepare their presentations, perform their High-Performance computations, run databases, serve out files, etc. *That*'s the essential work for *them*. The kernel, like so many good administrators, works behind the scenes, imperceptibly, doing work that others perceive as irrelevant, but that is indeed very important for the whole system to function, but that is most definitely not the end goal of the system. I'd concede to qualifying it as *an* essential part, but not as *the* essential part. In good teams, every member performs an essential task, and if you take any member out, the team gets a severe hit and may even become completely dysfunctional. Every member of such a team might claim to be the most important, because his/her removal would have such a severe impact, but the conclusion would be that *all* of them are *the* most important, and this doesn't make sense. I don't think that this is the kind of measuring stick we're looking for. > The parallel is simple --- the car engine is also the one "doing the > essential work" (converting fuel to mechanical --- ie. usable --- > energy). Converting fuel to mechanical energy is hardly what most people who purchase a car are interested in. In fact, I'd say that if someone purchases a car and get just an engine, and customer support goes "hey, the engine is the essential component of a car; Marko Vojinovic says so" it wouldn't get very happy customers. Very few people actually care that there is an engine in their car. Or a motor. Or both, for hybrids. Or propellers, jet propulsion, magnets and superconductors, magic powder, whatever. Converting energy is not the purpose of a car, and it's hardly even a relevant part of the user experience. People buy cars to drive to places, not to convert fuel to mechanical energy. People expect cars to have some steering and speed controls, seats, lights, and that's about it. Which is not to say that the engine is not relevant for today's cars. It is indeed very important. But, as you said yourself, many components are so important for a car to work that, if you take them out, it won't work any more, and the engine is not a part of the user experience that the user cares about. So how can we support the claim that the engine is the most important part? Or, avoiding any imperfections introduced by the analogy, how could we support the claim that Linux is the most important part of a system of which it is a kernel? > Consider a simple situation --- take a Fedora distro, and remove all > GNU utilities. The system will lose much of its functionality, but > not all. Do you have any evidence to support this claim? I very much doubt it, and I invite you to give that a try. I get the impression that you don't have the faintest idea of how extensive the GNU project is, and how extensive the reliance of the whole system on GNU software is. You wouldn't wave it away so easily if you did. Please "show me the code", as I'm sure you heard before, most often without the 'please', given the, erhm, source :-) > Some hypothetical userspace program could still be able to > communicate to the kernel and do some useful work. Indeed, you could boot up the kernel and have it run this hypothetical program as init. Nevermind the details of how you actually managed to compile, assemble and link this program into something that can issue system calls without GCC, GNU as, GNU ld and GNU libc. For the sake of the argument, let's assume you coded it by hand, in binary, directly into an ELF static executable, or that you used some other toolchain, and some other library that is far more limited but that serves your purpose. Great, it can probably do some useful stuff, such as printing Hello World, running a firewall or, to cite the example of the engine, converting electrical energy into heat. Or rather getting the microprocessors to do that because, you know, it's not the kernel that actually dissipates power, this actually happens several layers down in the abstraction stack. If you get a cluster of machines running Linux and this hypothetical program of yours (combined with this library it depends on, if any), you'll have a very good (and expensive) furnace :-) Now... Would anyone still recognize that as this system we're talking about, that people mistakenly call Linux? Would a kid on Jurassic Park, looking at such a system, shout "hey, that's Linux!"? I doubt it. Oddly, this would be one of the rare circumstances in which this assessment would have been correct and fair. And, even more oddly, this system would be missing nearly every major feature of what people recognize as features of this system, just like an engine by itself would be missing nearly every major feature of what people recognize as features of a car. == Defining features So let's think for a moment (or many moments) about what the defining features of this operating system are, what the common features shared by most recognizable instances of it are. One could start from the upper layer, since that's what's most visible to typical users. Applications such as OOo, Firefox, Thunderbird, etc, and servers such as bind, Apache http server, MySQL, Samba and Sendmail, are hardly defining features of GNU+Linux systems. They run on many other Unix-like systems, and some of them run even on Unix-unlike (dislike? :-) systems. Besides, although some of them are obvious leaders in their categories, even for those there are readily-available alternatives, so even those who need that major feature won't necessarily run these specific programs. Thus, while these are no doubt very important for the users that rely on them, they're not defining features, that make these systems what they are, that set them apart from other systems. Going down one layer in the graphical applications, we could go for say Gnome. This one happens to be part of the GNU system, and an important part of it. However, as users and developers of KDE, XFCE, WindowMaker and of various other low-footprint desktop and window managers would promptly argue, Gnome is not an essential part of the system, as in, you can refrain from installing Gnome components and nobody would dispute it's not a distribution of this system we're talking about. And then, again, Gnome, KDE and others do run on other Posix systems as well, so you can't just look at a screenshot of either one and have any certainty whatsoever that it's "our" system. One layer below that is the X Window System. Ok, ok, you on the back, there are gtk+ and qt and others in between; the same arguments as those to Gnome and KDE apply, so I won't go into that for the (futile?) sake of brevity :-) X was originally designed for Unix systems, long before such a thing as POSIX was even a theoretical plan, so claiming it to be a defining feature of our system would be quite a twist. Heck, it preceded the start of the GNU project for several years, and thus Linux for an even longer period. When the GNU system was deciding how to go about graphical user interfaces, it found that X11 was there, was available, and was under suitable terms. So the rest of the GNU system was designed to use it, like a number of other smallish components that spared the GNU developers from a bit of the total effort. Evidently, X can't be a defining part of GNU, let alone GNU+Linux (even if you call it Linux), since by looking at it you can't tell what's the operating system underneath. It runs on so many of them! And then, for people who run the relatively common headless servers, for their remote administrators, and for the relatively atypical user who most often stick to textual-interface applications, X is mostly, when not completely, replaceable by the CLI. Going by the same reasoning of availability on other Unix-like systems, we could take out most of the other programs, applications, scripting languages, CLI interfaces, and even libraries. Nearly all of them will run perfectly well on top of other systems. GNU libc will run perfectly well on top of other kernels. Some might be tempted, at this point, to claim victory for Linux, as the last standing component, and conclude that it is the defining feature of that system, even though we'd already established that it, by itself, wasn't even recognizable as the system. But wait! Taking the same reasoning we used to discard applications on the other end of the spectrum (that they could be easily replaced by alternatives) and other components all the way down, and taking the very argument we used to discard GNU libc as a defining feature (that it could easily target other kernels), we'll realize that Linux is also replaceable and retargetable. Indeed, you can just put another kernel in its stead, and pretty much nobody will even notice a difference. Furthermore, you can use it along with uClibc and newlib, or in the scenario of the library-less init proposed several pages above. (hey!, the subject said *long*, you were warned :-) The only reason we got the impression that Linux might be a defining feature is that we went top-down, so we looked at it last. Had we gone the other way, we'd have discarded it first, and at the end, should we cut the reasoning short (IOW, stop thinking when we reached an answer we found satisfying), we'd conclude that OOo, Firefox and Apache http server are defining features of our system. Unsurprisingly, some people do present this argument, and even defend it as if it made any sense. But it makes just as much sense as concluding, from this reasoning, that Linux is the defining feature of our system: none whatsoever. However, if we do not stop thinking just because we found an answer we're happy with, we're left with *nothing* as a defining feature. That's absurd, so something in the methodology we used must have been wrong. We must have been asking the wrong question, since the answer we got was 0, rather than 42 :-) == Impact of replacement It should be clear at this point that there's no single program or feature that defines the system. Like many complex systems (or teams), it is a set of components, some essential for most, some redundant but still essential for very many, and some clearly less relevant. So I propose that, instead of going about trying to determine one single component that makes the system what it is (we've already failed at that), we look at the system as a whole (as fuzzy as "whole" is defined), and then try to determine what impact, if any, the replacement of any of the components would have on a statistically significant sample of users of the system. The assumption being that, the larger the impact of replacing that one component, the further the system becomes notably different from what it is. IOW, a component that, if replaced, would make the system "very different" for "many users" would be regarded as more defining than a component that, if replaced, would hardly raise an eyebrow from any user. The more you (or rather many users) can tell there was a difference, the more defining the component is. So let's start again from the top. Desktop applications, as important as they are, are hardly irreplaceable. In fact, the efforts of Gnome and KDE have pretty much ensured that, for every major need of desktop users, there are at least two major applications that can fulfill that need. Of course there are minor variations in the feature of set of each application. Of course in some cases that are multiple overlapping applications that target the same desktop environment, and even some that aren't part of either. This means the impact of replacing say OOo with Abiword+Gnumeric+etc or KOffice, Firefox with Epiphany or Konqueror, Thunderbird with Evolution or KMail, etc, could affect a large number of users, but that it is unlikely to remove an essential feature for a large fraction of the total number of users. Likewise Desktop environments. They would definitely be missed by users who prefer Gnome over KDE or vice-versa, or those who prefer lighter-weight desktop/window managers, but an average user would hardly feel the system to be fundamentally different, or even totally unusable, when playing with say a Gnome-only or KDE-only LiveCD release of our system. Now, the X Window System is much trickier to replace. In spite of its being a relatively small portion of the entire system, the unavailability of a GUI, that depends entirely on it, would have a major impact on most users, and there's no viable replacement for X that I'm aware of. Sure, one could list various forks of X, but these all have the same heritage, so I wouldn't count them as actual replacements, certainly not complete replacements. They're more like variations, in a way like different major versions of Linux, or say Linux vs uClinux, or perhaps one *BSD vs another (-ENOCLUE for this last one, but I'll take the risk and assume they do have a large shared heritage; apologies if it is not so and someone takes offense at the implications :-) Even headless-system administrators (note the dash, angry headful but attentionless sysadmins! :-) would miss the ability to use X applications tunneled over SSH every now and then. Hard-core 100% VT "why would I ever want all this fscking xorg-* junk on my disk (or some even more, erhm, polite wording)" users are very rare, so we can count X11 as a highly-defining feature of the system. Database, smtp and http servers, there are several. Sure enough having to drop say PostgreSQL, Sendmail or the Apache http server and use some other server in their stead would be a pain for people with highly-customized scripts or configurations. But users with high customization levels *and* inability to obtain required features from other similar servers are probably the exception, rather than the rule. SMB and NFS servers are a bit harder to replace, but then again, although they're certainly essential for a significant number of users, missing them would turn the system into "something else" or into "unusable" for no more than a small fraction of the total number of users in our sample. Now, let's have a look at GNU software. All of it! I don't mean GPLed software (many are not GNU software, e.g. Linux itself, and not all GNU software is GPLed), I don't mean all software that is regarded as Free Software (yeah, GPLed is not the same as Free Software is not the same as GNU software), I mean the programs that are available from ftp://ftp.gnu.org/pub/gnu/, or listed there as part of the GNU system but offered for download elsewhere. These are the components of the GNU system. It's a *lot* of software. What if we set out to replace it all? Well, we'd have a lot of work ahead of us. Sure enough, replacing one component or another shouldn't be too hard. You could use newlib or uclibc instead of GNU libc, for example, although these are quite feature limited, for their focus on embedded systems, and so much software will fail to run on them, for depending on features that are missing or incomplete on them. You could use some other toolchain to rebuild everything with this other library, but you'd probably find out a significant amount of build machinery requires features from GNU make, GNU Compiler Collection (GCC), GNU ld; sometimes their build scripts also depend on GNU bash, GNU awk and GNU sed extensions or quirks. And then, some program's source code relies on extensions present in GNU CC, GNU libc, GNU as and GNU ld. Patch, patch, patch. Would the result of all that work be Apach[ey] operating system? :-) Once you replace GNU bash, GNU coreutils, GNU awk, GNU sed, GNU grep, GNU find, you'll certainly find out that a lot of software breaks. The system might even fail to boot up, since so many of the rc scripts used on this system we're talking about rely on extensions offered by the GNU implementations of these programs. You'd have to fix the scripts, or add support for GNU extensions to your replacements. More patching, or actual development. Now, it's obvious that it *can* be done. It doesn't even have to be done all at once. Indeed, GNU software was built just like that, one component at a time, each one replacing one of the components of the non-Free operating system on which GNU is inspired in, but is not. That was the most sensible approach, and, for the hypothetical efforts discussed herein, it would work just fine, even if it would take a while. However, because all of these GNU components were also developed to work together, and to work along with other preexisting Free Software components that the GNU project decided it didn't make sense to reimplement, they all work well together, and they rely on each others' idiosyncrasies, quirks and inconsistencies and extensions. Furthermore, as Linux developers decided to adopt all this software and use it along with the kernel they had created, to spare themselves from having to duplicate all that work to have a complete operating system, they found that a number of small pieces were necessary to get them all to work together. These pieces were thus developed within this environment that combined GNU software and Linux. Just like Linux itself, these other pieces were created dependent on GNU infrastructure, and only recently did it become possible to use Linux with other low-level libraries instead of GNU libc. That said, even distributions that adopt such alternate libraries still include a significant number of GNU components to make for a complete functional system. Therefore, if one set out today to replace all GNU software from our system, one would be have a lot of development work ahead to get back to a functional system. Certainly not as long as the 7 years it took GNU to get to the point where the kernel was the only major missing piece, for nowadays there is much more BSD and OpenSolaris Free Software that can be used as a starting point for several of the smaller components, but it would be a lot of work nevertheless. But until this effort was complete, users would notice the difference. Replacing all GNU software would render the system unusable, even unbootable, for nearly all users, until replacements were developed or dependencies on GNU features and extensions were fixed, which would take a lot of work and a long time. To the best of my knowledge, nobody has ever succeeded in, or even tried, anything like this. Now, let's look at Linux-specific software. Rather than going for the simpler "Linux is a kernel" approach, I'll concede to regarding some of the low-level programs and scripts developed specifically for the combination of GNU with Linux, but turned mostly towards the kernel, as Linux-specific. Say, programs to create and manipulate filesystem types that are implemented exclusively or at least originally in the Linux kernel, Linux-specific basic utilities (linux-util-ng), device-mapper and LVM, mdadm/raidtools, SELinux, boot-up scripts that rely heavily on Linux-specific /proc and /sys contents, and even all the effort that went into porting GNU and non-GNU software for it to run on this system we're talking about. Putting this all in shape and together was no doubt a lot of work. It is self-evident that there is merit in that, and that a Free kernel and all this work that completed and provided us with the first fully-functional Free operating system calls for our gratitude and praise. And, boy! or girl! Erhm. And, young human! :-), do they get enough of it! But, getting back to determining the impact that replacing the contributions of this project would have on the whole system, we'd find out: not so much. As mentioned before, some people have already shown this to be true. People took entire distributions of our system, replaced as little as the kernel and a few low-level applications with their counterparts in OpenSolaris or FreeBSD (or, surprise!, in the GNU operating system itself), configured the replacement kernel to emulate Linux syscalls or rebuilt GNU libc to target the replacement kernel while exporting the same ABI as before, and got functional systems! Not so much when using the Hurd, unfortunately; it's still suffering the consequences of unfortunate mistaken decisions and lower priority. But the other two are hardly distinguishable from their baseline, full-featured distros based on our system. Users can hardly tell the difference. Nearly-zero impact. Others actually went through the trouble of rebuilding all the software on top of this replacement kernel, which spared them from some adaptation layers in GNU libc, presumably getting them slightly better performance. Little to no trouble to doing that, and little to no perceptible changes for users. == Conclusion Summing it up, GNU is far more "irreplaceable" in the whole system than any other component, including the kernel Linux. Second to it is X, which happens to have been adopted early on to play this role in the GNU operating system. Linux developers deserve credit for having provided the last missing pieces, but it is not reasonable to pretend they did all the work, or even the largest part of the work, or even the most important part of the work towards the fully-functional system. They completed the last piece first, indeed, but their last piece is hardly essential to the system any more, i.e., it's easily replaceable. Conversely, the pieces they created depend heavily on GNU, just like the rest of the system. So, please give the GNU project the credit it deserves, and help us spread the philosophy that justified its development and provided us with the largest and most irreplaceable portion of the GNU+Linux operating system. Please don't refer to it as just Linux, no matter how many others make this mistake. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} FSFLA Board Member ¡Sé Libre! => http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} -- fedora-list mailing list fedora-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
