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
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
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
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.
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
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?
--
"If you do it the stupid way, you will have to do it again"
- Gregory Chudnovsky
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.
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?
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).
--
Upper reality >oftware.
Dave - Skp Core (skp-it.eu).
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.
On Jun 9, 2006, at 7:51 AM, Kyrre Nygard wrote:
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?
--
Eric Hodel - drbrain@segment7.net - http://blog.segment7.net
This implementation is HODEL-HASH-9600 compliant
Thanks Farrel, thanks a lot 
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.htmlIt's a source based Linux distro that uses Ruby for all it's setup.
Farrel
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
At 17:21 09.06.2006, James Edward Gray II wrote:
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
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.
On Sat, Jun 10, 2006 at 12:21:25AM +0900, James Edward Gray II wrote:
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
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
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 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:
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
--
M. Edward (Ed) Borasky
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
On Jun 9, 2006, at 10:52 AM, Kyrre Nygard wrote:
Feel free to show me some examples though.
>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.
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).
At 17:21 09.06.2006, James Edward Gray II wrote:
On 6/9/06, Kyrre Nygard <kyrreny@broadpark.no> wrote:
--
Lou.
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
On 6/10/06, M. Edward (Ed) Borasky <znmeb@cesmail.net> wrote:
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 likedu -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.
Louis J Scoras 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 -
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.
On 6/9/06, Kyrre Nygard <kyrreny@broadpark.no> wrote:
--
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 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.> 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
On 6/9/06, Louis J Scoras <louis.j.scoras@gmail.com> wrote:
> At 17:21 09.06.2006, James Edward Gray II wrote:
On 6/9/06, Kyrre Nygard <kyrreny@broadpark.no> wrote:
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.
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.
--
Posted via http://www.ruby-forum.com/\.
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.
On 6/9/06, James Britt <james_b@neurogami.com> wrote:
--
Lou.