From: Juergen Strobel Date: 2006-06-13T19:52:46+09:00 Subject: Re: Ruby as a kernel? --wRRV7LY7NUeQGEoC Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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. >=20 > When someone suggested a ruby-based kernel, he was responded by "that'd be > taking things too far". >=20 > 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, ... > 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 ( :P ) but > still, the advantages would be well worth it (depending on ruby being at = par > with Java regarding speed): >=20 > Development time of apps for an OS who's native API is ruby dinamic objec= ts > 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 ti= me > (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). >=20 > 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. >=20 > Everything in such a system would be interdependent is a way that would m= ake > customization a breaze - mixins would provide, for example, natural handl= ing > of "file types" - you just extend the type object to do the services you > 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). > Ruby is almost ready: it has natural threading and natural object securit= y. > It only needs /better/ natural object permissions, transparent saving of = the > environment on disk and a natural GUI that is done the-Ruby-way (tm)(r)(c= ). > A way to load C extentions from within ruby in runtime (I mean, write C c= ode > 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 syst= em > could be programmed easily from within itself using, say VMWare. >=20 > 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=FCrgen --=20 The box said it requires Windows 95 or better so I installed Linux --wRRV7LY7NUeQGEoC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) iQEVAwUBRI6Y9fy64gyiEfXtAQK0iAgA7MV6Vi8xmWzD6LBp9NBxjVSnS1isGvwv 7mO/DiNjD7ErIdOqV8NJUmGWkbunzfDtlyNaYESga5mvhuM9kxjxt4K6d8LEw5eX mXulPd96/k4swc5bYR6N0bCqlAMqXvjNO+YnL2rOI/1S+HXJf4qQRmnmLZDRiEnl Zgxb4vUEfztqnbshDijfBloBkpXpZwjefYoWz1PmAuwsBrz6exteB58W4thgYu8T yWFMyTkCIhF63YNQdEA4nfwOM+DXacG/81Uiy2vfiAGaxPKvwjRPzyFACVv5WNrS GfdhSHU+IoClsS5RFrAZGA2hrvMmiN2TlW/6zCQlFHoZBlgVLo85uA== =6+Wp -----END PGP SIGNATURE----- --wRRV7LY7NUeQGEoC--