Better for us, I'm sure. Better for Amiga Inc. shareholders? Not in a million years.
As for doing "great things with the OS", while Amiga OS still have some great features, you'd be much better off adding [insert favorite AmigaOS feature here] to existing open source software. The Amiga OS as most of us know it was very intimately tied to an architecture without memory protection for instance, which doesn't really make it easy to bring up to date.
That said, if you want "open source Amiga OS", take a look at AROS. Aaron Digulla and a few other people have done a great job at writing replacements for almost all parts of Amiga OS, and you can run it under Linux (or stand alone if you prefer).
Re:this can essentially already be done in /bin/ba
on
Fault Tolerant Shell
·
· Score: 1
Trying to justify your response by introducing context to your original post that didn't exist doesn't polish your image.
If your comment on fault-tolerant coding adressed shells that correct misspellings, that doesn't make it any more insightful. There is no reason to assume such a shell would encourage sloppy coding - the many examples in this article demonstrates very well why no such shell has been written: It could create dangerous situations from otherwise harmless mistakes - there is no indication that it would in any way make "sloppy coding" any safer, and hence no indication that it would encourage sloppy coding.
As for extending an existing shell, you specifically made the point that you didn't need to extend bash to provide the functionality of ftsh, while your example only show the most trivial functionality. You now "clarify" in a way that to me reads as backtracking. Fine. Yes you can handle errors in bash in a slightly more elegant way than the ftsh website indicates. I pointed out that this was only a small part of the functionality ftsh provides.
Your complaints about ftsh being written from scratch just reinforces the impression I got of your first message. Yes, writing a shell from scratch just to add this functionality might be a waste from your perspective. But we're talking about about 4000 lines of code here - hardly years of work - where providing the "try" functionality and error handling is the ONLY focus (gee, I actually bothered downloading and looking at the source).
It is not a bash replacement. It is not something you would want to use as an interactive shell. It is a shell with the specific purpose of providing more fault tolerant access to distributed, error prone resources. Which is also how it is presented on the website: As a tool to solve a specific problem in a generic, reusable way. Very much in the Unix tradition.
It's possible it would be significantly smaller if written as a bash script. But if it came at the cost of a syntactic kludge it would defeat much of the purpose: Making the appropriate error behavior default throughout the script.
Perhaps because if you have access to run software remotely on a few hundred desktop computers that "has to" run Windows you would like to have the same script environment to use on Windows as on the other platforms you use? Perhaps because automated scripts aren't particularly good at using GUI's?
Re:You're dealing with the problem too high up
on
Fault Tolerant Shell
·
· Score: 3, Insightful
If you can set up a distributed system at a reasonable cost where any program can continue to run without carying about an underlying failure, you would be richer than Bill Gates.
Resources DO become unavailable in most systems. It simply doesn't pay to ensure everything is duplicated, and set up infrastructures that makes it transparent to the end user - there are almost always cheaper ways of meeting your business goals by looking at what level of fault tolerance you actually need.
For most people hours, sometimes even days, of outages can be tolerable for many of their systems, and minutes mostly not noticeable if the tools can handle it. The cost difference in providing a system where unavailabilities are treated as a normal, acceptable condition within some parameters, and one where failures are made transparent to the user can be astronomical.
To this date, I have NEVER seen a computer system that would come close to the transparency you are suggesting, simply beause for most "normal" uses it doesn't make economic sense.
So what you are saying is that programming should be hard, and people should be expected to do it right, or it promotes bad practices.
Yet we are expected to excuse your grammatical and typos. Doesn't that just promote bad practices? Shouldn't we whack you over the head with a baseball bat just to make sure you won't post when you're not prepared to write flawless posts?
The more work you have to do to check errors, the more likely it is that however vigilant you might be, errors slip past. If you have to check the return values of a 100 commands, that is a 100 chances for forgetting to do the check or for doing the check the wrong way, or for handling the error incorrectly.
In this case, the shell offers a function that provides a more sensible default handling of errors: If you don't handle them, the shell won't continue executing by "accident" because you didn't catch an error, but will terminate. It also provides an optional feature that let you easily retry commands that are likely to fail sometimes and where the likely error handling would be to stop processing and retry without having to write the logic yourself.
Each time you have to write logic to handle exponential backoff and to retry according to specific patterns is one more chance of introducing errors.
No offense, but I would rather trust a SINGLE implementation that I can hammer the hell out of until I trust it and reuse again and again than trust you (or anyone else) to check the return code of every command and every function they call.
This shell does not remove the responsibility to for handling errors. It a) chooses a default behaviour that reduces the chance of catastrophic errors when an unhandled error occurs, and b) provides a mechanism for automatic recovery from a class of errors that occur frequently in a particular type of systems (distributed systems where network problems DO happen on a regular basis), and by that leave developers free to spend their time on more sensible things (I'd rather have my team doing testing than writing more code than they need to)
Re:Wouldn't be much work in Tcl
on
Fault Tolerant Shell
·
· Score: 2, Interesting
Bzzt. Try again. Where is the exponential backoff? Where is the ability to restrict each contained statement for a specific amount of time? Where is the ability to execute each command at specific intervals?
Your example only does a fraction of what ftsh does.
Re:It's got the concept backwards
on
Fault Tolerant Shell
·
· Score: 2, Interesting
I guess you didn't READ the article, considering that the example given on the page was specifically an example of pulling a data file, trying multiple hosts in turn.
The thing is, if you run a distributed system with a thousand servers, and your patch distribution points drop of the network, you don't suddenly want a thousand servers hammering the networks endlessly. You want things like exponential backoff, timeouts after which the system will change behaviour (stop requesting updates until explicitly requested to start again, start triggering alarms etc.), and that is exactly the kind of scenario ftsh makes easy to do in scripts without having to write all the logic yourself for every bloody script.
Re:Sounds like good way to do some serious damage
on
Fault Tolerant Shell
·
· Score: 2, Insightful
I could more damage with "wile true; do... " in bash. It's not like an infinite loop is very hard. ftsh on the other hand defaults to exponential backoff, which isn't exactly what you want if you want to DOS someone.
I assume you do all your calculations in your head without a pen, pencil, paper, abacus, computer. And if you DO use computers to compensate for your inadequacies I do assume you stick to command line interfaces and program by doing "cat >executable" and typing in the executable directly without resorting to such cheating as assemblers or *shudder* compilers...
If people make assumptions that are completely unjustified based on everything the manual says, then they get what they deserve. The purpose and semantics are quite clearly documented. If you base your usage of a software package based on a few lines long example with no clear purpose outside of being an example, then that is the problem, not the software package.
It's not about cleaning up. It's about fault tolerance. Deleting the data file in the case of the example is NOT a failure. Presumably the file is no longer useful (if not the script is buggy). Deleting the wrong data would be a failure. Not downloading the new data at some point in time would be a failure. THAT is what the script as written protects against.
The assumption that it's not ok to delete a data file before the new file is in place assumes that you know something about the uses of the data that the rest of us (presumably including the website author) does not. The deletion could very well be placed first in the script on purpose, to ensure that the data is deleted at the earliest possible time, regardless of the time it would take to download a new data set - possibly because the old data set is obsolete and clients should rather wait for a new dataset than rely on the old.
Re:this can essentially already be done in /bin/ba
on
Fault Tolerant Shell
·
· Score: 1
First of all, your comment about fault tolerant coding encouraging sloppy coding is either misguided or just plain stupid. Not catching and handling error conditions correctly IS sloppy coding. Catching and handling error conditions correctly IS fault tolerant coding.
ftsh provides a mechanism aimed at making it easier to catch and handle error conditions correctly. How does that encourage sloppy coding?
As for your bash example, it only demonstrates the most basic capability of ftsh - exiting on error. It does not differentiate between conditions where the error is likely to be temporary - which happens all the time in distributed systems - and conditions where immediate termination is justified.
You heretic.... Actually I think Asimovs work is some of the most timeless sci-fi out there due to the way it is written. Very few technical details that aren't an integral part of the plots. Mostly the technology is used as a plot devices for stories that range from detective stories (Naked sun, for instance) to morality stories and exploring human nature (many of the robot short stories), including what it means to be human (Bicentennial man), or large epics (Foundation).
Very rarely is technology itself the focus of the the story - even in the robot stories where a specific robot often seems to be in focus, as one of the main characters in the story, they tend to be only props used to make some point.
This is a common thread with most of the sci-fi that survives long term. HG Wells, the Time Machine stands the test of time because the technology of the time machine isn't relevant to the story line. For that matter, the story could more or less have been told without time travel - just like in for instance Gullivers Travels, the whole journey is just an excuse to set the scene the way the authors wants.
Gibson survives because he's detached enough from technology to write about it in very broad strokes - there are very few details to get hung up about as "dated".
Philip K. Dick survives because most of his stories are about his characters, not about the technology they surround themselves with.
And so on...
The sci-fi that dates badly is the techno-fetishist stuff that is about the technology, as opposed to the consequences of the technology.
It might have been deprecated by some, but outside of a handful of people on Slashdot I hardly ever see people trying to use the crappy "mebi" prefixes. To most of the world 1MB = 10^6, no matter how much you'd like it to not to be.
The thing is, referring to a GB as 1 billion bytes is NOT common use except among harddrive manufcaturers. In fact, there's an ongoing lawsuit going for deceptive marketing over this.
You miss the point. Viacom is putting the thumbscrew on and demands more money. Dish Network has told them they want to keep negotiating because they don't think the fees are worth it - if Dish gives in the customers will have to pay more. Obviously Dish Network is looking out for themselves too, but they have the same interest as their customers: To keep the price of their service down.
RTFA, and come back if you're ready to tell us you think the people they talked to who are on the blacklist deserve to be there. I'm sure there are lots of deserving assholes on the blacklist too, but the problem is that they are taking an event (suing a doctor) that is completely unrelated to whether or not you are a legitimate problem for a competent doctor (someone suing for no good reason) and blacklist you based on it regardless of whether you sued because you thought the doctor was rude, and lost, or sued because the doctor was addicted to painkillers and caused brain damage to your child, and won.
RTFA. The point is that the article gives several examples of people who WON legitimate malpractice lawsuits and now as a result has a problem finding doctors to treat them. This is a threat not only to those individuals, but to everyone - it raises the bar for people with legitimate concerns over the quality of care they have received to complain or sue to get a dangerous doctor punished.
In one of the cases listed, the hospital knew the doctor was dependent on painkillers and still let him operate. Would you have him operate on you because this system meant someone decided it wasn't worth the risk to sue or complain about him?
It's different, because a doctor can easily cause significantly harm to you if he's incompetent or not doing his job right.
If the database only returned information about people who have sued and LOST several times, it would have been less of a problem. As it stands, it's a danger to public health.
At least one printer company uses IC's in the ink cartrdiges for some models that has as it's sole purpose to make it more difficult to use generic replacements. And yes, those cartridges ARE "non-refillable" - you can of course put more ink in, but the IC tells the printer when the cartridge has been used for X amount of ink, and after that the printer refuse to use the cartridge regardless of how much ink you might have poured into it.
No, printer companies wouldn't have an incentive to standardize, on the contrary - it would give them extra incentives to ensure their models couldn't handle the ink manufactures. What you are missing is that "printer companies" are really INK DISTRIBUTORS. They lose money on all the low end and many of the high end models - what most of them make their money of is ink and toner cartridges.
To make your comparison valid, the oil companies would have been manufacturing cars that they dumped at below cost prices to sell gas, and made sure their car could only take gas from their pumps.
I don't think most people would be expecting something significant to happen with it. If something significant happened with it, the suprise of finding out what the ring really was at the start of LOTR shouldn't have been there. People who have seen or read LOTR should know from the way the story starts that the ring wasn't known by the hobbits to be a source of great evil.
I think that will be one of the things that could be turned into something very cool about a future Hobbit movie: Everyone that sees it will KNOW that the ring is dangerous, which could give the whole thing a very chilling effect with just minor hints here and there spread out in an otherwise relatively cheerful movie.
If it's being used to get rid of people to care for elderly people, then perhaps it would be bad. But if it is used to reduce the time elderly people have to rely on what for many is relatively humiliating assistance and instead give the people caring for them time to spend time with them it would be an improvement.
Technical solutions ARE relevant. I doubt needing to get help from someone to wash myself would be my preferred form of social contact if I was old.
Autozone has a market cap of 7.35 billion dollars. That's hardly small, even though it's "only" about an eight of Disney's size. Autozone reported about 1 billion in EBITDA last financial year on sales of about 5.6 billion, and a free cashflow of about 680 million. Enough that they wouldn't have any problem paying a few lawyers.
And that is without considering that they are likely eligible for quite a bit of funding from the various funds set up to indemnify and protect Linux users against SCO recently.
Slashdot Mirror
As for doing "great things with the OS", while Amiga OS still have some great features, you'd be much better off adding [insert favorite AmigaOS feature here] to existing open source software. The Amiga OS as most of us know it was very intimately tied to an architecture without memory protection for instance, which doesn't really make it easy to bring up to date.
That said, if you want "open source Amiga OS", take a look at AROS. Aaron Digulla and a few other people have done a great job at writing replacements for almost all parts of Amiga OS, and you can run it under Linux (or stand alone if you prefer).
If your comment on fault-tolerant coding adressed shells that correct misspellings, that doesn't make it any more insightful. There is no reason to assume such a shell would encourage sloppy coding - the many examples in this article demonstrates very well why no such shell has been written: It could create dangerous situations from otherwise harmless mistakes - there is no indication that it would in any way make "sloppy coding" any safer, and hence no indication that it would encourage sloppy coding.
As for extending an existing shell, you specifically made the point that you didn't need to extend bash to provide the functionality of ftsh, while your example only show the most trivial functionality. You now "clarify" in a way that to me reads as backtracking. Fine. Yes you can handle errors in bash in a slightly more elegant way than the ftsh website indicates. I pointed out that this was only a small part of the functionality ftsh provides.
Your complaints about ftsh being written from scratch just reinforces the impression I got of your first message. Yes, writing a shell from scratch just to add this functionality might be a waste from your perspective. But we're talking about about 4000 lines of code here - hardly years of work - where providing the "try" functionality and error handling is the ONLY focus (gee, I actually bothered downloading and looking at the source).
It is not a bash replacement. It is not something you would want to use as an interactive shell. It is a shell with the specific purpose of providing more fault tolerant access to distributed, error prone resources. Which is also how it is presented on the website: As a tool to solve a specific problem in a generic, reusable way. Very much in the Unix tradition.
It's possible it would be significantly smaller if written as a bash script. But if it came at the cost of a syntactic kludge it would defeat much of the purpose: Making the appropriate error behavior default throughout the script.
Perhaps because if you have access to run software remotely on a few hundred desktop computers that "has to" run Windows you would like to have the same script environment to use on Windows as on the other platforms you use? Perhaps because automated scripts aren't particularly good at using GUI's?
Resources DO become unavailable in most systems. It simply doesn't pay to ensure everything is duplicated, and set up infrastructures that makes it transparent to the end user - there are almost always cheaper ways of meeting your business goals by looking at what level of fault tolerance you actually need.
For most people hours, sometimes even days, of outages can be tolerable for many of their systems, and minutes mostly not noticeable if the tools can handle it. The cost difference in providing a system where unavailabilities are treated as a normal, acceptable condition within some parameters, and one where failures are made transparent to the user can be astronomical.
To this date, I have NEVER seen a computer system that would come close to the transparency you are suggesting, simply beause for most "normal" uses it doesn't make economic sense.
Yet we are expected to excuse your grammatical and typos. Doesn't that just promote bad practices? Shouldn't we whack you over the head with a baseball bat just to make sure you won't post when you're not prepared to write flawless posts?
The more work you have to do to check errors, the more likely it is that however vigilant you might be, errors slip past. If you have to check the return values of a 100 commands, that is a 100 chances for forgetting to do the check or for doing the check the wrong way, or for handling the error incorrectly.
In this case, the shell offers a function that provides a more sensible default handling of errors: If you don't handle them, the shell won't continue executing by "accident" because you didn't catch an error, but will terminate. It also provides an optional feature that let you easily retry commands that are likely to fail sometimes and where the likely error handling would be to stop processing and retry without having to write the logic yourself.
Each time you have to write logic to handle exponential backoff and to retry according to specific patterns is one more chance of introducing errors.
No offense, but I would rather trust a SINGLE implementation that I can hammer the hell out of until I trust it and reuse again and again than trust you (or anyone else) to check the return code of every command and every function they call.
This shell does not remove the responsibility to for handling errors. It a) chooses a default behaviour that reduces the chance of catastrophic errors when an unhandled error occurs, and b) provides a mechanism for automatic recovery from a class of errors that occur frequently in a particular type of systems (distributed systems where network problems DO happen on a regular basis), and by that leave developers free to spend their time on more sensible things (I'd rather have my team doing testing than writing more code than they need to)
Your example only does a fraction of what ftsh does.
The thing is, if you run a distributed system with a thousand servers, and your patch distribution points drop of the network, you don't suddenly want a thousand servers hammering the networks endlessly. You want things like exponential backoff, timeouts after which the system will change behaviour (stop requesting updates until explicitly requested to start again, start triggering alarms etc.), and that is exactly the kind of scenario ftsh makes easy to do in scripts without having to write all the logic yourself for every bloody script.
I could more damage with "wile true; do ... " in bash. It's not like an infinite loop is very hard. ftsh on the other hand defaults to exponential backoff, which isn't exactly what you want if you want to DOS someone.
Or perhaps you didn't RTFA.
It's not about cleaning up. It's about fault tolerance. Deleting the data file in the case of the example is NOT a failure. Presumably the file is no longer useful (if not the script is buggy). Deleting the wrong data would be a failure. Not downloading the new data at some point in time would be a failure. THAT is what the script as written protects against.
The assumption that it's not ok to delete a data file before the new file is in place assumes that you know something about the uses of the data that the rest of us (presumably including the website author) does not. The deletion could very well be placed first in the script on purpose, to ensure that the data is deleted at the earliest possible time, regardless of the time it would take to download a new data set - possibly because the old data set is obsolete and clients should rather wait for a new dataset than rely on the old.
ftsh provides a mechanism aimed at making it easier to catch and handle error conditions correctly. How does that encourage sloppy coding?
As for your bash example, it only demonstrates the most basic capability of ftsh - exiting on error. It does not differentiate between conditions where the error is likely to be temporary - which happens all the time in distributed systems - and conditions where immediate termination is justified.
RTFA. You're lightyears away from what it's about.
Very rarely is technology itself the focus of the the story - even in the robot stories where a specific robot often seems to be in focus, as one of the main characters in the story, they tend to be only props used to make some point.
This is a common thread with most of the sci-fi that survives long term. HG Wells, the Time Machine stands the test of time because the technology of the time machine isn't relevant to the story line. For that matter, the story could more or less have been told without time travel - just like in for instance Gullivers Travels, the whole journey is just an excuse to set the scene the way the authors wants.
Gibson survives because he's detached enough from technology to write about it in very broad strokes - there are very few details to get hung up about as "dated".
Philip K. Dick survives because most of his stories are about his characters, not about the technology they surround themselves with.
And so on...
The sci-fi that dates badly is the techno-fetishist stuff that is about the technology, as opposed to the consequences of the technology.
It might have been deprecated by some, but outside of a handful of people on Slashdot I hardly ever see people trying to use the crappy "mebi" prefixes. To most of the world 1MB = 10^6, no matter how much you'd like it to not to be.
The thing is, referring to a GB as 1 billion bytes is NOT common use except among harddrive manufcaturers. In fact, there's an ongoing lawsuit going for deceptive marketing over this.
You miss the point. Viacom is putting the thumbscrew on and demands more money. Dish Network has told them they want to keep negotiating because they don't think the fees are worth it - if Dish gives in the customers will have to pay more. Obviously Dish Network is looking out for themselves too, but they have the same interest as their customers: To keep the price of their service down.
Duh... For one thing, how do you think the PC manufacturers power their equipment? How do you think that electricity is generated?
RTFA, and come back if you're ready to tell us you think the people they talked to who are on the blacklist deserve to be there. I'm sure there are lots of deserving assholes on the blacklist too, but the problem is that they are taking an event (suing a doctor) that is completely unrelated to whether or not you are a legitimate problem for a competent doctor (someone suing for no good reason) and blacklist you based on it regardless of whether you sued because you thought the doctor was rude, and lost, or sued because the doctor was addicted to painkillers and caused brain damage to your child, and won.
In one of the cases listed, the hospital knew the doctor was dependent on painkillers and still let him operate. Would you have him operate on you because this system meant someone decided it wasn't worth the risk to sue or complain about him?
It's different, because a doctor can easily cause significantly harm to you if he's incompetent or not doing his job right.
If the database only returned information about people who have sued and LOST several times, it would have been less of a problem. As it stands, it's a danger to public health.
At least one printer company uses IC's in the ink cartrdiges for some models that has as it's sole purpose to make it more difficult to use generic replacements. And yes, those cartridges ARE "non-refillable" - you can of course put more ink in, but the IC tells the printer when the cartridge has been used for X amount of ink, and after that the printer refuse to use the cartridge regardless of how much ink you might have poured into it.
To make your comparison valid, the oil companies would have been manufacturing cars that they dumped at below cost prices to sell gas, and made sure their car could only take gas from their pumps.
If doing that do be aware that the ink cartridges sold with some printers are not full, or at least it used to be that way.
I think that will be one of the things that could be turned into something very cool about a future Hobbit movie: Everyone that sees it will KNOW that the ring is dangerous, which could give the whole thing a very chilling effect with just minor hints here and there spread out in an otherwise relatively cheerful movie.
Technical solutions ARE relevant. I doubt needing to get help from someone to wash myself would be my preferred form of social contact if I was old.
But it is a tool - not a solution in itself
And that is without considering that they are likely eligible for quite a bit of funding from the various funds set up to indemnify and protect Linux users against SCO recently.