Forum: Ruby Ruby's role in future operating systems

8ed45f7f2d23cc2ab08f78893a5feee8?d=identicon&s=25 Kyrre Nygard (Guest)
on 2006-06-09 16:53
(Received via mailing list)
Hey!

I'm relatively new to Ruby, but for damn sure consider it
the most important language to the future development of operating
systems.

Is there any material out there on this?
Or does anybody have any thoughts or experience?

I keep thinking that if all the Bash scripts in FreeBSD instead were to
be
Ruby, things would take less code and perhaps even move faster.
I'm sure there are other parts that could be replaced by Ruby as well,
anybody know?

All the best,
Kyrre
05be5d6610e2c3f1780aa0e39e902e93?d=identicon&s=25 Farrel Lifson (Guest)
on 2006-06-09 17:00
(Received via mailing list)
Have a look at Heretix:
http://www.h-e-r-e-t-i-x.org/doc/website/AboutHeretix.html

It's a source based Linux distro that uses Ruby for all it's setup.

Farrel
4299e35bacef054df40583da2d51edea?d=identicon&s=25 James Gray (bbazzarrakk)
on 2006-06-09 17:22
(Received via mailing list)
On Jun 9, 2006, at 9:51 AM, Kyrre Nygard wrote:

> I keep thinking that if all the Bash scripts in FreeBSD instead
> were to be
> Ruby, things would take less code and perhaps even move faster.

I wouldn't be so quick to dismiss the value of shell scripting
languages.  They target a different problem space:  gluing programs
together.  It's easy to write shell scripts using redirection and
pipes that would be significantly bigger when translated to Ruby.

James Edward Gray II
8ed45f7f2d23cc2ab08f78893a5feee8?d=identicon&s=25 Kyrre Nygard (Guest)
on 2006-06-09 17:36
(Received via mailing list)
At 16:57 09.06.2006, Farrel Lifson wrote:
>Have a look at Heretix:
>http://www.h-e-r-e-t-i-x.org/doc/website/AboutHeretix.html
>
>It's a source based Linux distro that uses Ruby for all it's setup.
>
>Farrel

Thanks Farrel, thanks a lot :)
8ed45f7f2d23cc2ab08f78893a5feee8?d=identicon&s=25 Kyrre Nygard (Guest)
on 2006-06-09 17:54
(Received via mailing list)
At 17:21 09.06.2006, James Edward Gray II wrote:
>
>James Edward Gray II

Hello James,

You're making a good point here. But to me it feels like a "if it works
don't fix it" kind of thing. I mean, all in all, wouldn't Ruby prevail?

Feel free to show me some examples though.

Also, what if this operating system were to use a Ruby shell?

All the best,
Kyrre
A90204c955db033cd975f7bb0ec9600b?d=identicon&s=25 Ashley Moran (Guest)
on 2006-06-09 18:29
(Received via mailing list)
On Friday 09 June 2006 15:51, Kyrre Nygard wrote:
> I keep thinking that if all the Bash scripts in FreeBSD instead were to be
> Ruby, things would take less code and perhaps even move faster.
> I'm sure there are other parts that could be replaced by Ruby as well,
> anybody know?

Don't forget the portupgrade tool is written in Ruby.  It's not part of
the
base system but it might as well be - virtually everyone uses it.

I started thinking I might start writing shell scripts in Ruby but I
realised
for most simple cases, standard bourne shell is easier.  It's only when
you
get to complex variable handling or lots of control structures Ruby's
advantage takes over.

Ashley
4299e35bacef054df40583da2d51edea?d=identicon&s=25 James Gray (bbazzarrakk)
on 2006-06-09 18:29
(Received via mailing list)
On Jun 9, 2006, at 10:52 AM, Kyrre Nygard wrote:

> Feel free to show me some examples though.

Well, try anything were you need to write to STDIN of an external
process, read it's STDOUT and STDERR, and check its return code.
Shells make that pretty trivial.

James Edward Gray II
76006c10b0773e69a6fcd70614ac258f?d=identicon&s=25 Joost Diepenmaat (Guest)
on 2006-06-09 18:41
(Received via mailing list)
On Sat, Jun 10, 2006 at 12:21:25AM +0900, James Edward Gray II wrote:
>
> James Edward Gray II

Also, some people are wary of having the "core"* functionality
dependent on complex technologies that are in a state of flux.

It can be pretty annoying if a "minor" language version upgrade
results in syntax errors all through the core system, while most
shells have had a stable, dependent "base language" for ages.

I seem to remember some distro (I think it was debian or one of
the *bsds) wanted to remove perl dependencies from the base os
for the same reason. That was a couple of years ago and I can't
seem to find any reference to that story now.

* core functionality is stuff like: low level system management,
startup scripts and package updates.

Joost.
51a34236538906ab994cf9f2e533d14d?d=identicon&s=25 Lou Scoras (ljscoras)
on 2006-06-09 18:41
(Received via mailing list)
> At 17:21 09.06.2006, James Edward Gray II wrote:
> >I wouldn't be so quick to dismiss the value of shell scripting
> >languages.  They target a different problem space:  gluing programs
> >together.  It's easy to write shell scripts using redirection and
> >pipes that would be significantly bigger when translated to Ruby.
> >

Precisely as James said.  This is part of  the Unix Philosophy and
what makes command-line interfaces so powerful.  Well behaved programs
can be used in pipelines to do far more than their creators originally
intended.

On 6/9/06, Kyrre Nygard <kyrreny@broadpark.no> wrote:
> You're making a good point here. But to me it feels like a "if it works
> don't fix it" kind of thing. I mean, all in all, wouldn't Ruby prevail?
>
> Feel free to show me some examples though.

    # mp32ogg [untested] - quick and dirty conversion:
    mpg321 -w - somesong.mp3 | oggenc -o somesong.ogg -

> Also, what if this operating system were to use a Ruby shell?

I believe this has been tried w/ several different languages before.
You could do it, but it's not awefully convienent because most general
purpose languages weren't designed for this (i.e.: they can't be typed
as quickly).
Bc6d88907ce09158581fbb9b469a35a3?d=identicon&s=25 James Britt (Guest)
on 2006-06-09 19:57
(Received via mailing list)
Louis J Scoras wrote:
>
Question (maybe a bit off-topic):

The example may be quick, but in what way is it dirty?

More generally, why do those two words get used as if they were joined
at the hip?    Is there a bias against being quick, a belief quick only
comes at the cost of clean code?

This "quick and dirty" dismissal comes up fairly often when describing
Ruby to the skeptical ("Well, Ruby may be good for quickandirty scripts,
but ..." ).

My usual response is that I prefer quick and dirty to slow and dirty;
Java or C# (the usual suggested alternatives for "real" programming)
offer no more assurance of clean code than using Ruby; indeed, the
opposite is likely more the case.

Just curious.

--
James Britt

"Programs must be written for people to read, and only incidentally
  for machines to execute."
   - H. Abelson and G. Sussman
   (in "The Structure and Interpretation of Computer Programs)
4b781b6ab8600b559b8d729f423db26e?d=identicon&s=25 Tait Pollard (customsgod)
on 2006-06-09 20:07
James Britt wrote:
> Louis J Scoras wrote:
>>
> Question (maybe a bit off-topic):
>
> The example may be quick, but in what way is it dirty?
>
> More generally, why do those two words get used as if they were joined
> at the hip?    Is there a bias against being quick, a belief quick only
> comes at the cost of clean code?
>
> This "quick and dirty" dismissal comes up fairly often when describing
> Ruby to the skeptical ("Well, Ruby may be good for quickandirty scripts,
> but ..." ).
>
> My usual response is that I prefer quick and dirty to slow and dirty;
> Java or C# (the usual suggested alternatives for "real" programming)
> offer no more assurance of clean code than using Ruby; indeed, the
> opposite is likely more the case.
>
> Just curious.
>
> --
> James Britt
>
> "Programs must be written for people to read, and only incidentally
>   for machines to execute."
>    - H. Abelson and G. Sussman
>    (in "The Structure and Interpretation of Computer Programs)

I'd have to agree in Java you are just as likely to scan hundreds of
lines looking for that missing curly bracket as you are in ruby to
search for a missing closure, and static typing brings up it's own
problems just as much as duck typing.
51a34236538906ab994cf9f2e533d14d?d=identicon&s=25 Lou Scoras (ljscoras)
on 2006-06-09 20:39
(Received via mailing list)
On 6/9/06, James Britt <james_b@neurogami.com> wrote:
>
> Question (maybe a bit off-topic):
>
> The example may be quick, but in what way is it dirty?

It is "quick and dirty" in that it is an incomplete solution in-so-far
as converting between the two formats in the most general sense.  That
is, if one were to stick that line into a file, chmod +x mp32ogg, it
wouldn't be very featureful (setting bit rates, meta information, et
cetera).

Then again, the whole point is the flexibility of using two or more
programs in all sorts of original and interesting ways.  If all I want
is to change the encoding, the above suffices admirably.  There's no
reason that extra options couldn't be specified either.

> More generally, why do those two words get used as if they were joined
> at the hip?    Is there a bias against being quick, a belief quick only
> comes at the cost of clean code?

I think I used that phrase because for as much as I hate them, I am
weak and easily fall into the temptation of using cliches *smirks.*

> This "quick and dirty" dismissal comes up fairly often when describing
> Ruby to the skeptical ("Well, Ruby may be good for quickandirty scripts,
> but ..." ).
>
> My usual response is that I prefer quick and dirty to slow and dirty;
> Java or C# (the usual suggested alternatives for "real" programming)
> offer no more assurance of clean code than using Ruby; indeed, the
> opposite is likely more the case.
>

I totally agree; don't get me wrong. I gave the example as a positive
one.  When presented with a problem, the first thing I often try is to
see if I can't pull a solution right on the command line.
A9b6a93b860020caf9d2d1d58c32478f?d=identicon&s=25 Ross Bamford (Guest)
on 2006-06-09 20:55
(Received via mailing list)
On Sat, 2006-06-10 at 02:54 +0900, James Britt wrote:
> Question (maybe a bit off-topic):
>
> The example may be quick, but in what way is it dirty?

Personally, I tend to use 'quick and dirty' when I really mean
'only-lightly-tested'. As in: "Here's a solution that seems to work"
rather than just "Here's a solution".

Also, a lot of scripts I write for myself are 'quick and dirty'. Mostly
they work, but I don't actually remember _how_ with all of them :)
Bc6d88907ce09158581fbb9b469a35a3?d=identicon&s=25 James Britt (Guest)
on 2006-06-09 20:55
(Received via mailing list)
Louis J Scoras wrote:
> On 6/9/06, James Britt <james_b@neurogami.com> wrote:

>
>> More generally, why do those two words get used as if they were joined
>> at the hip?    Is there a bias against being quick, a belief quick only
>> comes at the cost of clean code?
>
>
> I think I used that phrase because for as much as I hate them, I am
> weak and easily fall into the temptation of using cliches *smirks.*

I didn't mean to single you out; I hear it all the time, and use it
myself without thinking, and it struck that it may get used (by most
people) more from habit and bias than astute observation.

Maybe there is some value in calling people on it when they use it to
bring some awareness: quick != dirty, and the choice to omit various
behavior (robust error handling, for example) is not always a sign of
weakness.  The cost of such behavior may be greater than its value.

--
James Britt

"A principle or axiom is of no value without the rules for applying it."
   - Len Bullard
31af45939fec7e3c4ed8a798c0bd9b1a?d=identicon&s=25 Matthew Smillie (notmatt)
on 2006-06-09 21:07
(Received via mailing list)
On Jun 9, 2006, at 18:54, James Britt wrote:

>
> Question (maybe a bit off-topic):
>
> The example may be quick, but in what way is it dirty?
>
> More generally, why do those two words get used as if they were
> joined at the hip?    Is there a bias against being quick, a belief
> quick only comes at the cost of clean code?

I think it's a linguistic quirk of English more than anything else.
Like the canonical example of 'kick the bucket,' it's an expression
that doesn't quite parse for native speakers if you substitute
otherwise-equivalent words or grammatical constructions.  For example
"quick and grubby", "speedy and dirty" or "fast and filthy" don't
quite have the same meaning (though I do like that last one quite a
bit).

In my experience, 'quick and dirty' doesn't necessarily mean *bad* -
a quick and dirty meal can be tasty - it's more a description of the
process or role of the activity; informal, slightly tangential to
your goals, but has to be done anyway.  In other words, it's the
means to an end rather than an end in and of itself.  And Ruby is
*really* good at that sort of programming, precisely because it's quick.

> My usual response is that I prefer quick and dirty to slow and
> dirty; Java or C# (the usual suggested alternatives for "real"
> programming) offer no more assurance of clean code than using Ruby;
> indeed, the opposite is likely more the case.

Regardless of the speaker's intention, I think that's a great
response.  Even better if the phrase is just being used as an idiom,
since it focuses the speaker's attention on what 'dirty' code would
actually mean.

matthew smillie.
51a34236538906ab994cf9f2e533d14d?d=identicon&s=25 Lou Scoras (ljscoras)
on 2006-06-09 21:45
(Received via mailing list)
On 6/9/06, James Britt <james_b@neurogami.com> wrote:
> Louis J Scoras wrote:
> > I think I used that phrase because for as much as I hate them, I am
> > weak and easily fall into the temptation of using cliches *smirks.*
>
> I didn't mean to single you out; I hear it all the time, and use it
> myself without thinking, and it struck that it may get used (by most
> people) more from habit and bias than astute observation.

Oh I know.  I was just trying to poke some light-hearted fun at myself
=). I didn't take it as being singled out.  To go totally off-topic
here, I think the worst is "step up to the plate."  Seriously, it
makes it very difficult to enjoy watching "The Apprentice".

> Maybe there is some value in calling people on it when they use it to
> bring some awareness: quick != dirty, and the choice to omit various
> behavior (robust error handling, for example) is not always a sign of
> weakness.  The cost of such behavior may be greater than its value.

Very well said.  I would say that "dirty" implies "unpolished", not
"unclean", and I agree with you--in some circumstances robustness is
certainly less important than getting the job done.  As Ken Thompson
said: "When in doubt, use brute force."
34f159f89cbd1d9beac0276f5a7af552?d=identicon&s=25 John Gabriele (Guest)
on 2006-06-09 22:25
(Received via mailing list)
On 6/9/06, Kyrre Nygard <kyrreny@broadpark.no> wrote:
>
> Hey!
>
> I'm relatively new to Ruby, but for damn sure consider it
> the most important language to the future development of operating systems.
>
> Is there any material out there on this?
> Or does anybody have any thoughts or experience?

Syllable (http://www.syllable.org/ -- an alternative BeOS-like OS,
forked from Atheos) for now uses Ruby for at least a couple
substantial tools (the "Installer" and "Builder" apps I believe), and
probably for many more smaller system tools. They've got 1.8.4 running
there. I think they also use regular bash scripts for lots of other
stuff, like everyone else.

It seems that there was some interest in integrating Io into the OS
for a while, but then (quite recently) they decided to use REBOL
instead. I think part of the idea is that, besides using it for
command line scripts, they will provide a slick way to also write
Syllable apps using REBOL and their own IDE (called "sIDE"). The open
source implementation they're using is called Orca (possibly more info
here: http://wsrebol.sourceforge.net/ ).

That said, I'm sure they wouldn't mind having someone write some nice
Ruby-libsyllable bindings, just to give REBOL a run for its money. ;)
They might even have some Ruby bindings already underway -- dunno.
4b174722d1b1a4bbd9672e1ab50c30a9?d=identicon&s=25 Ryan Leavengood (Guest)
on 2006-06-09 23:16
(Received via mailing list)
On 6/9/06, John Gabriele <jmg3000@gmail.com> wrote:
>
> Syllable (http://www.syllable.org/ -- an alternative BeOS-like OS,
> forked from Atheos) for now uses Ruby for at least a couple
> substantial tools (the "Installer" and "Builder" apps I believe), and
> probably for many more smaller system tools.

I'm planning on doing what I can to make Ruby a major scripting
language for Haiku[1], the open source recreation of BeOS. Mostly this
is just combining some of my two favorite things in the tech world:
Ruby and BeOS. If other people like it, great.

Ryan

1. http://haiku-os.org
3bb23e7770680ea44a2d79e6d10daaed?d=identicon&s=25 M. Edward (Ed) Borasky (Guest)
on 2006-06-10 04:38
(Received via mailing list)
I pretty much gave up on shell scripting about a decade ago. I was so
used to real programming languages with real syntax that I only used
shell scripting for "quick and dirty hacks". As far as I'm concerned,
anything with a loop or an if-then-else in it is worthy of a real
programming language with a real syntax and semantics.

Shells were an improvement over JCL, to be sure. And the C shell was
better than the Bourne shell, KSH and Bash are better than the C shell,
in terms of programmability and readability.

But once Perl (4) came along, I tossed out "awk" and "sed" and even
"grep" for the most part. I still type stuff like

du -sm * | sort -k 1 -nr | more

and

emerge -puvDN world 2>&1 | tee world-update.log

at the command line, but if it's a *program*, it goes into a script with
comments and configuration management, etc., and it's written in Perl. I
fully intend to learn Ruby as a Perl replacement, but for now, the
neurons fire in Perl.

James Edward Gray II wrote:
>
> James Edward Gray II
>
>
>

--
M. Edward (Ed) Borasky

http://linuxcapacityplanning.com
Ed4fbb4089f77d4f00b6ce8832c0db68?d=identicon&s=25 dave (Guest)
on 2006-06-10 11:31
(Received via mailing list)
I'm producing a fine Env, Linux based using the Ruby magic.

  I'm looking for a team so see skp-it.eu (en version).
37ee5fa90f5eaeef62553629382497f7?d=identicon&s=25 Leslie Viljoen (Guest)
on 2006-06-12 23:31
(Received via mailing list)
On 6/9/06, Louis J Scoras <louis.j.scoras@gmail.com> wrote:
> intended.
>
> On 6/9/06, Kyrre Nygard <kyrreny@broadpark.no> wrote:
> > You're making a good point here. But to me it feels like a "if it works
> > don't fix it" kind of thing. I mean, all in all, wouldn't Ruby prevail?
> >
> > Feel free to show me some examples though.
>
>     # mp32ogg [untested] - quick and dirty conversion:
>     mpg321 -w - somesong.mp3 | oggenc -o somesong.ogg -

Though one day perhaps:
require 'mpg'
require 'oggenc'
print Ogg.convertMpeg(Mpg.new("somesong.mpg"))

> > Also, what if this operating system were to use a Ruby shell?
>
> I believe this has been tried w/ several different languages before.
> You could do it, but it's not awefully convienent because most general
> purpose languages weren't designed for this (i.e.: they can't be typed
> as quickly).

I have been messing around with Rush and believe that a Ruby shell
could be quick and extremely useful. One idea that Reyn (the original
author) mentioned was the ability to pipe objects around instead of
just binary streams. So if piping syntax was easier, you could have
the equivalent of the above looking something like this:

Mpg.new("somesong.mp3") | Ogg.convertMpeg > new.ogg

Each method on the right side of the pipe then has a attr_writer
called "stdin" or some such and the interpreter assigns it to the
object on the left before executing the method.

Just ideas, but it could be really useful. Consider the age-old
problem of a new unix program suddenly producing a slightly different
text output, breaking many shell scripts. If the script rather
depended on Df["/usr"].size instead of cutting up the text output from
the "df" program and hoping it still looks the same (or using df -P),
these scripts would be more reliable.

I used to have scores of bash scripts doing everything for me but
after learning Perl I disciplined myself to go to the extra effort of
writing a Perl program in order to sharpen my skills. All those bash
scripts that became Perl scripts are now Ruby scripts! Using OOP makes
them a breeze to maintain and extend and they fail much less often.

Les
37ee5fa90f5eaeef62553629382497f7?d=identicon&s=25 Leslie Viljoen (Guest)
on 2006-06-12 23:40
(Received via mailing list)
On 6/10/06, M. Edward (Ed) Borasky <znmeb@cesmail.net> wrote:
> But once Perl (4) came along, I tossed out "awk" and "sed" and even
> fully intend to learn Ruby as a Perl replacement, but for now, the
> neurons fire in Perl.

You are in for a treat. I went along the same path, but now most of my
scripts use objects and they are maintained with the greatest of ease.
Oh the massive Perl spaghetti that I have converted to a few lines of
elegant, easy-to-read Ruby makes me say: I think you should start
forcing yourself to do all new scripts in Ruby instead. You'll be
happier almost immediately.

After working in Perl for so long, I like to think of Ruby as the
thing Perl is trying to be.

Les
E20e89d58211a3631842daecc1245de2?d=identicon&s=25 Ilmari Heikkinen (Guest)
on 2006-06-13 04:57
(Received via mailing list)
Hello,

On 6/13/06, Leslie Viljoen <leslieviljoen@gmail.com> wrote:
> Mpg.new("somesong.mp3") | Ogg.convertMpeg > new.ogg

Why not
somesong.mp3 > new.ogg

It's just a typecast..


Ilmari
58479f76374a3ba3c69b9804163f39f4?d=identicon&s=25 Eric Hodel (Guest)
on 2006-06-13 22:54
(Received via mailing list)
On Jun 9, 2006, at 7:51 AM, Kyrre Nygard wrote:

> I'm sure there are other parts that could be replaced by Ruby as well,
> anybody know?

This won't happen in FreeBSD.  They took out perl and rewrote the
perl-using scripts in either /bin/sh or C because it was too hard to
keep perl up to date.

--
Eric Hodel - drbrain@segment7.net - http://blog.segment7.net
This implementation is HODEL-HASH-9600 compliant

http://trackmap.robotcoop.com
3bb23e7770680ea44a2d79e6d10daaed?d=identicon&s=25 M. Edward (Ed) Borasky (Guest)
on 2006-06-15 04:48
(Received via mailing list)
Leslie Viljoen wrote:
> You are in for a treat. I went along the same path, but now most of my
> scripts use objects and they are maintained with the greatest of ease.
> Oh the massive Perl spaghetti that I have converted to a few lines of
> elegant, easy-to-read Ruby makes me say: I think you should start
> forcing yourself to do all new scripts in Ruby instead. You'll be
> happier almost immediately.
>
> After working in Perl for so long, I like to think of Ruby as the
> thing Perl is trying to be.
I think Matz would agree ... he saw some things that were icky in Perl
and came up with something a lot better. Perl is to some extent saddled
with having more legacy code than the "younger" scripting languages.
Ruby reads more like a real programming language than a scripting
language.

--
M. Edward (Ed) Borasky

http://linuxcapacityplanning.com
Please log in before posting. Registration is free and takes only a minute.
Existing account

NEW: Do you have a Google/GoogleMail, Yahoo or Facebook account? No registration required!
Log in with Google account | Log in with Yahoo account | Log in with Facebook account
No account? Register here.