unRAID 5

[prostuff1]

So I don't know how many of you have checked out the new site (and especially the extension devs) but there was a little blurb from Tom:

 

"Speaking of extensions - I had hoped to release a preview of unRAID Server 5.0 for review during the holiday break.  Unfortunately addressing the download crisis consumed all my development time.  I promise to have something out there very soon.  Hint to prospective extension authors: start learning Ruby..."

 

It looks like Ruby is going to be the "supported" method for extension development.

 

Feel free to discuss...

[bubbaQ]

[spit] Then my first extension will be one that installs PHP!

[Joe L.]

[spit] Then my first extension will be one that installs PHP!

And I think I've got a "php" extension that runs "awk" (cough... unMENU) 

 

In reality, I'll learn "ruby"... just never had a reason to do so until now.  I'll teach it how to run "awk" 

 

I've got no idea how many languages I've learned over the years...  For the most part, they are all the same once you learn:

variable assignment

structure

conditional tests

iteration

The rest is just how to write a comment, where (if) you put the semi-colons, and becoming acquainted with the various library functions available. 

 

Bring it on Tom...  If you had a good reason to use "ruby" it will work for me too.

 

Joe L.

[bubbaQ]

That's true and I've made the same point --- Any good coder can use practically any language (as long as it does not end in the letter "L").  I've coded in about 22 different languages in various projects when the project scope or other reasons necessitated it. 

 

There is one important exception in the special case of using one language (php, ruby, awk, perl, etc) to produce html output to serve up via a web server.  Nothing does that better than php in terms of simplicity and readability.

 

 

[prostuff1]

Bring it on Tom...  If you had a good reason to use "ruby" it will work for me too.

 

Joe L.

 

I am also wondering why he choose to go with Ruby...

 

I would love to get an explanation/reason just for curiosities sake.  I am going to start looking into Ruby... I also need to get an unRAID test machine setup so I can not take down my main machine to mess with all the 5.0 goodies that are hopefully coming!!

[Joe L.]

Any good coder can use practically any language (as long as it does not end in the letter "L"). 

I guess you disliked "Object-Oriented-COBOL" 

[BRiT]

My highly opinionated response is "Fuck Ruby". I'd prefer for it to be based of PHP. There's plenty of reasons numerous websites and forums are developed using PHP. PHP offers simplicity, readability, ease of use, and extensibility. Actually, I think I'd even prefer Perl over Ruby.

 

 

[bubbaQ]

I guess you disliked "Object-Oriented-COBOL"

 

Yes... most vociferously.... along with Algol, Snobal, APL, etc.

[Joe L.]

I guess you disliked "Object-Oriented-COBOL"

 

Yes... most vociferously.... along with Algol, Snobal, APL, etc.

Will you make an occasional exception for "shell", "perl", and "html" ??

 

Good thing I'm not a programming language:

Joe L.

[bubbaQ]

HTML is a *markup* language, not a programming language.

 

Shell is not a language, but an environment.

 

Perl... I hate it.... but it is better than COBOL (but so is a root canal).  I used to have to do stuff in perl (using mod_perl) but luckily, not any more.

[Joe L.]

HTML is a *markup* language, not a programming language.

I'll grant you that one.

 

Shell is not a language, but an environment.

Shell is definitely a programming language.  and it is an environment too.  (See... it is a floor-wax.... and a desert topping too)

When you've programmed as much in shell as I have over the years, you'll understand my position.  One ex-Bell-Labs manager I once worked for bet me I could not write a b-tree data structure/database in shell.  He lost the bet.  he finally admitted he had only seen one other person that had stretched the shell to do as much as I had, and that person had written the system admin scripts for the early unix systems AT&T sold at that time.  Yes, you have to get creative when working on binary data structures using shell scripts... but it can be done.  Inter-process communications was easy... Co-processing... just a tiny bit harder. 

 

I've had to work very little with "perl" ... but I did once write an e-mail to Larry Wall (original author of perl) long long ago... and he answered....  the computing world was a lot smaller back then... and he was active on usenet, and so was I.

Perl... I hate it.... but it is better than COBOL (but so is a root canal). 

I interviewed for a COBOL programming position once...  I had never used it prior to the interview.  I did not get the job, but did make the short list...    I did not want the job, but it was great job interview practice for positions I really wanted.

I used to have to do stuff in perl (using mod_perl) but luckily, not any more.

I had to modify other peoples "perl" code... and they did not comment it.... horrible experience...  OK language.... has come soooooo far since I originally looked at it when Larry first described it on usenet around 1987.  never got back to it, since "shell" and "awk" were powerful enough for me to do just about anything I needed to do.

 

If we need to learn a bit of "ruby" it will just mean another language I can say I've worked with.  (Never worked with Snobal, Algol, APL so you've got a few up on me... but I'm sure I've worked on a few you've never had a chance to play with.  Ever work with "rpg" ?  No, not the IBM "rpg" most people know, but the one in a very obscure, little known very early version of Unix used in the Bell System maintenance center computers.

 

It also stood for "Report Program Generator"

 

Every "command" was a single character, preceded by a "*"

*?  was an "if" statement

*>  was a "forward goto"

*<  was a "backwards goto"

*p  was a "print" command

*[  was a while loop  (I think..... it was a LONG time ago)  The loop ended with *!

 

The "goto's were fun.  They were to single letter labels in a specific direction.

Yes, gotos... and labels...  26 labels... letters "a" through "z"  But... you could use the exact same label again, and again, and again, as the forward or backwards goto were relative to where you were in the program and went to the closest matching label, in the direction indicated.  this made tracing a program's flow really interesting.

There were 26 variables... Yup, you guessed it, "a" through "z"  Made it "really easy" to understand what a variable was holding.  It almost exactly paralleled the basic system calls on unix.  there were commands to open files, close files, read and write to/from open files, unlink files (remove them)  I think that was *u.  As I said a very long time ago...

 

So

*? a = 1 *> a

:b

a=a+1

a:

*> d

a=2

*< d

d:

*p "done"

What's really sad is I did a google search for examples of this old bell-labs created language, and I could not find any on the web.  A "dead" computer language...  so sad... lost....  Even worse... I still am cluttering up my mind with its syntax... 

 

Joe L.

[bubbaQ]

Never used *that* rpg, but did use the IBM variety.  My hairiest stuff was writing a multi-boot partition loader back about 1984, by hand-coding machine language and writing it byte by byte to sector 0 of the hard drive.

 

I've seen many hacked up bailing-tine and ducktape fiascos in my day.  C&C waring here..... I once watched an attorney using Lotus, put in a column of numbers with some text creating an invoice/statement, then add up the numbers on a calculator and type in the sum.  She though Lotus was a word processor used when you wanted to decimal-align a column of numbers.

 

If anyone tells you that a language is "self-documenting" you should run away very fast--- there is no such thing.  Some Perl programmers are the worst at commenting -- and trying to maintain or fix their code after they are gone is pure frustration.  They will use a single line regexp with no comments, that takes someone reviewing their code half a day to figure out what the hell they are doing, and call it "elegant".... when 5 lines of code that broke it into discrete recognizable steps would be much better.

 

OTOH, I've seen 80 lines of clueless SQL code doing 6 queries and creating massive temporary tables that took 30 minutes to execute, that I replaced with a single outer join that ran in 2 seconds.

 

 

[WeeboTech]

My highly opinionated response is "F*** Ruby". I'd prefer for it to be based of PHP. There's plenty of reasons numerous websites and forums are developed using PHP. PHP offers simplicity, readability, ease of use, and extensibility. Actually, I think I'd even prefer Perl over Ruby.

 

*sigh* I was hoping for PHP too. I suppose I could learn ruby, or may i'll wait for bubba to teach unraid PHP. hahahaha!!!

[Joe L.]

My highly opinionated response is "F*** Ruby". I'd prefer for it to be based of PHP. There's plenty of reasons numerous websites and forums are developed using PHP. PHP offers simplicity, readability, ease of use, and extensibility. Actually, I think I'd even prefer Perl over Ruby.

 

*sigh* I was hoping for PHP too. I suppose I could learn ruby, or may i'll wait for bubba to teach unraid PHP. hahahaha!!!

If I could teach "php" how to run "awk" based unMENU screens, odds are we can adapt to "ruby" too.

[limetech]

[spit] Then my first extension will be one that installs PHP!

And I think I've got a "php" extension that runs "awk" (cough... unMENU) 

 

In reality, I'll learn "ruby"... just never had a reason to do so until now.  I'll teach it how to run "awk" 

 

I've got no idea how many languages I've learned over the years...  For the most part, they are all the same once you learn:

variable assignment

structure

conditional tests

iteration

The rest is just how to write a comment, where (if) you put the semi-colons, and becoming acquainted with the various library functions available. 

 

Bring it on Tom...  If you had a good reason to use "ruby" it will work for me too.

 

Joe L.

 

Hey Joe I appreciate your insight into things...

 

There are a few reasons why I'm trying out Ruby:

 

- The 'erb' templating engine is already very close to how the current webGui is implemented internally, so translating will not be very difficult.

 

- An unRAID user sent me some screen shots of a prototype webGui he was coding in Ruby and it is very impressive for the small number of lines of code.

 

- Like you (and others on the board), I've been at this (hacking s/w) for a number of years now, and to be honest, PHP just doesn't excite me very much - it's just more of the same.  Ruby though, requires a different way of thinking.  Another life ago (seems like it), I did a major project using Forth & that was very satisfying - Ruby has a similar "eleguence" to it.

 

Anyway, I'm not trying to say Ruby is the be-all-end-all language - just something that interests me quite a bit.

 

Also, I should mention, this is not Ruby-on-Rails - rather Ruby on Sinatra.

 

Here is how you can install Ruby on unRAID:

 

wget http://slackware.osuosl.org/slackware-12.2/slackware/d/ruby-1.8.7_p72-i486-2.tgz
installpkg ruby-1.8.7_p72-i486-2.tgz

ruby -v

wget http://rubyforge.org/frs/download.php/60718/rubygems-1.3.5.tgz
cd rubygems-1.3.5
ruby setup.rb

gem install sinatra

[aiden]

The benefit of this platform being so adaptable means you guys can keep PHP while Tom can continue to stay interested in development with Ruby.  In the end, we all win with a constantly maturing product that has a lot of customizable features and user-designed add-ons.  And Joe and the guys are right.  If any of you fellow coders had to learn on Fortran and Pascal, you can attest to the fact that coding is much more about engineering and design than it is syntax.  Syntax is easy... finding your infinite loops and untrapped errors is not. 

[BRiT]

If you do go with Ruby, can you at least use the current version, 1.9.1, and not an old version?

[limetech]

If you do go with Ruby, can you at least use the current version, 1.9.1, and not an old version?

 

LOL, yes of course.  That was just a quick and dirty set of commands to let people play around with it.

[purko]

If you do go with Ruby, can you at least use the current version, 1.9.1, and not an old version?

 

Well, "current" for slackware 13 is ruby-1.8.7_p174.

 

From where do you get a slackare package for ruby-1.9.1?

 

 

[limetech]

If you do go with Ruby, can you at least use the current version, 1.9.1, and not an old version?

 

Well, "current" for slackware 13 is ruby-1.8.7_p174.

 

From where do you get a slackare package for ruby-1.9.1?

 

 

 

I have to build it myself.

[purko]

Another life ago (seems like it), I did a major project using Forth & that was very satisfying

 

Tu quoque, Brute, fili mi?

 

I worked for a long time with PolyFORTH and with ChipFORTH.  Those were the days! 

 

Purko

 

 

 

[Joe L.]

finding your infinite loops and untrapped errors is not. 

And the infinite loops run soooooooo much faster on these new multi-core pentium4 processors...    Unfortunately, they seem to take as long to run... 

[Joe L.]

Another life ago (seems like it), I did a major project using Forth & that was very satisfying

 

Tu quoque, Brute, fili mi?

 

I worked for a long time with PolyFORTH and with ChipFORTH.  Those were the days! 

 

Purko

My first computer was "analog" ... FORTH didn't come along until nearly 15 years later.  (Yes... I'm OLD in computing terms...)

[BRiT]

Well, "current" for slackware 13 is ruby-1.8.7_p174.

 

From where do you get a slackare package for ruby-1.9.1?

 

If you use Slackware Current, they provide Ruby 1.9.1 patch243.

 

As Tom said, they provide the source for it off the Ruby website. The current patch level is 1.9.1_p376, so even Slackware-Current is behind.

[aiden]

finding your infinite loops and untrapped errors is not. 

And the infinite loops run soooooooo much faster on these new multi-core pentium4 processors...     Unfortunately, they seem to take as long to run... 

 

LOL