Oy. I've worked on safety-critical systems with hard real-time constraints too. For the most part they didn't *have* file systems or the file systems were basically read-only in production. Sticking a relational database any closer than the SCADA monitoring node would not be a thing that happens, let alone using a compressing file system to hold that database. But there's a whole spectrum of embedded systems between that and arcade games.
On Wed, Apr 10, 2019 at 5:17 PM Keith Medcalf <[email protected]> wrote: > > On Wednesday, 10 April, 2019 14:21, Peter da Silva <[email protected]> > wrote: > > >On Wed, Apr 10, 2019 at 3:12 PM Keith Medcalf <[email protected]> > 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 > [email protected] > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > _______________________________________________ sqlite-users mailing list [email protected] http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
