Preinstalled Hurd Now Available

Roger_Wilco writes "The GNU Web site is announcing that Spacetime Systems will now install GNU/Hurd as well as GNU/Linux. Hurd is Object Oriented, unlike Linux, so it may be a superior system in the long run."

Comments

Huh?

[Rombuu]

Hurd is Object Oriented, unlike Linux, so it may be a superior system in the long run.

Huh? Why would you say something like that? I mean I can see arguing microkernel v. monolithic kernel archetectures, but saying an OS is better than another due to its programming methodology?

Besides in the words of John Maynard Keynes, in the long run, we're all dead.

To head off some of the bashing (hopefully)

[Gokmop]

This is very, very cool. The HURD is awesome, and I for one am going to be following it very closely as it develops.

For all of the people who are now going to bash the HURD as completely useless and still in development, keep in mind that linux was once at the point that the HURD currently is. It's in development, there are probably more things to be implemented than things that have already been implemented (although any developers feel free to jump in and comment at length about the status relative to the long term goals of the project) but the project is VERY cool.

It doesn't *compete* with linux in the way that you might think - it's sort of a UNIX, but it's based off of the Mach microkernel, which is a very different way of going about operating system design than your typical UNIX.

Let's face it, of course linux rocks, but in terms of operating system design concepts, linux really didn't change much, it just took ideas that were already out there and created an excellent implementation of said ideas. The HURD on the other hand is based on a different worldview of operating systems and has a lot of promise.

Besides, how bad can it be to have another choice for an operating system? You don't have to use Linux, BSD, Win95, or HURD, but it's good to know that the choice is out there. Personally, I don't know if I'm ready to join the HURD, but I'm watching the code, and I plan to jump in and contribute where I can.

And to all you people who say that the term GNU/Linux is a total travesty of fairness on the part of the FSF, the HURD is pretty much the last component of the GNU system that is needed. Whether they choose to call that GNU/HURD or just HURD is up to them, but if you look at the HURD in terms of the framework of GNU's work, it explains a lot about why Stallman wants to call Linux GNU/Linux. (And I agree with him)

Re:To head off some of the bashing (hopefully)

[Eythain]

And to all you people who say that the term GNU/Linux is a total travesty of fairness on the part of the FSF, the HURD is pretty much the last component of the GNU system that is needed. Whether they choose to call that GNU/HURD or just HURD is up to them.

Wouldn't the name be GNU? The GNU project (Gnu's Not Unix), was designed to make a complete Unix replacement (forgive me for saying so, but a good thing Linus came along, or we'd still be ten years away from the revolution (kidding!)).

The Herd would be the long awaited final component of the FSF's GNU project, and RMS for one has certainly stressed that the kernel is merely a small part of the OS, so calling it GNU/HURD doesn't make sense from that perspective. Using the name of the kernel for the OS is the Linux way.

-- Eythain

Re:To head off some of the bashing (hopefully)

[pb]

Your post was wonderful and fair until you mentioned the incredibly stupid "GNU/[blah blah blah]" flamewar.

First, some "facts" about Linux. Linus didn't even want to call it Linux, or GNU/Linux, or Bob, or anything. In his mind, it was probably originally called "386 protected mode assembly tutorial", and eventually grew into an OS kernel. He did mention that he wanted to call it FreaX, or something silly like that. The guy on the ftp archive said "Nah, that's a dumb name. His name is Linus, I'll call it Linux." This is all paraphrasing what I remember about the subject -- feel free to post more detailed accounts of this story if you wish.

Second, once development really got going in C, and Linus managed to get gcc running under Linux, he was grateful enough that he GPL'ed the Linux kernel. Linux is essentially an excellent GPL'ed, Unix-looking OS kernel, which can be used to fulfill the final bit of the GNU project. Calling Linux GNU/Linux makes about as much sense as calling GNU GNU/Linux.

Linux can also be used with many other free and commercial packages, but is not dependent on them, as it is an OS kernel. If you wanted to, you could probably run iBCS, and use FreeBSD or SCO or Solaris's system tools. Most people would rather just compile the GNU ones, but this is a distribution issue, not a kernel issue. Even so, we don't name the kernel or the distribution by the name of the packages within. Otherwise, the full and accurate name of my modified Redhat 6.0 distribution would consist of about 494 separate names, not counting anything I compiled myself. That's a long name, and unless you're writing the new Sumerian Unix epic poem, I don't recommend doing so.

Finally, if you're stupid or arrogant enough to call the OS kernel GNU/Linux, or the distribution "a GNU/Linux system", why stop there? How about "GNU/RedHat 6.1", even though the GNU project has no real corporate association with RedHat? (they didn't merge or anything, guys)

The GPL cuts both ways. We can use your software, and we'll give you your source, but the GPL doesn't include any "advertising clause". Is this what you want, RMS? The good old BSD license provisions to protect you?

How about a new license, the JPL, for "Jealous Public License", requiring any program or collection of programs to clearly state all the programs or projects involved in its name, regardless of how stupid, inane, or non-marketable the resulting name sounds? If using the GPL for your software isn't enough for you, does that sound inane enough for you, RMS? (*please* don't take this seriously. I *beg* of you.)
---
pb Reply or e-mail; don't vaguely moderate.

It seems to me

[BaptistDeathRay]

that as long as a software project is intelligently planned and developed, it really doesn't NEED to be OO. OO programming has some advantages to development (especially when it comes to designing a UI) but its main advantage is that if you use OO programming you MUST be more careful in your design (in order to really get any benefits OO programming gives you).

As far as I understand, the Linux kernel is very consistently thought out and new additions are considered very carefully before being implemented. So is there any really significant gain to an OO kernel?

+----------------------------------------------- -------

Re:It seems to me

[hey!]

you use OO programming you MUST be more careful in your design (in order to really get any benefits OO programming gives you).

Object oriented design gives you more dimensions in which to design -- thus more opportunities to screw up, as well as more ways to simplify projects.

I'm curious exactly what it means for an operating system to be object oriented. Unless you put a very precise definition on it, anything can be called object oriented. It used to be people tried to say that you need three different things to qualify: encapsulation, inheritance and polymorphism.

Encapsulation is a snap for any OS worthy of the name. For files, you can work at the file descriptor level or the file handle level. Very few applications work by setting device registers these days. Unix does a nice job of stretching the file abstraction fit over things like serial ports.

Inheritance is a tricky one. I can see some interesting things such as abstracting out different kinds of files. Unix basically provides only a couple of different primitive file types, but it would be interesting to be able to create subclasses of random addressible files for indexed files, balanced b-trees etc. At this stage it kind of blurs the line between the operating system, utility libraries and applications.

Is this a good thing? It beats the hell out of me. It might be pretty cool. I think, for example, that Reiser FS is interesting because it allows you to efficiently create data structures that normally would require specialied file structures using standard filesystem operations. This extends the range of simple scripting type applications. On the other hand, once you start subclassing well understood objects such as files and directories, some of the simplicity of using a well understood model such as files/directories goes out the window.

What?!

[Ledge Kindred]

"...Hurd is Object Oriented, unlike Linux, so it may be a superior system in the long run."

I'm sorry, usually I try to stay away from straight-flamage type comments, but I can't help myself this time.

What the hell is that statement supposed to mean? What makes an "Object Oriented" OS "better" than another that's not "Object Oriented"? What do you mean by saying the OS is "Object Oriented" anyway? By extrapolation, does this mean we can now definitively say that since C++ is "Object Oriented," it may be a superior language to C in the long run? (And if so, is Hurd written in obviously superior C++ or obviously inferior C?)

Hurd goes about supplying services to the system processes and end-user in a different way than Linux does. They're different. That's it. End of story. If you think "the way Hurd does it" is "better" then fine, that's your opinion. Better people than you have had similar opinions; go search the 'net and find that legendary exchange between Torvalds and Tannenbaum regarding why a microkernel is superior and why Linux is doomed to failure because it's monolithic.

This is one of the most incredibly content-free, flame-inviting statements I've seen in the main body of an article on /. for a long time.

-=-=-=-=-

Re:What?!

[be-fan]

Object oriented means that the system uses objects to communicate with servers. And it is FAR superior to non OO systems for many reasons.
1. It naturally fits the server/client model. The app essential "logs on" to the object, which serves as a client to the server. For example, BeOS (which is totally OO) uses several graphics objects to manage the connection to the graphics server. This connection is buffered, and several functions have to have access to the buffer. This is possible in C, but so much more elegant in C++.
2. It allows the system API to be consolidated. Draw() called inside a window can mean different things than Draw() called in a bitmap. (Ideally, this kind of system needs the kind of object services in VisualC++ since remembering the parameters becomes harder.) Not only is this more elegant, it is easier to learn.
3. It allows system APIs to evolve more easily over time. Ever program windows and call the DirectDrawCreateEx or CreateWindowEx functions? They are a waste of code space. You don't need thoe kind of hacks in an OO system. (The functions in IDirectDraw7 and IDirectDraw work differently, but have the same name.) I also think it may reduce code bloat over time since it is so easy to extend an old object by inheriting it in a new one. This way you shave of a lot of overlapping code.
4. It is very condusive to multithreading. Use BeOS for 5 minutes and wonder at the way it can play 12 MP3s in reverse while copying a large file while effortlessly moving through the desktop. The system never feels like it is working hard at all. Part of it is that the OS is very clean and efficient, but its also the fact that these different jobs use different resources. When copying a file, very little processor is required. But if the OS is not heavily multithreaded, the copying will slow down the rest of the machine becase the copy thread is just waiting for the harddrive.

Re:What?!

[Anonymous Coward]

"But if the OS is not heavily multithreaded, the copying will slow down the rest of the machine becase [sic] the copy thread is just waiting for the harddrive."

You're obviously not a programmer, just a user who was a little too taken in by Be's marketing department, so I'll ignore the artificial distinction between "multithreaded" and "heavily multithreaded" that you made (presumably prompted by Be marketing literature). Instead, I'll merely point out how linux handles the situation you gave. The copying process (or thread) is waiting on the disk, so it is no longer on the runqueue, and is not considered for scheduling until the disk is finished. Since it is not on the runqueue, it does not affect the processes that are.

In laymans terms, linux, and windows NT both behave this way. Be's (exagerated by many) snappiness is a result of being well written, not simply because it is in C++, or has a lot of threads all blocked doing nothing.

Just because Be forces programmers to use a lot of threads doesn't make it any easier for Be Programs to break up large tasks into parallel threads. Linux and NT programs can do it just as easily. the problem is, concurrent programming is difficult. On my dual CPU box running Linux has just as many processes ready to run as Be, since 99% of those threads in your "heavily threaded" apps are doing absolutely nothing, while 1 or 2 threads do 99% of the work. (percents guesstimated, feel free to test this yourself).

BeOS is neat, but there is no reason to let rabid advocacy cloud your ability to think rationally about what people tell you. Do you think that Be's marketing department might have some vested interests, and might not tell the whole story? No... of course not, everything they say must be the whole, un-spun truth.

Inferior Technology

[Anonymous Coward]

Lets see...
PC vs. Macintosh
VHS vs. Beta
Windows vs. OS/2
Linux vs. Hurd

Gee, if Linux has now become the inferior technology... it's gonna DOMINATE!!!!!!!!! YEEEEEEEESSSS!!!!!!!!! WORLD DOMINION!!!!!!!

Duh!

[BJH]

1: A post on the same topic was made quite a while ago (search the /. archives if you're really interested.)

2: WTF does he mean by "Object-Oriented"?! That phrase has absolutely zero meaning when applied to the HURD.

The real difference between the HURD and Linux is that the HURD uses a full microkernel architecture, which allows you to all sorts of cool stuff with "servers" that sit between your basic kernel and the rest of userspace.

Micro v. Macro: The Torvalds / Tanenbaum debates

[deusx]

I'm not sure that "Object Oriented" is the correct term to apply to the Hurd's microkernel architecture. I may be wrong.

As for why Linux is not like Hurd, read The Torvalds / Tanenbaum debates or do a random search on "Linus," "Tanenbaum", and "Microkernel". Linus details all of the reasons why Linux is monolithic versus being broken up into micro modules. Very historic, in Linux terms.

Why Linux isn't OO

[image]

I've noticed a few posts asking what the advantage of rewriting the kernel in a language like C++. I don't know the answer, but in the linux kernel mailing list faq, question 1.4 states:

Why don't we rewrite the Linux kernel in C++?


(ADB [Andrew D. Balsa]) Again, this has to do with practical and theoretical reasons. On the practical side, when Linux got started gcc didn't have an efficient C++ implementation, and some people would argue that even today it doesn't. Also there are many more C programmers than C++ programmers around. On theoretical grounds, examples of OS's implemented in Object Oriented languages are rare (Java-OS and Oberon System 3 come to mind), and the advantages of this approach are not quite clear cut (for OS design, that is; for GUI implementation KDE is a good example that C++ beats plain C any day).


and


(REW [Roger E. Wolff]) In the dark old days, in the time that most of you hadn't even heard of the word "Linux", the kernel was once modified to be compiled under g++. That lasted for a few revisions. People complained about the performance drop. It turned out that compiling a piece of C code with g++ would give you worse code. It shouldn't have made a difference, but it did. Been there, done that.



And question 1.5:

Why is the Linux kernel monolithic? Why don't we rewrite it as a microkernel?


(ADB) No opinions here, just a few pointers. Linux has been implemented as a "personality" on top of a modified version of the Mach3 microkernel. This is a fully functional piece of code, known as MkLinux. The project was in part funded by Apple, and as such it was running at first on PowerPC Macs. But an x86 version is available, with fully open source code. Similarly, the Hurd (the GNU kernel) is being implemented on top of Mach3.

There is a historical Usenet thread related to this subject, dating back from 1992, with posts from Linus, Andrew Tanenbaum, Roger Wolff, Theodore Y T'so, David Miller and others. Nice reading on a rainy afternoon. It's fascinating to see how some predictions (which seemed rather reasonable at the time) have proved wrong over
the years (for example, that we would all be using RISC chips by 1998).

Re:Why Linux isn't OO

[Anonymous Coward]

Why don't we rewrite the Linux kernel in C++?

Because C++ sucks and it is evil.

Why is the Linux kernel monolithic? Why don't we rewrite it as a microkernel?

Because then Linus would have to admit to Tannenbaum that he was wrong.

Hey, put that flamebait marker down... Hey, I said put it down! No!

Re:But why would I want to?

[Weezul]

I have yet to have anyone convince me that there will be any substantial practical advantage to the HURD over Linux in the long term. And we've been waiting for it to arrive for /at least/ 10 years.

The best Linux using lay person argument for the Hurd is a Windows vs. Linux analogy, i.e. the Hurd just lets the user screw with more stuff. The counter argument is basically "shure eating (abstraction) is importent, but eating too much will make you fat and slow."

Personally, I suspect the Hurd (or some other microkernel) will ultimatly depose Linux by addicting people to the additional power and flexability (i.e. past experence will be the only convincing argument for the people who eventually switch). This dose not necissarily mean that the current incarnation of the Hurd has the right stuff.

Analogy continued: Abstraction is like eating in that you must do it tomarrow too, i.e. what is a reasonable compramize between usability (abstraction) and effeciency today may be starving tomarrow (because the abstraction is necissary to process the increased quantity of information).

Also, the Hurd has some interesting ideas, but I am concerned that it *may* be too much the "bastard child of Unix" to really provide the abstract interface people will need in the future, i.e. translators are a really neet idea, but I am unconvinced that they are the best we could be doing. I have this fealing that the real revolution would somehow involve the scripting langauges in a more fundamental way. Who knows.

It is worth mentioning that abstract and structured dose not always imply slow, but we currently do not depend much on our compilers for opimisation since we are increasing chip speed so fast. Eventually, we will hit a limit in chip speed and need more structured langagues which allow more automatic opimisations by the compiler.

Example: It is possible to do global analysis of functional code that you would never dream of doing to C code.

Example: some of the fastest OSes out there are microkernels which could be writen in a protable high level language, but no portable high level langauge has the balls to preform the optimisations (higher order function, i.e. fucntions which write functions or structured self-modifing code).

Jeff

OO is "Better"

[MisterE]

This is starting to remind me of the vi/emacs religious wars.

The fact is that OO is a design paradigm. It isn't any "better" or "worse" than other design paradigms. In fact, it owes much to the structured software design movement from whence it was derived. It should all compile to the same code... it's a question of which one fits the particular mind set you have and the problem you are trying to solve.

What is HURD, you ask?

[redled]

I found this amusing. From Debian's HURD Page, an informative site, by the way, we can learn:

"According to Thomas Bushnell, BSG, the primary architect of the Hurd, ```Hurd' stands for `Hird of Unix-Replacing Daemons'. And, then, `Hird' stands for `Hurd of Interfaces Representing Depth'."

We also find some more information on the page, like it uses the "GNU C library," not C++ as other comments suggest, and its main strong points seem to be:

"Unlike other popular kernel software, the Hurd has an object-oriented structure that allows it to evolve without compromising its design. This structure will help the Hurd undergo major redesign and modifications without having to be entirely rewritten."

"The Hurd interfaces are designed to allow transparent network clusters (collectives), although this feature has not yet been implemented."

"It is possible to develop and test new Hurd kernel components without rebooting the machine (not even accidentally). Running your own kernel components doesn't interfere with other users, and so no special system privileges are required."

--

Inflammatory abbreviations

[spaceorb]

So for we have Gnulix for GNU/Linux. What's next, Gnurd for GNU/Hurd? I hereby decree that everyone seeking to flame GNU/Hurd users refer to them as GNURDS.

Simmer down, little cowpokes.

[DerMarlboro]

Kaboom! I expected a couple of know-it-alls to sneer at the suggestion that object-oriented design is better than a procedural design, but I never expected such a violent response.

How can an OS be object-oriented?! What the hell is that supposed to mean?!

Settle down. The poster (I'm sure) wasn't trying to say that the design methodology or language used to create a piece of software will, alone, decide its usefulness. A lot of us that write both C and C++ on a regular basis get used to the ease of conceptualizing object-oriented code, and are elated when new projects use a framework we favor. I would prefer to hack an OS written in C++. I think the code would probably much easier to get my head around. Naturally, I would rather USE whichever OS was fast, reliable, supported, etc.

Of course, that which gets hacked most frequently tends to become fast, reliable, supported, etc, etc.

The bottom line is this: OO vs. Anti-OO is a holy war, and the crusades will rage on. If you don't like OO, fine. Write C, or Fortran, or Cobol, or assembler for all I care. Object-oriented languages were created for a reason. Some people find advantages in them. And to those people, all other factors held constant, an OS written in C++ would clearly be an improvement.

Re:Linux not oo?

[elegant7x]

How much would it take to make Linux's kernel object oriented?

Well, It would take as much work as making an entire new kernel. And, if you did it, it wouldn't be Linux anymore. I suppose you could call It Linux, and it could certainly be able to do all the same things as Linux. Maybe you could call it ObjectLinux or something like that. (Of course given the stupid names that the Open Source community sometimes comes up with, I wouldn't be surprised if they called it ooplix ;)

Anyway, OO doesn't make programs faster, or give better performance, what it does, is make things easier to program, and a lot easier to update and maintain. This would probably be a good thing for an open source project, and a clear, well designed object hierarchy would make it much easier for people to start hacking around.

On the other hand, Linux has no real lack of development support, and Kernel hacking isn't really something that the timed are going to be diving into anyway. Anything that can be done in OO can be done in a non-objective language (as long as its Turing-complete :). And I don't think a kernel is really an aria that needs to be OO (other things like the GUI, etc should probably be done that way). They still use assembly in parts of the kernel.

Amber Yuan (--ell7)

This is what open source is about

[dsplat]

Linux, HURD and FreeBSD share quite a bit. A huge number of tools port between them with little effort. We welcome each other at conferences and users' groups. Etc., etc. In the end, the best open source OS will win. The best open source desktop OS will run on desktops. The other best open source desktop OS will run on the other desktops. The best open source web server OS .... It's about choice. It's about comparing them objectively for different uses. It is about learning from each one's strengths and bring that knowledge from one to another.

Every open source OS is stronger because they are all a training ground for open source programmers. You don't have to use a single book or a single kernel's source code to learn the One True Way (tm). I'm using Linux (sorry Richard, GNU/Linux) at home right now. I may switch to FreeBSD or HURD, or dual boot. And my data and applications will come with me. Standards are common data formats and common protocols, not a specific version of a specific program or OS.

The BIG question

[Tim Behrendsen]

Is Hurd fully Linux compatible? Device drivers, XFree86, desktops, the whole shebang?

Particularly device drivers. If everyone has to rewrite device drivers for Hurd, then they might as well close up shop.

--

Re:The BIG question

[Tim Behrendsen]

People DO say that about Linux, and it keeps many of them from it. Compatibility was what killed OS/2 (not marketing, by the way).

A new platform rises when it solves problems that the old platform does not, and it does not make the transition too painful. Linux has risen on the server side because it provides solutions better than NT in a lot of areas. You'll note that Linux so far is a miserable failure for the client-side desktop, because of the lack of applications (read: compatibility). OS/2 was far and away technically superior to Win 3.1, but IBM couldn't give it away (they sold machines with both, and people deleted it in favor of 3.1). Again, compatibility rules.

Hurd might have some advantages, but if they aren't huge advantages, not many is going to spend the effort to port applications, device drivers, etc away from Linux when Linux works well enough. Or at the very least, Hurd becomes a second class citizen waiting for a vendor to take pity (Sound familiar OS/2 and Mac users?)

In fact, this is a good lesson for many Linux advocates. On the one hand, advocates decry people choosing the "technically inferior" Windows platform, yet we see the same processes at work that keep people on the "technically inferior" Linux rather than switching to Hurd.

It's all about the applications and getting work done. The OS is just not that big a factor in how people choose platforms.

If the Hurd guys are smart, the will put in a Linux compability layer everywhere that's required and makes porting a simple matter of copying binaries.

--

OOP does matter

[Wyvern13]

I think all of you who are dis-advocated the effect of OOP on the perfermance of an OS are being very one-dimensional. Sure, it all ends up as machine code one way or another, the difference is in the human factor, the pyschological element of programming. Programming is, after all, just a metaphor for computer functionality. The GNU website says it best...

it's built to survive Unlike other popular kernel software, the Hurd has an object-oriented structure that allows it to evolve without compromising its design. This structure will help the Hurd undergo major redesign and modifications without having to be entirely rewritten.

In the initial version the methodology doesn't matter much, but as the OS matures, methodology beings to play a larger role. It's a lot easier to revise an OOP system, maintaining elegance and performance, than it is to revise a conventional structued program. Remember, the article says "better in the long run", which it is. In programming, you must always remember the human element, some might say it's the most important of all.

HURDOneTM Files for Public Offering

[spoonyfork]

Mountain View, CA., September 22 - HURDOne, Inc., a leading-edge developer of HURD software, products and services, filed to raise $24 Million in an initial public offering, according to a Securities and Exchange Commission filing.

The Mountain View, California-based Company offers online products, tools, news, and services for the HURD operating system and other "open source" communities, at its website http://www.hurdone.net/.

Under its open source model, anyone may contribute to the software coding.

The Company's principal product, HURDOne OS, provides a wide variety of server functions, including setting up a web, e-mail, file or print server, as well as using the computer as a general purpose desktop workstation to perform virtually any computer function. HURDOne OS will be available in English, Chinese, Japanese, German, Spanish and French.

HURDOne plans to sell 3 million shares in the IPO and will have approximately 9.2 million shares outstanding once the sale is completed, according to the filing.

The company was founded and is run by its President, Dr. One L. Inux, Jr., who has worked in senior engineering and technology positions at Hughes Aircraft Co., Teledyne Systems, Co., and California Institute of Technology, Jet Propulsion Laboratory. Dr. Inux was also Chief of Artificial Intelligence Branch, NASA Ames Research Center and organized Lockheed's Artificial Intelligence Center. He was the former founder and CEO of Alantic Macroelectronics and WebCIS.

HURDOne applied to sell its shares on NASDAQ under the symbol "HURD".

The company will be in its "Quiet Period" during SEC review of its filing, which is available on EDGAR.


About HURDOne

Our company provides world-class quality HURD software targeted to the server, workstation and home environments. It is distinguished by the unchallenged availability of applications and platform support, ease of installation and use, and technical support. The software is characterized by stability, security and usability. HURDOne expects to become the highest rated supplier of HURD solutions based on packaging, support, and capability worldwide.

Not according to the XP Movement!

[werdna]

that as long as a software project is intelligently planned and developed, it really doesn't NEED to be OO. OO programming has some advantages to development (especially when it comes to designing a UI) but its main advantage is that if you use OO programming you MUST be more careful in your design (in order to really get any benefits OO programming gives you).

That's what I used to think as well. However, a substantial contingent of the OO community argues violently against extended design at the outset of a project, relying instead upon an OO programming technique, refactoring, to "adjust" OO designs over time to facilitate change and reuse for additional functionality not contemplated in the prototype.

The theory is to build VERY EARLY ON "the simplest thing that could possibly work," exploiting refactoring and agressive (most tests written before most code) regression testing to evolve the prototype to a superior design over time. Fowler's book, "Refactoring" and Kent Beck's "Extreme Programming" really opened my eyes to a new way to thinking about code.

Having experimented with XP techniques on recent projects, albeit in the small, I have discovered that there is much more truth than hype in Beck's writing. While I haven't "gone to the dark side" completely yet, I now recognize that there are in fact some truly fundamental, and exciting, differences between OOPing and traditional hacking.

On one point I will agree, however: good ooping requires discipline to attain its benefits, perhaps more discipline than can be imposed on a large decentralized project such as an Open Source OS. You can write groty code, of course, in any programming languauge.