You make a long list of things that you probably had to google on, but you still seem to lack any actual, hands-on experience on how things actually work and mo

You make a long list of things that you probably had to google on, but you still seem to lack any actual, hands-on experience on how things actually work and mostly important why systems like SABRE take forever to be replaced. Trust me: it was not because of Linux or the lack of it. Most importantly, though, you keep missing the forest for the three: yes, modern cars have more and more electronics in them, and this most probably runs on customized, hardened Linux or some other modern OS. And they need constant communication with cloud based services etc. etc. This applies also to fridges, TVs and so on. My point is that IN ORDER TO PRODUCE THE CAR, FRIDGE OR TV manufacturing industry still uses for the most part legacy systems and that the cost to replace these with newly developed applications (that for some reason are either available only on Linux or "work better" on Linux) is never been appealing enough to justify the switchover. [also, please stop quoting buzzwords at me: "JIT supply chain management" is what I was working on when I encountered the aforementioned problem on DEX/VAX. The application was written in COBOL, but was the first project where we adopted Oracle (Version 6 I believe) instead of a Hierarchical DBMS. The year was 1991 or 1992, and the company I was working for was definitely a late adopter]. When companies producing TVs switched to more modern, larger screens (let's say LCD/LED)... they just changed the BOM of the new models in their own heavily customized SAP instance. Maybe they had to add a couple of fields to a table because of new characteristics they needed to track and that were not present on older models. They probably revamped their production lines, for sure. They had to hire younger engineers to develop or productivize (sp?) these new technologies. This still did not make a dent in the large pile of legacy code that was used to manage the company as a whole. Even when the PRODUCT is totally, radically new, the systems that manage its production (and sale, and post sale support) do not need to follow suit. You still need to order components to suppliers, schedule the production, deliver the completed product to the customer or to the reseller, possibly keep track of where something was sold/sent in case they need to recall some faulty batch or police needs to know about it (a common requirements for vehicles, for example). The only exceptions to this simple rule are companies like Tesla, i.e. someone who creates a completely new manufacturing company from scratch. Of course, these are outliers, but they are also the only ones that don't already have an enormous amount of resources invested in systems created 25+ years ago. The other exceptions, of course, are companies who do not produce or handle anything physical (remember when I mentioned Airbnb?). These, too, can start from scratch, and maybe for these the technology makes a difference. On the other hand, a startup cannot really afford to pay the exorbitant fees requested by Oracle, and they find it much more convenient using Postgres or any other Open Source product. More power to them. All this does not change my original viewpoint: IT for mature companies is exactly like any other utility. If you need fuel for your steel mill furnace, changing provider every 3 months might help you save a few thousands bucks (because you use so much of the stuff that even a sub-cent decrease in price will be noticeable) ... but by doing so you will probably have to pay 10 times that just guarantee that the switchover to the new supplier goes on without any glitch (like having your gas supply cut off one day or two before the new one starts working). If you need electrical power you may consider to put solar panels on the roof of your plants... just like you may want to put a REST interface in front of some of your stored procedures. But you will still depend on the power company for 99% of your energy, and you will still have to mantain your stored procedure because if you need to change something there, no amount of JSON will solve the problem. This is the gist of my argument, if it still sounds unconvincing to you it may just be because I worked most of my career server side as a system integration expert for large, mature companies. Maybe you have a different background - companies established after the web was born are surely a completely different beast, and my experience most probably would not apply, but as long as we are talking of anything founded before 1990 I am pretty sure that inertia is the prevalent force that shaped their IT landscape.