I understand the arguments for unified RAM on a SoC, but it’s still a shame; even the new Mac Pro doesn’t have RAM slots.

The soldered-in SSD is worse, though. The SSD WILL wear out, so then you get to throw away your Mac?

Just like AirPods and AirPods Pro when their 7 cents worth of batteries die! A perfect system.

That will have to change in 2027 with he new EU battery regulation.

Do they? I thought it was only iPhones. Either way, Apple will find a way out...

No, it’s basically all portable consumer devices with batteries.

But how quickly though? Do we know the write endurance of the Mac SSDs?

I'm not a Mac fanboy by any means. But SSD write endurance has become ridiculous. Even on a cheap-ish read-intensive server-class 1 TB NVMe SSD (~$300) you get around 1 petabyte total write endurance, meaning you can write essentially the entire contents of the disk every day for 5 years and still be within the warranty. That is orders of magnitude beyond what any consumer is going to subject their disk to.

There is always a possibility that a part of the computer will fail. But if the SSD is less likely to fail than any other random IC on the motherboard, having it soldered on doesn't factor significantly into the failure statistics.

Of course it's super annoying that you can't upgrade the disk size, but that's another point.

I've got two Macbook Pros - a 2014 15" (500 GB SSD) and a 2015 13" (1 TB SSD). Both are still going. I can't imagine newer Macs are worse. I'd be more concerned about replacing the battery!

My MacBook Pro (2015, 15 inch) started having some SSD issues earlier this year after a bit more than seven years of heavy use, but it does seem to be partially mechanical because it would mostly happen after it had been in my bag.

Since I bought an M2 Pro to replace it, it hasn’t had the issue I think because I’m just leaving it at home and not flexing or squeezing it much. Perhaps the issue could be fixed permanently and properly with a bit of hot air to re-flow the solder balls.

The newer ones could be worse as they move to smaller process nodes and storing more bits per cell. That said, the controller logic is improving, and larger capacities mean more room for wear leveling, so it shouldn't be too bad.

That's not even that bad if you have a hot air gun and a reball kit. What's worse is the flash chips having some kind of cryptographic identifier that locks them to the machine, so you couldn't replace the flash if you wanted to.

> The SSD WILL wear out

This is by no means certain, certainly not enough to SHOUT about.

Modern SSDs have lifetimes that make them impractical to literally wear out, short of some kind of fault.

OK BUDDY YOUR WELL-CITED CLAIMS ARE NOTED.

Is it accessible enough it can be soldered-out, or is this one of those effectively-permanent things?

The Mac Pro missing RAM slots was disappointing to me. Performance uber alles and all that, but upgradability has benefits as well. Until Apple started soldering RAM, I always did aftermarket RAM upgrades, and even recently doubled the RAM on a 12 year-old file server.

They could still allow adding more RAM that would just be slightly slower.

They would need to extend the slots from the existing ram, which would slow it down even when empty, or they would need to use up a lot of silicon adding more memory channels. It really does make sense to solder on RAM for best performance. Though alternative sockets like CAMM might help in the future.

But you can't do a trade-in, the RAM they sell is extremely overpriced, and as mentioned elsewhere there's no excuse for the SSD.

This is even more true today, because Apple Silicon Macs are able to store twice the amount of information in the same amount of memory, meaning that a paltry 8GB configuration can store 16GB of FizzBuzz boilerplate, 4 Google Chrome tabs, or 20% of the average node_modules.

I don't think that feature is exclusive to Apple Silicon, or Macs.

It's a joke (clearly not a very good one) based on my experience that when Apple first offered only 8GB of RAM on the first ASi Macs, everyone's response was that Apple Silicon can simply store more data in the same amount of memory or something. Back when I used macOS on Intel, 16GB was relatively comfortable, but I can't imagine that switching to ARM would magically halve memory requirements.

(Yes, the Intel Mac had memory compression as well. And my Windows 11 PC also has memory compression, but only if you also enable swap because Microsoft says "fuck you".)

The AS memory compression is better as it's hardware accelerated.

IIRC Windows doesn't like to overcommit memory and its allocation calls will actually fail instead, but I don't remember the details.

I think ASi Macs also use swap by default now, because the SSDs are so fast that it's actually a tenable solution to memory pressure. My Intel Mac never had any swap.

> IIRC Windows doesn't like to overcommit memory and its allocation calls will actually fail instead

Yeah... one of the reasons why I dislike it.

Intel Macs have swap too. You can check it in Activity Monitor: https://support.apple.com/en-gb/guide/activity-monitor/actmn...

zswap supports pretty much any cryptographic accelerator. Accelerating memory compression isn't really a new or particularly "better" innovation.

Not cryptographic acceleration, compression acceleration. Anyway, they ain't got one, so it doesn't matter if it's supported.

You can always use a PC if you want upgradeable RAM.

Not really. Classic Mac OS didn't support virtual memory so everything had to fit in RAM unless a program itself offloaded data it's not currently using to the disk. Modern OSes, however, all support swapping. Your compilation would continue, just much slower. To truly "run out of memory" on a modern computer, you have to fill up both the RAM and the disk.

Which version?

Regarding "everything had to fit in RAM": prior to real virtual memory, the Macintosh Resource Manager was capable of loading and unloading resources on the fly. Resources marked purgeable could be discarded when memory was needed. Code segments (another type of resource) could be loaded by automatically by the Segment Manager, but as you said would not unload until the application requested it or exited. INITs (system extensions) unloaded all code after initialisation by default (requiring extra steps to keep anything in RAM).

Virtual memory was built-in by System 7 (and I think available on supported hardware via 3rd party utilities earlier?).

Unloading code and resources is easy — you already have them on the disk. Unloading runtime state though, that's the hard part. I've never used classic Mac OS when it was current, much less haven't developed for it, so no idea how often, if at all, apps used temporary files to work on more data than can fit in memory.

Ok, fair. Mac resources, including CODE resources, could be modified by the running program and unless marked as read-only were saved to disk by the relevant Manager before unloading. Photoshop was noted for its unusual use of disk, which was said to work like a virtual memory system.

Due to lack of protected memory, a few programs, especially on the earliest machines, with the least memory, 'abused' the display buffer by using it as RAM. Of course, this corrupted the screen, but it would all just be drawn again as soon as the program yielded time to the OS. Back then, only one user program could be running at a time, and it mostly had the screen to itself, so why not use it to copy floppies with less disc swapping?