Ruby as a kernel?

Ruby
1

This forks out of the “Ruby’s role in future OSs” thread, since it deals
with something completely different than the discussed there.

When someone suggested a ruby-based kernel, he was responded by “that’d
be
taking things too far”.

Well, if we consider Moore’s law and YAMV, I think it isn’t.

I know a ruby kernel would be a desperate effort to continue the M$
policy
of making OSs make up for changes in computer speed and beat Moore, who
works for a competitor ( :stuck_out_tongue: ) but
still, the advantages would be well worth it (depending on ruby being at
par
with Java regarding speed):

Development time of apps for an OS who’s native API is ruby dinamic
objects
would go drastically down. Drastically. It’s like developers choosing to
use
ruby today even though it’s much slower than C, since their time is
worth
more than CPU time. Remember how much better ruby itself would be in a
system that would not demand it to interface with un-OOP stuff all the
time
(which I feel the most dirty when I do in ruby - it’s just not right to
output a file when you have everything as objects).

Such an OS would be naturally reflective, a feature that would make the
world (and especially the business world) a far better and more
productive
place.

Everything in such a system would be interdependent is a way that would
make
customization a breaze - mixins would provide, for example, natural
handling
of “file types” - you just extend the type object to do the services you
want.

Ruby is almost ready: it has natural threading and natural object
security.
It only needs /better/ natural object permissions, transparent saving of
the
environment on disk and a natural GUI that is done the-Ruby-way
™®©.
A way to load C extentions from within ruby in runtime (I mean, write C
code
in a ruby text editor, invoke gcc from the editor and dinamically load
the
resulting .so) would help, too, and it’s almost possible (well, it is,
but
not as simple as it should be). From there it would be a matter of
months to
create an OS that uses a linux kernel for bootstrap, memory management,
basic disk i/o and networking and ruby for /everything/ else. Such a
system
could be programmed easily from within itself using, say VMWare.

Why is it too much?

2

On Tue, Jun 13, 2006 at 04:38:30PM +0900, Son SonOfLilit wrote:

This forks out of the “Ruby’s role in future OSs” thread, since it deals
with something completely different than the discussed there.

When someone suggested a ruby-based kernel, he was responded by “that’d be
taking things too far”.

Well, if we consider Moore’s law and YAMV, I think it isn’t.

Apart from all else, Ruby is too highly abstract for an OS kernel,
which would have to manage CPU registers, byte addressed memory and
I/O hardware.

And almost no software ever uses kernel APIs directly. C/C++ projects
use the C library, which abstracts over many different kernels, and
that is as low as you get. Most other interpreter/compilers boil down
to using the C compiler and its library in the end, including ruby,
java,
perl, php, …

system that would not demand it to interface with un-OOP stuff all the time
want.
Well that is all conjecture – just because the kernel is written in
Ruby, neither of these features would be present neccessarily. And
neither is a kernel written in ruby required for having them, or
even useful… Just write a ruby library with your desired API. Maybe
have a DRb server running to handle requests (like syscalls).

Why is it too much?

  • Ruby os totally unready for in-kernel deployment. No low level
    hardware access.

  • Ruby’s threading is not adequate for an OS kernel. Besides not
    beeing SMP-able, a kernel needs to do isolating multi-process
    management too, or you end up with a very insecure and unstable OS.

  • Performance. For a piece of software which is run really a lot by a
    lot of people, it makes sense to invest time into it to make it fast.
    Now OS kernels are run by every user of this OS all the time, so this
    is on the extreme end of where you don’t want to trade development
    time for execution time.

  • Ruby, as of now, relies heavily on a C library. When Ruby calls a
    C library function, the library might go to the kernel, which is Ruby
    itself again, which depends on the C library …

  • I speculate you might embed a rewritten, absolutely self contained
    ruby interpreter into the linux kernel, and have it do non-essential
    work (drivers, modules). But since you want to delegate the most
    important OS jobs to the linux kernel part anyway (memory, I/O,
    process management) the resulting kernel’s API will be not much
    different than linux is now.

  • A GUI is not a required part of an OS kernel.

  • Let’s assume you succeed writing this linux-ruby kernel-GUI, and
    change the API to be ruby-ish. Now you have a new system architecture,
    but no software for it. Since your kernel is by your definition
    nowhere close to POSIX-family, it will be very hard, if not
    impossible, to port the C-library to it, which is the foundation of
    everything else. ANSI C requires byte adressable memory (with bytes
    having a minimum of 8 bits), but your ruby-ish API only provides
    object references.

That said, if you want to provide a more ruby-ish environment, go
ahead, but do it as a library/server, make your own GUI, and run it
under plain linux. That way you can do it piecemeal, step by step, and
at the same time keep access to all the other wonderful software not
written in ruby (yet).

Jürgen

3

I know a ruby kernel would be a desperate effort to continue the M$ policy
of making OSs make up for changes in computer speed and beat Moore, who
works for a competitor ( :stuck_out_tongue: ) but
still, the advantages would be well worth it (depending on ruby being at par
with Java regarding speed):

The thing is… Java is normally 10/20 times faster than Ruby. I feel
sick now that I think of that fact :stuck_out_tongue:

4

OK, you caught me on terminology.

What I was meaning was creating a computer operating system (not by the
usual, low level definition, but the more windows 3.11 definition: a
system
that controlls everything useable on the system and everything the user
interacts with) in ruby.

To make this useful, there have to be /no services/ running on the
system
that didn’t originate from it except for device drivers.

Otherwise it would be on par with portable windowing systems and there
would
be no gain from it’s dinamicity.

What I am envisioning is a system where things are developed only for
YARV
or as ruby extentions. It would indeed be non-POSIX, and loose most of
the
current available software (until a ruby cygwin-clone would be
developed).
But ten, twenty years from now, though perhaps POSIX won’t be dead
because
of legacy systems, it would become a bad thing. Computers will be fast
enough to incorporate reflection, fully OO APIs and persistent sessions.
POSIX doesn’t leave room for these features (except for the
persistence).
POSIX would be like building a wooden carriage on a modern Mercedes-Benz
engine. With a horse for navigation.

Reflection and OO communication between processes would be a must, and
POSIX
will have to go or remain a compatibility layer.

I think Ruby is fit for the challenge. Especially if invoking C
extentions
from within it would be easier.

I already mentioned the problems you suggested with ruby inter-object
security. I answereed your POSIX question.

What say everyone?

5

On 13/06/06, Son SonOfLilit [email protected] wrote:

Development time of apps for an OS who’s native API is ruby dinamic objects
would go drastically down.

Why?

Such an OS would be naturally reflective, a feature that would make the
world (and especially the business world) a far better and more productive
place.

I can’t think of anything useful that would give you. Can you?

Ruby is interpreted. A lot of it’s beauty is a wrapper around system
calls. I can’t begin to think what benefits a high-level dynamic
language
gives you in kernel space
(where things like memory allocation can’t be taken for granted).

6

On 6/13/06, Dick D. [email protected] wrote:

On 13/06/06, Son SonOfLilit [email protected] wrote:

Development time of apps for an OS who’s native API is ruby dinamic objects
would go drastically down.
Apart from higher level of abstraction, the fact that it’s all Ruby
idioms, with no dependencies on C or other low level stuff. You could
do that by simply changing extensions to be more Ruby-like, though.

–
Rasputin :: Jack of All Trades - Master of Nuns
http://number9.hellooperator.net/

I think it sounds a lot like Squeak/SqueakNOS (standalone Squeak, with
no external OS). I’m not going to try to sound like I know more than I
do, but aren’t those written in a Smalltalk subset and minimal custom
C? Such systems are fun and productive, but I’m not sure whether it’ll
become practical anytime soon.

7

Well in the Squeak-case, the developers started out in smalltalk,
writing a
smalltalk2c-converter and implemented 16 rewriting-rules that made
everything
work…
then they extended it until it just ran on it’s own and could be
dispatched
from everything else, continuing to let smalltalk write its own
implementation.

there are two projects in ruby atm that are trying to achieve that atm,
one
being metaruby, the other one is RubyToC (main-developer is zenspider
afaik -
and it’s the thing that makes the obfuscator tick that you might have
just
heard of some days ago on this mailinglist.)

so, given that we already can translate most of ruby to C, what is
stopping
us?
sure, ruby will be painfully slow as an OS - squeak is not the fastest
thing
on earth too, but they have a lot more optimization than i think is
possible
with a system like ruby (i’m ready to get proven wrong on that)

just some thoughts from me :slight_smile:

more infos about how they went about writing this whole squeak-thing are
here:
http://users.ipa.net/~dwighth/squeak/oopsla_squeak.html

8

Indeed, I’m talking of a Squeak-alike… Or an Oberon-alike.

I just think Ruby would work much better for it.

9

On Tue, Jun 13, 2006 at 09:30:09PM +0900, Matthew H. wrote:

Matt

Really? Can you cite hard numbers for this for real applications, or
is this just from artificial benchmarks? I’ve yet to see sanely
crafted Rails Web-DB based applications to be noticeable slower than
what I’d expect from Java, and that’s with maybe 1/10th the memory
footprint (no hard numbers either…).

At least I’ve managed to run RoR on a P3-350/128MB machine (aside
other services) for a small user base without big problems, and I
probably can’t even start tomcat there.

I feel quite good knowing that Ruby’s speed is not a problem for the
kind of work it is supposed to do, and that Ruby does not need to play
the corporate game of benchmark BS.

Jürgen

10

On Jun 13, 2006, at 11:04 PM, Michael F. wrote:

there are two projects in ruby atm that are trying to achieve that
atm, one
being metaruby, the other one is RubyToC (main-developer is
zenspider afaik -
and it’s the thing that makes the obfuscator tick that you might
have just
heard of some days ago on this mailinglist.)

MetaRuby depends upon RubyToC to make a bootstrapping Ruby. We might
be able to build a stripped-down Ruby that uses the MetaRuby
implementation for most methods.

Ryan and I are the primary developers.

so, given that we already can translate most of ruby to C, what is
stopping
us?

  1. Lack of a complete test suite for Ruby’s C libraries
  2. Incomplete implementation of MetaRuby (partially dependent upon 1)
  3. Incomplete implementation of RubyToC
  4. Lack of developers to help with 1, 2 and 3

1 is easy, 2 is slightly more difficult (we’ve already completed the
easy parts of 2), 3 is hard.

sure, ruby will be painfully slow as an OS - squeak is not the
fastest thing
on earth too, but they have a lot more optimization than i think is
possible
with a system like ruby (i’m ready to get proven wrong on that)

–
Eric H. - [email protected] - http://blog.segment7.net
This implementation is HODEL-HASH-9600 compliant

http://trackmap.robotcoop.com