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 ?
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! :-)
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.
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.)
Consensus gestalt that I've gotten as a Python user and reading a lot of debates on this topic is that structurally, Ruby is a little more pure OO then Python, but the practical differences seem minimal, especially after the type/class unification in Python. (Ruby advocates are proud of their block syntax but I'm yet to see something I don't immediately know how to write in Python, too; the question is which fits your mind better.)
Syntactically, Ruby is more like Perl. If you consider sigils an abomination upon the land, as I do (despite working professionally in Perl), then you'll want Python. If you consider them Larry Wall's gift to syntax, then you'll want Ruby.
The other thing is, if you're expecting to use a library of some kind, check for availability. Python has the edge right now AFAIK but that doesn't matter unless Python has something that Ruby doesn't that you need, or vice versa; for most people my impression is that the necessary modules are there in both languages.
I use Python mostly for "work", but I much prefer Ruby and try to use it whenever possible.
If you are a theoretical guy who loves a conceptually elegant and consistent language like Smalltalk or Scheme, you'll love Ruby. Ruby is so consistent, it's really lovely.
If you're more practical and need good documentation and extensive libraries, you'll probably be annoyed by it.
If you like to write programs FAST but not sacrifice readability like Perl, you'll really love Ruby. For instance in Ruby, you don't have to type "self" in method argument lists the way you do in Python. Ruby is 100% object oriented inside and out. Classes are first class objects, subclasses of Module objects. There are no "old style classes" or "new style classes", no cruft held over from previous versions of the language.
In Python, you have built-ins like "str()" which can call the __str__() method on an object. None of that kind of repetition in Ruby. Just call obj.str (or actually, obj.to_s) directly. You don't need the parens in that case.
Ruby has "blocks" which are a nice syntactic sugar for a whole class of operations. For instance a database transaction can be implemented as a block:
transaction { |t|
do stuff with t
more stuff
}
in Python that would be:
t = start_transaction()
try:
do stuff with t
more stuff
finally:
end_transaction()
The ruby version is easier to read.
If you want a large selection of tools and implementations, well, Ruby doesn't have too many like Python.
Also the Ruby community is still small and friendly. The python community is turning into the Perl community, in my opinion. A little arrogant.
Python is starting to look more and more like Ruby every revision though.
Sigils? You mean punctuation at the front of variables? That's a little misleading, Ruby doesn't *require* them because you can program entirely with method calls:
:foo, :bar
class Thing
attr_accessor
def add_me_to_foo_and_bar(me)
foo + bar + me
end
end
t = Thing.new
t.foo = 5
t.bar = 34
puts "look: #{t.add_me_to_foo_and_bar(4)}"
And class variables, in my opinion should never be used. You should use instance variables on the class object, which uses similar syntax to the above and feels more consistent.
If you consider sigils an abomination upon the land, as I do (despite working professionally in Perl), then you'll want Python. If you consider them Larry Wall's gift to syntax, then you'll want Ruby.
In Ruby, Sigils indicate scope, not type! Whole different thing.
It doesn't obfuscate the code. Makes it easier to read actually.
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.
Seriously, where do you get your statistics from? Your arse? Thought so.
a ^= b; b ^= a; a ^= b;
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.
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.
(note that '#' starts a comment, and => (value) in an end-of-line comment is showing the resulting value of an expression.)
You can collect as many matches as you want before you process them. There are no freaky, hard to remember variable names that you need to remember. You can still do it the Perlish way if you want to, but a lot of that stuff has been slowly made less desirable to use. I wouldn't be surprised (or upset) if they disappeared altogether in the future.
Then again, there may be the exact same thing in Python, and you're wondering why it's special. Since I went to Ruby straight from Perl, I wouldn't know.
(The code was pulled directly from online docs, so I'm not pretending I wrote it :)
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'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
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.
Ruby is the first programming language I've used where I can actually write an entire script and have it work the first time. Not always, but fairly often. I've heard similar things (about Python) from my Python friends. To me, that is the most important aspect of a language, since debugging bugs me :)
The |x| is a block parameter list. Blocks are Ruby's way to emulate higher order functions.
[ 1, 2, 3 ].each { |x| puts x }
would print "1", "2" and "3" in three different lines.
The block parameters are very clever, you can also put something else than only variables there. If you want to compute the sum of the products of some pairs, you could do it that way:
a = [[1, 4], [2, 5], [3, 6]]
sum = a.inject(0) { |s, (x, y)| s + x * y }
The block would first be called with s = 0 and (x, y) = [1, 4], that would assign x to 1 and y to 4.
The inject would compute
s = 0 + 1 * 4
s = 4 + 2 * 5
s = 14 + 3 * 6 = 32
by calling the block three times once for every pair in the list and adding the results in the s and returning the result s.
The ||-syntax looks very similar to the Smalltalk syntax for local variables. Ruby is very strongly influenced by Smalltalk. The inject method name stems also from Smalltalk. You can use blocks to make sure something is done after a block of code has been executed instead of using destructors or finalizers. An example would be to close a file after reading it:
File.open("/etc/passwd") do |f|
puts f.read.count("\n") # => number of lines
end # => file f is closed here
do...end is equivalent to { } and usually used if the block is not an oneliner. Readability is actually very important in Ruby culture.
Ruby has an exception handling that is very similar to Python's, but the keywords seem to be blatantly stolen from Eiffel's Design By Contract. The transaction example from above could also be coded that way in Ruby:
t = start_transaction()
begin
do stuff with t
more stuff
rescue => e
puts "Caught an exception: #{e}"
ensure
t.end_transaction
end
I don't think that Ruby has a problem wth "non-alphanumeric" characters - it uses them very wisely, actually. I remember that Python uses lots of __foo__ and """bar""" - that really makes me feel uncomfortable when I have to read Python code!