On Wednesday, 10 April, 2019 14:21, Peter da Silva <res...@gmail.com> wrote:
>On Wed, Apr 10, 2019 at 3:12 PM Keith Medcalf <kmedc...@dessus.com> wrote: >> Why would anyone fart about with added complication and the >> concomittant increased unreliability when storage is so damn cheap? >Embedded systems and mobile devices. You mean "play things", for the most part. By their very definitions "play things" do not require reliability and as such the added complication and inherent increase in unreliability due to that increased complexity is of no real effect. I am used to dealing with "important shit". That means that if it stops working, even for a minute, it might entail costs of millions of dollars and perhaps a few deaths or cripplings as well. There is a very great difference between the "streaming media crap" not working for a bit and you have to (heavens forbid) read a book, or the mail server going down for a day or two, which are really nothing more than minor inconveniences by comparison. The streaming box screws up? Throw it out and buy another. In the "play things" world adding complexity to increase unreliability and save a few pennies is often a reasonable trade-off. After all, nothing of any real significance will be lost -- it is merely a bit of inconvenience to suffer through with no real lasting impact. On the other hand if the consequence of failure is certain death of 10 people, then I would much rather be spending more money on reliable hardware to maintain the designed level of reliability than to save a few shekels by tossing "compression" into the mix thereby reducing reliability and increasing the probability (through an increase in unpredictable failure modes) of those 10 people dying. I think if you were one of those 10 people with your life at risk you would see things the same way. >But of course those probably don't apply here. :) It is all a matter of perspective. Lets imaging that the problem with the 747MAX was not that the new control system was designed by an idiot and that insufficient training on the detection and correction of the "we know this is going to be a problem" so intruduced were not the issue. Lets say instead that the files were merely a bit too big for the hard drives they decided to use. They have the option of (a) spending an additional $100 and getting larger storage and not changing the failure scenario's at all; or, (b) not spending any money and instead adding yet another layer of software to perform "compression" instead (thus changing the failure scenario's because now you have a whole whack of new failure modes). The "Play Things" people consider that the crash of the airliner and the loss of equipment and all life aboard is merely an "inconvenience" and will choose option (b) because hey, the software always works, right? The "Important Shit" people will consider that the *possible* increase in risk of loss of equipment and life due to the addition of yet more complexity cannot be tolerated and will chose option (a) because it is far more cost effective than the analysis that will be required to *prove* option (a) has not increased the risk. I simply happen to fall into the "Important Shit" category of people by default. I am somewhat risk-adverse as they say. If the risk associated with a thing is significant, then spend as much as required to reduce that risk to an acceptable level. If the risk associated with a thing is negligible, then get the cheapest shit available and when it "breaks" throw it out and get another. This does not mean that the "Play Things" outlook is incorrect. It merely depends on the garden in which you are playing and in to which category the product falls. --- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume. _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
