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?..."
---For good measure, Rubyx (the os) sports an all new init and rationalised service management system written in ....can you guess?..."
PERL ?
Little too late....
Look down 1 post.
Mod the parent down redundant. It's obvious the comment is stolen.
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.
I am not familiar enough with Rubyx to comment on it one way or another. But I will tell you this - if I am ever in the market for an obscure and potentially very slow object oriented scripted OS - I will certainly consider Rubyx to be in my top 20 picks.
Lets start an OS written entirely in Logo. Drawing buttons and such will be easy enough, but it's the scheduler that is going to take some creativity. All user apps will also be written in Logo and it will be possible to virtualise the entire OS inside a user app. Extra care must be taken to ensure process don't write over the top of each other.
If Linux can become more flexible in the areas of package management and system configuration... For example, making it easy to run multiple versions of, say, gcc on the same system and switch between them at will; automatically generating configuration files based on system-wide settings. Seamlessly integrating with the latest source or binary packages of my favorite software ... and letting all these features be available from the bash shell, while making it easy for GUI wrappers to be built for those shell apps ... these are the things that can make Linux a more ideal platform! At the end of the day, I really don't care what language the configuration scripts are written in!
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.
I'm not too sure how this isn't 'Rubyx, the Linux distribution with an installer/package manager written in Ruby'. If it had been written in any other language, would it still be cool?
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 like scones ;-) They're wonderful for breakfast..
If Rubyx is an OS then it does: Mandrake. The installer is written in Perl and the package management is done with Perl. That is all Rubyx is.
But if you want an example of extreme silliness in Perl you can look at http://freshmeat.net/projects/perlbox/ a Desktop Environment written in Perl.
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? Are they a bit redundant in languages or does one have merit as a tool that the other doesn't.
If it's basically different tool that does more or less the same thing, I probably should just stick with what I know. I just haven't heard one way or another if it's worth putting that tool on my belt or not.
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.)
So, what do you think of gentoo's system, which is written using Bash and Python?
And Ruby isn't some academic language, it does tip it's hat to Scheme and Smalltalk much more than the other languages do, but that's part of it's appeal: you can write lovely dynamic object-oriented programs that modify their methods on the fly, suspend their execution with continuations, and zip around the network with distributed calls, but back on earth, you can also write a CGI script or a web server with it, or use regular expressions as first-class constructs like Perl.
Inertia and length of time on the market?
There was also some talk (I don't know how far this was pursued) about using Perl as your interactive shell program. Does Ruby have that?
github.com/chrispollitt
...of making an os based 100% on one language, why not be super hard-core and make it assembly?
Given that Seymour Papert designed Logo as Lisp minus parentheses plus turtle graphics, you might look to a Lisp OS for a proof that it could be done. Well, here's your prototype.
Who is Timoth 5?
Check out the 'modules' program at modules.sourceforge.net. It makes it fairly easy to switch between versions of any program you like (and choose to set up with modules).
It's distribution-agnostic (works on non-Linux UN*X, too). The common usage is more or less module load gcc2.95 (now, 'gcc' will execute gcc v2.95).
Anyway, as someone else mentioned, Debian already offers this for some packages (the package maintainer has to do some things differently to make it work). For gcc, there's a gcc-2.95 package which installs /usr/bin/gcc-2.95 (CC=gcc-2.95 ./configure; make CC=gcc-2.95; etc.). Relatively few packages are available under this scheme, though.
Debian also has 'alternatives' (/etc/alternatives) which route common binaries to a system-wide configurable version of a package (or meta package). Example uses of this system in mainline Debian are 'editor' (vim, emacs, nano, ...), 'sensible-browser' (galeon, mozilla, firefox, konq, ...), and 'java' (kaffe, sun, blackdown, ...).
Seriously, where do you get your statistics from? Your arse? Thought so.
a ^= b; b ^= a; a ^= b;
Why devote so much energy into implementing a mediocre system using ruby, of all languages, when you could spend time improving an existing system?
How do you know it's mediocre? Have you tried it?
Do you even understand what it does?
Total waste of time...99.99% of the code out there is written in C -based languages (java, php, C++) for a reason...
You could be the one that's totally wasting your time. One should choose the right language for the job at hand.
I recently inherited a project which took six months to develop in C++. It weighed in at ~4800 lines of C++ code. Since we needed to significantly expand the scope of the project and also add a GUI _and_ since execution speed wasn't an issue, but development time _was_ an issue I decided to rewrite the code in Ruby. It took a week and came to ~1200 lines of Ruby. The resulting Ruby code is much more flexible and easier to modify and add to than the previous C++ codebase (good riddance to it). I'll gain back that week invested to do the conversion several times over as the project progresses and as the requirements (inevitably) change... and I'll keep my sanity.
Choose the right tool for the job. If speed of execution is an issue then by all means use C/C++ (I do). However, if you need to develop code quickly then use an agile (aka scripting) language - I prefer Ruby for that role.
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
(Anyone caring to translate this character?
At first glance, I thought this would be similar to Cleese, a Python-based operating system, but it isn't: RubyX is a distro with some stuff written in Ruby, and Cleese is an actual effort to write a kernel in Python. Not that it's progressing a lot, though... the CVS tree can be found here.
When will it be self aware?
I rather dislike Ruby.
Oh, it's got consistent semantics and a decent object model (a proto model would have been better) and every CS professor's favorite item: true closures. But Ruby has one nasty feature which trumps 'em all. It was designed by an ex-Perl guy, and as such Ruby has approximately five billion different ways of writing the same syntax. As long as it can't be "misinterpreted", you can delete or change all sorts of stuff.
This is language design which borders on the grotesque. Great. So I can write any way I want. That means that every OTHER programmer can too, including everyone I'm collaborating with. So to understand their code, I have to know not only My Favorite Syntax but I have to know all *their* favorite syntaxes as well. Repeat after me: knowing the syntax of a language should demand as few neurons in your brain as possible. Ruby violates this on a grand scale.
What's next, a browser written in Ruby? A ruby interpreter written entirely in Ruby?
I recently inherited a project which took six months to develop in C++. It weighed in at ~4800 lines of C++ code.
Okay, be fair, how much of that six months was analysis and design time vs actual coding? With a bit of effort I can do 4800 lines of C++ in a weekend if I already know my overall design and data structures going in (*)-- and you had that advantage doing the rewrite in Ruby.
That said, I certainly agree with choosing the right tool for the job, and scripting languages do lend themselves to rapid production of working code. (May not be scalable, or many not handle corner cases well, but it depends on the task at hand.)
((*) Extrapolating from a "personal best" of about 3000 lines in one day. And yes, the code worked, after cleaning up a few typos.)
-- Alastair
Well, Ruby does have an interactive mode, whereas Perl does not. I suspect this would make it easier to modify to such purposes, if you were nuts.
Karma: It's all a bunch of tree-huggin' hippy crap!
So they haven't yet implemented garbage collection -- what do you do, keep putting in more RAM sticks?
That's a sort of lame argument... perl doesn't have an "interactive mode" because it doesn't need one. Look at this, ma, no hands:
.= <STDIN>) {
#!/usr/bin/perl
use strict;
my $buffer = '';
print "[perl] ";
while ($buffer
# check if code compiles, else allow continuation of input, ala shell
my $code = eval "sub {no strict; $buffer}";
if ($code) {
print &$code;
$buffer = '';
print "\n[perl] ";
}
else {
print "> ";
}
}
Which gives you an interactive perl session like so:
[me@host]$ perl interact.pl
[perl] 1+
> 1
2
[perl] ++$x
1
[perl] ++$x
2
[perl] for (1..5) {
> print "sucka!\n";
> sleep 1;
> }
sucka!
sucka!
sucka!
sucka!
sucka!
[perl] exit
[me@host]$
Now, really... How hard was that? Was it worth building into the interpreter? Is it better than building it into the interpreter because the code is right there, and you can do something differently with it if you want?
:Wq
Not an editor command: Wq
At that point you're not using Perl as your interactive shell, you're using a script written in Perl as your active shell.
Karma: It's all a bunch of tree-huggin' hippy crap!
The interactive Ruby mode isn't built into the interpreter. It's a Ruby program nameed "irb" that is distributed with Ruby. It is also more comfortable than your little try, it has got a history, a builtin Ruby Lexer and usually calls the inspect method for every object.
/^a/" into irb.
Perl has built in something like an interative mode, try this:
perl -de1
But in comparison to Ruby's it sucks, and I rarely use it while I use the irb the whole time. Perhaps it is also more useful because Ruby's introspection possibilites are so much better than Perl's, that is: you can find out the instance methods of an object that begin with "a" by typing "object.methods.grep
Or you can find out all the instance variables of object by typing "object.instance_variables"
So I disagree, Perl would need an interactive mode, and to be really useful it would need an object model that isn't totally fucked up.
I've installed and used Rubyx and have found it a pleasant surprise, my past Linux experiences have been with RedHat, Mandrake and Gentoo. The package management in Rubyx handles package dependencies far better than RedHat RPMs and Gentoos emerge. I can also figure out where my applications have been installed and all the files related to that application by looking in the /pkg directory, so simple yet so effective! I'm sick of operating systems scattering there files across my harddrive not giving me any idea what needs to be removed to completely un-install an application from my system.
Rubyx is clean, simple and doesn't hide anything!
I actually use GCC-3.3.4-20040301 (as gcc33), GCC-3.4.0-20040303 (as gcc34) and gcc-ssa-3.5ssa-0.20040304 (as gcc35) for building packages well-benchmarked.
I'm building a linux-system for my EPIA 733 MHz / 6 Watts:
export CFLAGS="-Wall -pipe -DNDEBUG -O2 -fomit-frame-pointer -march=i586"
export LDFLAGS="-Xlinker -s"
export CXXFLAGS="$CFLAGS"
open4free: my gods are two: C and C++
FreeBSD's "portupgrade" system is able to find, build, install, and resolve conflicts in both source and binary distributions of FreeBSD ports/packages even with a moving target of a source tree, with full potential for overrides and magic.
I use it constantly for system maintainence; it fits the Source-based BSD philosophy beautifully, the way APT fits Debian's Binary-package-based orientation.
The only thing that keeps it from being in the base install is that it requires Ruby.
- J