4 ms·
> at the same time, desktop Linux distributions and macOS keep iterating and innovating without having that burden. That's a bit of a re-write of history. Mac
by wvenable 4y ago
> at the same time, desktop Linux distributions and macOS keep iterating and innovating without having that burden.
That's a bit of a re-write of history. Mac OS tried to throw away all backwards compatibly on day one but major software vendors told them to pound sand so they had to spend another year building out Carbon. Not to mention that Mac OS X itself is built on NextSTEP.
Linux breaks front-end compatibility so much that never seem to make much progress on stability.
> on top of that, technical baggage keeps holding back Microsoft as well. Apple ditched Intel long ago and now reaps the reward
It's not technical baggage that is the problem. It's strategic issue. Microsoft had a fully functional build of Windows 7 for ARM a long time ago. The problem is they never just released an ARM version of their OS and let developers port their code to it. It was always paired with a new API, the windows store, a locked down version of the OS, etc, etc. This might be specifically to avoid pissing off their hardware partners.
Windows NT was always multi-platform and they always made sure it would build and run on non-Intel CPUs. It has never been a technical issue.
- creatonez 4y agoDid the first OS X release have great NeXTSTEP compatibility?
- pjmlp 4y agoThey did, via OPENSTEP, https://en.wikipedia.org/wiki/Rhapsody_(operating_system) https://en.wikipedia.org/wiki/Rhapsody_(operating_system)
- vetinari 4y agoMacOS breaks compatibility much faster than Linux. New features or APIs in MacOS are adopted much faster than in Linux world, too (see also: Wayland. Or, on similar complexity level, global dark mode).
- wvenable 4y ago"Linux" is harder to define. Are we talking about the kernel, the console user-land, desktop environment? My most recent experience with this was updating the Raspberry Pi OS -- the latest version completely breaks RetroPi and I had to reinstall and revert.
- mschuster91 4y ago> That's a bit of a re-write of history. Mac OS tried to throw away all backwards compatibly on day one but major software vendors told them to pound sand so they had to spend another year building out Carbon. Yes, and other than that the only non-workaroundable - but reasonable - break has been the removal of 32-bit x86 support. The PPC->Intel and Intel->ARM transitions had fully fledged and (at least in the latter case, didn't have a Mac at PPC time) high performant and fully functional runtime emulation/translation to ease it. > Microsoft had a fully functional build of Windows 7 for ARM a long time ago. That depends on your definition of "fully functional". Apple invests insane amounts of effort to tape out good hardware that isn't riddled with weird bugs and edge cases. They don't even publish much documentation, and yet not even a dozen people (iirc, please correct me if wrong) managed to reverse engineer enough to get support merged to Linux mainline. In contrast, the utter bullshit that the rest of the ARM world dares call a CPU is so riddled with bugs that it's a nightmare even for the vendors to keep their custom kernel patches / BSPs up to date, and completely forget about ever upstreaming it to the Linux kernel. And now imagine someone has to write Windows drivers for all that buggy crap. The completely sorry state of how the entire "embedded" world works is holding everyone back so immensely that it takes companies the size of Apple and Amazon to show that the problem isn't ARM itself - and unfortunately, Apple doesn't sell to anyone else and Amazon only makes server CPUs, which means there is zero market pressure, neither for a re-imagine of x86/64 without legacy crap in the instruction set and die, nor for anyone with an ARM license to tape out a SoC at above "barely works, fix the rest in software" quality and decent open source Linux and Windows drivers, nor is there much pressure on AMD/Intel to improve because as long as there is no quality competition from ARM they don't have to fear anyone else eating their lunch. Sorry for the rant, this topic has annoyed me ever since I tried putting an at-the-time modern kernel to an at-the-time-current Mediatek based phone and miserably and utterly failed a decade-ish ago. And nowhere I have looked at in the embedded space since then has shown me any sign of improvement. To the contrary, even projects as popular as Raspberry Pi couldn't arse Broadcom enough to check if the PCIe implementation passed standards validation, they only cared if the USB (and iirc, wifi too) chipset worked. J F C
- wvenable 4y ago> And now imagine someone has to write Windows drivers for all that buggy crap. I don't know how modders manage to get Windows 10 working on Android phones without any source code yet they still somehow manage to get it running with various degrees of success: https://www.xda-developers.com/renegade-project-boot-arm64-windows-10-11-on-android-devices/ https://www.xda-developers.com/renegade-project-boot-arm64-w... And yet, I don't disagree with your rant. The entire "embedded" world is a bit of a mess when it comes to hardware and software. Apple can only do what they do because they manage most of it themselves. Now Microsoft can, and has, also done that to various degrees of success but they're still both hamstrung by their own strategic decisions and by the problems you've described because they're still outsourcing much more than Apple is.