[lkml]   [1997]   [Mar]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Now, why didn't we think of this before?
    Miguel, I'm not good with sarcasm, so I'm hoping that your statement is one
    oozing with sarcasm. If it's not sarcastic, then please take my apologies

    The ideas behind implementing anything in like an OS in Java is
    groundbreaking, but ultimately, bnound to fail as Java stands now - it has
    too few OS necessities (like pointers, the ability to control hardware, the
    list goes on).

    But - Linux as it stands has a few major failings:
    * non-dynamic object allocation (see recent >256 fd thread for just one
    * non-re-entrant kernel
    * non-threaded kernel

    Now, why would we need these things? We would need far fewer compilation
    options or tuneable areas if we simply allowed objects to be allocated from
    a dynamically resizeable pool. Memory is cheap, and in many circumstances,
    a well chosen algorithm will be better than just allocating enough for the
    average user. For a single user box, a well chosen algorithm will use less
    memory and be faster, and for a high end Internet server, with 4
    processors, lots of RAM and fast disk, a well chosen algorithm can extend
    the necessary objects as necessary to support the load. No tuning required.
    Computers are far better tuners than humans anyway.

    A re-entrant kernel would allow us to have different parts of the kernel
    alive at different times. This would help SMP machines no end. How to do a
    re-entrant kernel? Basically globals are out unless they are OS-Wide
    constants. It will require some work (an understatement of the century),
    but since we're Unix compatible, and not unix, we can still provide POSIX
    services to a program, whilst supporting it upon a much better foundation.
    I am not saying here that we throw away support for 2.0/2.1 binaries, just
    that we can do better with the kernel.

    A fully threaded kernel, (for example) breaking down device drivers into
    their own threads would help again, as we could schedule them on any
    available processor, and be more independant of the kernel state. This
    would give us a major speed boost, particularly on SMP machines.

    I'd also like to see much better boot management. The idea of an OS booting
    to a textual display in 1997 is ridiculous. Also, the current boot strategy
    is an all or nothing approach. If you don't make it to a login prompt, you
    better have a recovery boot disk around. That sucks.

    At this stage of the game, we should be laying down ideas for a 3.0 version
    of Linux, and trying to stabilize 2.1 for final release, and definitely
    maintenance mode 2.0 to encourage upgrades to the next stable release. As
    far as I can tell, there are far too few reasons for any reasonable user to
    upgrade to 2.1 at the moment if you have a recent 2.0 kernel - we need to
    change that.
    "Hate is not a family value" - bumper sticker
    Andrew Vanderstock (

    > From: Miguel de Icaza <>
    > To:
    > Subject: Now, why didn't we think of this before?
    > Date: Tuesday, 25 March 1997 6:05
    > And I wonder, why were we ever concerned about speed issues?
    > Miguel.
    > Date: Mon, 24 Mar 1997 10:16:50 -0800 (PST)
    > From: "W. Reilly Cooley" <>
    > To:
    > Subject: Re: Portability
    > In-Reply-To: <>
    > X-X-Sender:
    > MIME-Version: 1.0
    > Content-Type: TEXT/PLAIN; charset=US-ASCII
    > I had an idea for an interesting project, which would provide
    > remarkable portability: A Java VM server for a Mach4 MK, which could
    > run Sun's JavaOS, or any other OS written in Java. Considering that
    > JavaOS is not free, it would perhaps be a good excuse to implement the
    > Linux kernel in Java, as had been thrown around a bit. This second
    > project could draw also from the work done on MkLinux.
    > Maybe when I return to school and have more time...
    > What do you think?
    > Wil
    > - -------------------------------------------------------------
    > W. Reilly Cooley
    > NakedApe Consulting & Navi.Net representative
    > 1509 NE 10th Ave., #104 Portland, OR 97232
    > 503 287-2165
    > As a service, I provide analysis for viruses and poor grammar to senders
    > of unsolicited commercial e-mail at a rate of US$250 per hour. Delivery
    > said correspondence constitutes a request for the aforementioned services
    > at said price.
    > ------- End of forwarded message -------

     \ /
      Last update: 2005-03-22 13:39    [W:0.023 / U:2.684 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site