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?..."

Comments

haha

[Anonymous Coward]

got here first

Article...

[Creepy Crawler]

---For good measure, Rubyx (the os) sports an all new init and rationalised service management system written in ....can you guess?..."

PERL ?

Re:Article...

[JDWTopGuy]

RTFA, it's in Malbolge.

Ummm...

[heldlikesound]

"Rubyx (the os) sports an all new init and rationalised service management system written in ....can you guess?"

Perl?

Re:Ummm...

[Creepy Crawler]

Little too late....

Look down 1 post.

Re:Ummm...

[timothv]

Mod the parent down redundant. It's obvious the comment is stolen.

Re:Ummm...

[Anonymous Coward]

Who is Timoth 5?

insane

[Anonymous Coward]

Wouldn't it be better to try and make the best operating system possible than this childish attempt to prove that Ruby is better than we think, and make people get it's attention?

Ruby is not ment for this kind of software and if people can't handle that it's their loss of time and hard work.

It's like building a boat with only stone.
But we have some nice wood right over here!
Pfft, I came up with the idea to use stone and we stick to that!

(posted as anonymos so i wont get flamed to hell by ruby zealots)

Re:insane

[cowens]

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.

Re:insane

[Anonymous Coward]

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! :-)

Re:insane

[Anonymous Coward]

flamebait?

It's called facts you ruby programmer who accidentally became a moderator.

ROS

[davegaramond]

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.

Re:ROS

[jonadab]

> 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.

My thoughts on Rubyx

[Anonymous Coward]

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.

Re:My thoughts on Rubyx

[the_womble]

If you had actually followed the link you would know that the whole OS is not written in ruby. It is Linux with a ruby installer and package system.

Re:My thoughts on Rubyx

[Anonymous Coward]

The number one choice would be Emacs.

Re:My thoughts on Rubyx

[Trejkaz]

Interesting. Gentoo is Linux with a Python package system, so why is Rubyx so special? ;-)

Re:My thoughts on Rubyx

[Anonymous Coward]

Because it's Linux with a Ruby package system.:)

Logo

[Steven Reddie]

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.

Enhanced Package Management

[osewa77]

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!

Re:Enhanced Package Management

[Jerf]

I don't want to be accused of irrational advocacy of any particular distribution, but for the record, everything you mention in your posts already exists in at least one very popular distribution, and probably more.

Perhaps you should poke around the existing world a bit more. If you've only tried one distro odds are good you haven't found your match. Red Hat(/Fedora), Gentoo, and Debian are probably good ways to sample the major ways of doing distros; each has a fairly different philosophy and is large enough to have good implementations of the philosophy in running code. OK, I'm a Gentoo myself, and that's the distro I was referring to above, but they are all good distros and I've had the opportunity to use them all lately from start to finish, and they are all fine choices.

(I think Debian meets all your requirements too, but I'm not too sure about the multi-gcc one. I'd expect it is but there might not be a built-in switcher. Gentoo has 'gcc-config', which works as you describe, and also has a pretty clear "configuration files based on system-wide settings", the USE flags. Fedora I'd have to check on; I don't how clean you could make source integration but good package management in it is definately possible if you use yum in addition to rpm; rpm alone kinda sucks but with yum it's OK. I don't think multiple gcc's works well in Fedora, but I could be wrong. If you have a source RPM I believe it's rpmbuild --rebuild [source RPM] but I don't have Fedora handy to look at the man pages; corrections welcome on anything in this paragraph. I've used them all but I wasn't looking for these specific things.)

"What's your distro?"

Re:Enhanced Package Management

[Anonymous Coward]

Yes, all this is cool, and it needs to be written in a clear, object-oriented, unit-tested, well-documented way, with logical API's and separation between modules, so that writing quick scripts to solve problems is super-easy.

I have more hope for Ruby because, because it seems more experienced people are using it, while the masses are using Python.

Gentoo's package system is written in Python and it doesn't seem to meet all those goals I listed above. Is this Ruby-based system any better? Who knows.

Re:Enhanced Package Management

[Deagol]

(I apologize for this lengthy off-topic post, but I had to respond to the parent's desire for concurrent multiple versions in a package system. Maybe someone with coding skill -- unlike myself -- could run with it.)

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:

/mfs/pkg/openssh/3.8p1
/mfs/pkg/zlib/1.2.1
/mfs/pkg/openssl/0.9.6l
/mfs/pkg/tcp_wrappers/7.6

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

Re:Enhanced Package Management

[Nevyn]

Maybe someone with coding skill -- unlike myself -- could run with it.

There is already stow.

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.

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...

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

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.

But another great benefit is that you can change the stable version on the fly, on a live system, simply by pointing that stable link to the version you wish it to now point to (yes, sometimes between versions you gain or lose files, so this is not perfect).

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).

Re:Enhanced Package Management

[LittleBigLui]

I'm a Gentoo myself

Don't worry, on the internet nobody knows you're a penguin.

Re:Enhanced Package Management

[stevey]

I think Debian meets all your requirements too, but I'm not too sure about the multi-gcc one.

Yes it does.

If you install gcc v2.9x and gcc v3.x you end up with something like this

/usr/bin/gcc is symlinked to /usr/bin/gcc-3.3 and there is still a /usr/bin/gcc-2.95.

That way you have a default which is gcc, and the option of being explicit about the version if you really care which compiler you use.

I think that meets the requirements of having two side-by-side compilers.

Re:Enhanced Package Management

[Circuit Breaker]

Yes, it is cool. Check out Dan Bernstein work on package management at http://cr.yp.to/slashpackage.html

Re:Enhanced Package Management

[Cthefuture]

That sounds a lot like the MacOS bundle system.

That is, an application and all or most of its dependencies can exist in one directory. To install the application you just copy a directory. Delete the directory to uninstall.

The ROX filer can also do this for Linux but I haven't used it much.

By the way, I use GCC 2.95, 3.0, 3.2, and 3.3 on Debian all at the same time (for compatibily tests). Debian is pretty good about concurent versioning.

Re:Enhanced Package Management

[Z-MaxX]

This sounds a LOT like how GoboLinux does things.

From the GoboLinux FAQ:

What the heck is GoboLinux?

GoboLinux is a Linux distribution that breaks with the historical Unix directory hierarchy. Basically, this means that there are no directories such as /usr and /etc. The main idea of the alternative hierarchy is to store all files belonging to an application in its own separate subtree; therefore we have directories such as /Programs/GCC/2.95.3/lib.

To allow the system to find these files, they are logically grouped in directories such as /System/Links/Executables, which, you guessed it, contains symbolic links to all executable files inside the Programs hierarchy.

To maintain backwards compatibility with traditional Unix/Linux apps, there are symbolic links that mimic the Unix tree, such as "/usr/bin -> /System/Links/Executables", and "/sbin -> /System/Links/Executables" (this example shows that arbitrary differentiations between files of the same category were also removed).

Re:Enhanced Package Management

[Corporate Gadfly]

There is already stow [gnu.org].

I prefer to use xstow which is a replacement of GNU Stow written in C++. It supports all features of Stow with some extensions.

Re:Enhanced Package Management

[Deagol]

That, my friend, is awesome! I'm browsing the site now. The tree structure is just what I describe (more or less). I don't know if they use a decent package manager, but I'll keep reading.

Thanks for the link!

Re:Enhanced Package Management

[Deagol]

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...

My specific gripe was Redhat 7.1, I think -- the ssh version is woefully out of date and vulnerable. There are no more vendor upgrades (I don't know if LegacyFedora.org has the updates). The point was that sometimes you run into "dependancy hell" on systems that aren't current.

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 ...

From a system standpoint, it doesn't really matter how much spaghetti is under the hood, does it? For my hand-maintained version of my tree, I have scripts that traverse the tree, removes all of the links, then re-links them whenever I install a new "stable" version. Yes, this is inefficient, as I do all of them, rather than only the new packages -- but I only maintain maybe 100 apps this way, so it works for me. More intelligent automation would re-link only those items whose "stable" pointer had changed. It really does work.

I'd disagree, openssl is pretty notorius of breaking backward compat. on library upgrades.

I think you totally missed the point. With this system, you can install as many new/old/cvs versions of openssl you wish. Binaries linked against a particular version will still point directly to /mfs/pkg/program/version/lib/foo.a. If you're thinking that that apps are built to link to the symlinked libraries in /mfs/lib/foo.a you have a point, but that's not what I do.

The benefit is that you can install any package, and it will never affect another package.

Sure, you can wind up with lots of cruft, but an intelligent package manager will track these and know when a particular dependancy is no longer needed then, finally, remove it.

Understatement of the century. Be very affraid of any "package management" system that hand waves away problems like this

I never suggested that a "package management" system be this sloppy. I only stated that it could be done -- I do it on less complex packages. It works, too, until I get around to re-linking the tree.

Good points, but I think you underestimate the flexibility of the system.

Re:Enhanced Package Management

[Anonymous Coward]

Ahem. You didn't read 'Using Rubyx' yet, did you? Rubyx puts packages into directories under /pkg, and creates symlinks into the legacy filesystem.

And it builds all it's packages in user-mode as well.

Re:Enhanced Package Management

[Deagol]

I just glanced at it. The Rubyx method isn't as granular (for lack of a better word) than the method I describe or the one that GoboLinux uses.

It takes the concept part of the way, but does not take it to its logical extreme.

Re:Enhanced Package Management

[mjand]

you might want to look into the gentoolinux distribution and their concept of "slots".

Re:Enhanced Package Management

[Nevyn]

My specific gripe was Redhat 7.1, I think -- the ssh version is woefully out of date and vulnerable.

And my probably badly phrased retort was that if the entire OS is out of date there is an obvious solution upgrade the OS. The 95% use case (IMO) is being able to upgrade certain application(s) (those that the user(s) care significantly more about than the rest) when most of the system is at the latest stable version ... ergo. security updates should almost certainly be got in the normal way.

This is what the external Fedora trees, and debian unstable/testing try and do ... and they are much closer to something that people can realisticly use and not screw themselves with.

From a system standpoint, it doesn't really matter how much spaghetti is under the hood, does it?

I would have to say yes, it does, esp. when talking about LD_LIBRARY_PATH etc. which have to be preserved in all the environments you want to run an application. One of the minor problems on my boxes atm. is that "ssh foo cmd" stopped working last OS upgrade because "cmd" is in $HOME/bin and for some reason that isn't in the PATH when just running the command over ssh (but if I ssh and then run the command manually it works fine). Also setuid apps. will just not honor LD_LIBRARY_PATH.

I think you totally missed the point. With this system, you can install as many new/old/cvs versions of openssl you wish.

This is not true, maybe I didn't explain very well libraries link to openssl ... so if libA links to openssl and appB links to libA and openssl you cannot just compile appB if you have previously upgraded openssl (and the symlinks are using the new version). Your examples used static libraries, but I assume that was just a typo ... and it doesn't help you anyway it'll just not give a compile time error some of the time.

The biggest hit you currently take here is gtk/gnome/app. But you have to be able to manage this problem all the way down to libc changing the "public interface ABI" -- and realistically you should try managing some of the private ABI changes of glibc (which I'm guessing would be a lot worse in a stow based system).

Re:Enhanced Package Management

[Trejkaz]

Isn't switching between multiple versions of gcc as easy as using "gcc-config" under Gentoo? Come to think of it, it uses much the same scheme for switching between multiple versions of everything else which has alternatives... OpenGL, Java, ...

Re:Enhanced Package Management

[Trejkaz]

As opposed to building packages in kernel mode?

Re:Enhanced Package Management

[k_head]

Dude. Next time before you go through all that work do a google search.

Check out encap.

Re:Enhanced Package Management

[h3]

I use and like http://www.encap.org/

Re:Enhanced Package Management

[awalrond]

:)

How would you phrase it? Non-root user?

Re:Enhanced Package Management

[Trejkaz]

Pretty much. Although I like the way Portage does it. You're root, but since you're sandboxed any build which tries anything funny will be denied.

Re:Enhanced Package Management

[horos2c]

> I'm sure there are problems that a real package
> maintainer would spot right away, but I think
> this system is probably feasible to roll into a
> full package management system. And, no, I
> haven't tried all 1273 linux distros out there,
> so somebody may actually be doing this already.
> I'd love to hear about it.

> Damn -- I hope somebody thinks this is a cool
> idea. :)

yeah, I built something like what you describe. Got a packaging management system that builds from code and does exactly what you mention. Works for solaris, os390, linux, aix, win32 (via cygwin) and builds into multiple prefixes that can be switched at will.

Programmable ( you define a build process via a subroutine that matches the project file name) handles patch management, version management, user configuration files (which are source controlled), package creation, user tweaks and interactive input, 'manual' editing of projects (just in case configure breaks down when creating Makefiles) and so forth.)

I'll release it someday; unfortunately right now its (loosely) tangled around some proprietary stuff, but I'll untangle it.

Oh yeah, its written in perl.. (of course). what's this newfangled ruby/python thing I'm hearing about nowadays? ;-)

horos

(ps - forget about debian and gentoo doing this... in fact, I integrated debian into my process because the packages have lots of assumptions; man in /usr/local/man, etc)

in fact, its generally hell to do this. source control projects are not that careful with making their projects 'path independent'; they tend to hard code things, or have dependencies buried in config files. Sometimes I need to have my process 'hand' edit files that make generates as part of an intermediate step, sometimes autoconf gets things wrong, etc. etc. So its not a small task. For the time being you are better off doing what you do already.
)

Re:Enhanced Package Management

[horos2c]

oops - s/source control projects/open source/g horos

Re:Enhanced Package Management

[Anonymous Coward]

Arachen 1.70 was, or appeared to be, an OS within an OS. I have run it within Windows 98 dos.

Um, isn't this just another Linux distro?

[ivern76]

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?

Re:Um, isn't this just another Linux distro?

[popeyethesailor]

Damn straight. They should have named it GNU/Glibc/XFree(C)TM/QT/KDE/Ruby-Lang/Rubyx .

Re:Um, isn't this just another Linux distro?

[FFFish]

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.

Re:Um, isn't this just another Linux distro?

[dagbrown]

Actually, there are a couple of cool things about Rubyx that make it different from a run-o'-the-mill Linux distro, and the language they're in ain't one of 'em.

The first is that it's self-bootstrapping--you can just download the Rubyx script and use that to build an install ISO. That's pretty darned cool if you ask me.

The other cool thing about it is that it completely eschews the entire SysV init system with one of its own, based on dependencies instead of on educated guesses by the sysadmin (read: arbitrary order) as to what order services should start up and shut down in. This lets you speed up booting by starting independent services concurrently instead of waiting for each service to start up individually.

Re:Um, isn't this just another Linux distro?

[Feztaa]

several of the Linux and BSD distros use Python for their installers.

Yeah, and you don't see Fedora calling itself "Pythonx" :)

Re:Um, isn't this just another Linux distro?

[Colonel Panic]

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.

Re:Um, isn't this just another Linux distro?

[cyborch]

The other cool thing about it is that it completely eschews the entire SysV init system with one of its own, based on dependencies instead of on educated guesses by the sysadmin (read: arbitrary order) as to what order services should start up and shut down in. This lets you speed up booting by starting independent services concurrently instead of waiting for each service to start up individually.

I'm not booting very often, so the speedup isn't that important to me (a speedup is still nice, tho), but the increased ease of configuration is nice indeed!

Re:Um, isn't this just another Linux distro?

[Anonymous Coward]

The first is that it's self-bootstrapping--you can just download the Rubyx script and use that to build an install ISO. That's pretty darned cool if you ask me.

Gentoo has Catalyst.

The other cool thing about it is that it completely eschews the entire SysV init system with one of its own, based on dependencies instead of on educated guesses by the sysadmin (read: arbitrary order) as to what order services should start up and shut down in.

Gentoo is the same.

So when is PerlOS coming out?

[topher67]

If Ruby can have its own OS, so should Perl.

BTW, on a somewhat related note, I still think Cons is a better idea than SCons but now were getting into language wars...

Re:So when is PerlOS coming out?

[Creepy Crawler]

I like scones ;-) They're wonderful for breakfast..

Re:So when is PerlOS coming out?

[cowens]

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.

Re:So when is PerlOS coming out?

[topher67]

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?

Re:So when is PerlOS coming out?

[Trejkaz]

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.

Re:So when is PerlOS coming out?

[etcshadow]

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:

#!/usr/bin/perl
use strict;

my $buffer = '';
print "[perl] ";
while ($buffer .= <STDIN>) {
# 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?

Re:So when is PerlOS coming out?

[Trejkaz]

At that point you're not using Perl as your interactive shell, you're using a script written in Perl as your active shell.

Re:So when is PerlOS coming out?

[xteddy]

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.

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 /^a/" into irb.
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.

a Ruby-based package manager?

[Anonymous Coward]

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.

Who the hell cares?

[Anonymous Coward]

Why devote so much energy into implementing a mediocre system using ruby, of all languages, when you could spend time improving an existing system? These guys just did things that people have already done using a novel tool that has no real benefits for the task. Really, a programming language is just a tool...it's the binary that matters, regardless of how you created it...and the end result really has no practical use. Mod me into oblivion, I don't care...this is just a waste of time...it's the same people who spend all this time fooling around with those academic languages like SML and Scheme. Total waste of time...99.99% of the code out there is written in C -based languages (java, php, C++) for a reason...

Re:Who the hell cares?

[Anonymous Coward]

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.

Re:Who the hell cares?

[cowens]

99.99% of the code out there is written in C -based languages (java, php, C++) for a reason...

Inertia and length of time on the market?

Re:Who the hell cares?

[pyman]

99.99% of the code out there is garbage and would be better written in INTERCAL.

Seriously, where do you get your statistics from? Your arse? Thought so.

Re:Who the hell cares?

[Colonel Panic]

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.

Re:Who the hell cares?

[AJWM]

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.)

hmm.. maybe a bit Off Topic.. but

[Pengo]

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.

Re:hmm.. maybe a bit Off Topic.. but

[Jerf]

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.

Re:hmm.. maybe a bit Off Topic.. but

[Anonymous Coward]

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.

Re:hmm.. maybe a bit Off Topic.. but

[Anonymous Coward]

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:

class Thing
attr_accessor :foo, :bar
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.

Re:hmm.. maybe a bit Off Topic.. but

[ibbey]

The AC parent should be modded up... Excellent comparison of the two languages.

Re:hmm.. maybe a bit Off Topic.. but

[gavri]

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.

Re:hmm.. maybe a bit Off Topic.. but

[trouser]

One definition of sigil is 'magic symbol'.

Having recently used Perl for the first time I found the use of 'magic symbols' like '@_' and '$_' confusing. Does Ruby have similar 'features' ?

Re:hmm.. maybe a bit Off Topic.. but

[Colonel Panic]

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.

Re:hmm.. maybe a bit Off Topic.. but

[Discordantus]

It has some of them. But their use is mostly discouraged... the ugliness of the $s and @@s are supposed to keep people from using them :) Also, there are many excellent constructs built in to replace them. Take Perl's regex match variables, for instance. Here is an example of a Ruby way of using regex matching, where you can collect "MatchData" objects from a match:

(note that '#' starts a comment, and => (value) in an end-of-line comment is showing the resulting value of an expression.)

re = /(\d+):(\d+)/ # match a time hh:mm
md = re.match("Time: 12:34am")
md.type #=> MatchData
md[0] # == $& => "12:34"
md[1] # == $1 => "12"
md[2] # == $2 => "34"
md.pre_match # == $` => "Time: "
md.post_match # == $' => "am"

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 :)

Re:hmm.. maybe a bit Off Topic.. but

[ichimunki]

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?

Re:hmm.. maybe a bit Off Topic.. but

[cyborch]

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 have never used python, so I can't comment on whether python has more readily available libraries than ruby has, but ruby has a CPAN-like institution called RAA and raa-install (the ruby version of "perl -MCPAN -e shell"). Does python have something similar?

Re:hmm.. maybe a bit Off Topic.. but

[avdi]

Then again, if you consider things like _foo and __bar__ to be just as ugly as Perl sigils, you won't find ruby to be any more of an abomination than Python!

Re:hmm.. maybe a bit Off Topic.. but

[Genghis Troll]

Yes, you can bootstrap it into an existing system.

To create a bootable cd, you just do "rubyx --create-iso /path/to/yourrubyxinstall name.iso", and then burn the iso yourself.

Re:hmm.. maybe a bit Off Topic.. but

[Jerf]

I don't recall claiming that Ruby sigils indicate type. I seem to recall claiming they exist.

I also don't recall claiming that they "obfuscate" code. I seem to recall claiming that I don't like them, and if you also feel that way you won't want Ruby.

Please read what I said, not what you expected me to say, it's better for all of us.

Re:hmm.. maybe a bit Off Topic.. but

[Jerf]

but ruby has a CPAN-like institution called RAA and raa-install (the ruby version of "perl -MCPAN -e shell"). Does python have something similar?

No, but at this point the only reason for that is that they are typically not necessary. In Perl, when I need to get anything done I need to install 10 or 20 CPAN modules. Generally, in Python, they came with the interpreter and I only need to install two or three. This is why no similar thing has emerged.

(This is going on the "People are in general equally smart"... if Python needed such a thing it would exist. It doesn't, therefore it is a reasonable conclusion that it is not needed. It's not "logically rigorous" but it's a fairly good guess.)

Re:hmm.. maybe a bit Off Topic.. but

[gavri]

I don't recall claiming that Ruby sigils indicate type. I seem to recall claiming they exist.
I also don't recall claiming that they "obfuscate" code.

I don't recall claiming that you claimed that Ruby sigils indicate type.

I also don't recall claiming that you claimed they "obfuscate" code.

Please read what I said, not what you expected me to say, it's better for all of us.

Re:hmm.. maybe a bit Off Topic.. but

[Jerf]

For the record... (the >>> indicates I'm running this in the interpreter, and allows you to seperate what I'm entering vs. the interpreter output; if you've got it installed and if you're on Linux you probably do, type 'python' and you can follow along...)

>>> import re
>>> r = re.compile(r"(\d+):(\d+)")
>>> md = r.search("Time: 12:34am")
>>> md
<_sre.SRE_Match object at 0x400890f8>
>>> md.group(0)
'12:34'
>>> md.group(1)
'12'
>>> md.group(2)
'34'
>>> md.string[:md.start()]
'Time: '
>>> md.string[md.end():]
'am'

Note that Python explicitly is not written to minimize keystrokes; if you're choosing languages bear that in mind. In my experience, this is a good thing (I tend to get it right the first time much more often) but of course YMMV.

The "r" in front of the RE expression indicates a "raw" string, which tells Python that the backslashes are literal for everything except \\ and \". This makes it easier to write RE expressions. I could also have written

>>>r = re.compile("(\\d+):(\\d+)")

but that is less readable.

Personally, I slightly prefer RE's not really being treated specially, but at least in Ruby it looks like they can be passed around as first-order objects; the gyrations this takes in Perl is annoying.

Re:hmm.. maybe a bit Off Topic.. but

[cyborch]

No, but at this point the only reason for that is that they are typically not necessary. In Perl, when I need to get anything done I need to install 10 or 20 CPAN modules. Generally, in Python, they came with the interpreter and I only need to install two or three. This is why no similar thing has emerged.

(This is going on the "People are in general equally smart"... if Python needed such a thing it would exist. It doesn't, therefore it is a reasonable conclusion that it is not needed. It's not "logically rigorous" but it's a fairly good guess.)

I know i'm going to burn karma saying this but...

Does that make python as big and bloated as java? Java comes with loads of stuff, and the java programmers I know generally tend to think that there are no libraries outside those that java ships with. I tend to favor the perl approach. It gives the feeling of openness and freedom to choose what I like. If I suggest googling for a java library that does some task I am labeled a heretic. I'd much rather have a small built-in library and a lot of freedom than a huge library with the lock-in feel that is in java.

This may come down to a matter of taste in which way of life you like better, rather than which way is the best...

Re:hmm.. maybe a bit Off Topic.. but

[Anonymous Coward]

really? I actually find the python one easier to read and more importantly UNDERSTAND.

A person who doesnt know python at all can still read that snippet and get a sense of what is going on. While a person who doesnt know ruby (me for one) would get confused by the |t|. Are you taking the absolute value (which is my first gut interpretation)? If || has a special meaning what is it?

Using non-alphanumeric characters as syntax is exactly the problem perl has (to an extreme) that ruby seems to have.

Re:hmm.. maybe a bit Off Topic.. but

[Discordantus]

You are correct, regexes are full-fledged objects in Ruby. In the Ruby interactive interpreter (">>" is me, "=>" is the interpreter):

>> /foo|bar/.match("this foo that").to_s # the matched string
=> "foo"
>> %r(/etc/hosts|/bin/sh).class # returns the object's class
=> Regexp
>> a = /(foo)bar/m # stores it in a variable
=> /(foo)bar/m
>> /test#{a}test/i # embed it using #{} (string interpolation)
=> /test(?m-ix:(foo)bar)test/i

Usually the %r syntax is used to make the regex clearer, like when you don't want to have to escape a bunch of slashes. Similar to Perl, anything can be a delimiter, so you can pick what looks best in the situation.

>> # an array of regexen!
>> [ %r(foo/bar), %r:(foo/bar):, %r_(:foo/:bar)_ ]
=> [/foo\/bar/, /(foo\/bar)/, /(:foo\/:bar)/]

After learning Perl, I went looking for a language with a clearer syntax. At first I looked at Python, and the only reason I didn't stick with it was that I like being able to use regex literals. So I guess it's a matter of taste.

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 :)

Re:hmm.. maybe a bit Off Topic.. but

[xteddy]

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!

Re:hmm.. maybe a bit Off Topic.. but

[Anonymous Coward]

The Python version looks easier to read to me.
And, of course, to an average person (i.e. manager) who is used to reading plain English.
Python is just a much cleaner language.

Re:hmm.. maybe a bit Off Topic.. but

[Tukla]

I don't understand why other programmers shunning third-party Java classes would make you feel "locked-in".

Re:hmm.. maybe a bit Off Topic.. but

[LWATCDR]

I have also heard.
"Why should I learn c I know Pascal/Fortran/ASM."
And I have often heard "Why should I learn Python I already know Perl."
The real question is why not learn a new language. Once you know it then you can decide if it is a good solution for you.

A little too much Fanboy vibe

[Jerf]

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.)

Re:A little too much Fanboy vibe

[Colonel Panic]

The name Ruby x conveys a little too much "Ruby fanboy" vibe.

Perhaps. I suppose I'm a 'Ruby fanboy', but I did wince a bit when I saw the headline for this story which said something like "Rubyx - it shows the power of Ruby". I think there are lots of other things that show the power of Ruby better.

However, that said, there are zillions of Linux distros out there and they did need a name and since the rather novel init system is written in Ruby (a feature I really like about Rubyx, btw) it sort of makes sense to call it Rubyx, doesn't it?

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.

Instead of seeing it as deceptive, I see it as a way to keep their options open. How's that? Well, why couldn't the Rubyx script also be used to build a FreeBSD or Darwin system? It's just a different kernel after all, so why should you be limited to the Linux kernel? Now _that_ would be flexible. I hope they take it to that level, then it will be truely unique and not just another Linux distro.

Re:A little too much Fanboy vibe

[some guy I know]

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.

Yes, they should be calling it GNU/Linux/Rubyx.

Re:A little too much Fanboy vibe

[sonamchauhan]

> should be calling it GNU/Linux/Rubyx.

Grubyx! :)

If going to the trouble...

[lortho]

...of making an os based 100% on one language, why not be super hard-core and make it assembly?

Re:If going to the trouble...

[Vector7]

Or better yet, LISP.

Logo OS? Try a Lisp OS

[tepples]

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.

Re:Logo OS? Try a Lisp OS

[highwindarea]

I know you're joking but the mzscheme interpreter can actually be run as an OS. It's pretty useless, but going from pressing the button to a scheme prompt in 5 seconds in kinda cool.

Re:Logo OS? Try a Lisp OS

[alex_tibbles]

you might want to see Movitz a "Common Lisp OS development platform".

Re:Logo OS? Try a Lisp OS

[tamills]

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...

Re:Logo OS? Try a Lisp OS

[Trejkaz]

I guess these days since Common Lisp compiles to native code, it wouldn't be that evil. LOGO, however... is there even a single LOGO to binary compiler? Would you want to write one as part of this exercise? (I guess so, or you would have an interesting recursion problem.)

Re:Logo OS? Try a Lisp OS

[tepples]

is there even a single LOGO to binary compiler? Would you want to write one as part of this exercise?

Writing a Logo compiler or a Logo->CL translator would probably be straightforward for anybody who has studied compiler design, but I have more important things to do at the moment.

Re:Logo OS? Try a Lisp OS

[ShadowRage]

well, my little OS I'm building has an optional lips shell for you masochists out there.

Re:Logo OS? Try a Lisp OS

[ShadowRage]

note: typo was intended ;P

'modules', Debian Re:Enhanced Package Management

[metallidrone]

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, ...).

The Slashdot experience - By the Rubyx author

[awalrond]

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

Re:The Slashdot experience - By the Rubyx author

[Gopal.V]

Does the new init thing support parallell startup ? there was some way to start stuff like apache and mysql at the same time instead of serially ... though the original guys who tried this used "make" to handle dependencies

Re:The Slashdot experience - By the Rubyx author

[awalrond]

The stable version does semi-parallel startups. (Probably enough for most needs - see the script for details)

I am testing a simple variation of the init scipt which does it properly. I'm pretty happy with it and will probably release it in rubyx version 38.

Japanese

[GerritHoll]

Judging from the background image of the RubyX homepage, it's probably advantegeous to learn Japanese in order to get the full potential from it ;-)

(Anyone caring to translate this character?

Re:Japanese

[ladislavb]

The character ("li" in Chinese) means "power" or "strength" (in both physical and spiritual senses of the word).

Re:Japanese

[ichimunki]

See this table for a rough idea.

Cleese

[GerritHoll]

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.

So .....

[CoolCat]

When will it be self aware?

Actually, as a computer science professor...

[Anonymous Coward]

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.

That's what I thought...

[jkauzlar]

That's what I thought at first. I did some investigation. I researched the backgrounds of some of the lead developers. Turns out that none of them had ever written any perl. My next guess was prolog, but upon downloading the source, printing it out, and spending all day at the library sifting through the hundreds of pages, I discovered that the entire thing was actually written in a language called Ruby. You can imagine my surprise.

What's next, a browser written in Ruby? A ruby interpreter written entirely in Ruby?

No garbage collection (yet)

[Latent Heat]

So they haven't yet implemented garbage collection -- what do you do, keep putting in more RAM sticks?

Rubyx is clean and simple!

[Megadeath]

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!

Re:GCC-3.3.4-ss is very stable

[Anonymous Coward]

I had deleted the obsolete GCC-2.95.3 and <= GCC-3.2.3.

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.

[jjgm]

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