Backwards compatibility has never been Apple's interest or strong suit. That stance allows them to make transitions like this, so you won't see them giving it up anytime soon, for better or worse.
I feel an enormous amount of sympathy for those suffering from this issue, but part of the problem is that these are closed source programs and document formats.
> I opened PageMaker 4 files in PageMaker 6, opened the PageMaker 6 files in InDesign CS6, and opened the InDesign CS6 files in InDesign 2020.
If these applications (or even just the file processing parts of them) were open source, it would be much easier for someone to port them to the new platform than for someone to write an emulator for intel macs.
The files are the actual design files, not just a static version. You can edit, move things around, completely redo the entire composition, etc. Even the full version of Adobe Acrobat is severely limited by comparison.
In effect, these design files are the source code. InDesign/PageMaker/Quark are the compilers with a target output of PDF or some other supported doc type.
Right - this should be completely aimed at Adobe (not Apple) for having piss-poor backwards compatibility and their aggressive deprecation of fully paid software people want to keep using because it's good enough.
Yeah, this isn't exactly a new problem either - the DTP industry has been coping with this for decades. There's probably still some old G4s stashed around just to open old pagemaker/quark files.
OTOH, there's probably plenty of old open source apps where the file formats are inscrutable memory dumps. It's more an open format issue than open code.
Is this Apple's fault? Processors change architecture. Code becomes obsolete. I don't want to minimize the problem the author is decrying, but it doesn't seem like specifically Apple's fault.
That being said, why write an emulator to ARM? Apple Silicon will die someday as well. Write an emulator to JavaScript. If there's a day where JavaScript isn't a valid platform, we'll probably have transcended physical matter by then. There's definitely prior art in browser emulators too.
While I agree the issue is most certainly real, I feel that Apple Silicon is the scapegoat. Computing platforms need to evolve in order to progress, and sometimes the burden lies on developers to keep up. I think this is more of a story about legacy software compatibility and lack of open source solutions.
One of the nice things for users on MacOS is devs are forced to keep up and use the latest standards pretty quickly so everything just works mostly as long as you aren't using an unmaintained tool or updating OS on day one. On Linux I have to use Wayland to properly support different screen DPIs but then a bunch of software hasn't updated to use the new apis because they can just tell the user to revert to X.
This is just a problem with technology generally and digital archives. It's part of the reason why the Internet Archive exists and its mission keeps expanding (thankfully). This is hardly unique to the Apple Silicon moment, especially as the author's concerns largely date back to M64 and PPC days.
I'm certain an open source x86 emulator on ARM will get done (QEMU already?), as these requirements aren't specific to Apple Silicon (although will likely accelerate it).
But if the author is concerned about PageMaker and old zines, why not run the original in something like SheepSaver that emulates PPC? Surely that port will exist (ARM -> PPC) with no need to run old Intel Mac apps.
For PPC Mac emulation specifically, QEMU has been making strides in the past couple of years. It can competently run several versions of Classic Mac OS as well as OS X up through 10.4. 3D acceleration is still missing, but last I checked was in the works.
Yeah... both QEMU and Bochs have long been able to emulate a full x86 system. QEMU at least has had some people boot x86 macOS under emulation, but it hasn't been that interesting until now, since on x86 running macOS under a VM has been more useful.
About 8 years ago, the last time I tried QEMU, it was painfully slow. With 8 years more development & much faster hardware, it should be relatively smooth. In general it seems like emu tech keeps up with the desire for its use.
To be fair, full-system emulation is still going to be pretty slow; emulating an MMU is painful and it's not going to be any easier when you can't use 4k pages.
Oh, this is very interesting—I just finished the Virtual Memory assignment for my Operating Systems class. (We had to use Bochs, and it was slow.) Why is emulating an MMU particularly painful?
Just curious, what OS were you using with Bochs? Last I used it around 8-10 years ago, playing around with Win95. It was painfully slow then, unusable, but I'd be curious about the level of improvement: was it minimally usable?
Well, sort of. The first assignment was to write a bootloader in x86 assembly. For the second assignment we were given a bootloader and a partially-implemented kernel, and we had to finish the kernel by writing a non-preemptive (cooperative) scheduler (including implementing context switching and so on). Third assignment same thing but a preemptive scheduler. And so on. The partially-implemented kernel is very rudimentary—kernel threads but no userspace threads or forking, no filesystem, no virtual memory and no actual difference between kernel mode and user mode (until the virtual memory assignment, in which the partial kernel we were given did actually do ring transitions), etc.
Anyway all this is to say that we were running a very very bare-bones, stripped-down kernel, and even then it was annoyingly slow, so I expect that it would be still be extremely slow running a "real" OS. It's my understanding that that's not really what Bochs is for, though. If you want to run Win95 use a normal VM; Bochs is meant to be a low-level x86 development tool. Though again that's just my impression, so I could be wiong in that.
I don't think so. I recently had a very similar problem to solve (converting old PM4 files from my college years) and had to dig around for a way to run it.
I ended up using a mixture of DOSBox and Windows For Legacy PCs under Parallels:
Not sure on this particular format but apparently the majority of file formats on those older now dead programs were basically just raw dumps of data structures in memory and not actually something well defined like the xml/json files we have today.
Makes reverse engineering them pretty difficult when you have to work out how the original software was laid out.
this my my reaction too, a lot of folks have these things and even love running them (myself included!) it used to be hard to find folks with these, but the internet has brought everyone closer!
This has always been the goal once Apple released the iPhone. It's been their MO for decades even before iOS. They are strongly opinionated and it doesn't stop at the UI. Using Apple is like living a Frank Loyd house. It's really nice, but Frank Loyd was known to tell you how he wanted you to dress and even down to what cutlery and textiles you should have. This is Apple, and in their defense it's how they are able to achieve "It just works" and maintain security. Unlike Microsoft, Apple refuses to say yes to everything. If you don't like it, vote with your wallet. They are many alternatives now, and most applications aren't even native anymore.
It's a solution with a lot of its own problems, but old hardware can help mitigate a lot of this. I can easily run software written for any Apple platform back to the original Apple II (along with several other non-Apple platforms) on original hardware. I'm not suggesting everybody with an interest in old data hoard old machines like me, but perhaps organizations like the Computer History Museum could make available machines for accessing, converting, and saving old software and data to those who need it (possibly for a fee).
And for the specific items in this post, it's not as if anything is an emergency right now. It's reasonable to expect that working Intel Macs will be around for decades to come, just like you can find operational 68K and PowerPC Macs without much trouble right now. It's actually gotten easier to get data on/off a lot of old machines with time, due to things like floppy emulators, SCSI2SD adapters, serial to WiFi adapters, etc. The author could buy a G4 capable of running OS 9 and OS X for less than $100 if they wanted to, and it would still easily connect to modern networks, access modern USB drives, etc.
All hardware will die eventually, but that's going to happen regardless of any processor transition, and there's just no way that these same problems are going to be entirely prevented by sticking with x86 forever.
I do hope somebody comes up with a (non-Apple/Rosetta) x86 emulator for Apple Silicon Macs, sort of like VirtualPC for PowerPC Macs.
It would be awesome if operating systems had super-powered file type detection, to the point where you could double click a “ancient” file format and it would download the correct “ancient” program and run it in the correct emulator transparently.
One of the reasons I’m very for open-source (including all my code) is for the reason that porting is easier. It seems like the gripe should not be with Apple changing processors (or OS’s or hardware features or ...), but rather that (especially commercial) software is so fragile to medium-term environmental change. Binaries are just not very resilient artifacts, especially when they so closely depend on their surroundings. High-level programming language code, on the other hand, is much more resilient.
It’s also a reason I use Lisp: the spec doesn’t change and won’t change. Stuff runs forever.
Bingo! It’s boil-the-ocean level crazy to attempt to recreate the environment for a particular file, when the sensible approach would be to just have the file format and it’s reader/viewer software be open so it can be recompiled or ported to any new platform. The blame/responsibility lies not with those innovating on hardware, but those who have created brittle software systems which have no ability to adapt to the changing environment.
Yet another example of how holding binary artifacts is not functional equivalent to “owning” software.
agree, the authors mention of hacking around activation servers on legacy products is as much the problem as anything. it’s an odd sort of expectation that we’d have to be able to emulate 3+ generations of hardware on top of one another just to access an old file. Should we expect to be able to do this as hardware gets more sophisticated? I’m not convinced we should.
This is probably a path dependent outcome from the process that brought us the the "personal computing" era. It really kicked into gear and achieved ubiquity with Microsoft selling both the main operating system AND the "standard" productivity software suite that was the primary reason people owned computers. MS made their money back then selling upgrades to Microsoft Office that broke backwards compatibility. Part of the strategy was owning the environment so they could work in some amount of engineered obsolescence into the software lifecycle.
Of course, because Microsoft was a multi-headed chimera, Windows itself bent over backwards to keep everything not Office chugging along forever.
Binaries are just not very resilient artifacts, especially when they so closely depend on their surroundings. High-level programming language code, on the other hand, is much more resilient.
That’s a modern phenomenon. AS/400 or Solaris binaries were different.
Which was, in fact, a lot of the impetus behind open source generally early on. And even the less formal sharing of Unix source code given that it was written in a high-level language and could therefore be relatively easily ported to new systems.
> Binaries are just not very resilient artifacts, especially when they so closely depend on their surroundings.
Depends on the platform. I can run statically compiled Linux binaries that were released 20 years ago just fine. Similarly, I'm able play Windows games that were released over 20 years ago.
These are examples of binaries that explicitly don’t depend on so much of their surroundings. They depend on the existence of a processor and a binary executable format, and perhaps some very basic syscalls that had no business changing.
Maybe the binary runs, but for any non-trivial I/O (GUI, 3D, specialized input devices) you're still dependent on specific interfaces which are probably not the same anymore.
Case in point: try running any of the Loki Linux game ports from 20 years ago on a modern distribution...
Not by accident... Linux, windows and intel have put in a lot of effort to ensure this holds, specifically because binaries are so incredibly fragile — hell, you’d have the same trouble Mac is having now if you tried to swap out to AMD on any OS; or tried to swap out OS on same hardware.
Really, you should generally be under the presumption that changing anything at all could screw up anything and everything; it’s really a marvel of human engineering anytime software runs successfully
There is a great DailyWTF somewhere about a company that was using an early IBM mainframe, which when it died, instead of porting their code to the newer mainframe, the wrote an emulator. And when AIX came around they wrote a mainframe emulator to run their old emulator...
Indeed. The most stable long-term is probably a small C program, designed for pipes with stdin as input, and stdout as output. UNIX philosophy is great for longevity.
"Everything is a file" only works when TXT is the file format though. When things build up to PostScript or PDF, or Claris... then things get out of hand too quickly.
… why would it not run fine? Python 2.7 is “no longer receiving updates”, not “ceasing to exist”. You can still download source code back to Python 1.5.1 if you really want to run code with old syntax (Which I just did for fun - the C code needed one tweak to avoid conflicting with a recently introduced standard library function; the python code was fine)
Will Lisp ever specify concurrency as part of the specification ? Standard well-supported concurrency is vital for any modern-day programming language. Without that, common LISP is relegated to the realm of gradually dying languages.
Exactly the reason I dipped my toes in Racket, loved it, then went back to Elixir (and Rust). Without a good runtime / libraries to tackle concurrency and parallelism in a transparent way -- as Erlang/Elixir and other BEAM VM languages do -- the other traits of a language take a back seat.
I would like to see more companies open source their commercial products after maintaining them is not cost effective. I would like to see mostly open source code, period.
re: Lisps: I have been using Common Lisp since 1982 (and other Lisps before that) and I love it that my old code and archives of other peoples’ Common Lisp code usually runs with no problems.
Here's the thing: Apple is to computing hardware as Prince is to music.
Prince was, notoriously, very protective of his music. Much, perhaps most, of his output is locked away in a vault, perhaps never to be heard. And of the material that was released, he didn't allow covers except by artists he handpicked; he was also the only artist to consistently turn Weird Al down when approached for a parody of his music.
But Prince was a Da Vinci level genius. Every song he released was a treasure. So anyone who knows anything about music will admit that not only did Prince have the right to be so protective, but he has already gifted us with so much that to be angry at him for not giving us more is to be selfish.
Apple is like that. They kickstarted the personal computing revolution, and every single computing revolution to come after. GUIs in 1984, portable digital music players in 2000, smartphones in 2007, tablets in 2010. The Apple M1 Mac is the first personal computer to be developed, hardware and software, soup to nuts by a single company. It is the first machine to uncompromisingly represent a single vision for computing and how humans engage in it. It is not only the best computer on the market by a wide margin, it is the next revolution. The machines they just released are only the beginning: the future portends even higher performance desktops and laptops with lower power draw and heat/noise output than anyone else on the market. They absolutely deserve the very strict control they exercise over their platforms because that control has let them shape an impeccable vision of how computing should work. (Which becomes even more appealing when you consider the messes the Windows and Android ecosystems have become.) To demand that they turn loose of that control, for the sake of the few users still running legacy apps, is to compromise what makes Apple, Apple. Macs run macOS, and macOS runs on Macs. Demanding open source emulation of macOS compromises that. It's not going to happen.
When I started work at MIT in the 90s, they had a lot of SGIs around. Those were amazing machines at the time.
Apple is going to ship at some point a 5k (or maybe a 6k, since they're already selling a 6k display that all of the M1 Macs can drive [1]) super thin, iMac Pro with the desktop version of the M series, with 6 or 8 FireStorm cores (instead of the 4 the M1 has) that supports 32 or 64 GB of RAM…
As someone who went through the PowerPC->Intel change, it was very smooth. At some point Apple decided that the translation layer would not be supported in the new OS (leaving 3 applications for me to unexpectedly stop working, as I had forgotten they weren't x86 apps). Probably why they had pop-ups telling us the old 32 bit applications would stop working recently.
Apple could have made "Rosetta 1" open source for enthusiast to maintain. They didn't. I doubt they'll do it now for Rosetta2.
Apple does this all the time, pushing aside the old to make way for newer stuff. (MacOS before X, 32/64 bit, a lot of my old iOS apps just stopped working with a note to contact the publisher). My my old snow leopard machine stopped working getting updates from macOS and became useless, but will run windows/linux. Software support requires endless maintenance esp on mac, and Apple limits support to the last 5 years (or so) of machines.
The "WinTel" (is that still a term window/ intel) machines seem to bend over backward for legacy applications to still run, which is part of their appeal (esp to business), but probably saddles them with technical debt. The "new" cost of lower performing machines and shorter battery life, is software lifespan.
I was led to believe Rosetta (1) left us so quickly because a majority of the tech behind it was licensed from someone else (Transitive?). There's a high chance open sourcing it was never an option.
I hadn't heard that, but I wasn't really paying attention.
I looked into Transitive and they did do Rosetta1. So it wasn't Apples to open source (and apple was in a more precarious financial position back then). . They're an IBM company now which makes since IBM could use PPC translation. I know a few people who really liked that instruction set.
The author never clarified why SheepShaver and other emulators can't be made to work on ARM.
SheepShaver in particular already works on PowerPC and Intel so clearly they structured the code to support multiple platforms. Instead of trying to get Apple to open source Rosetta 2 maybe instead focus on adding ARM support.
Sheepshaver runs on the Pi, so I don't see any fundamental problem. The Author genuinely seems more annoyed that the goal posts keep moving, rather than any of this actually being impossible.
There's no fundamental blocker to emulating x86 either - qemu does it, and will run up to Tiger. I'm almost positive the only reason we're not emulating amd64 is that the cost hasn't been worth it so far. And eventually, one day, we'll be emulating Apple Silicon on something too.
This article seems to laying a lot of blame/duty on Apple for reasons I don't think are very valid. The author even recognizes the fact in the piece.
If there is anyone to lay a duty toward, I would argue it's the developers (Big developers, like Adobe) who could contribute directly in providing code/documentation for their legacy formats.
• Should not have dropped support for Carbon and 32bit apps.
• Should not remove Rosetta 2 in a few years, as many believe they will.
I acknowledge that it's easy for me to sit here in my chair and say that someone else should be doing extra work—but we're talking about one of the most profitable companies in the world! Apple could hire engineers to maintain this stuff, if they wanted to spend the money. It would not somehow make the rest of macOS worse—no one is required to use old APIs.
If you compared the amount of effort it would take Apple to maintain these systems, with the combined effort of every single developer migrating their software, I'm pretty confident the former route would be a lot less work. The alternative is that developers migrate to systems like Electron instead of trying to keep up with macOS's changing base, and that's not good for users.
I acknowledge that it's easy for me to sit here in my chair and say that someone else should be doing extra work—but we're talking about one of the most profitable companies in the world! Apple could hire engineers to maintain this stuff, if they wanted to spend the money. It would not somehow make the rest of macOS worse—no one is required to use old APIs.
It's not about not forcing developers to use old APIs; there are lots of developers who wouldn't upgrade their existing apps because they still ran.
It's just human nature to not want to update your apps if they're working fine under Rosetta or using Carbon and 32-bit APIs.
Among the many other issues this would cause, people would expect 32-bit Carbon apps to run on an M1 Mac; trying to do so would make Rosetta much more complicated.
The other thing is by pushing the leading edge, it gives upstarts a way to enter the market against incumbents. It's doubtful Affinity, which makes fabulous design apps [1] would been able to gain a foothold at all if old versions of Photoshop, Illustrator and PageMaker/InDesign just ran forever because Apple kept backwards compatibility with old APIs and frameworks.
And unlike Adobe, Affinity takes full advantage of Apple's latest APIs and frameworks in a way Adobe never has, to make them competitive.
It also discourages developers from using newer, better APIs to move things forward. Apple developed some amazing technologies in the 80's/90's they discontinued when MacOS X became a thing, like QuickDraw GX, HyperCard, OpenDoc, OpenTransport, etc.
I've experienced every Mac transition starting from the classic Mac days (16-bit 68000) to today, with 64-bit Intel and ARM processors. There's not anything off the top of my head I'd want to use today from back then.
I also started the first Newton users group in the world at least a year before the Newton MessagePad shipped in 1993. I know people who are still pissed that Steve Jobs canceled the Newton when he became iCEO in 1997.
> It's not about not forcing developers to use old APIs; there are lots of developers who wouldn't upgrade their existing apps because they still ran. It's just human nature to not want to update your apps if they're working fine under Rosetta or using Carbon and 32-bit APIs.
And for every developer who took the time to update their apps to modern libraries (and would not have done if not forced), how many just moved to a non-native framework like Electron instead? I don't think this work the way Apple thinks it does.
> And for every developer who took the time to update their apps to modern libraries (and would not have done if not forced), how many just moved to a non-native framework like Electron instead?
Like the poster you're replying to, I've been through all of Apple's transitions from the 68K days to now. And in this context? I can't honestly think of any apps like that. The Electron-based apps I know of started as Electron-based apps. Adobe and Microsoft have their own proprietary cross-platform toolkits, but they're still ultimately building actual Windows or macOS apps; the Affinity apps are likewise native to their operating systems; many of the productivity programs I'm often in (Ulysses, Acorn, Drafts, Scrivener, BBEdit, Nova, MindNode, Safari) are actual genuine Mac apps.
I think the things here are that (a) it may be easier to port an "old" native Mac app to "new" native Mac frameworks than to completely rewrite the app; (b) Electron is relatively new compared even to the "new" Mac frameworks (Cocoa is nearly two decades old, older if you count NextStep!); (c) while Electron might be high-performance enough now to write a full-blown desktop publishing program in like the one the article poster (who is my former college roommate, it turns out, hi Franklin), it definitely didn't start out that way; (d) a lot of folks are still not super thrilled with most Electron apps compared to native ones anyway. Yes, Visual Studio Code rocks, but it's kind of the exception to the rule.
Personally, I also think Apple being more ruthless than Microsoft in deprecating old APIs is probably a good thing for the Mac platform in the long run. one of the programs I used to use more often, Dramatica Story Expert, has been tenaciously clinging to the trailing edge of technology for years: like me, it started on the Mac in the 68K days, and it has stubbornly missed every single transition, its developers doing the absolute bare minimum after the fact to get it quasi-working. This is an app which, in 2020, is not only still 32-bit, but does not run at retina resolution because they have been hacking their old codebase rather than moving to "new" -- i.e., from this century -- APIs for shit as basic as text rendering. Its text boxes don't respond to OS X key shortcuts, it doesn't support services, its fuzzy UI is in Lucida Grande. I look at its sorry ass and shudder to think what the state of Mac software would be like if Apple had gone out of their way to make it easy for developers to behave that way.
Ideally there would be incentives to upgrade because there are benefits to doing so, and not just because upgrading is convenient for Apple's bottom line.
I realize this ship has long since sailed, but when OS X dropped Classic, it weirded me out that they could keep the name "Mac" for this completely incompatible computer, and that seemingly nobody blinked.
> but we're talking about one of the most profitable companies in the world! Apple could hire engineers to maintain this stuff, if they wanted to spend the money. It would not somehow make the rest of macOS worse—no one is required to use old APIs.
I think it's a mistake to assert that a company should always indefinitely support their software. There's certainly an upside in maintaining backwards compatibility, but there's also certainly a distinct other upside in breaking it (e.g. authentication services dropping support for HTTP and requiring HTTPS).
To restate that in a more generic way: given multiple existing constraints and you want to add on even more constraints, there's no guarantee that you can always satisfy all constraints under all circumstances (e.g. if you have to support multiple API versions, you can't necessarily always support every single one since sometimes the changes are fundamentally backwards incompatible).
I had to convert some ancient college stuff I had done in PageMaker 4, and it was bizarre enough to do it using a mixture od DOSBox and Windows FLP on Parallels, so I fully get this.
And it's not "just" the software or the architecture or the OS, sometimes things like fonts (and other minor things) get in the way. But it's amazing to unpack an old Windows binary from 1994 and having it _just work_:
This is an anti-technology point of view. It's astounding to read (on HN of all places) a complaint about this major new processor advancement, because it won't support all his legacy desktop apps.
Technology can't simultaneously progress while still remaining backwards-compatible for years or decades. As another commenter here says: just use an old computer to run your old software. When your old computer breaks, buy another on ebay. Ebay won't run out anytime soon.
That's because you're locked into the x86 paradigm. Look at the leaps and bounds Apple is making with performance/Watt by moving away from x86. This is the cost of legacy.
Architecture emulation like QEMU provides is commonly used, just a matter of how much investment is made into backwards compatibility by those who build your operating system/platform.
Apple works hard to break backwards compatibility every few years, while other operating systems will happily run software from decades ago as they care and invest in not breaking userspace.
Apple really likes being on the bleeding edge of computers, and it often comes at the cost of older programs and features being killed off in that process.
The key is that they're statically linked. Even so, you will begin to run into some issues in that time frame.
My last experience trying to deal with ancient Linux binaries on an ARMv5 device running linux 2.4 was pretty abysmal. There were some breaking changes in the mid 2000s, I believe regarding threading? Old executables wanted LinuxThreads while modern linux uses NPTL. Not sure though. Might have just been a userland/libc problem.
Sometimes, even Linux breaks backwards compat to progress.
This is the problem. They could bundle an emulator for old hardware, but they don’t bother. Why should they? Customers are signaling a willingness to buy new hardware that simply won’t run some of their software.
Heck there will be a time (already happening in some cases) when these same apps will run better/faster emulated on new hardware. Your computer today can run old DOS applications a lot better than the IBM PC 5150 ever did.
Emulation & virtualization isn't exactly a new thing, either. In the same way we have DOSBox for running old DOS stuff, we'll end up with an OSXBox when Rosetta 2 is EOL'd or whatever. Or just fire up a copy of Sierra in VirtualBox for your old software needs - we're not going to forget how to execute x86 in a few years or anything like that.
> Technology can't simultaneously progress while still remaining backwards-compatible for years or decades.
This seems like the truly anti-technology opinion, to claim that technology lacks the ability to progress into the future without losing sight of the past.
> As another commenter here says: just use an old computer to run your old software.
Developing emulators is a much easier solution than preserving compatibility at the hardware or even the OS level. The fact that 20-year old windows games work fine is a product of Microsoft spending insane resources to maintain vendor lock-in.
Emulators themselves tend to be highly portable, for example I suspect that zsnes and dosbox will "just work" on arm64 macs or even RISC-V.
Otherwise I agree but: ZSNES is probably a bad example. It's written in inscrutable 32-bit x86 assembly language and hasn't been updated in nearly 15 years, so it's unlikely to be ported anywhere.
Sure :) although I don't know if that still means that the inner emulator is "highly portable" or "just works" exactly - at least compared to any other software.
(At the end of the day you shouldn't be running ZSNES anyway. In terms of accuracy, compatibility, even security: way better SNES emulators out there.)
> Technology can't simultaneously progress while still remaining backwards-compatible for years or decades.
microsoft and x86 have entered the chat...
in all seriousness, there is a legitimate tradeoff to be made here. the accumulated legacy cruft can make it quite annoying to write code targeting windows. but once you get it done, you can be confident that it will work for a long time. on macOS, the APIs tend to be a lot cleaner, but you pay for that with features that are routinely deprecated, triggering major rewrites. as a developer, I do prefer microsoft's stance. I don't use macOS enough to have a real opinion as a user, but it is nice that I can run pretty much any windows software from the last twenty years without spinning up a VM or booting an older machine.
Here's a thought I just had: backwards compatibility will keep old customers happy while breaking changes make a certain percentage of them quit your platform or perhaps just complain loudly on Internet forums. But if you keep your product modern and flexible, free of cruft, then you're able to pivot quickly when new technology, new markets, and new products demand it, and address the ever growing market. New customers and developers are being born every day or in the developing world coming into the market. These will outstrip any losses you have from grumbling ex-customers. Being able to address their needs is probably more profitable.
Sidenote - it's funny that Microsoft is so stable for their customer base while just constantly churning their frameworks and APIs. I worked in an MS shop, and boy, it seemed like they were introducing a new GUI or Web framework every six months, while of course slowing down or deprecating the older ones.
you're not wrong; it's definitely a tradeoff. different points along the continuum of new features vs compatibility will make sense for different products.
imagine a word processor that made breaking changes to its file format every year. there's no new feature that could be worth that amount of hassle in 2020. in markets that are still changing rapidly, it's okay to be more aggressive with phasing out support for older versions. from my perspective, the desktop OS is already mature. more than anything else, I just want it to not break things that already work.
Apple Silicon is good for everyone. If it succeeds, it shows other businesses how powerful ARM can be.
Apple does not need to dominate the PC market to make money. What they deliver pushes other competitors to improve.
I, like the commenter I've replied to, can't believe that we're even able to frame a processor power shift like this in a bad light. It shows companies they can build something big without x86 - that's good for hardware in the long run, irrelevant of whether it's Apples variant or not.
It's our responsibility, as enthusiasts, to make sure legacy lives on. Plenty of people are building emulators, making home networks with old hardware.
It would be much easier if Copyright/Patents expired shorter after the big money has been made. Things should become open source to let everyone in after the inventor has reaped the benefits of their creation.
>If it succeeds, it shows other businesses how powerful ARM can be.
You say that as if it's about ARM. Plenty of ARM chips on mobile side - none of them come close to Apple mobile performance. Maybe I'm missing something but it looks like Apple has a good chip design department and I don't see how this translates to other ARM devices - Microsoft had their surface with Snapdragon and AFAIK the performance/usability was nowhere close.
It's not that I meant to be even ARM specific, but it shows that you can build a modern, performant system with your own chips without x86.
That sucks for Intel but is fantastic for everyone else.
Other vendors using ARM chips means virtualization becomes easier between platforms. Linux servers are going to be running ARM soon with Amazon etc designing their own chips so web devs will want to be ARM native.
AMD can essentially take the high end x86 market and dominate gaming alongside Nvidia GPU's and others can experiment elsewhere!
But can one compare them? Isn’t it true that RISC-V is merely an instruction set, whereas ARM is much, much more than that - it’s a whole universe of high-quality hardware designs sold (licensed) by a private company right now. And if some other company starts selling/licensing similarly high-quality designs that use the RISC-V instructions, why would that be exciting?
I'm not particularly expert on this, but it seems like RISC-V is ramping up pretty quickly. Presumably an advantage to customers would be that they ideally wouldn't have any vendor lock-in (they could easily switch to a different RISC-V vendor, or even start manufacturing RISC-V chips themselves). They could also customize the ISA with extensions if they had an application for that (although it seems quite conceivable that that's a possibility with ARM too in some way; I don't really know).
I realize that just having a lot of RISC-V hardware options available isn't a guarantee that they're particularly good in terms of their price-power consumption-performance tradeoffs, especially in comparison to ARM (the "whole universe of high-quality hardware designs" that you mention). That may well have more of a delay.
No that sucks for everyone. It sucks for Intel too, but apples chips are now a proprietary design that apple themselves own, where software has to conform to.
Nothing good comes from one company owning the entire pie. You create conformance with apple's chips you're subjugating software to apples monopaly whims.
Apple is nowhere near 'owning the entire pie'. If anything, by adding the ARM option to the pie it increases the amount of competition.
A few years ago (before AMD rebounded with Ryzen) Intel was also a de-facto monopoly, but the only possibility of avoiding them was to settle for significantly less performance.
Now we have 3 players in the high-performance desktop market, seems like an improvement to me.
Except it’s really not though? OP loves technology, saying it revolutionized several industries and really appreciates the power and innovation desktop publishing specifically brought. All they’re asking for is a stronger ecosystem for porting older applications, not for Apple to go back to x86. OP is even way more open than most (surely than I would be) to all the steps it takes to convert between the various proprietary file formats over the years.
I wish a research group would start from scratch and design the best PC and server hardware and software for today's world, not taking any backwards compatibility in mind, just pure, new stuff that's designed with all of today's advancements in mind.
Itanium tried to design the best possible processor for tomorrow's world, when compilers were going to be much smarter than they are now. Unfortunately that didn't happen.
> Technology can't simultaneously progress while still remaining backwards-compatible for years or decades
I agree to some extent, but at some point we (as in society) need to come up with some sort of standard for file formats and for user interfaces that will last for decades. Part of what makes technology useful is that when a tool is invented, it's function and our interface to it don't significantly change for sometimes thousands of years.
Take a hammer as an example. Even though there have been advancements in design and durability, any human who has ever used one can use another. That's why so much of the actually important stuff still runs inside the Windows ecosystem. Until the ribbon redesign, you could take anyone who knew excel, sit them in front of any newer or older version, and they could get to work.
What I don't understand is why the technology industry can't deliver one UI paradigm per decade, loosely couple the UI to the services that manipulate the state, and then allow the user to stick with one interface to get their work done for as long as their career. Then every 30 years you could break the oldest UI -- not sure why you would need to, but whatever -- and then the whole world could save trillions of hours of lost productivity instead of dragging themselves through redesigns that only exist because they give VPs a line in their resume.
(In this fever dream we all work four days a week. Programmers have time to produce immaculate, well documented, and bug free code. The hacker gods are now roboticists putting the finishing touches on fully automated luxury space communism.)
Really well put comment! People padding CVs / resumes are a huge problem in our area and everybody is suffering -- programmers, IT/sysadmins, and the users. I really can't understand why is this tolerated. I mean, I can... but it's a figure of speech.
I dream of the day when programming and UIs will be much more strictly regulated (yes, actually regulated) but I am 40 now and I am not sure I'll live to see the day.
171 comments
[ 5.2 ms ] story [ 212 ms ] thread> I opened PageMaker 4 files in PageMaker 6, opened the PageMaker 6 files in InDesign CS6, and opened the InDesign CS6 files in InDesign 2020.
If these applications (or even just the file processing parts of them) were open source, it would be much easier for someone to port them to the new platform than for someone to write an emulator for intel macs.
In effect, these design files are the source code. InDesign/PageMaker/Quark are the compilers with a target output of PDF or some other supported doc type.
OTOH, there's probably plenty of old open source apps where the file formats are inscrutable memory dumps. It's more an open format issue than open code.
That being said, why write an emulator to ARM? Apple Silicon will die someday as well. Write an emulator to JavaScript. If there's a day where JavaScript isn't a valid platform, we'll probably have transcended physical matter by then. There's definitely prior art in browser emulators too.
I'm certain an open source x86 emulator on ARM will get done (QEMU already?), as these requirements aren't specific to Apple Silicon (although will likely accelerate it).
But if the author is concerned about PageMaker and old zines, why not run the original in something like SheepSaver that emulates PPC? Surely that port will exist (ARM -> PPC) with no need to run old Intel Mac apps.
Well, sort of. The first assignment was to write a bootloader in x86 assembly. For the second assignment we were given a bootloader and a partially-implemented kernel, and we had to finish the kernel by writing a non-preemptive (cooperative) scheduler (including implementing context switching and so on). Third assignment same thing but a preemptive scheduler. And so on. The partially-implemented kernel is very rudimentary—kernel threads but no userspace threads or forking, no filesystem, no virtual memory and no actual difference between kernel mode and user mode (until the virtual memory assignment, in which the partial kernel we were given did actually do ring transitions), etc.
Anyway all this is to say that we were running a very very bare-bones, stripped-down kernel, and even then it was annoyingly slow, so I expect that it would be still be extremely slow running a "real" OS. It's my understanding that that's not really what Bochs is for, though. If you want to run Win95 use a normal VM; Bochs is meant to be a low-level x86 development tool. Though again that's just my impression, so I could be wiong in that.
I ended up using a mixture of DOSBox and Windows For Legacy PCs under Parallels:
https://taoofmac.com/space/blog/2020/10/24/2100
Makes reverse engineering them pretty difficult when you have to work out how the original software was laid out.
And for the specific items in this post, it's not as if anything is an emergency right now. It's reasonable to expect that working Intel Macs will be around for decades to come, just like you can find operational 68K and PowerPC Macs without much trouble right now. It's actually gotten easier to get data on/off a lot of old machines with time, due to things like floppy emulators, SCSI2SD adapters, serial to WiFi adapters, etc. The author could buy a G4 capable of running OS 9 and OS X for less than $100 if they wanted to, and it would still easily connect to modern networks, access modern USB drives, etc.
All hardware will die eventually, but that's going to happen regardless of any processor transition, and there's just no way that these same problems are going to be entirely prevented by sticking with x86 forever.
I do hope somebody comes up with a (non-Apple/Rosetta) x86 emulator for Apple Silicon Macs, sort of like VirtualPC for PowerPC Macs.
It’s also a reason I use Lisp: the spec doesn’t change and won’t change. Stuff runs forever.
Yet another example of how holding binary artifacts is not functional equivalent to “owning” software.
Of course, because Microsoft was a multi-headed chimera, Windows itself bent over backwards to keep everything not Office chugging along forever.
That’s a modern phenomenon. AS/400 or Solaris binaries were different.
My point is about this sort of thing:
> [...] anybody who has read the Old New Thing blog (https://blogs.msdn.microsoft.com/oldnewthing/) or Raymond Chen's chapter on Windows backwards compatibility (http://ptgmedia.pearsoncmg.com/images/9780321440303/samplech..., PDF) will be both impressed and horrified at the lengths the Windows team went to in order to avoid breaking programs.
https://news.ycombinator.com/item?id=13450629
Depends on the platform. I can run statically compiled Linux binaries that were released 20 years ago just fine. Similarly, I'm able play Windows games that were released over 20 years ago.
Case in point: try running any of the Loki Linux game ports from 20 years ago on a modern distribution...
Really, you should generally be under the presumption that changing anything at all could screw up anything and everything; it’s really a marvel of human engineering anytime software runs successfully
Epigram 120, Alan Perlis.
http://www.cs.yale.edu/homes/perlis-alan/quotes.html
There is a great DailyWTF somewhere about a company that was using an early IBM mainframe, which when it died, instead of porting their code to the newer mainframe, the wrote an emulator. And when AIX came around they wrote a mainframe emulator to run their old emulator...
This maybe the story I was misremembering the details of?: https://thedailywtf.com/articles/No_Need_to_Change_It!_
"Everything is a file" only works when TXT is the file format though. When things build up to PostScript or PDF, or Claris... then things get out of hand too quickly.
I would like to see more companies open source their commercial products after maintaining them is not cost effective. I would like to see mostly open source code, period.
re: Lisps: I have been using Common Lisp since 1982 (and other Lisps before that) and I love it that my old code and archives of other peoples’ Common Lisp code usually runs with no problems.
Prince was, notoriously, very protective of his music. Much, perhaps most, of his output is locked away in a vault, perhaps never to be heard. And of the material that was released, he didn't allow covers except by artists he handpicked; he was also the only artist to consistently turn Weird Al down when approached for a parody of his music.
But Prince was a Da Vinci level genius. Every song he released was a treasure. So anyone who knows anything about music will admit that not only did Prince have the right to be so protective, but he has already gifted us with so much that to be angry at him for not giving us more is to be selfish.
Apple is like that. They kickstarted the personal computing revolution, and every single computing revolution to come after. GUIs in 1984, portable digital music players in 2000, smartphones in 2007, tablets in 2010. The Apple M1 Mac is the first personal computer to be developed, hardware and software, soup to nuts by a single company. It is the first machine to uncompromisingly represent a single vision for computing and how humans engage in it. It is not only the best computer on the market by a wide margin, it is the next revolution. The machines they just released are only the beginning: the future portends even higher performance desktops and laptops with lower power draw and heat/noise output than anyone else on the market. They absolutely deserve the very strict control they exercise over their platforms because that control has let them shape an impeccable vision of how computing should work. (Which becomes even more appealing when you consider the messes the Windows and Android ecosystems have become.) To demand that they turn loose of that control, for the sake of the few users still running legacy apps, is to compromise what makes Apple, Apple. Macs run macOS, and macOS runs on Macs. Demanding open source emulation of macOS compromises that. It's not going to happen.
Apple is going to ship at some point a 5k (or maybe a 6k, since they're already selling a 6k display that all of the M1 Macs can drive [1]) super thin, iMac Pro with the desktop version of the M series, with 6 or 8 FireStorm cores (instead of the 4 the M1 has) that supports 32 or 64 GB of RAM…
That will be a stunning computer.
[1]: https://www.apple.com/pro-display-xdr/
http://www.neilcic.com/Prince.mp3
Apple could have made "Rosetta 1" open source for enthusiast to maintain. They didn't. I doubt they'll do it now for Rosetta2.
Apple does this all the time, pushing aside the old to make way for newer stuff. (MacOS before X, 32/64 bit, a lot of my old iOS apps just stopped working with a note to contact the publisher). My my old snow leopard machine stopped working getting updates from macOS and became useless, but will run windows/linux. Software support requires endless maintenance esp on mac, and Apple limits support to the last 5 years (or so) of machines.
The "WinTel" (is that still a term window/ intel) machines seem to bend over backward for legacy applications to still run, which is part of their appeal (esp to business), but probably saddles them with technical debt. The "new" cost of lower performing machines and shorter battery life, is software lifespan.
https://www.linkedin.com/company/transitive/
because http://www.transitive.com goes to IBM now....
SheepShaver in particular already works on PowerPC and Intel so clearly they structured the code to support multiple platforms. Instead of trying to get Apple to open source Rosetta 2 maybe instead focus on adding ARM support.
There's no fundamental blocker to emulating x86 either - qemu does it, and will run up to Tiger. I'm almost positive the only reason we're not emulating amd64 is that the cost hasn't been worth it so far. And eventually, one day, we'll be emulating Apple Silicon on something too.
If there is anyone to lay a duty toward, I would argue it's the developers (Big developers, like Adobe) who could contribute directly in providing code/documentation for their legacy formats.
• Never should have removed Rosetta 1.
• Should not have dropped support for Carbon and 32bit apps.
• Should not remove Rosetta 2 in a few years, as many believe they will.
I acknowledge that it's easy for me to sit here in my chair and say that someone else should be doing extra work—but we're talking about one of the most profitable companies in the world! Apple could hire engineers to maintain this stuff, if they wanted to spend the money. It would not somehow make the rest of macOS worse—no one is required to use old APIs.
If you compared the amount of effort it would take Apple to maintain these systems, with the combined effort of every single developer migrating their software, I'm pretty confident the former route would be a lot less work. The alternative is that developers migrate to systems like Electron instead of trying to keep up with macOS's changing base, and that's not good for users.
It's not about not forcing developers to use old APIs; there are lots of developers who wouldn't upgrade their existing apps because they still ran.
It's just human nature to not want to update your apps if they're working fine under Rosetta or using Carbon and 32-bit APIs.
Among the many other issues this would cause, people would expect 32-bit Carbon apps to run on an M1 Mac; trying to do so would make Rosetta much more complicated.
The other thing is by pushing the leading edge, it gives upstarts a way to enter the market against incumbents. It's doubtful Affinity, which makes fabulous design apps [1] would been able to gain a foothold at all if old versions of Photoshop, Illustrator and PageMaker/InDesign just ran forever because Apple kept backwards compatibility with old APIs and frameworks.
And unlike Adobe, Affinity takes full advantage of Apple's latest APIs and frameworks in a way Adobe never has, to make them competitive.
It also discourages developers from using newer, better APIs to move things forward. Apple developed some amazing technologies in the 80's/90's they discontinued when MacOS X became a thing, like QuickDraw GX, HyperCard, OpenDoc, OpenTransport, etc.
I've experienced every Mac transition starting from the classic Mac days (16-bit 68000) to today, with 64-bit Intel and ARM processors. There's not anything off the top of my head I'd want to use today from back then.
I also started the first Newton users group in the world at least a year before the Newton MessagePad shipped in 1993. I know people who are still pissed that Steve Jobs canceled the Newton when he became iCEO in 1997.
There does come a time when you have to move on.
[1]: https://affinity.serif.com/en-us/
And for every developer who took the time to update their apps to modern libraries (and would not have done if not forced), how many just moved to a non-native framework like Electron instead? I don't think this work the way Apple thinks it does.
Like the poster you're replying to, I've been through all of Apple's transitions from the 68K days to now. And in this context? I can't honestly think of any apps like that. The Electron-based apps I know of started as Electron-based apps. Adobe and Microsoft have their own proprietary cross-platform toolkits, but they're still ultimately building actual Windows or macOS apps; the Affinity apps are likewise native to their operating systems; many of the productivity programs I'm often in (Ulysses, Acorn, Drafts, Scrivener, BBEdit, Nova, MindNode, Safari) are actual genuine Mac apps.
I think the things here are that (a) it may be easier to port an "old" native Mac app to "new" native Mac frameworks than to completely rewrite the app; (b) Electron is relatively new compared even to the "new" Mac frameworks (Cocoa is nearly two decades old, older if you count NextStep!); (c) while Electron might be high-performance enough now to write a full-blown desktop publishing program in like the one the article poster (who is my former college roommate, it turns out, hi Franklin), it definitely didn't start out that way; (d) a lot of folks are still not super thrilled with most Electron apps compared to native ones anyway. Yes, Visual Studio Code rocks, but it's kind of the exception to the rule.
Personally, I also think Apple being more ruthless than Microsoft in deprecating old APIs is probably a good thing for the Mac platform in the long run. one of the programs I used to use more often, Dramatica Story Expert, has been tenaciously clinging to the trailing edge of technology for years: like me, it started on the Mac in the 68K days, and it has stubbornly missed every single transition, its developers doing the absolute bare minimum after the fact to get it quasi-working. This is an app which, in 2020, is not only still 32-bit, but does not run at retina resolution because they have been hacking their old codebase rather than moving to "new" -- i.e., from this century -- APIs for shit as basic as text rendering. Its text boxes don't respond to OS X key shortcuts, it doesn't support services, its fuzzy UI is in Lucida Grande. I look at its sorry ass and shudder to think what the state of Mac software would be like if Apple had gone out of their way to make it easy for developers to behave that way.
I think it's a mistake to assert that a company should always indefinitely support their software. There's certainly an upside in maintaining backwards compatibility, but there's also certainly a distinct other upside in breaking it (e.g. authentication services dropping support for HTTP and requiring HTTPS).
To restate that in a more generic way: given multiple existing constraints and you want to add on even more constraints, there's no guarantee that you can always satisfy all constraints under all circumstances (e.g. if you have to support multiple API versions, you can't necessarily always support every single one since sometimes the changes are fundamentally backwards incompatible).
And it's not "just" the software or the architecture or the OS, sometimes things like fonts (and other minor things) get in the way. But it's amazing to unpack an old Windows binary from 1994 and having it _just work_:
https://taoofmac.com/space/blog/2020/10/24/2100
Technology can't simultaneously progress while still remaining backwards-compatible for years or decades. As another commenter here says: just use an old computer to run your old software. When your old computer breaks, buy another on ebay. Ebay won't run out anytime soon.
Yet I can run statically compiled Linux binaries from 20 years ago just fine, and play Windows games that were released over 20 years ago, too.
Apple works hard to break backwards compatibility every few years, while other operating systems will happily run software from decades ago as they care and invest in not breaking userspace.
[1] https://en.wikipedia.org/wiki/Binfmt_misc
My last experience trying to deal with ancient Linux binaries on an ARMv5 device running linux 2.4 was pretty abysmal. There were some breaking changes in the mid 2000s, I believe regarding threading? Old executables wanted LinuxThreads while modern linux uses NPTL. Not sure though. Might have just been a userland/libc problem.
Sometimes, even Linux breaks backwards compat to progress.
Tell that to people running DOS programs: https://blog.storagecraft.com/dos-quite-dead/
It's a choice that Apple gets to make. And that consumers, who buy or don't buy from Apple, get to make too.
- https://www.youtube.com/watch?v=mBiQgLlgcnA
- http://spritesmods.com/?art=minimacplus, http://spritesmods.com/minimacplus/mac_full2_tmb.jpg,
- https://news.ycombinator.com/item?id=15880450
This seems like the truly anti-technology opinion, to claim that technology lacks the ability to progress into the future without losing sight of the past.
Developing emulators is a much easier solution than preserving compatibility at the hardware or even the OS level. The fact that 20-year old windows games work fine is a product of Microsoft spending insane resources to maintain vendor lock-in.
Emulators themselves tend to be highly portable, for example I suspect that zsnes and dosbox will "just work" on arm64 macs or even RISC-V.
And x86/x86-64 supporting legacy instructions smh.
(At the end of the day you shouldn't be running ZSNES anyway. In terms of accuracy, compatibility, even security: way better SNES emulators out there.)
microsoft and x86 have entered the chat...
in all seriousness, there is a legitimate tradeoff to be made here. the accumulated legacy cruft can make it quite annoying to write code targeting windows. but once you get it done, you can be confident that it will work for a long time. on macOS, the APIs tend to be a lot cleaner, but you pay for that with features that are routinely deprecated, triggering major rewrites. as a developer, I do prefer microsoft's stance. I don't use macOS enough to have a real opinion as a user, but it is nice that I can run pretty much any windows software from the last twenty years without spinning up a VM or booting an older machine.
Sidenote - it's funny that Microsoft is so stable for their customer base while just constantly churning their frameworks and APIs. I worked in an MS shop, and boy, it seemed like they were introducing a new GUI or Web framework every six months, while of course slowing down or deprecating the older ones.
imagine a word processor that made breaking changes to its file format every year. there's no new feature that could be worth that amount of hassle in 2020. in markets that are still changing rapidly, it's okay to be more aggressive with phasing out support for older versions. from my perspective, the desktop OS is already mature. more than anything else, I just want it to not break things that already work.
Apple does not need to dominate the PC market to make money. What they deliver pushes other competitors to improve.
I, like the commenter I've replied to, can't believe that we're even able to frame a processor power shift like this in a bad light. It shows companies they can build something big without x86 - that's good for hardware in the long run, irrelevant of whether it's Apples variant or not.
It's our responsibility, as enthusiasts, to make sure legacy lives on. Plenty of people are building emulators, making home networks with old hardware.
It would be much easier if Copyright/Patents expired shorter after the big money has been made. Things should become open source to let everyone in after the inventor has reaped the benefits of their creation.
You say that as if it's about ARM. Plenty of ARM chips on mobile side - none of them come close to Apple mobile performance. Maybe I'm missing something but it looks like Apple has a good chip design department and I don't see how this translates to other ARM devices - Microsoft had their surface with Snapdragon and AFAIK the performance/usability was nowhere close.
That sucks for Intel but is fantastic for everyone else.
Other vendors using ARM chips means virtualization becomes easier between platforms. Linux servers are going to be running ARM soon with Amazon etc designing their own chips so web devs will want to be ARM native.
AMD can essentially take the high end x86 market and dominate gaming alongside Nvidia GPU's and others can experiment elsewhere!
I realize that just having a lot of RISC-V hardware options available isn't a guarantee that they're particularly good in terms of their price-power consumption-performance tradeoffs, especially in comparison to ARM (the "whole universe of high-quality hardware designs" that you mention). That may well have more of a delay.
Nothing good comes from one company owning the entire pie. You create conformance with apple's chips you're subjugating software to apples monopaly whims.
Except it’s really not though? OP loves technology, saying it revolutionized several industries and really appreciates the power and innovation desktop publishing specifically brought. All they’re asking for is a stronger ecosystem for porting older applications, not for Apple to go back to x86. OP is even way more open than most (surely than I would be) to all the steps it takes to convert between the various proprietary file formats over the years.
That got them started but Apple has written a ton of frameworks since 2000 when the first version of MacOS X shipped.
The point being made was that Apple didn't attempt to be backwards compatible with classic Mac OS.
The Mac didn't try to be backwards compatible with the Apple II that came before it.
The iPhone wasn't compatible with any of the phone platforms and standards in 2007.
There is a huge amount of problems to solve before a new architecture is usable. This may be not viable at all.
It didn't actually fail, at least not yet. But it's not clear it can succeed either.
… Yeah that's not really relevant anymore. Turns out a lot of people like their old cruft to keep working.
I agree to some extent, but at some point we (as in society) need to come up with some sort of standard for file formats and for user interfaces that will last for decades. Part of what makes technology useful is that when a tool is invented, it's function and our interface to it don't significantly change for sometimes thousands of years.
Take a hammer as an example. Even though there have been advancements in design and durability, any human who has ever used one can use another. That's why so much of the actually important stuff still runs inside the Windows ecosystem. Until the ribbon redesign, you could take anyone who knew excel, sit them in front of any newer or older version, and they could get to work.
What I don't understand is why the technology industry can't deliver one UI paradigm per decade, loosely couple the UI to the services that manipulate the state, and then allow the user to stick with one interface to get their work done for as long as their career. Then every 30 years you could break the oldest UI -- not sure why you would need to, but whatever -- and then the whole world could save trillions of hours of lost productivity instead of dragging themselves through redesigns that only exist because they give VPs a line in their resume.
(In this fever dream we all work four days a week. Programmers have time to produce immaculate, well documented, and bug free code. The hacker gods are now roboticists putting the finishing touches on fully automated luxury space communism.)
Really well put comment! People padding CVs / resumes are a huge problem in our area and everybody is suffering -- programmers, IT/sysadmins, and the users. I really can't understand why is this tolerated. I mean, I can... but it's a figure of speech.
I dream of the day when programming and UIs will be much more strictly regulated (yes, actually regulated) but I am 40 now and I am not sure I'll live to see the day.