Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU |
>From the flamethrower of Robert L Krawitz <rlk at alum.mit.edu>... > A highly specialized, very minimal run time executive might take a few > weeks to write; a highly functional, general purpose operating system > kernel (not a "microkernel" which needs a lot of services to function > as such) is quite another matter. Even DOS took quite a bit more than > that :-) We're not in disagreement here. I started out my career on TOPS-10/TOPS-20, which were huge pieces of code for their time. The nice thing about Linux circa 1992 was its elegant simplicity. By comparison, today's Linux has gotten much fatter than the old TOPS-20 system, but retains most of its elegance. And of course, it's measured against the likes of Windows, which have bloated beyond the comprehension of us '80s-vintage hardware developers. I wrote: > Here are a couple of kernel developments in which I've participated: Robert wrote: > I wouldn't call either of these a general purpose operating system. > They're both highly specialized, very restricted I/O processors. Indeed. I didn't say they were anything other than specialized kernels, and in fact I spelled out what their special niche was, and what Linus' initial kernel was for (a t.e., and later self-compilation). Why the confrontational attitude? > Comparing them to a general purpose operating system kernel > (especially one that was to implement POSIX semantics), however, isn't > very useful in this context. I disagree here. Linus was able to write a kernel in a matter of a few months, and make it useful for compiling itself. Today's Linux is now a "general purpose operating system", but the 1992 versions (I started with 0.98pl5) were a far cry from it. Yet I was able to do quite a lot with the restricted early versions. My point in posting this was that Linus took a different approach from the FSF. He was able to divvy up the development effort into smaller pieces than the Hurd required, and thereby leverage the efforts of a far larger number of people during the crucial development stages between summer 1992 and the 2.0 release (1995? I forget). It was important to start with something small enough to be done by a single under-funded individual, yet big enough to be useful in an initial version. I've worked with kernels and O/Ses of several flavors, hence my bias toward discussing this aspect. -rich - Subcription/unsubscription/info requests: send e-mail with "subscribe", "unsubscribe", or "info" on the first line of the message body to discuss-request at blu.org (Subject line is ignored).
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |