Slashdot Mirror
Fault Tolerant Shell
Paul Howe writes "Roaming around my school's computer science webserver I ran across what struck me as a great (and very prescient) idea: a fault tolerant scripting language. This makes a lot of sense when programming in environments that are almost fundamentally unstable i.e. distributed systems etc. I'm not sure how active this project is, but its clear that this is an idea whose time has come. Fault Tolerant Shell."
It's a well meaning idea, but it would cause more problems than it would solve. It would just encourage sloppy code; people would rationalize "I don't need to fix errors because it doesn't matter", which is a very bad habit to get into when programming, ignoring errors, or even warnings
a auto-completing python interpreter and editor
Try the Wing IDE. It has most of the functions you wanted... But it's not free software.
The right to offend is far more important than the right not to be offended. (Rowan Atkinson)
how many times have you hacked something together in perl that ended up being relied on for some pretty important stuff, only to find 6 months down the track that there's some condition (db connects fine, but fails halfway through script execution as an example) you didn't consider and the whole thing just collapses in a heap - a nasty to recover heap cause you didn't write much logging code either.
This would REALLY be useful when you're connecting to services external to yourself - network glitches cause more problems with my code than ANYTHING else, and it's a pain in the arse to write code to deal with it gracefully. i'd really really like to see a universal "try this for 5 minutes" wrapper, which, if it still failed, you'd only have one exit condition to worry about. hey, what the hell, maybe i'll spend a few days and write one myself.
Perhaps the answer to the problem of teenagers dropping bricks from motorway and railway bridges is to sue Tetris.
So what happens if the files are crucial (let's use the toy example of kernel modules being updated): The modules get deleted, then the update fails because the remote host is down. Presumably the shell can't rollback the changes a la DBMS, as that would involve either hooks into the FS or every file util ever written.
Now I think it's a nice idea, but it could easily lead to such sloppy coding; if your shell automatically tries, backs off and cleans up, why would people bother doing it the 'correct' way and downloading the new files before removing the old ones?
Doesn't that depend on the definition of clustered though? Clustered systems can be things like beowulf clusters. But often a collection of standalone web servers behind a http load balancers is commonly referred to as a web cluster or array.
IMHO as someone who works in a complex web server / database server environment, there are many interdependancies brought by different software, different platforms and different applications. Whilst 100% uptime on all servers is a nice to have, it's a complex goal to achieve and requires not just expertise in the operating systems & web / database server software but an indepth understanding of the applications.
A system such as this fault tolerant shell is actually quite a neat idea. It allows for flexibility in system performance and availability, without requiring complex (and therefore possibly error prone or difficult to maintain) management jobs. An example would be server which replicates images using rsync. If one of the targets is busy serving web pages or running another application, ftsh would allow for that kind of unforeseen error to be catered for relatively easily.
The Romans didn't find algebra very challenging, because X was always 10
I think it still will promote bad programming/scripting practices. Many people ( including myself ) started with scripting before moving on to full-fledged programming. What they learned in scripting they carry forward with them into programming, and trust me, I learned to be very meticulous when it comes to interacting with things outside of my scripts control ( such as files ). Every I/O operation should be tested for success. Trying to open a file? Did it work? Ok, try writing to the file...did it work? Open a database connection...did it work? Let the user enter a number...did they enter a valid number? Error handling and input validation is something you just have to learn, like it or not. Something that holds your hand and lets you code while remaining oblivious to the realities of the scripting/programming environment is a bad thing IMHO.
On a side note for Perl, one thing I always hated were the examples that had something like "open( FH, "file/path" ) || die "Could not open file!" . $!; I mean, come one, you don't want your script to just quit if it encounters an error...how about putting in an example of error handling other than the script throwing up its hands and quitting! LOL.
Please excuse any grammatical/other typos above, I was on 4 hrs sleep when I wrote this. Thank You.
I can't afford a sig!