|
|
|
|
|
by stcredzero
4035 days ago
|
|
There is a huge cadence mismatch between software cycles and capital good replacement cycles. How well would you say that Tesla is coping with this as a company? For that matter, what about Apple? I can't even imagine the number of security patches that have gone into the Linux kernel in the last 11 years. Let's take a step back and think about this statement. Isn't this insane? We know enough to be able to build something much better than this. The reason that we don't, is that we've just kept on pragmatically building on what we had before. We're like a corporation that keeps pouring money into its "stovepipe" system because we keep on making short-term decisions. (Somehow "stovepipe" has come to mean "vertically isolated," but I seem to remember that it also used to refer to the tendency of iron stovepipes to corrode and need constant patching.) |
|
Apple just kind of assumes that you have the latest shiny, because why wouldn't you? This induces a phenomenon I call the Apple Turnover: when a software update aimed at new Apple things comes out and makes your old Apple thing not run so good anymore. Sluggish iPhones are the hallmark example today, but I was bitten badly by this in the mid-2000s when Panther would no longer compile C++ files. You see, one of Apple's OS updates for Panther came with Tiger's libstdc++, which used the new Itanium ABI. This was so Xcode for Tiger could compile programs to run on Panther, but without heroic efforts to set up compiler flags in every package you built to link against the old static libstdc++, compiling on Panther would link against the new libstdc++ by default and fail horribly, rendering C++ code uncompilable. (Deleting or renaming the new libstdc++ was not an option; it was a heavily depended on system component and I think even the header files were changed for the new library.) And a lot of stuff depended on C++, including C-API stuff like SDL. And Apple did fuck all to fix it.
So if you buy a shiny Apple toy, your choices are to commit to upgrading early in the new product cycle or risk an Apple Turnover rendering your purchase, if not useless, then with degraded functionality even relative to the same device when you bought it.
And the pisser is during the 80s and 90s, Apple gear was legendary for running well, and being supported, many years if not more than a decade after its purchase date.