> Turns out, an operating system is more than just a kernel with some userspace crap tacked on top, unlike what Linux distros tend to be.
This is also my opinion of OSX, let's not pretend that the userland mess is the most beautiful part of OSX.
Apple has great kernel and driver engineering for sure but once you go the stack above, it's ducktape upon ducktape and you better not upgrade your OS too quickly before they fix the next pile they've just added.
Nobody in their right mind prefer the web apps over the native apps if they sit all day doing e.g spreadsheets. I tried the M365 web app for Word the other day and it's sluggish.
I would bet the opposite, Twitter was already a small competitor compared to Facebook and never reached its popularity, switching the audience to the far right likely cut down even more of what was left.
> this simplicity also comes specifically because there's less contributions.
Not entirely. A rather large amount of Linux's mess stems from the fact that it was a hobbyist project in its foundational years. It was never clean or well designed, at any point in its life. Go look at Linux 1.2.0 vs FreeBSD 2.0
Even when Linux began to get traction, it had already developed an ingrained culture that didn't particularly care about "nice" code or architectural solutions. The BSDs inherited their culture where such things were prioritized. You're right that things get messier as they get larger, but the gap between the two is much, much larger than can possibly be accounted for. Things like Linux not respecting NICE values have very little to do with surface-level problems like stylistic inconsistencies in the source code.
Apple or Google know what the cryptographic signature of the boot should be. They provide the keys. It's how they know that "factory reset" does not include covert code installed by the factory. That's what we're talking about.
I don't think it will matter too much in the long run, 8 of the top 10 smartphone manufacturers are Chinese, there's nothing the US government can really do.
You can support older devices, but admittedly Apple does not make it super easy to find. The easy "happy path" in Xcode is to only support the most recent OS versions.
iirc even then there's a minimum that xcode will still deploy to. The only way to have an app work on older versions than that is to not update it at all
With Android that's definitely not the case. Supporting older phones might get harder over time because you can't use any new APIs introduced in more recent OS releases, respectively always have to provide some fallback code path, and occasionally (at least if you want to publish on the Play Store) you're forced to use the new APIs, so you can't avoid the complexity of supporting both old and new APIs.
Plus if you're using any dependencies, you're also bound by whatever minimum API version all your dependencies are using. (Even Google's support library – on the one hand that one does try to somewhat smooth over the API differences between various OS releases and make your life easier, but eventually it'll also drop old Android API versions – on the conservative side, but eventually it'll do.)
But – if you're prepared to somehow work around all that, there's no hard cut-off, and a modern Android toolchain will still happily produce APKs that would run on by now very old phones, too.
Like e.g. I've taken an old app that had initially been developed during the Android 2.x era (around 2010/11) in order to fix a few annoyances and add some features. Since I didn't do any kind of radical overhaul of the original code so far, the resulting app happily runs both on modern phones (albeit with a somewhat older look-and-feel), but also on the oldest emulator image I could still get to work on my computer (Android 2.3.3 / API10 from February 2011).
reply