Ruby OS

I was considering porting the Ruby 1.9 VM to bare metal (something
similar to Cleese - http://code.google.com/p/cleese/). I was wondering
if someone is already working on this. The end goal is to have a Ruby
OS, with everything running on the VM. I have yet to analyze the
complete changes needed.

My original idea was for such a (Ruby) OS to be coupled with a versioned
file-system to have a completely rollback-able OS where the whole
userland and parts of the system land are in pure Ruby, with patches
being .diff files :slight_smile: .

I have a discussion running on the OSDev forums regarding this (Link:
http://forum.osdev.org/viewtopic.php?f=15&t=20220)

So is there such a project already?

TLDR: Is someone working on porting the Ruby 1.9.x VM to bare metal?

···

--
Posted via http://www.ruby-forum.com/.

Hi,

I know one laboratory trying to such a kernel (where I had been when I'm
a student).

# And this lab made a Perl OS, last year.

Sparky Mat wrote::

···

I was considering porting the Ruby 1.9 VM to bare metal (something
similar to Cleese - Google Code Archive - Long-term storage for Google Code Project Hosting.). I was wondering
if someone is already working on this. The end goal is to have a Ruby
OS, with everything running on the VM. I have yet to analyze the
complete changes needed.

My original idea was for such a (Ruby) OS to be coupled with a versioned
file-system to have a completely rollback-able OS where the whole
userland and parts of the system land are in pure Ruby, with patches
being .diff files :slight_smile: .

I have a discussion running on the OSDev forums regarding this (Link:
OSDev.org • View topic - Scripting language loading kernel/OS)

So is there such a project already?

TLDR: Is someone working on porting the Ruby 1.9.x VM to bare metal?

--
// SASADA Koichi at atdot dot net

Sparky Mat wrote:

I was considering porting the Ruby 1.9 VM to bare metal (something
similar to Cleese - Google Code Archive - Long-term storage for Google Code Project Hosting.). I was wondering
if someone is already working on this.

I don't know for YARV, but I know that there was a thread on the
Rubinius mailing list, where one guy was working on porting Rubinius
running on a microcontroller. It doesn't look like it's gone anywhere,
though, but you could definitely contact him.

Here's the thread:

  <https://Groups.Google.Com/group/rubinius-dev/browse_thread/thread/2e19e0ac73362f75/&gt;

jwm

I was considering porting the Ruby 1.9 VM to bare metal (something
similar to Cleese - Google Code Archive - Long-term storage for Google Code Project Hosting.). I was wondering
if someone is already working on this. The end goal is to have a Ruby
OS, with everything running on the VM. I have yet to analyze the
complete changes needed.

My colleague and I have been toying with a similar idea for a couple of years now, but we're more interested in a register-based VM than YARV and haven't managed to settle on one yet (if only Google would open-source Dalvik...).

We've also done some proof-of-concept work to see if writing a Unix userland in pure Ruby is possible and I'm hoping the two ideas will merge into something useful at some point.

From a maintenance perspective Ruby would make for a pretty sweet systems programming language and assuming a build which supports ruby/dl or ffi then all the functionality of C is there - or with Wilson even assembler.

My original idea was for such a (Ruby) OS to be coupled with a versioned
file-system to have a completely rollback-able OS where the whole
userland and parts of the system land are in pure Ruby, with patches
being .diff files :slight_smile: .

The idea of a transactional file system does sound rather interesting - especially if it were backed by transactional memory.

Ellie

Eleanor McHugh
Games With Brains
http://slides.games-with-brains.net

···

On 4 Jun 2009, at 09:14, Sparky Mat wrote:
----
raise ArgumentError unless @reality.responds_to? :reason

Umm, have you thought perhaps of using an existing kernel and just
having one binary, that being ruby? You could then build your whole
userspace on top of that.

I've toyed with the idea, but never had the time to really do it.

It's easy, take a linux, BSD (or any other "Real OS"™), and add an
entry into the bootloader, telling it that the init program is
whatever binary or executable script you wish. You could add entries
for irb, a commodore 64 basic interpreter, and an apple-basic
interpreter in less than 5 minutes.

I know just booting into irb or commodore basic may count as an OS
from the 8-bit days, but it really doesn't cut it now days :slight_smile: So
after proving it works to yourself, try writing your own init as a
ruby 1.9 script.

my 2¢

--Kyle

···

On Thu, Jun 4, 2009 at 3:14 AM, Sparky Mat <max@sparkymat.net> wrote:

I was considering porting the Ruby 1.9 VM to bare metal (something
similar to Cleese - Google Code Archive - Long-term storage for Google Code Project Hosting.). I was wondering
if someone is already working on this. The end goal is to have a Ruby
OS, with everything running on the VM. I have yet to analyze the
complete changes needed.

> I was considering porting the Ruby 1.9 VM to bare metal (something
> similar to Cleese - http://code.google.com/p/cleese/\). I was wondering
> if someone is already working on this. The end goal is to have a Ruby
> OS, with everything running on the VM. I have yet to analyze the
> complete changes needed.

Umm, have you thought perhaps of using an existing kernel and just
having one binary, that being ruby? You could then build your whole
userspace on top of that.

A peek inside the mind of a genius. Why not use existing code and increase
your chances of success? You will have to use binary at some level, and if
you did want to use ruby to write kernel modules you could perhaps build
on a microkernel (maybe minix) where the system is made up of daemons
running in user space.

Actually a simple way to prototype the system would be to run it in ms-dos
which is as near to no operating system as you can get anyway.

···

On Thu, Jun 4, 2009 at 11:15 PM, Kyle Schmitt <kyleaschmitt@gmail.com>wrote:

On Thu, Jun 4, 2009 at 3:14 AM, Sparky Mat <max@sparkymat.net> wrote:

I've toyed with the idea, but never had the time to really do it.

It's easy, take a linux, BSD (or any other "Real OS"™), and add an
entry into the bootloader, telling it that the init program is
whatever binary or executable script you wish. You could add entries
for irb, a commodore 64 basic interpreter, and an apple-basic
interpreter in less than 5 minutes.

I know just booting into irb or commodore basic may count as an OS
from the 8-bit days, but it really doesn't cut it now days :slight_smile: So
after proving it works to yourself, try writing your own init as a
ruby 1.9 script.

my 2¢

--Kyle

--
"The UNIX system has a command, nice ... in order to be nice to the other
users. Nobody ever uses it." - Andrew S. Tanenbaum

Kyle Schmitt wrote:

Umm, have you thought perhaps of using an existing kernel and just
having one binary, that being ruby? You could then build your whole
userspace on top of that.

I suspect that this would be the most practical approach, and probably,
after failing the bare-metal thing, I would end up doing this. However,
I'd still like to give the bare-metal port a try.

···

--
Posted via http://www.ruby-forum.com/\.

A peek inside the mind of a genius. Why not use existing code and increase
your chances of success? You will have to use binary at some level, and if
you did want to use ruby to write kernel modules you could perhaps build
on a microkernel (maybe minix) where the system is made up of daemons
running in user space.

Minix has a few shortcomings, but in general this approach is doable. A better choice of kernel though would probably be NetBSD thanks to the large number of hardware platforms that it supports.

Actually a simple way to prototype the system would be to run it in ms-dos
which is as near to no operating system as you can get anyway.

You can already run Ruby on top of MS-DOS so in a sense the experiment has been done.

Ellie

Eleanor McHugh
Games With Brains
http://slides.games-with-brains.net

···

On 4 Jun 2009, at 14:49, Dylan Evans wrote:
----
raise ArgumentError unless @reality.responds_to? :reason

Well keep us informed on how it goes. I could really use a bare-metal Ruby but I don't have the time to work on it right now :frowning:

Ellie

Eleanor McHugh
Games With Brains
http://slides.games-with-brains.net

···

On 8 Jun 2009, at 09:10, Sparky Mat wrote:

Kyle Schmitt wrote:

Umm, have you thought perhaps of using an existing kernel and just
having one binary, that being ruby? You could then build your whole
userspace on top of that.

I suspect that this would be the most practical approach, and probably,
after failing the bare-metal thing, I would end up doing this. However,
I'd still like to give the bare-metal port a try.

----
raise ArgumentError unless @reality.responds_to? :reason

What would you want the bare-metal port to do? If you just want to run
in-memory without using any hardware devices like disk drives,
graphics, etc it would be fairly simple.

However, there's a reason why Linux and BSDs have bazzilions of
drivers that took years to develop and debug and half of them are
still failing half of the time. There's simply way too much different
hardware which is either not documented or has undocumented bugs so
you will have hard time if you try to run on bare metal and support
any hardware but the main memory.

Exotic microkernels won't help you either because they suffer from the
same basic problem: they don't have drivers for most hardware so the
chance you can boot anything based on them on your machine is pretty
small.

The bare-metal approach is only viable for specialized applications
where you select and buy a well documented piece of hardware and port
the system to that.

Thanks

Michal

···

2009/6/8 Sparky Mat <max@sparkymat.net>:

Kyle Schmitt wrote:

Umm, have you thought perhaps of using an existing kernel and just
having one binary, that being ruby? You could then build your whole
userspace on top of that.

I suspect that this would be the most practical approach, and probably,
after failing the bare-metal thing, I would end up doing this. However,
I'd still like to give the bare-metal port a try.

Actually a simple way to prototype the system would be to run it in ms-dos

which is as near to no operating system as you can get anyway.

You can already run Ruby on top of MS-DOS so in a sense the experiment has
been done.

Yes, but just the interpreter, from there you could set up a multi tasking
environment, somewhat like how win 9x worked, and because ms-dos is fairly
trivial it wouldn't be a huge leap to writing device drivers in ruby.

···

On Fri, Jun 5, 2009 at 1:58 AM, Eleanor McHugh < eleanor@games-with-brains.com> wrote:

On 4 Jun 2009, at 14:49, Dylan Evans wrote:

Ellie

Eleanor McHugh
Games With Brains
http://slides.games-with-brains.net
----
raise ArgumentError unless @reality.responds_to? :reason

--
"The UNIX system has a command, nice ... in order to be nice to the other
users. Nobody ever uses it." - Andrew S. Tanenbaum

Eleanor McHugh wrote:

···

On 8 Jun 2009, at 09:10, Sparky Mat wrote:

Kyle Schmitt wrote:

Umm, have you thought perhaps of using an existing kernel and just
having one binary, that being ruby? You could then build your whole
userspace on top of that.

I suspect that this would be the most practical approach, and probably,
after failing the bare-metal thing, I would end up doing this. However,
I'd still like to give the bare-metal port a try.

Well keep us informed on how it goes. I could really use a bare-metal Ruby but I don't have the time to work on it right now :frowning:

I wish I had the time :frowning:

Cheers,
Mohit.
6/8/2009 | 10:43 PM.

Michal Suchanek wrote:

However, there's a reason why Linux and BSDs have bazzilions of
drivers that took years to develop and debug and half of them are
still failing half of the time. There's simply way too much different
hardware which is either not documented or has undocumented bugs so
you will have hard time if you try to run on bare metal and support
any hardware but the main memory.

Exotic microkernels won't help you either because they suffer from the
same basic problem: they don't have drivers for most hardware so the
chance you can boot anything based on them on your machine is pretty
small.

I agree with most of what you've said, and yes, I don't want to spend
the next few years writing/re-writing drivers just to get stuff working.
I had already shelved my Minix setup yesterday and am now setting up a
RubyVM on Linux kernel. Well, starting with a default Debian
installation and stripping out stuff now.

···

--
Posted via http://www.ruby-forum.com/\.

I'm not sure it would even be that difficult - at least in principle - to write device drivers for unix in Ruby as ruby/dl gives you memory buffers and callbacks. However my DD experience is on other operating systems that get in your way less (like OS/9) so there are probably kernel interface complexities that I'm overlooking. Might be a fun experiment to look into though if I can find the time.

Ellie

Eleanor McHugh
Games With Brains
http://slides.games-with-brains.net

···

On 5 Jun 2009, at 03:58, Dylan Evans wrote:

On Fri, Jun 5, 2009 at 1:58 AM, Eleanor McHugh < > eleanor@games-with-brains.com> wrote:

On 4 Jun 2009, at 14:49, Dylan Evans wrote:
Actually a simple way to prototype the system would be to run it in ms-dos

which is as near to no operating system as you can get anyway.

You can already run Ruby on top of MS-DOS so in a sense the experiment has
been done.

Yes, but just the interpreter, from there you could set up a multi tasking
environment, somewhat like how win 9x worked, and because ms-dos is fairly
trivial it wouldn't be a huge leap to writing device drivers in ruby.

----
raise ArgumentError unless @reality.responds_to? :reason

It's the one thing there's never enough of.

Ellie

Eleanor McHugh
Games With Brains
http://slides.games-with-brains.net

···

On 8 Jun 2009, at 15:43, Mohit Sindhwani wrote:

Eleanor McHugh wrote:

On 8 Jun 2009, at 09:10, Sparky Mat wrote:

Kyle Schmitt wrote:

Umm, have you thought perhaps of using an existing kernel and just
having one binary, that being ruby? You could then build your whole
userspace on top of that.

I suspect that this would be the most practical approach, and probably,
after failing the bare-metal thing, I would end up doing this. However,
I'd still like to give the bare-metal port a try.

Well keep us informed on how it goes. I could really use a bare-metal Ruby but I don't have the time to work on it right now :frowning:

I wish I had the time :frowning:

----
raise ArgumentError unless @reality.responds_to? :reason

Note that on Linux many drivers (filesystem, USB, parallel, ...) can
be written in userspace so you can still use any language you like for
these. Hopefully the number of subsystems that are open in this way
will increase over time.

Thanks

Michal

···

2009/6/9 Sparky Mat <max@sparkymat.net>:

Michal Suchanek wrote:

However, there's a reason why Linux and BSDs have bazzilions of
drivers that took years to develop and debug and half of them are
still failing half of the time. There's simply way too much different
hardware which is either not documented or has undocumented bugs so
you will have hard time if you try to run on bare metal and support
any hardware but the main memory.

Exotic microkernels won't help you either because they suffer from the
same basic problem: they don't have drivers for most hardware so the
chance you can boot anything based on them on your machine is pretty
small.

I agree with most of what you've said, and yes, I don't want to spend
the next few years writing/re-writing drivers just to get stuff working.
I had already shelved my Minix setup yesterday and am now setting up a
RubyVM on Linux kernel. Well, starting with a default Debian
installation and stripping out stuff now.