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 
.
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?
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 M. 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/
jwm
On Thu, Jun 4, 2009 at 3:14 AM, Sparky M. [email protected] 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.
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 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 11:15 PM, Kyle S.
[email protected]wrote:
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 4 Jun 2009, at 09:14, Sparky M. 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 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 .
The idea of a transactional file system does sound rather interesting
- especially if it were backed by transactional memory.
Ellie
raise ArgumentError unless @reality.responds_to? :reason
On 4 Jun 2009, at 14:49, Dylan E. wrote:
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
raise ArgumentError unless @reality.responds_to? :reason
On Fri, Jun 5, 2009 at 1:58 AM, Eleanor McHugh <
[email protected]> wrote:
On 4 Jun 2009, at 14:49, Dylan E. 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.
On 5 Jun 2009, at 03:58, Dylan E. wrote:
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.
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
raise ArgumentError unless @reality.responds_to? :reason
Kyle S. 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.
On 8 Jun 2009, at 09:10, Sparky M. wrote:
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 
Ellie
raise ArgumentError unless @reality.responds_to? :reason
2009/6/8 Sparky M. [email protected]:
Kyle S. 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.
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
On 8 Jun 2009, at 15:43, Mohit S. wrote:
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
I wish I had the time
It’s the one thing there’s never enough of.
Ellie
raise ArgumentError unless @reality.responds_to? :reason
Eleanor McHugh wrote:
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 
I wish I had the time
Cheers,
Mohit.
6/8/2009 | 10:43 PM.
Michal S. 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.
2009/6/9 Sparky M. [email protected]:
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.
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