Slashdot Mirror
Rubyx OS - A Testament To The Power Of Ruby
Andrew Walrond writes "Rubyx the OS is created from source by rubyx the ruby script. Got it? The same small ruby script handles all subsequent package management, customised parallel and distributed user-mode package builds, and can create a live CD. For good measure, Rubyx (the os) sports an all new init and rationalised service management system written in ....can you guess?..."
I am a Perl user
</disclaimer>
It is an installer and package manager written in Ruby not an OS. The website doesn't seem to make this very clear though, so I don't blame you for being confused. It is really a Linux (or GNU/Linux if you prefer) distribution. If we were to follow this logic then Mandrake Linux would be a Perl OS and Fedora/Redhat would be a Python OS.
When evaluated on that level it looks interesting. It seems to combine the concepts of LFS and Gentoo with stow like package managment.
Are there any ruby zealots? Seriously, every Ruby programmer I know is remarkably calm and rational. Must be the Japanese influence, eh? Or maybe all the free time they have after writing programs in Ruby! :-)
You mean, like FreeBSD's portupgrade?
(Yeah yeah, portupgrade layers on top of the existing FreeBSD package system but still, this isn't *that* mind-blowing.)
If you want to talk about the power of ruby, I can think of a lot more cool things. Like, how you can add aspect-oriented programming without modifying Ruby or using any pre-compiling, or how you can write a profiler for Ruby programs, in Ruby itself, without any external hooks, in under 200 lines. Or how you define the "+" operator by using "def +(x)" instead of "def __add__(self, x)". Etc. Etc.
I wasn't going to say this, but after reading a few of the comments here I've changed my mind.
The name Ruby x conveys a little too much "Ruby fanboy" vibe. It's a Linux distribution, yet the name doesn't mention it and the website gives only cursory mention of this fact, which borders on the deceptive. I want to emphasize that I mean these things exactly as I say... a little too much fanboy vibe, borders on the deceptive. It's not irredeemably bad, but I do have to say at the moment I'm having a hard time respecting the project.
In fact this could well hurt even the Ruby advocacy side of the project by scaring people off, thinking they'll need to know Ruby to install, when instead it looks like Yet Another Linux Distribution.
I mean this as constructive criticism. To the project leaders, I strongly recommend that you more carefully evaluate the goals of the project, more clearly partition the "Ruby" concept from the "Linux Distribution" concept, and determine whether your goals justify the seemingly over-strong focus on Ruby. Yes, I know Ruby lovers have a bit of a persecution complex, I recognize this in myself as I like Python and see the same in the Python community, but in the long run you're going to get more real respect by building a real project on Ruby and discreetly pointing out that it runs on Ruby then by shouting out in the streets that THIS RUBY DISTRIBUTION OF RUBYX IS MADE POSSIBLE BY RUBY, THAT WONDERFUL (RUBY) LANGUAGE! (Yes, this time I'm exaggerating for dramatic effect; again I emphasize I'm not claiming the site actually sounds like this but the tone is definately there.)
If I recall correctly, several of the Linux and BSD distros use Python for their installers.
So, no, I guess it wouldn't be any big deal. Certainly not Slashdot front-page stuff.
News for nerds, stuff that matters? Not this time.
--
Don't like it? Respond with words, not karma.
For example, making it easy to run multiple versions of, say, gcc on the same system and switch between them at will...
I have a home-brew system like this, and I would die of joy if something like Debian's apt or {Free,Open}BSD's ports system would integrate it.
I actually can't take credit for it, and I really don't know if it's that unique, but the people I've introduced it to love it. And thanks, Lou, for showing it to me. It's a shame this post won't get a larger audience (then again, maybe it's a conceit to believe anyone would actually care. :)).
Okay, here goes...
I have on all of my machines (or "boxen", just to annoy those of you who loathe the term), a directory called /mfs -- "my file system". The philosophy is that of /opt or /usr/local: a place to install custom software without colliding with the main system tree.
Within /mfs, there's dist, src, obj, & pkg. I place the tarballs in dist, I unpack the source into (you guessed it) src, I (sometimes) build in obj, and I install into pkg.
My most common use is installing OpenSSH onto various platforms, so I'll use that to illustrate.
I download the tarballs into my dist dir: tcp_wrappers_7.6.tar.gz, openssl-0.9.6l.tar.gz, zlib-1.2.1.tar.gz, & openssh-3.8p1.tar.gz.
Next, I unpack them into src, where I usually build them, though sometimes I build them in obj.
Sometimes, it's a matter of a simple --prefix paramater to the config script. Sometimes it takes modifying Makefiles. But usually without fail, I can shoehorn most any application into it's proper place: /mfs/pkg/package/version.
The goal is to totally isolate the application within its own directory -- even it's own etc, tmp, var (or whatever) directories. If it's possible (never mind the convenience of making it happen), that program will never collide with another version of that program on the system: .pid files, logs, sockets - nothing.
So when all's said and done, I now have:
Each, of course, has all of the etc, bin, lib, include, sbin, var, tmp, and man directories the app needs to run.
Once this structure is in place, it's pretty obvious where it leads: you can painlessly have concurrent versions of any program and/or library you could ask for. Since apps are linked to a specific library version, installing a new version of that library won't collide with the old one.
Ever try installing a current SRPM of openssh onto an older Redhat release? It's a nightmare! The RPM requires a current version of openssl, but the KDE libraries all require openssl 0.9.5 (or some such). You just cannot get it to work.
So you may now be thinking to yourself, "Okay, that's kinda useful. But when you have hundreds (or thousands) of apps, your PATH would be insanely long. This just won't work."
That's a good point -- but there's a solution. Use the "lndir" command from within /mfs, to link your desired package into the root /mfs directory:
cd /mfs && lndir pkg/openssh/3.8p1
Now, thanks to the lndir command, you now have the directories /mfs/{bin,etc,sbin,man} populated with symbolic links to the actual programs. Now you can set your PATH, MANPATH, and even init scripts to point to the "main" /mfs directories.
But wait, there's more! Let's say we h
Method of processing duck feet
There is already stow.
Without upgrading you mean, ok fair enough. Although I'm not sure why I'd care about what version openssh is (unless it's a security errata -- in which case it's coming from my vendor anyway). But using a better example of evolution or whatever...
Ta-da you've now got the same problem plus a billion symlinks. You could argue that putting a serious amount of crack in the PATH and/or LD_LIBRARY_PATH could save you ... I'd disagree, openssl is pretty notorius of breaking backward compat. on library upgrades. So you are likely to end up with something that installs but doesn't work. And the deps. won't be half as good as any of the major distros, as you are basically doing download tarball type ./configure -- see what fails -- then, eventually, run and see what fails.
Understatement of the century. Be very affraid of any "package management" system that hand waves away problems like this (and god help you if you are doing anything like "obsoletes" markings ... which again all the major package
management solutions have).
ustr: Managed string API with ave. 44% overhead over strdup(), for 0-20B
Can someone explain clearly why someone who works a lot with python, why one might find it worth while to invest into learning about Ruby?
If Python is doing everything you need it to do and you're happy with it and you're not curious, then maybe there isn't any reason for you to learn Ruby.
However, if you have at least a little bit of intellectual curiosity, you might find it rewarding to spend an hour learning some Ruby and trying it out. I emphasize the tryinging it out part: sure the two languages have very similar capabilities, however it feels much different programming in Ruby than it does in Python. It's difficult to explain, you have to try it. I tend to think it has something to do with the fact that Ruby's built-in libs made use of iterators from the start (and it also has something to do with Ruby's blocks).
Also, if you prefer not having syntactically significant pieces of your code be invisible then you'll probably prefer Ruby. Yes, it's that indentation-as-syntax thing in Python that kept me from going with the snake a few years back before I found Ruby. Yes, I've heard all the arguments from the Pythonistas about how your editor will just take care of things for you and how life will be so wonderful. However, I was bit by this twice within the first hour that I tried Python. One person might have his editor set to expand tabs and another might not. I haven't got time to spend several minutes trying to figure out why some code (which looks perfectly fine) doesn't work only to find that it's a tab expansion problem, "gee, the code looks identical to the code in the book?! WTF?!" - Life's too short.
How much can you convey in 1 paragraph? Maybe I did a bad job, but I did at least expect/prime (with "can you guess") the ruby/perl/python flamefest.
:)
But a few people were intelligent enough to pick out the salient points, or were bothered to read the website. And then downloaded 8Gb of Rubyx overnight. (Hang the cost; It made me smile!)
For those of you who somehow missed those salient points:
Rubyx is 'yet another linux distro', that builds from source (like gentoo). It is _not_ an OS written in ruby.
But it's different because...
Rubyx can be created, with a single command, using the rubyx script.
With a second command, you can create a bootable Rubyx CD/DVD.
The same script handles ALL subsequent package management.
Reread that last bit. This is one small script we are talking about, written in the ruby language.
I wrote the new init system inside 2 days. Go figure. A complete init replacement in two days.
Yes, I'm a fan of ruby. Its the most writable, readable scripting language I have tried. Could Rubyx have been done in another language? Surely. But, I argue, not as quickly, elegantly and maintainably.
Have a lovely day
Andrew Walrond
No, it's more than just another Linux distro. It's more of a way of creating Linux distros. But if you take it a step further, there's no reason why it couldn't also be used to build *BSD systems as well by specifying a *BSD kernel instead. If that can be done, then Rubyx is something much more than just another Linux distro. It would be a sort of a cafeteria-style system builder: I'll take this Darwin kernel and this GnuStep WM and this MPlayer and... There are lots of possibilities. Is Linux too vulnerable to attacks this week? Ask Rubyx to build you a system with an OpenBSD kernel instead.
I'm sure with a little effort a system without any sigils at all could be worked out for Ruby. Indeed, if you set up accessors for all your instance and class variables right off the bat, you needn't ever use the sigils at all outside the initialize method. The only thing the sigils buy you is not having to declare non-local variables to be class or instance variables. In this respect Ruby could stand to learn something from Perl, especially with regards to local(). That said, I much prefer Ruby to Perl in all other respects.
So, is anyone still reading who is familiar enough with Rubyx to tell me if I can bootstrap this onto an existing system, or will this require me to reinstall from scratch? Am I getting this right that it can create a bootable CD image?
I do not have a signature
> FYI, there's another initiative to develop a fully Ruby-based operating
> system (including the kernel), though one wonder when -- if ever -- this
> project will deliver something usable.
The mere existence of the initiative, as anything other than a joke, increases
my interest in Ruby a thousandfold. I've been passing on learning Ruby because
I've been figuring it's Yet Another Language With Perl Envy, but if these
people understand the importance of writing an operating system in a VHLL
and throwing out all the legacy C code, then I'm going to have to pay some
closer attention to the language they want to do it in. Maybe they've got
something after all.
Cut that out, or I will ship you to Norilsk in a box.
It's been done. 20 years ago. My first serious workstation development was on a Symbolics Workstation whose OS was written in LISP. We had a windowing operating system with bit-mapped graphics, source-level debugging, suspend-substitute-and-continue code execution. Just all kinds of cool stuff. And coding in an OO LISP was the best experience. Ruby and Perl have both similar levels of joy in programming, but as LISP was my first, it will always hold a special place.
Unfortunately it was too expensive. My workstation cost $125000. Alas...
Be careful what you wish for...
Where your treasure is there is your heart also...