Opposite anecdote, in the 2000s, I worked at a company that had dozens of computers running jobs, built out a server room with raised floors and built out a SAN to store a whopping 3 TB of data and we had a home grown VB6 job scheduler that orchestrated jobs across the computers running Object Rexx scripts.
We had our own internal load balancer, web servers, mail servers, ftp servers to receive and send files, and home grown software.
Now I could reproduce the entire setup within a week at the most with some yaml files and hosted cloud services. All of the server architected is “abstracted”. One of the things he complains about.
As far as backwards compatibility, worshipping at the thrown of backwards compatibility is one reason that Windows is the shit show it is. Even back in the mid 2000s there was over a dozen ways to represent a string when programming and you had to convert back and forth between them.
Apple has been able to migrate between 5 processors during its existence by breaking backwards compatibility and even remove entire processing subsystems from ARM chips by removing 32 bit code compatibility.
Windows is a shitshow beacuse the leadership is chaotic, dragged all around all the time, never finishing nothing well. They only survived because of backward compatibility! Building on the unlikely success in the 90s.
Also, why do I have to install new software in every couple of months to access my bank account, secure chat, flight booking system, etc., etc., without any noticable difference in operation and functionality. A lot of things unreasonably becoming incompatible with 'old' (we are talking about months for f's sake!!) versions. That's a nuisance and erosion of trust.
I wouldn’t call Microsoft’s success in the 90s unlikely. They had a decent product at a low price for commodity hardware when nothing else was as good for as cheap. They also had decent marketing. The company worked hard and delivered. That’s not unlikely, it’s good execution. The unlikely part was something more like OSX taking Microsoft developer market monopoly away.
You needed Visual Studio and C++ to automate even the most mundane things in Windows. Without decent scripting or command line Windows was a developer's nightmare compared to Linux.
Anything providing something like Linux with a polished surface and support for the tools of the rest of office IT (e.g. MS Word) was going to blow Windows away in this area.
OS X was the product of NeXT and Jobs returning to Apple, and those two weren't the only option. There was also Be and Gassee. Apple had to have compatibility layers for that transition, and the amount of work involved was far higher, making success less likely.
At this point, MS had been among the largest purveyors of developer tooling in the PC space, MS-DOS and Windows 3 were pervasive enough to have emulators on workstations, and Apple was nearly dead. When it came to microcomputers that were not workstations (so almost all by percentage), MS was king. They were pushing, for the time, a decent product at a decent price.
Apple coming out of nowhere with a solid product just wasn't likely. It would have been far more likely for the company to die. They did well, executed well, marketed well, but it wasn't likely. It was very risky. Facing down Microsoft at that time was Herculean.
The app updates you mention are most likely due to the problem of not being able to hot update client side code easily / at all in the google/apple ecosystems.
Web actually excels here because you can use service workers to manage versioning and caching so that backwards compatibility is never a concern.
Yes but those updates aren’t guaranteed like they are on web, so you have to ensure backwards compatibility at all times or do painful forced upgrade modals.
Uber still has plenty of drivers in Europe using super super years old versions of the app (I think to circumvent new limits or something) and they still have to keep it working for them
> Also, why do I have to install new software in every couple of months to access my bank account, secure chat, flight booking system, etc., etc., without any noticable difference in operation and functionality. A lot of things unreasonably becoming incompatible with 'old' (we are talking about months for f's sake!!) versions. That's a nuisance and erosion of trust.
And my other question, is why are constant updates a concern? It’s not like you have to get a stack of floppies and upgrade your software or even do anything manually. Everything auto updates.
At least with iOS, iOS 18 supports devices introduced since 2018 and iOS 16 just got a security update late last year and that supports phones back to 2017.
By removing a feature you use, by breaking said feature, by changing UI, requiring relearning, by introducing a new bug, etc - the possibilities are infinite, just use your imagination and rely on your experience using software!
You should be able to write something and have it work for the next 1000 years. There is no reason why it can't.
I imagine a simple architecture where each application has its own crappy CPU some memory and some storage with frozen specs. Imagine 1960 and your toaster gains control over your washing machine. Why are they even in the same box?
And your needs and technogy doesn’t change in 1000 years?
Does it really make sense in 2025 to use Quicken (?) with a dialup modem that calls into my bank once a day to update my balances like I did in 1996?
Imagine 1960 and your toaster gains control over your washing machine. Why are they even in the same box?
Imagine in 2002 your MP3 Player, your portable TV, your camera, your flashlight, your GPS receiver, your computer you use to browse the web, and your phone being the same device…
> Does it really make sense to use Quicken (?) with a dialup modem that called into my bank once a day to update my balances like I did in 1996
Well, the modern hot garbage Intuit forces people to use takes 5-15 seconds to save a transaction, 3-5 seconds to mark a transaction as cleared by the bank, it sometimes completely errors out with no useful message and no recourse other than "try again", has random UI glitches such as matched transactions not being removed from the list of transactions to match once matched (wtf?), and is an abject failure at actually matching those transactions without hitting "Find matches", because for whatever reason the software can't seem to figure out that the $2182.77 transaction from the bank matches the only $2182.77 transaction in the ledger. That one really gets my goat, because seriously, WTF guys?
Not to mention the random failure of the interface to show correct totals at random inopportune moments.
Oh, and it costs 5x as much on an annual basis.
I sure would take that 1996 version with some updated aesthetics and a switch to web-based transaction downloading versus the godawful steaming pile of shit we have now- every day of the week and twice on Sunday. Hands down.
This idea that we've made progress is absolutely laughable. Every single interaction is now slower to start, has built-in latency at every step of the process, and is fragile as hell to boot because the interface is running on the framework-du-jour in javascript.
Baby Jesus weeps for the workflows forced upon people nowadays.
I mean seriously, have none of you 20-somethings never used a true native (non-Electron) application before?
Tbf, RocketMortgage makes Quicken; Intuit makes QuickBooks. Still, I hate the latter with a burning passion, so I’ll indulge that.
What kills me about Intuit is that they _can_ make decent software: TurboTax. Obviously, I’d rather the IRS be like revenue departments in other countries, and just inform me what my taxes were at EOY, but since we live in lobbyist hell, at least Intuit isn’t making the average American deal with QuickBooks-level quality.
It’s not like the non-SaaS version of QB is any better, either. I briefly had a side business doing in-person tech support, and once had a job to build a small Windows server for a business that wanted to host QB internally for use. Due to budget constraints, this wound up being the hellscape that is “your domain controller is also your file server, application server…” Unbeknownst to me at the time, there is/was a long-standing bug with QB where it tries to open ports for its database that are typically reserved by Windows Server’s DNS service, and if it fails to get them, it just refuses to launch, with unhelpful error logs. Even once you’ve overcome that bizarre problem, getting the service to reliably function in multi-user mode is a shitshow.
> I mean seriously, have none of you 20-somethings never used a true native (non-Electron) application before?
Judging on the average web dev’s understanding of acceptable latency, no. It’s always amusing to me to watch when web devs and game devs argue here. “250 msec? That’s 15 screen redraws! What are you doing?!” Or in my personal hell, RDBMS. “The DB is slow!” “The DB executed your query in < 1 msec. Your application spent the other 1999 msec waiting on some other service you’ve somehow wrapped into a transaction.”
It is my understanding that Dan Gilbert (Detroit businessman, owner of the Cleveland Cavaliers) sold Rock Financial to Intuit who then re-branded it as QuickenLoans.
Gilbert then bought the mortgage unit back from Intuit a few years later, and re-branded it RocketMortgage.
I don't think Rocket has anything to do with Intuit/Quickbooks/TurboTax, with RocketMortgage being in Detroit and Intuit still in California (although I know geography doesn't have anything to do with anything really).
That being said, I fully agree with you 120%. I know desktop QB isn't great (it used to be, especially the DOS-based versions), but the SaaS is a hellhole. It's even worse.
How can businesses literally waste people's time like this? It's a real, quantifiable drain on productivity, with an absolutely insane multiplier based on the number of QuickBooks users. Things that used to take under 30 seconds (marking transactions cleared), now takes a minimum of 5 minutes or more. Ditto for any data entry.
For any bookkeeper, this could be an hour or two of just wasted time, each and every day. Just poof. Why? ARR.
Seriously, f*ck these guys. Asshats.
P.S. on your latency comments; I have something that is very relatable (because I do not think modern developers can relate to a non-programming workflow), modern devs, how would you feel if all of a sudden, every keypress in your IDE now took 3 seconds instead of being (mostly) instantaneous? How about if every time you saved your source file locally you got a spinning icon that took 5-10 seconds? What about if the "cd" command on the cli or the "up dir" or "back dir" button in your file explorer suddenly similarly randomly had a spinning icon for 15 seconds? These tiny delays add up in heavily-used software.
This is the effect your latency has on OTHER PEOPLE'S WORK. Just because you think that random sales, accounting, and clerical staff might not be on your level, doesn't mean they like having their time wasted. It's just absurd that this has become commonplace. If devs had to put up with it, that shit would stop immediately, because then they would feel the pain.
Well yeah, 1000 years is obvious hyperbole. But I've been annoyed and frustrated enough by churn over the last two and a half decades that I always ask myself "will this still work in 5 years?" when considering new software - and especially its build process.
It's alarming how often the answer isn't a confident "yes".
That's fair. Too many languages and frameworks are all too happy to break things for pointless cleanups or renames.
Python for example makes breaking changes in minor releases and seems to think it's fine, even though it's especially bad for a language where you might only find that out runtime
Python doesn’t follow SemVer. It’s more like “3.{major}.{patch}.” Also, they have deprecation warnings for many, many releases before finally killing something off.
yeah, it follows their documentation, it's just a bad idea.
A lot of the things they break are pretty minor cleanups and it seems they could easily not have broken things. Many other languages, even compiled languages where the explosions happen at compilation, are much more careful about these things. For a dynamic language like python it's an especially bad idea.
> without any noticable difference in operation and functionality
Presumably a security update would mean a difference in operation somewhere. They were probably referring to the updates that just exist to add ads, promos, design changes, etc.
I am talking about getting outdated and inoperable frequently, several software.
I wouldn't blame it on security, as many of them do.
...or if it is true, this mass security issues emerging from their design, then the situation is even worse than just being lazy ignorant bastards.... or perhaps the mass security problems are related to this incompetence as well?... oi!
> worshipping at the thrown of backwards compatibility is one reason that Windows is the shit show it is
You say Windows is a shit show, but as someone who has developed a lot on both Windows and Linux, Linux is just as much a shit show just in different ways.
And it's really nice being able to trust that binaries I built a decade ago just run on Windows.
I have a legally-purchased copy of Return to Castle Wolfenstein here, both the Windows version and the official Linux port.
One of them works on modern Linux (with the help of Wine), one of them doesn't.
I wrote some specialist software for Linux round about 2005 to cover a then-business need, and ported it to Windows (using libgtk's Windows port distributed with GIMP at the time.) The windows port still works. Attemping to build the Linux version now would be a huge ordeal.
What older architecture? Windows has been on x86 for decades. You should be able to run any 32-bit application built 20+ years ago on modern Windows, assuming the application didn't rely on undocumented/internal Windows APIs.
It has no driver standard on purpose with the intention of getting drivers into the mainline kernel tree.
If drivers are "standard" then low quality drivers full of bugs and security vulnerabilities proliferate and only the OEM can fix them because they're closed source, but they don't care to as long as the driver meets a minimum threshold of not losing them too many sales, and they don't care about legacy hardware at all or by then have ceased to exist, even if people are still using the hardware.
If there is no driver standard then maintaining a driver outside the kernel tree is a pain and more companies get their drivers into the kernel tree so the kernel maintainers will deal with updating them when the driver interface changes, which in turn provides other people with access to fix their heinous bugs.
The drivers for most PC hardware are in the kernel tree. That part is working pretty well.
It's clear that something more aggressive needs to be done on the mobile side to get the drivers into the kernel tree because the vendors there are more intransigent. Possibly something like right to repair laws that e.g. require ten years of support and funds in escrow to provide it upon bankruptcy for any device whose supporting software doesn't have published source code, providing a stronger incentive to publish the code to avoid the first party support requirement. Or greater antitrust enforcement against e.g. Qualcomm, since they're a primary offender and lack of competition is a major impediment to making it happen. If Google wanted to stop being evil for a minute they could also exert some pressure on the OEMs.
The real problem is that the kernel can't easily be relicensed to directly require it, so we're stuck with indirect methods, but that's hardly any reason to give up.
I don't think I'd put the difference between the pc and server markets vs mobile down to vendor "intransigence". Rather, I would say it's a result of the market incentives. For PCs and especially for servers, customers insist that they can install an already released OS and it Just Works. This means that vendors are strongly incentivised to create and follow standards, not to do odd things, and to upstream early. On the other hand in mobile and embedded there is basically no customer demand to be able to run preexisting distro releases, and so vendors feel very little pressure to put in the extra work to get support upstream or to avoid deviating from common practice. On the contrary they may see their custom deviations as important parts of what makes their product better or more feature rich than the competition.
Right to repair laws as you suggest might do something to shift the incentives of vendors in these markets; I don't think they're ever going to "see the light" and suddenly decide they've been doing it wrong all these years (because measured in commercial consequences, they haven't)...
> On the other hand in mobile and embedded there is basically no customer demand to be able to run preexisting distro releases
This is not a difference in customer demand. The customers are by and large the exact same people and the inability to do this has been a major longstanding complaint of phone customers, both from the nerds who want a real third party OS and the ordinary users who are frustrated that the OS on the phone they only bought two years ago is already out of support and the device can't have any currently supported OS from any source installed on it even though there is no good reason it couldn't at least run the current version of vanilla Android.
The difference is a difference in competition. There are a thousand PC OEMs and you can start one in your garage by assembling PCs from parts. The parts are made by a variety of companies (Asus, Gigabyte, ASRock, MSI, SuperMicro, etc.) If PC OEMs started locking the OS to the device so you had to buy a new PC every three years, they would lose customers to ones that don't, because customers would actually have a choice. Even Apple doesn't prevent Asahi Linux from running on Apple Silicon Macs.
The phone market is much more consolidated. Suppose you want a normal ~$300 phone with similar specs to other Android phones at a similar price point, but with an unlocked boot loader and in-tree kernel drivers. It doesn't exist. Customers can't express a preference for it because it isn't available, and the market is sufficiently consolidated that the incumbents benefit more from lock-in and planned obsolescence than they would from gaining market share by providing customers with what they want. Because the companies who do that first would be the small ones or startups who use it to gain market share, but the barriers to entry are kept high through vertical integration because of the lack of antitrust enforcement.
> On the contrary they may see their custom deviations as important parts of what makes their product better or more feature rich than the competition.
This is, to begin with, questionable. Phone customers are not buying phones over "custom deviations". They care about cameras and storage and battery life and price. Nobody wants custom buggy bloatware from the hardware company.
But regardless of that, it's orthogonal to the issue. There is nothing about Vendor Cloud AI Thing which is incompatible with having the drivers in the kernel tree.
> I don't think they're ever going to "see the light" and suddenly decide they've been doing it wrong all these years
Do some trust busting and see what having actual competition does to their behavior.
It's absolutely on purpose. But the tradeoff is Linux has become a really great server OS (because the kernel team can quickly refactor flawed code), but a poor desktop OS (because drivers are harder to ship than on Windows). This tradeoff isn't really well-known or debated in the Linux community, it just kind of exists.
>Apple has been able to migrate between 5 processors during its existence by breaking backwards compatibility and even remove entire processing subsystems from ARM chips by removing 32 bit code compatibility.
I would consider myself an Apple evangelist, for the most part, and even I can recognize what's been lost by Apple breaking backwards compatibility every time they need to shift direction. While the philosophy is great for making sure that things are modern and maintained, there is definitely a non-insignificant amount of value that is lost, even just historically but also in general, by the paradigm of constantly moving forward without regard for maintaining compatibility with the past.
What was the alternative? Sticking with 65x02, 68K, or PPC?
They could have stuck with x86 I guess. But was moving to ARM really a bad idea?
They were able to remove entire sections of the processor by getting rid of 32 bit code and saving memory and storage by not having 32 bit and 64 bit code running at the same time. When 32 bit code ran it had to load 32 bit version of the shared linked library and 64 bit code had to have its own versions.
>What was the alternative? Sticking with 65x02, 68K, or PPC?
No, including an interpreter like they did (Rosetta) was an alternative. The "alternative" really depends on what the goals were. For Apple, their goal is modern software and hardware that works together. That's antithetical to backwards compatibility.
>They could have stuck with x86 I guess. But was moving to ARM really a bad idea?
I don't think I ever suggested that it was or that they couldn't have...
>They were able to remove entire sections of the processor by getting rid of 32 bit code and saving memory and storage by not having 32 bit and 64 bit code running at the same time.
Yes, and, in doing so, they killed any software that wasn't created for a 64-bit system. Again, for even a purely historical perspective, the amount of software that didn't survive each of the instanced transitions is non-negligible. Steam now has an entire library of old Mac games that can't run on modern systems anymore because of the abandonment of 32-bit without any consideration for backwards compatibility. Yes, there are emulators and apps like Wine and CrossOver than can somewhat get these things working again but there's also a whole subsection of software that just doesn't work anymore. Again, that's just a byproduct of Apple's focus on modern codebases that are currently maintained but it's still a general detriment that so much useable software was simply lost immediately because of these changes when there could have been some focus on maintaining compatibility.
> No, including an interpreter like they did (Rosetta) was an alternative.
The downside of including an interpreter with no end of life expectations is that some companies get lazy and will never update their software to modern standards. Adobe is a prime example. They would have gladly stuck with Carbon forever if Apple hadn’t changed their minds about a 64 bit version of Carbon.
That was the sane reason that Jobs made it almost impossible to port legacy text based software to early Macs. Microsoft jumped onboard developing Mac software and Lotus and WordPerfect didn’t early on.
But today you would have to have emulation software for Apple //es, 68K, PPC and 32 bit and 64 bit x86 software and 32 bit and 64 bit ARM (iOS) software all vying for resources.
Today because of relentlessly getting rid of backwards compatibility, the same base OS can run on set top boxes, monitors (yeah the latest Apple displays have iPhone 14 level hardware in them and run a version of iOS), phones, tablets, watches and AR glasses.
Someone has to maintain the old compatibility layers and patch them for vulnerabilities. How many vulnerabilities have been found in some old compatible APIs on Windows?
> The downside of including an interpreter with no end of life expectations is that some companies get lazy and will never update their software to modern standards. Adobe is a prime example. They would have gladly stuck with Carbon forever if Apple hadn’t changed their minds about a 64 bit version of Carbon.
I don't see that as a downside; I see it as a strength. Why should everyone have to get on the library-of-the-year train, constantly rewriting code -- working code! -- to use a new API?
It's just a huge waste of time. The forced-upgrade treadmill only helps Apple, not anyone else. Users don't care what underlying system APIs an app uses. They just care that it works, and does what they need it to do. App developers could be spending time adding new features or fixing bugs, but instead they have to port to new library APIs. Lame.
> Someone has to maintain the old compatibility layers and patch them for vulnerabilities.
It's almost certainly less work to do that than to require everyone else rewrite their code. But Apple doesn't want to spend the money and time, so they force others to spend it.
This may come as a surprise to you, but the vast majority of users absolutely hate it when their software changes.
They don't want all new interfaces with all new buttons and options and menus.
People get used to their workflows and they like them. They use their software to do something. The software itself is not the goal (gaming excepted).
I'm not suggesting that things should never be gussied up, or streamlined or made more efficient from a UX perspective, but so many software shops change just to change and "stay fresh".
I'm not sure why you're responding to me. Nothing that you're saying is anything that I've mentioned or brought up. I know what the downsides are. I'm just saying that the goals that Apple has optimized for have resulted in a loss of things that many would consider valuable.
If Apple users really appreciated backward-compatibility, the would be a significant market for 3-rd party emulators and VMs to run old software using no longer supported hardware or software API. It is not there. There are VMs, but they are mostly used by developers or by people who want to run Windows software on Mac, not old Mac software. So from Apple perspective if their users do not want to pay for backward compatibility, why should Apple provide it?
I wonder how much of that is just lack of awareness. E.g., the whole story at [0] needn't have occurred if anyone involved were aware of VM emulation for older OS versions. But there's no money in selling old software, and Apple would probably open themselves up to lawsuits ("you told me to use a VM, and then it got hacked!") if they openly advertised it.
Plus, the reduced power consumption and battery life extension is insanely good now. Whereas I could only get an hour and a half from an Intel MacBook Pro, I can now get over a days use out of the M4. I have not been affected by the lack of “legacy” software support and I am more than happy to have this tradeoff.
Engineering is always about trade offs. Microsoft could never make the trade offs that Apple has made and while it has suffered because of it in new markets, it’s gained the trust of Big Enterprise. Microsoft should not be trying to act like Apple.
There is room for both. But if you are a gamer, the Mac isn’t where you want to be anyway. Computers have been cheap enough for decades to have both a Windows PC and a Mac. Usually a desktop and a laptop.
I never suggested that they should, in either case. I'm just saying that there are things that are lost by completely ignoring backwards compatibility. There are plenty of Mac-only applications that aren't games that are now obsolete and unusable because of architecture changes.
> All of the server architected is “abstracted”. One of the things he complains about.
This is my personal bugbear, so I’ll admit I’m biased.
Infrastructure abstractions are both great and terrible. The great part is you can often produce your desired end product much more quickly. The terrible part is you’re no longer required to have the faintest idea of how it all works.
Hardware isn’t fun if it’s not working, I get that. One of my home servers hard-locked yesterday to the point that IPMI power commands didn’t work, and also somehow, the CPUs were overheating (fans stopped spinning is all I can assume). System logs following a hard reset via power cables yielded zero information, and it seems fine now. This is not enjoyable; I much rather would’ve spent that hour of my life finishing the game of Wingspan.
But at the same time, I know a fair amount about hardware and Linux administration, and that knowledge has been borne of breaking things (or having them break on me), then fixing them; of wondering, “can I automate X?”; etc.
I’m not saying that everyone needs to run their own servers, but at the very least, I think it’s an extremely valuable skill to know how to manage a service on a Linux server. Perhaps then, the meaning of abstractions like CPU requests vs. Limits will become clear, and disk full messages will cause one to not spam logs with everything under the sun.
You can also reproduce it within a week without hosted cloud services. What matters is that you don't have to develop custom software and instead spend that week writing config files and orchestration scripts, be it cloud stuff, docker containers or whatever.
I can reproduce it without cloud services sure. But then I have to maintain it. Make it fault tolerant. Make sure it stays patched and backed up, buy enough hardware to make sure I can maintain peak capacity instead of having the elasticity, etc.
I have done all of this myself with on prem servers that I could walk to. I know exactly what’s involved and it would be silly to do that these days
> It’s more about x86. Using an x86 laptop feels archaic in 2025. Compared to my M2 MacBook Air or my work M3 MacBook Pro.
From the user PoV, isn't that one of those things that are irrelevant? The users, even the very technical ones, neither know nor care that the computer they are using is x86 or ARM or ...
You might say that the battery life is part of UX, so, sure, I get that, but while, in practice, battery life on the M1/M2/M3/M4 is superior, as a trade-off the user gets a limited set of software that they can run, which is also part of the UX.
So the user gets to choose which UX trade-off they want to make.
If I want the balls to the wall fastest computer that I can buy at a given price, it’s going to be an x86 PC with an Nvidia based video card. If it’s a desktop, I don’t really care about performance per watt.
I personally care because I travel a lot and I need a laptop. For non gamers of course Mac desktops including the new base Mac Mini is good enough.
x86 laptops can’t be as hood as ARM processors as far as performance per watt. Mac laptops using x86 processors the same atrocious battery life, heat issues and fan noises as x86 Windows laptops.
Most likely he doesn't know, as he isn't a phone OEM.
In reality pretty much no Android phone runs a stock upstream Linux. They all have horrible proprietary modified kernels.
So no, Android isn't even Linux in the narrow technical sense of the kernel it runs.
(The Android userland, of course, is an entirely different OS that has nothing at all whatsoever to do with Linux or any other flavor of UNIX, current or historical.)
Wrong question. Android phones run proprietary kernels. So by definition they aren't Linux, even if technically the largest parts of their codebase are taken from the Linux source tree. (Yes, all Android phones technically violate the GPL; in spirit if not in letter of the law. Unfortunately that ship sailed long, long ago.)
Semantic versioning is an illusion. It's a human-managed attempt to convey things about the surfaces and behaviors of software systems. Best case, it isn't completely misleading and a waster of everyone's time.
There is no perfection here, but the correct way to reason about this is to have schema-based systems where the surfaces and state machines are in high level representations and changes can be analyzed automatically without some human bumping the numbers.
So what was the great benefit of removing 32 bits brought? Are you are to use a single string type without conversions with Swift or has that part never disappeared in those 5 migrations?
You know that their desktop processors are minor variants of their mobile processors as are their operating systems? In fact, they ship the same processors in their iPads and Macs.
We had our own internal load balancer, web servers, mail servers, ftp servers to receive and send files, and home grown software.
Now I could reproduce the entire setup within a week at the most with some yaml files and hosted cloud services. All of the server architected is “abstracted”. One of the things he complains about.
As far as backwards compatibility, worshipping at the thrown of backwards compatibility is one reason that Windows is the shit show it is. Even back in the mid 2000s there was over a dozen ways to represent a string when programming and you had to convert back and forth between them.
Apple has been able to migrate between 5 processors during its existence by breaking backwards compatibility and even remove entire processing subsystems from ARM chips by removing 32 bit code compatibility.