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
example)
* 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 (ajv@greebo.svhm.org.au)---------- > From: Miguel de Icaza <miguel@nuclecu.unam.mx> > To: linux-kernel@vger.rutgers.edu > 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" <wcooley@navi.net> > To: mach4-users@cs.utah.edu > Subject: Re: Portability > In-Reply-To: <199703241352.NAA06096@odie.barnet.ac.uk> > X-X-Sender: wcooley@navi.net > 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 then > 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 wcooley@navi.net > www.navi.net/~wcooley www.navi.net/~nakedape > > 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 of > said correspondence constitutes a request for the aforementioned services > at said price. > ------- End of forwarded message -------