Apple Silicon and losing our legacy | Hacker News Reader

Apple Silicon and losing our legacy

tacit.livejournal.com

138 pointslproven165 comments

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.

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.

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.

"Adapting old programs to fit new machines usually means adapting new machines to behave like old ones."

Epigram 120, Alan Perlis.

http://www.cs.yale.edu/homes/perlis-alan/quotes.html

> adapting new machines to behave like old ones

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!_

This is how IBM mainframes are still able to run COBOL binaries from many decades ago

> 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.

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

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...

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.

And when your Linux environment moves to ARM?

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. 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.

Binaries on Microsoft Windows are more resilient than some GNU/Linux source code.

Except it's really the OS doing cartwheels to keep them going.

At one point I stopped caring how they do it. I just want them to do it. We can't all be everywhere at the stack at the same time. We have work to do.

Or maybe it's the OS refraining from doing cartwheels that keeps them going.

You're right in that a stable ABI goes a long way to keep old binaries working!

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

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.

+1 right on.

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.

Right... Let me know how Python 2.7 code runs ina few years.

… 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)

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.

Id be very surprised, shocked if I cant run a vanilla stdlib only Python 2.7 script on all the major platforms in 10 years time, even 20 years time.

If the code isn't going to change, you could statically compile it and it will run just fine.

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?

It adds a layer of indirection (which has to be intercepted and emulated) for every single access to RAM.

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?

The one we wrote for the class :)

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.

*M64->MK68

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.

https://www.linkedin.com/company/transitive/

because http://www.transitive.com goes to IBM now....

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.

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!

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.

Maybe that will help RISC-V for the same reasons, too!

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.

The more the merrier!

> 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.

> 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.

> The fact that 20-year old windows games work fine is a product of Microsoft spending insane resources to maintain vendor lock-in.

And x86/x86-64 supporting legacy instructions smh.

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.

A better example would be the SNES emulators bsnes and higan, written in modern C++, which did just work when compiled on an ARM Mac the other day.

But can’t you simply run an emulator in an emulator (or a VM)?

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.)

> This is an anti-technology point of view.

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.

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.

You can replicate a Mac Plus at about 1:7 scale, just with an esp32, which is important if you need to see flying toasters: http://spritesmods.com/minimacplus/toaster-optimized.gif

- 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

> Technology can't simultaneously progress while still remaining backwards-compatible for years or decades.

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.

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.

That was my comment you're replying to, and yup: I have a full Amiga development environment on my Macbook. Good times!

> Technology can't simultaneously progress while still remaining backwards-compatible for years or decades.

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.

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.

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.

binfmt_misc[1] would like to have a word with you.

[1] https://en.wikipedia.org/wiki/Binfmt_misc

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

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.)

Please don't make me tear up. :(

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.

Easy problem to solve. Apple needs to allow macos to run virtualized, on non Mac hardware. Get over the hill already Apple, your wasting our time.

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.

Didn't Intel try to do that with Itanium?

… Yeah that's not really relevant anymore. Turns out a lot of people like their old cruft to keep working.

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.

Like the Mill?

There is a huge amount of problems to solve before a new architecture is usable. This may be not viable at all.

What's a Mill? A supposedly modernized CPU architecture that failed?

> https://en.wikipedia.org/wiki/Mill_architecture

It didn't actually fail, at least not yet. But it's not clear it can succeed either.

Isn't that pretty much what Apple did?

Apple was not starting from scratch, they used NeXT for software and ARM for hardware. Those are both from the 1980s.

Apple was not starting from scratch, they used NeXT for software and ARM for hardware.

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.

I am furious that my Sinclair Spectrum games don't run anymore! What the hell was wrong with the Z80?

> 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.

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 a strange complaint because PageMaker etc are document editors which produce paper documents - or PDFs in the worst case.

There's no benefit to archiving the source files and demanding they be opened on new hardware because the historical interest is in the content. And the content hasn't been edited for decades and won't need to be edited in the future.

If you really need the content you can pull it out of a PDF or scan it from paper. And if you really need to preserve it you can scan or screen shot the source files - which takes work, but so does setting up old software on new machines. (Probably at least as much considering how hard it is to emulate an identical operating environment with all fonts, deprecated image formats, and so on.)

So this makes as much sense as complaining that MacOS or Windows don't support the ancient professional magazine typesetting systems that used to run on minicomputers.

The files for those are doubtless backed up somewhere - probably on mag tape, possibly in landfill - but they're culturally irrelevant because the output has either been scanned and put on the web or simply forgotten because it's of no cultural value.

The bigger question is why there's a cultural fixation with preserving every last element of the past. It makes sense for content of record such as newspapers and certain magazines, but it's hard to understand why a crossword puzzle magazine for seniors from 1982 or a zine that only ever had twenty five readers needs to be preserved.

And what's going to happen 25 years from now? Are we going to have the entire archives of YouTube, Spotify, Facebook, IG, and Twitter to sift through?

Would we want to, even if we could?

I think the main value of preserving such material is sociological -- a lot of interesting conclusions could be drawn by having such a historical record. It gives future generations insights of what did the current society do wrong and what did it do well.

I don't mean the entirety of all social networks, of course... they follow roughly the same pattern so no use keeping 50 zettabytes of that; like 10-20 terabytes would be quite enough.

But the general point stands. If we want to evolve as a civilization, we should try and extract lessons from our past.

I'm all for archival, but "help us access these files in the future even though people aren't bothering with accessing them now" is an odd request.

The time to access those files and migrate them into more durable and supported formats is right now. Or 5-10 years ago for that matter.

> In a perfect world, someone would write a Mac emulator that lets you emulate a High Sierra Mac on Apple Silicon hardware, just like SheepShaver lets you emulate a PowerPC Mac on Intel hardware.

OR... or... there are computers other than Apple's. Computers which could be used to emulate an x86-64 Mac without having to deal with ARM translation because they're x86-64 based themselves.

The author's viewpoint is so Apple-centric that the idea of this digital archaeology happening on something besides Apple hardware didn't even enter the picture.

>> The author's viewpoint is so Apple-centric that the idea of this digital archaeology happening on something besides Apple hardware didn't even enter the picture.

That was my first thought as well. Also if he wanted to preserve old DTP documents, the way to do that is obviously exporting them as .pdf before moving to other software.

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.

The article does not say it's Apple's fault.

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.

I think that Apple:

• 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.

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.

There does come a time when you have to move on.

[1]: https://affinity.serif.com/en-us/

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.

> 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.

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_:

https://taoofmac.com/space/blog/2020/10/24/2100

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.

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.

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.

Again, the article is not aiming at Apple, they are talking about a new development from Apple that illustrates a predicament.

They have to get out of these file formats. PDF (or epub?) seems reasonable.

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.

File formats are the real lock in, not operating systems.

Keeping people on Windows was never Microsoft's goal - the real lock in is the .doc/.xls/.ppt (and newer "Open" XML versions that aren't really that open), and keeping them buying Office or SaaS offering year in and out so they can open older files.

GSuite and Libreoffice are more of a threat to Microsoft than Linux ever was...

OpenOffice/LibreOffice has been around for more than 2 decades and I've only seen it in use by a minority of users at small, cheapskate companies.

Microsoft could probably sleep well if OO/LO were the best competitors out there :-)

> Keeping people on Windows was never Microsoft's goal

That is an overbroad statement.

I'm not so concerned about the Intel versions of macOS in the near future, because there are a lot of x86 processors out in the world, and most of them can be hacked to run macOS.

macOS is a little strict about processor generations—in order to run Mavericks (10.9, circa 2013), I had to build my Hackintosh around Haswell—but I think a kernel developer could get around this by lightly modifying macOS's open-source XNU kernel. There are custom Mavericks kernels that work on modern Ryzen processors, for instance[1].

The graphics side of things is admittedly a bit more worrisome—macOS doesn't work with all that many GPUs, and none of the driver code is open source. Graphics acceleration isn't strictly necessary, but you will have a gimped experience without it.

1: https://macintoshgarden.org/apps/custom-kernels-ryzen-proces...

I have no background on PageMaker etc. but this is a perfect example for why fully open, well-documented file formats are an absolute requirement in computing today.

If you have a .xyz file but not the ability to write software from scratch to read/write/manipulate this file as needed, you cannot consider access to that file to be permanent.

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.

I think this is not so much a gripe about Apple's new chip, as it is the painfully fragile nature of maintaining access to anything digital made in closed formats.

We are, for good or ill, the first generations for whom more of our 'legacy' is digital, and as much as there's the idea that anything on the net is forever, the reality is that more is lost, perhaps forever, than is magically, infinitely available.

Future humans (and AIs) will reverse engineer old file formats for fun. As long as the data is there, it will be readable.

Bingo. I've been experimenting with an old TRS-80 CoCo I have. I've got the original system, built in 1982, and it still works. But, emulators of the machine are actually easier to use. So, I'm developing software for the machine there and I'll transfer it over.

As long as we save these old files, they'll be accessible in the future.

But, probably not everything will survive, only the most important things. I think I'm okay with that.

Then again, maybe by 2120 there will not be enough interest in a machine from 1982 to continue to build an emulator. But, maybe they will emulate the MacBook M1 and from there my great grandkids can load an even older emulator to try the TRS-80 that they read about in my programming ebook from 2019. If HTML, Kindle or PDF still exist anyway.

Just out of curiosity, has anyone ever reverse-engineered the PageMaker file formats?

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:

https://taoofmac.com/space/blog/2020/10/24/2100

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.

The most surprising part is that LiveJournal is still around.

Someone using livejournal in 2020 is complaining that Apple’s new M1, won’t open their quark publishing app from 1998.

this is front page on HN?

As of time of writing, it is indeed front page on HN. Your comment's other claims also appear to be true. Since we agree on the facts so far, let's discuss the article.

"writing an emulator for x86–64 on ARM is a huge undertaking, something beyond what an open source project is likely to do" - There are already open source projects that have tackled complex emulations so I feel like this isn't unlikely in the long term but maybe true in the short term.

I understand the author's fears, but the things he is afraid of have absolutely nothing to do with Apple Silicon.

They do, quote:

"SheepShaver and InDesign CS6 both won’t run on Apple Silicon."

That's the issue. But, how does he know that? They don't run now, maybe they will later.

Use the old silicon until then.

The striking thing to me was how much easier these conversion tasks would be, if the author truly insists on using new hardware, with a new x86-based PC. All the software the author is worried about existed on Windows, and those old Windows versions are easy to run in Virtualbox.

Apart from the fact that this is a somewhat niche complaint (and that has been covered by many other comments), I in general am still flabbergasted to this day that the basic promise of source code -- compile it under a different machine and platform and it should work -- somehow doesn't hold.

But I know that's not the fault of the tooling. Sometimes it's the fault of the OS / framework vendor for aggressively deprecating stuff (like Apple does). But most of the time my observation has been that a lot of companies simply won't budge and won't even hire an intern to try and recompile their app for the new platform. Sad.

My old man is going through a similar thought exercise right now. He is a retired hardware engineer/software entrepreneur who built a few businesses on top of SCO's Unix back in the day. All the licensing (and floppys) are long gone but there exists a few towers that still boot. In the spirit of archiving all his work, he is now systematically DD'ing the SCSI drives onto external usb harddrives, moving them onto modern hardware and creating bootable VMware images. I am sure that once VMware and etc catch up with the new Apple Silicon/ARM instruction, we won't be hearing much from people like the author who fear architecture and technology changes.

Maybe qcow2/KVM would be better for this than VMware, as that's an open & widely available technology?

Otherwise the cycle might repeat yet again once VMware goes under.

Great point! Fact is the tooling is great in VMware and it's hard to get an old dog to learn new tricks. Getting the image to boot properly will be a win. We will see about moving it to open source afterwards..

Hmm, LibreOffice (via libpagemaker) can read PageMaker and it is open source and runs on ARM so it should work on Apple Silicon at some point. Also pmd2odg (from writerperfect) can use libpagemaker to convert PageMaker files to OpenDocument

I don't understand this attitude at all. The existence of new platforms does nothing to affect legacy software or hardware. And when these things eventually break, that's OK. Not everything needs to be forever.

I'm more worried about software that relies on temporal things - like internet services being accessible and running still, for example. Such external dependencies are a worry for retaining old software.

Perhaps archiving to PDF is the right solution to this specific dilemma?

Acrobat can do exactly that.

> But for various arcane technical reasons, writing an emulator for x86–64 on ARM is a huge undertaking, something beyond what an open source project is likely to do. I honestly don’t see the open source community writing a Mac emulator that will run High Sierra on Apple Silicon. Emulating x86 on ARM is an enormous project, one that requires a well-resources company to do.

A company like Oracle or VMware? Lots of developers are going to not just want, but need Docker to run properly. Just be patient and pipe down.

And don't forget all the email history trapped in .pst files

Imagine how much more we could know about the motivations of Galileo's inquisitors if we could read their archived email.

You can run macOS in a QEMU VM.

It seems that proprietary software and mindless dependence on it has been killed the legacy; not the change or evolution of hardware platform.

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.

Game console emulators simulate entire chipsets in memory that have nothing in common with the underlying hardware. This approach doesn't perform nearly as well as virtualization, of course, but it would be enough for preservation purposes. What's stopping people from doing that with legacy Apple architectures? Is x86 just too complicated?

Just use an old computer

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!

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.

This article applies to every architecture and os transition that isn’t backwards compatible.

PDP->intel meant we can’t run pdp code (oh wait many banks now just emulate PDPs running cobol)

macOS: 68k->ppc, ppc->intel, and now intel->arm. macOS <= 9 to X

Etc

> InDesign CS6, the last modern app that can read a PageMaker file, won’t run on new versions of macOS because it’s 32-bit only.

Does the author not realize that emulators exist?

I once heard someone joking (?), that Qemu was written to run Macromedia Flash on PowerPC Linux. So, maybe it takes ten years, but why not emulate M1?

Who said that Sheepshaver won't run on Apple ARM? That's silly to even suggest. We already have qemu. A little research goes a long way.

I will gladly vote for burning down and having to rewrite legacy stuff if it gets me a quiet, cool laptop with a 20 hour battery life.

Why is the concern focused on new silicon? Doesn't this problem occur (more often?) as a side effect of software being updated?

This wouldn’t be a problem if Adobe (and others) would release the specifications for their now dead formats.

in a few years, all these apps will run in an in-browser x86 emulator hosted by a site like archive.org

If he see what happened with Commodore 64 apps, he shouldn’t have to worry.

we should celebrate it - it gets us a bit back into the situation of fast hardware progress due to competition like it was back in 80-90ties. The x86/64 has been great (in no small part because it was the "natural selection" winner of that tough competition with RISCs/etc.), yet the last decade of lackluster progress is the direct result of its own unchallenged dominance and the resulting failure to adapt.

>losing our legacy

"legacy" is mostly a bad word in the tech, so shouldn't we celebrate losing it too ? :)

I dislike their conclusion of "I really do feel we as a society are, in the relentless march of late-stage capitalism, destroying part of our own history simply because there’s no profit in keeping it."

It's a very cynical take on the fact that as a society we aim to design and build better products and therefore use those products over old. Particularly because the author was concerned purely because they are an archivist and historian. With seeming no productive use of the older technology aside of historical value.

Does that mean that the new PS5 should have a VHS drive to accommodate historians? No, you can still buy and own a second hand VHS drive.

I don't see why it is viable for companies to spend their time innovating and designing new products only to have to think about keeping historic software designs alive. I understand there is of course a balance between compatibility with older software and the new. But you pick and choose your battles.

it's called progress

Why would anyone at hackernews chat about this and not Big Sur?

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.

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.

> first 80s and 90s Sun and SGI would like to have a word with you. The M1 Mac mini is the closest thing to a new SGI O2 that we've had in 20 years.

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…

That will be a stunning computer.

[1]: https://www.apple.com/pro-display-xdr/

well, I agree with the initial claim...

http://www.neilcic.com/Prince.mp3

Reply on news.ycombinator.com