They are a heavy engineering company. But they do indeed have a new ship which is flying now, the Zeppelin-NT:
http://www.zeppelinflug.de/pages/E/haupt.htm
Cargolifter were going to create a f*cking *huge* ship which with a cargo capacity of 160 tonnes but ran out of money. When I say "f*cking huge", imagine an ocean liner floating in the air in front of you.
http://www.cargolifter.com/
It seems that military spending is needed for these kinds of projects to succeed.
This is potentially as important a project as Project Gutenberg itself is. Seriously, a much better way to spend your spare time than 8 hours per day of VegeVision.
Needs a GUI markup tool which can handle their DTDs though.
You're right, and this is really the trick that Microsoft is missing, frankly they're not really that smart if they haven't seen it so far.
They have billions, put up a few tens of millions of dollars as seed money for a bunch of small operations to produce several cool but incompatible Linux distributions.
And I say too right! Anything with the word "monoxide" in it *should* be banned!
Yeah, that's been in my usenet sig for ages.
Re:It's got the concept backwards
on
Fault Tolerant Shell
·
· Score: 3, Interesting
I did. Endlessly is good. The network overhead is negligible.
Check once every 1,2,4,8,16,32,64,whatever,mins *all the time anyway* whether it fails or succeeds and you *absolutely don't* want to have to explicitly tell 1000 machines to start again.
You simply generalise the update process, get rid of the special cases. In the case of patches, you know you're going to have to distribute them out to clients at some point anyway so have all the clients check once a day, every day. If the distribution server is down for a couple of days it's pretty much irrelevant.
My error detection code is trivial the network traffic is negligible unless the job's actually being done and I still haven't been given a good case for ftsh. I have a good case for a better randomising algorithm within a shell and a decent distributed cron (which is simple BTW), but not for a specifically fault tolerant shell.
You've got to stop thinking of these things as individual systems. The network is the machine.
Nope, pull doesn't break down in heterogeneously managed/owned or even platformed environments. It works best in these environments. The www is an ideal example of such, apt-get is another, seti@home is another, distributed.net, I could go on.
In Grid based computing environments, jobs queue until they can be started, and as it happens, they tend to be architected as pull based systems whether you see that as a user or not.
Again, I can't see a reason for ftsh in this case. I'm sure there's a niche for it somewhere but even their examples don't give any good reason for it's existence.
Their cd example for instance resolves to a silly script:
cd/work/foo rm -rf bar cp -r/fresh/data. ----------Bloody slashdot compressionfilter
*They* resolve this to:
----- #!/bin/sh
for attempt in 1 2 3
cd/work/foo
if [ ! $? ]
then
echo "cd failed, trying again..."
sleep 5
else
break
fi done
if [ ! $? ] then
echo "couldn't cd, giving up..."
return 1 fi -----Bloody slashdot compressionfilter
Just for the cd statement, it's just silly. It simply shows that they are either trying to justify the writing of another shell or they don't understand how to shell script.
It should resolve to something more like:
----- #!/bin/sh
JOBDONE=1 until $JOBDONE do
cd/work/foo && \
rm -rf bar && \
cp -r/fresh/data . && \
JOBDONE=0
sleep 30 done -----
You simply don't have to test every statement the way they suggest you do. It's a ridiculous premise. Even the decades old bourne shell has an easy way to only execute commands if they depend on a previous success.
The system you pull from is a distribution server, all it does is distribute files. If it's slow, it's slow for all the machines sucking data and you need a bigger infrastructure. If it's down, the client scripts fail safe and do nothing.
Even here, pull scales better than push, look at a web server as an example thousands of machines sucking web pages from a server is not uncommon. Try pushing those pages out to the same number of machines.
Push methodologies simply don't scale, I've been there, done that and it's a bad architecture for more than trivial numbers of machines and I'm not the only one to notice:
http://www.infrastructures.org/bootstrap/pushpul l. shtml
Re:You're dealing with the problem too high up
on
Fault Tolerant Shell
·
· Score: 2, Insightful
"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."
It depends how you organise your systems. If you push to them then yes you need something like ftsh. If you organise them so that they pull updates, pull scripts to execute and arrange those scripts so that they fail safe (as they all should anyway) then you'll have something which is a couple of orders of magnitude more reliable and scalable. It just needs a little more thought to begin with.
While, yes, you manage distributed systems from the center, you don't *push* updates, changes, modifications because, it doesn't scale. You end up having to write stuff like this fault tolerant shell which is frankly backwards thinking.
Instead, you automate everything and *pull* updates, changes, scripts etc. That way if a system is up, it just works, if it's down, it'll get updated next time it's up.
I won't go into details but I'll point you at http://infrastructures.org/
Fantastic. I've been looking for something exactly like this for syslog monitoring! I thought I was going to have to write something myself.
When you've got several hundred systems from different OS platforms all logging to a central log server the conventional log monitoring software is just not up to the task of discriminating important logged messages from unimportant.
And spend the rest on beer, or a lifetime subscription.
http://www.directv.com/DTVAPP/imagine/TIVO.dsp And hey, you'll have something that "just works" from the word go, instead of having to fuck about for 3 weeks and still not be up to scratch. Face it, the tivo guys did a better job than you can.
Because of Perl versioning problems. Half a dozen different versions on a single platform.
Because Perl exists in random locations.
Because a particular Perl installation will have random modules installed.
Because Perl is not on *everything*.
Because writing a shell script take a fraction of the time a Perl script takes.
Because Perl encourages monolithic scripting.
Perl has tried so very hard (and suceeded) to become a fully featured programming language, it hasn't been suited to small scripting tasks since version 4.
Slashdot Mirror
They are a heavy engineering company. But they do indeed have a new ship which is flying now, the Zeppelin-NT:
http://www.zeppelinflug.de/pages/E/haupt.htm
Cargolifter were going to create a f*cking *huge* ship which with a cargo capacity of 160 tonnes but ran out of money. When I say "f*cking huge", imagine an ocean liner floating in the air in front of you.
http://www.cargolifter.com/
It seems that military spending is needed for these kinds of projects to succeed.
According to the spec it should have a lifting capacity of somewhere around 140 tonnes[1], though much of that will be consumed by the ship itself.
[1] At sea level and assuming my US->metric conversion is ok.
This is potentially as important a project as Project Gutenberg itself is. Seriously, a much better way to spend your spare time than 8 hours per day of VegeVision.
Needs a GUI markup tool which can handle their DTDs though.
You're right, and this is really the trick that Microsoft is missing, frankly they're not really that smart if they haven't seen it so far.
They have billions, put up a few tens of millions of dollars as seed money for a bunch of small operations to produce several cool but incompatible Linux distributions.
Hydroxylic acid...
It makes dihydrogen monoxide look like water in comparison...
And I say too right! Anything with the word "monoxide" in it *should* be banned!
Yeah, that's been in my usenet sig for ages.
I did. Endlessly is good. The network overhead is negligible.
Check once every 1,2,4,8,16,32,64,whatever,mins *all the time anyway* whether it fails or succeeds and you *absolutely don't* want to have to explicitly tell 1000 machines to start again.
You simply generalise the update process, get rid of the special cases. In the case of patches, you know you're going to have to distribute them out to clients at some point anyway so have all the clients check once a day, every day. If the distribution server is down for a couple of days it's pretty much irrelevant.
My error detection code is trivial the network traffic is negligible unless the job's actually being done and I still haven't been given a good case for ftsh. I have a good case for a better randomising algorithm within a shell and a decent distributed cron (which is simple BTW), but not for a specifically fault tolerant shell.
You've got to stop thinking of these things as individual systems. The network is the machine.
Nope, pull doesn't break down in heterogeneously managed/owned or even platformed environments. It works best in these environments. The www is an ideal example of such, apt-get is another, seti@home is another, distributed.net, I could go on.
/work/foo /fresh/data .
/work/foo
/work/foo && \ /fresh/data . && \
In Grid based computing environments, jobs queue until they can be started, and as it happens, they tend to be architected as pull based systems whether you see that as a user or not.
Again, I can't see a reason for ftsh in this case. I'm sure there's a niche for it somewhere but even their examples don't give any good reason for it's existence.
Their cd example for instance resolves to a silly script:
----- FFS!Bloody slashdot compressionfilter
#!/bin/sh
cd
rm -rf bar
cp -r
----------Bloody slashdot compressionfilter
*They* resolve this to:
-----
#!/bin/sh
for attempt in 1 2 3
cd
if [ ! $? ]
then
echo "cd failed, trying again..."
sleep 5
else
break
fi
done
if [ ! $? ]
then
echo "couldn't cd, giving up..."
return 1
fi
-----Bloody slashdot compressionfilter
Just for the cd statement, it's just silly. It simply shows that they are either trying to justify the writing of another shell or they don't understand how to shell script.
It should resolve to something more like:
-----
#!/bin/sh
JOBDONE=1
until $JOBDONE
do
cd
rm -rf bar && \
cp -r
JOBDONE=0
sleep 30
done
-----
You simply don't have to test every statement the way they suggest you do. It's a ridiculous premise. Even the decades old bourne shell has an easy way to only execute commands if they depend on a previous success.
This simply isn't required in a properly organised distributed architecture.
Write your scripts to fail safe, then don't perform ad-hoc updates, schedule them regularly.
The system you pull from is a distribution server, all it does is distribute files. If it's slow, it's slow for all the machines sucking data and you need a bigger infrastructure. If it's down, the client scripts fail safe and do nothing.
l l. shtml
Even here, pull scales better than push, look at a web server as an example thousands of machines sucking web pages from a server is not uncommon. Try pushing those pages out to the same number of machines.
Push methodologies simply don't scale, I've been there, done that and it's a bad architecture for more than trivial numbers of machines and I'm not the only one to notice:
http://www.infrastructures.org/bootstrap/pushpu
"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."
It depends how you organise your systems. If you push to them then yes you need something like ftsh. If you organise them so that they pull updates, pull scripts to execute and arrange those scripts so that they fail safe (as they all should anyway) then you'll have something which is a couple of orders of magnitude more reliable and scalable. It just needs a little more thought to begin with.
While, yes, you manage distributed systems from the center, you don't *push* updates, changes, modifications because, it doesn't scale. You end up having to write stuff like this fault tolerant shell which is frankly backwards thinking.
Instead, you automate everything and *pull* updates, changes, scripts etc. That way if a system is up, it just works, if it's down, it'll get updated next time it's up.
I won't go into details but I'll point you at http://infrastructures.org/
http://www.bcs.org.uk/
I'm sure there's something similar in the US.
This really depends on whether you live in a country which is a client state of the American Empire or not. Doesn't it.
Fantastic. I've been looking for something exactly like this for syslog monitoring! I thought I was going to have to write something myself.
When you've got several hundred systems from different OS platforms all logging to a central log server the conventional log monitoring software is just not up to the task of discriminating important logged messages from unimportant.
No, they really can fly. Try it next time you're high, smuggle a dog up to the roof of your building and throw it off. It'll fly, you'll see.
Bugger prestige, it's results which matter.
If the teams can't finish they lose, if they finish, they win.
And spend the rest on beer, or a lifetime subscription.
http://www.directv.com/DTVAPP/imagine/TIVO.dsp
And hey, you'll have something that "just works" from the word go, instead of having to fuck about for 3 weeks and still not be up to scratch. Face it, the tivo guys did a better job than you can.
Sorry, but that site is dead and gone. Taken down by the Internetequivalent of a nuclear overpressure.
The moral of the story is that if you want to advertise something, don't mention it to any of your techie staff.
The wrath of slashdot is mighty indeed.
Only if you turn everything on, everywhere, all the time.
Really? Do you use 25kW heaters in your house?
It just doesn't do quite what you might expect if your only experience is Linux.
"Perl has higher level programming constructs such as variable scoping, references, hashes, reg exp, etc that make programming"
*That* is why Perl is no longer suitable for general day to day scripting.
Because of Perl versioning problems. Half a dozen different versions on a single platform.
Because Perl exists in random locations.
Because a particular Perl installation will have random modules installed.
Because Perl is not on *everything*.
Because writing a shell script take a fraction of the time a Perl script takes.
Because Perl encourages monolithic scripting.
Perl has tried so very hard (and suceeded) to become a fully featured programming language, it hasn't been suited to small scripting tasks since version 4.
Because you now have thousands of bits of paper you can look at and say. "Look they gave out the wrong ballot papers, they shouldn't be in this box".