First, this is an illusion of choice. The software changes anyway, and you can't realistically opt out of it changing by opting out of updates, since compatibility with the external world will force you to keep updating.
Secondly, if you don't like change, putting off upgrades may actually make it worse for you. You will have an "OMG, they've changed everything!" shock when you upgrade rarely. OTOH if you run regular updates, you'll get small changes one at a time, boil-the-frog style. You can't opt out of changes, you can only get them in small drops, or a whole bucket at a time.
> you can't realistically opt out of it changing by opting out of updates, since compatibility with the external world will force you to keep updating
Long term, this has truth (although it's usually overstated -- most software, even internet software, that I have still works even after many years). But what I can do is decide for myself when to make that change. This is particularly important when features I need are removed, as it lets me still have working software while I look for an alternative.
> if you don't like change, putting off upgrades may actually make it worse for you.
It doesn't. UI changes, particularly, are disruptive. Having frequent small ones is far more disruptive to me than infrequent large ones.
In every car I’ve ever looked into, the baffle that selects between recirculate and windshield intake is intentionally leaky enough to prevent CO2 and moisture buildup even in full recirculate mode.
In ICE cars gear shifting gives extra control and power. In an EV it’s emulated by lowering power and reducing the range of control. Technically it’s all backwards.
To me it doesn’t do anything except appeal to feelings and associations drivers have developed in ICE cars.
It’s like adding hiss and crackling noises, and tape rewinding simulator to digital audio.
Chrome is closed-source though. There’s no way to make a reproducible build of Chrome (the Google binary adds DRM and could be adding more).
I’m mentioning this, because this open-closed ambiguity is a typical Google strategy. Similarly, Android in the AOSP flavor is open, but the OS that actually ships on phones is different.
I actually got multiple computers. Some are a bit old, but still usable. Got a MacBook Air for the rare times that I travel. Using an 27” iMac when I am working from home in village. Using a Intel NUC when I am working in the city.
Supposedly macOS learns about your use and applies charging rules appropriately. I haven't seen it actually work in practice though, unlike Windows 11 of all things that asked me "You seem to be using this laptop mostly while connected to power, do you want to limit charging to 60% or 80% to preserve battery life?" And reminds me every month that's the case and that it can be disabled.
Rust has features that look like equivalents of footguns in other languages, so it's easy to assume it can have the same failures.
For example, Rust has Option<String> that is a "nullable" string. missing.unwrap() will throw an exception or abort the program, just like a null pointer access would. You could think that a "bad programmer" will find these footguns and write just as bad code. But subtle differences in how these features work make a big difference in real-world use, even in the hands of careless programmers. A change between non-optional and optional is a type error that needs to be fixed everywhere. Option requires answering "what if it's empty" on every use, so a properly lazy programmer will avoid making things optional in the first place.
Rust also has good defaults. A struct type by default can't be copied, can't be compared, can't be serialized, can't be printed, can't be implicitly created from default values. The programmer is forced to think and explicitly write what can be done with the type. So users of a type can't carelessly copy a unique handle, or end up comparing addresses when they mean to compare values, even if the programmer writing the type forgot to consider these issues.
Apple has fat binaries, and made Xcode produce them by default, with seamless cross-compilation. AFAIK Windows has nothing like that. There are no fat binaries. Cross-compilation is fiddly and needs to be done manually.
There is a massive difference between developers just needing to press the "Build" button again (with no code or config changes), and requiring developers to manually add support for both architectures the hard way.
Secondly, if you don't like change, putting off upgrades may actually make it worse for you. You will have an "OMG, they've changed everything!" shock when you upgrade rarely. OTOH if you run regular updates, you'll get small changes one at a time, boil-the-frog style. You can't opt out of changes, you can only get them in small drops, or a whole bucket at a time.