Although TimeCapsule is more than decade old, it serves nicely with TimeMachine (automatic backups). Sad to see that going away permanently for Apple Silicon.
It may not be the easiest surgery in the world, but you can replace the hard drive in a Time Capsule. You'll probably want to replace the power supply too after this much time
wasn't it capped at 3tb? is the drive swappable to something bigger? They discontinues them in 2018, the wifi in them is old, single disk (no raid).. better to just pick up a multidrive nas or use cloud backups. What we should be asking for is timemachine backends for cloud providers.
It's not "officially" supported, but iFixit has a guide for swapping the drive on a time capsule. I used mine with a 4TB drive for years with no trouble.
My old trusty readynas should still work i think.. probalby. Supports smd for time machine and smb3 generally. If it doesn't I might finally be pushed onto a nas that isn't discontinued.
the one i have is my second readynas.. its a later one and is x86 but it's still kickin'. The first failed suddenly so i bought the second hoping to migrate the disks, but they changed the architecture so that wouldn't work. I determined that all that happened to the first was that the power supply gave up. Sourced one from ebay and it was back to working but i went ahead and did a migration then gave the old one to a friend. It's apparently also still doing just fine.
From a risk assessment standpoint, I’ve seen my Time Machine backups corrupted much more frequently than I’ve experienced drive failure. Happened with both my Time Capsule and then my Synology RAID.
It’s a “nice to have” automatic backup, but not a primary backup destination for me.
"Dropping support for things just because they are old" is typical commercial software behavior. I can run the latest Linux kernel and still have access to an internal floppy disk drive if I wanted to, yet billion dollar companies can't seem to manage to support 10 year old stuff.
I still am sore from when I "upgraded" macOS and suddenly support for my 1080i TV was gone. Yesterday it worked fine, today it's gone. All because they can't be bothered to maintain a code path.
With closed source IP, every bit of support, from bug fixes, to feature requests, to compatibility fixes to integrate with newer mainline/foundational tooling, costs money.
With open source projects (and in particular ones like Linux where there's a huge number of contributors and interested parties), support for would-be niche facilities can keep going as long as there's someone with the knowledge and spare time to do it.
There's somewhere in the ballpark of 166,000 employees at Apple, just unfathomable scale [1]. It is not unreasonable to ask that someone specific is responsible for each particular small feature and ensuring it keeps working. Trying to apply an economic analysis to such a "free as in beer" operating system does not seem to work well. Consider the question of "how many small holes can you have in your wooden sailing ship"?
Ideally, at a certain point, you'd have some sort of upstream FLOSS project where you could let John Q. Public do that sort of low-level, maintenance-only stuff, while the proprietary "value adds" are closed source, until it becomes financially attractive to FLOSS them.
IIRC, that could exist for MacOS in the form of Darwin.
AFAIK, Linux has a policy that any change you make must not break existing kernel features, and if it does, you have to fix them yourself.
With that said, kernel maintainers have recently indicated that some unused subsystems are likely to be removed soon, as AI is now finding (real) security vulnerabilities in them that nobody is willing to fix.
> The economics make the reasoning obvious, though.
Looking through Apple’s financial statements, they theoretically could support these old systems. I’m not saying a cut doesn’t make sense, but just that economics-wise they could keep one guy for it
> With open source projects (and in particular ones like Linux where there's a huge number of contributors and interested parties), support for would-be niche facilities can keep going as long as there's someone with the knowledge and spare time to do it.
And that increasingly gets difficult to do. i386 support went down the drain in the kernel in 2012, i486 is probably going down the drain as well this year [1] and soon-ish another bunch of really really old stuff will go as well because it isn't maintained [2] - good luck finding someone still running IPX networks or ISDN hardware.
Just this week we've seen Linux talking about dropping support for some older hardware precisely because attacks against it were becoming easier with LLMs.
Do you have a detailed source for this? I want to read more about it.
Because I noticed my old Core 2 Quad PC with Nvidia 8600GT that my parents use as their email and Facebook machine, doesn't boot with any linux newer than Kernel 6.1 even though I can get Windows 11 to boot on it.
So the myth around "Linux is great for old PCs", highly depends on what HW you have.
Sounds like an Nvidia driver module issue more than anything else. If I had to guess, simply removing the Nvidia module should fix that and still get you video through one of the various backup paths (opennuveau etc)
You can run no-mode-set to get video output at boot/installation phase but then you're stuck with 800x600. That's with the FOSS nouveau driver in the kernel.
There's no fixes that I could find. My LLM research says nouveau dropped support for that Nvidia architecture on newer kernels. Bummer.
> "Dropping support for things just because they are old" is typical commercial software behavior.
You are deluding yourself if you think open source folks are better. You can't compile and run a modern version of GCC on Solaris 10 on SPARC, for example. And we just had a story here last week about removal of bus mouse support. It's only a mild exaggeration to say that lots of folks will check the commit activity on github and of a project doesn't have commits this week it should be banned from the internet and the universe.
Then you have the problem that many dev tools are not forward compatible. CMake is a huge issue. An ubuntu system from 2020 has CMake on it, but it won't compile anything that uses CMake that was released in recent years because the cmakefiles are incompatible.
Open source is better because if you need the device driver then you can step up to maintain it yourself. It doesn't mean someone else will magically do it for you. I've used devices with very obscure incantations to get some random person's hack to run on Linux that worked natively on Windows.
CMake is a bad example, you can build latest CMake and run it on Debian Jessie. It will work perfectly. CMake is the thing you can build on really old compilers.
Really? Like actual internal floppy drives, and not just USB floppy drives (which even Windows still supports)?
I actually wouldn't expect macOS to support actual floppy drives since the OS's list of supported devices doesn't include any that shipped with floppy drives. The fact that I cannot install the latest macOS on any devices older than 2019 is a related, but separate problem.
In this case, what would internal floppy drive mean? The last Macs with floppy drives (I think Old World G3s?) used a custom Apple controller, integrated into the chipset, with a bespoke 20-pin cable.
A USB floppy drive behaves almost identically to a USB hard drive-yet another SCSI block device. The cost of keeping support for them is minimal
This is very different from legacy PC floppy drive controllers which spoke a completely different protocol, which was very complex and full of footguns
Legacy floppy controllers also had various legacy features almost nobody used, like soft deletion of sectors (IBM added this in the 70s for use with primitive database systems), or attaching tape drives using the floppy interface (nowadays if you buy a brand new tape drive, the interface options are SAS or Fibre Channel)
It's my understanding that those are (mostly?) devices where they legitimately have reason to believe there are zero users. In particular, there's a pattern where someone will discover that Linux has a driver that hasn't actually worked for a long time, and nobody's complained, so then they remove it.
I'm not suggesting they keep it all... just ironic as a statement considering Linux is literally removing a bit lately... <= 486, the bus drivers for mice, etc.
I'm mostly okay cleaning out a lot of legacy and unsupported devices. In some ways, and for people who want to support really old hardware it may not be great, but they're most likely stuck on older versions for other reasons.
I don't think it is ironic, though; Linux isn't "Dropping support for things just because they are old", it's dropping unused things when they cause code quality problems. That's rather different than features being dropped because the vendor doesn't want to bother supporting them even though they still worked and have active users.
Feetures being dropped because nobody wants to support them is a prominent feature of free software. That's part of "no warranty". If it does bother you, you're supposed to step up to support it yourself, or pay someone to.
Okay, but that's the exact opposite of what we're discussing here? Linux, which is free software, isn't dropping features because nobody wants to support them, but because nobody's using them. Meanwhile, macOS, developed as a commercial product and with a much weaker showing of open source or even source availability, is dropping features because Apple doesn't want to support them.
> Linux, which is free software, isn't dropping features because nobody wants to support them, but because nobody's using them.
I disagree. They are dropping support because nobody is maintaining them. There may very well be people still using these features, but they haven't been motivated or aren't properly skilled to offer to maintain them going forward, and haven't motivated some other skilled person via payments.
Rather, the core difference is that Apple does not offer a way to have external people take over providing support.
If anybody would care to keep these drivers up, it would be easy to revive them as kernel modules. It's not that Linux is going to lose an upstream interface to publish events from a bus mouse.
Support for 486 is another thing, but, frankly speaking, running a modern Linux kernel on a 486 makes no sense, either form a practical or preservationist / museum perspective.
> There are still some people who need to run 32-bit applications that cannot be updated; the solution he has been pushing people toward is to run a 32-bit user space on a 64-bit kernel. This is a good solution for memory-constrained systems; switching to 32-bit halves the memory usage of the system. Since, on most systems, almost all memory is used by user space, running a 64-bit kernel has a relatively small cost. Please, he asked, do not run 32-bit kernels on 64-bit processors.
Ok what do you suggest? Every feature ever written should be supported in perpetuity even if 3 people are using it? Clearly you didn't think this through. Should 2026 computers have a ISA interface as well?
Supporting old hardware and software has a substantial cost that only grows exponentially. Companies exist to print money, not to cater to the smallest niches.
It would be great if they could support things, but I most definitely understand why they don't.
The story of TimeMachine is a tragedy: a revolutionary feature that made backups accessible for normal people allowed to lie fallow for a decade or more until it's as annoying and unreliable as anything else. I now use Carbon Copy Cloner to avoid the TM headaches.
I never found it to be overly reliable. It was reliable... for a while. Then would silently fail/stop working, or just tell you that it had stopped working and that whatever you had in it was no longer accessible.
And then I went to Acronis True Image backing up to my Synology NAS, but that became unreliable too - oftentimes when I'd go to do a restore, the client would crash trying to read the catalog.
So, like you... CCC nightly to my Synology, with a Snapshot rotation on it - snapshot the previous night's backup at 8pm, and then kick off that night's backup at 11pm.
Yeah, you may be right. I have fond memories of it from around 2008, but those might be from the initial experience and not all the "you need to recreate your back from scratch" errors that would crop up after a while.
It was unreliable over SMB. Not surprising when you look at what it was doing. It would create a virtual drive on the share, map that and backup to it. There was too much going on for that to be reliable.
I've loopback mounted disk images over network filesystems for many years without any recurring issues outside of macOS. It's not rocket science, particularly if you have a reliable network connection.
I'm aware there's a long tail of possible issues that can come up, but most of the complaints I've seen amount to "I have a reliable connection and Time Machine is still a tire fire", which suggests that the problem exists outside of that particular set of edge cases.
(It seems to genuinely be that nobody at Apple really cares about network filesystems at this point - people in this thread talking up AFP makes me want to look at migrating _to_ using it for my mac's backups, because SMB on macOS randomly drops or hangs for no reason and Time Machine at least twice has just started stating the backup was completely unreadable, leading to me having to restore the backup filesystem from backups.
And attempting to use NFS on macOS somehow makes everything three times as buggy, like they special cased SMB shares to not be touched in some random "touch everything synchronously" calls throughout the OS but didn't do it with NFS shares, so Finder will now take seconds or minutes to do things that shouldn't involve that share, but as soon as you remove it, it stops doing so.)
Changing out the network protocol used for local network backups isn't the same thing as getting rid of local network backups.
TFA:
> Apple made SMB its primary file-sharing protocol in OS X 10.9 Mavericks, over 12 years ago, and has repeatedly told us that support for its predecessor AFP will be removed in the future.
> Next: macOS iCloud backups and the eventual deprecation of local Time Machine backups altogether. More services revenue!
The "new computer" out of box account creation and first sign in experience on both Windows 11 and MacOS are clearly designed to drive end users towards perpetual for life monthly recurring subscriptions for (Microsoft 365 Personal, OneDrive, iCloud storage, etc).
Imagine the difficulty for the ordinary non technical person (absolutely not a stereotypical HN reader) ever being able to stop paying for iCloud when they have 600GB+ of their family photos and videos and stuff backed up to it.
> Imagine the difficulty for the ordinary non technical person (absolutely not a stereotypical HN reader) ever being able to stop paying for iCloud when they have 600GB+ of their family photos and videos and stuff backed up to it.
To be fair, non technical folks get a lot of value from this scheme too. I can't imagine many of my relatives successfully juggling backups and external media in a way that would actually keep their content safe in case their phone is lost/stolen/destroyed.
Right now the monthly fees for this stuff are rather modest, but I could see a future where the dominant players lock out competitors and use their market position to raise prices significantly.
I don’t think they’re going to drop support for local backups any time soon. There are lots of enterprise customers relying on Time Machine who will never switch to iCloud. TM can also be configured via MDM settings and is a really common solution for Mac IT administrators, so it would take ages to deprecate it.
"There are a lot of enterprise customers using Xcode server". And poof, it's gone and there's now only the Xcode cloud service. It would not take ages. It would take a single release which no longer supports it. Complaints? Keep using the old one or subscribe.
I am fairly confident in saying that approximately zero enterprise customers used Xcode server. It was extremely limited and targeted at small shops which didn't see the need for a proper CI setup but had an extra machine sitting around to run builds on.
- BigCo already is a zero-sum deal, they use Xcode-cloud as a service, which runs back on their servers anyway... (Google, Amazon, Azure, etc)
- It was not a long-standing product. Introduced somewhere around 2016~ish if I remember correctly. Only lasted a few major releases. Easier to kill than an established one (ie. TimeMachine)
People have been asking for iCloud macOS backups since iCloud was introduced. It would be very popular. I'm not sure why Apple doesn't offer this, because it's easy revenue.
Because people will fill their iClouds. An important value proposition of iCloud is that customers pay for more space than they need. Time Machine grows to fill all available space.
They could sell a separate service for Time Machine backups. I'm not an Apple customers so I don't know if it makes sense, but they could make customers pay X times the last N days in the backup plus Y times a number M of snapshots in the past.
I've been working on improving an open source menubar that wraps restic. Right now it is a bit rough around the edges, but my plan is to have a simple onboarding experience for various backend services like B2.
Over the weekend, I added a "Smart backups" feature that uses all the same directories that the backblaze menubar app and timemachine excludes. This was the primary missing feature for me. It even generates and backups your Brewfile...
I would have agreed if they hadn't put in the engineering effort to upgrade the backup disk image to APFS instead of HFS+. They wouldn't have done that if the plan was to deprecate it soon. (IIRC the next version of macOS is also dropping HFS+ support)
Also it's honestly really weird that they don't have iCloud backups for Macs yet. It seems like a no-brainer feature. I know I would easily switch to Apple over Backblaze as Backblaze's client is just terrible.
"...if you have an Apple silicon Mac and AFP support is dropped from macOS 27, that would leave you unable to upgrade without replacing your network storage."
How big is this market? I'm not saying vibe code a product, but...
That "replacement" is not always full-on hardware.
I have colleagues who are running AFP on BSD for continuous backups on their systems, and they have to reconfigure something new to be able to continue backing up their systems.
They are compatible with netatalk though. The project split between version 2 and 3, but in recent releases they folded them back into a single thing. Current netatalk releases support all versions of AFP.
One of my COVID projects was to set up a networked Time Machine backup on Raspberry Pi.
Every single one of the blogspam sites (lifehacker, howtogeek, etc.) told you to use AFP/HFS+/Netatalk. I had so many problems with this. Time Machine would work well the first few times and then slow to a crawl. If there was a power outage, look out. The whole thing would be corrupted. It wasn't the network. FTP and scp worked just fine.
Eventually I found one blog that told you how to do it with SMB and ext4. It was that site that I learned about the much malignment of AFP and HFS+. SMB/ext4 worked like a charm. Six years later and not a single hiccup.
Relevant to the discussion is that the project comes with an AFP client as well. I have no experience with the client but I've used the Netatalk server for more than 15 years.
It's been more than a decade since they replaced AFP with SMB as the default protocol for file sharing, and they've been warning that AFP would be going away for years.
Yeah but AFP is still performing way better than SMB on Mac for any fast networking. Like 10GigE and faster. Apple SMB stack is a disaster, and thoroughly unprofessional. NFS is faster, too, but unfortunately the Finder, being the rat nest of bugs it is, has often trouble with NFS shares.
macOS 26 still has a hard kernel panic if you try to mount an NFS share with krb5 auth but don’t have a valid Kerberos ticket. 100% reproducible.
Every OS update I try mounting with no ticket, get a panic, fill in the error reporting dialog with a nice “hope you had a nice holiday break!” message or whatever is seasonally appropriate, with the same simple steps to reproduce. It’s just kinda comical at this point.
My guess is kerberized NFS has absolutely zero users within Apple, and it’s likely hard to find an engineer there who even knows what Kerberos is anymore.
I used to work at Apple and I’d have filed a radar for it but now I’m just a customer so I’m powerless.
It's been a while since I worked at Apple, but back in the day the entire OS X Server team made extensive use of kerberized NFS shares for moving around large files...
...the last version of Server shipped in 2021 (and the last real version shipped almost a decade before that).
Hmm, the more I think about I think you’re right, they likely still do use kerberized nfs, but I think the auth layer they use is… different. Without giving too much away, the internal SSO software ends up either wrapping or providing Kerberos tickets in some way, so I’m imagining that code path doesn’t panic.
In fact that’s probably the clue… everyone internally at Apple using krb5 auth with nfs is probably using the internal SSO software and the code path for “vanilla” Kerberos (ie. Ticket Viewer.app and so on) has zero testing. Maybe I’ll write that into the next crash tracer report I type up :-D
Hah. I actually had opendirectory, OSX clients, and CentOS/RedHat clients running krb5 NFS off of netapp filers circa … 2008? Lots and lots of NFS in the (mansfield) hardware org at that time. I think krb on osx started getting hard around 2010 when they moved tickets and other credentials to a process aware in memory store. Became difficult to use TGT or machine identity for automation.
And yes, Im sure theres a very lonely radar bug for this. But even MM of revenue wont fix “edge cases” like this.
> I used to work at Apple and I’d have filed a radar for it but now I’m just a customer so I’m powerless.
I filed a radar while working there on a bug that was introduced in 2009 and it's still not fixed because it was low in the stack and the person responsible for it said they didn't think it was wise to make changes that late in the beta cycle (it was close to the annual release). It's never been fixed. I stopped checking major releases about five or six years ago.
Where "new" in this case could be a NAS running Samba from 2011? Samba added official support for Time Machine much later, but I think it was possible on earlier versions with some extra steps.
That's when Samba gained official easy to use support for being used with Time Machine. I'm pretty sure it was possible long before then, IIRC by changing a setting on the Mac to allow selecting unsupported network volumes.
I don't recall when I stopped running netatalk on my NAS and switched to pure Samba, but I think it was before 2018.
SMB1 has major security issues but even those ignored (which a lot of people on private home networks shouldn't be too worried about) it's also slow as hell on MacOS
philosophically, it depends on who you are. If you're Sam Altman or Vitalik Buterin, yeah, your private home network should be considered to be under attack by hostiles trying to steal from you, but for the rest of us, the NSA isn't going to make an international incident trying to get at your Plex server.
1. When I benchmarked it, AFP was significantly faster than SMB. Both with SMB2 and SMB3. Even when transport encryption was turned off.
2. On SMB2+, symlinks created by the client are not real symlinks. They're "Minshall+French" links which only look like symlinks to other SMB2+ clients. To the server and NFS mounts they look like flat files with the target path encoded in them.
3. It exposes a different precision for certain timestamps. Software that uses this metadata to decide whether a file needs to be updated will see almost every file as needing a resync.
It's been a year or two since I checked the status of these. The situation may have improved since last I looked.
Yeah I recently migrated my NAS and took the opportunity to switch from AFP to SMB for my Time Machine backups. There were so many problems like the ones you describe that I gave up and went back to AFP. Looks like I'm going to be forced to spend a weekend with Claude figuring this out.
Did they ever work? No, seriously. I've had a couple of them and the few times I really could have used them I discovered that they represented the worst backup solution I've ever had the misfortune to deal with. Slow, very hard to use beyond their primary integration with the OS (which isn't good to begin with), there's really no good way to keep an eye on how they are doing (what's actually backed up, if it is still there) and the performance is worse than any hand rolled solution I've ever used.
They never supported it properly in the first place and then it just meh'ed out of existence.
I hope "the new Apple" is going to take software seriously.
My old trusty readynas should still work i think.. probalby. Supports smd for time machine and smb3 generally. If it doesn't I might finally be pushed onto a nas that isn't discontinued.
It’s a “nice to have” automatic backup, but not a primary backup destination for me.
I still am sore from when I "upgraded" macOS and suddenly support for my 1080i TV was gone. Yesterday it worked fine, today it's gone. All because they can't be bothered to maintain a code path.
With closed source IP, every bit of support, from bug fixes, to feature requests, to compatibility fixes to integrate with newer mainline/foundational tooling, costs money.
With open source projects (and in particular ones like Linux where there's a huge number of contributors and interested parties), support for would-be niche facilities can keep going as long as there's someone with the knowledge and spare time to do it.
[1] https://stockanalysis.com/stocks/aapl/employees/
These arguments fall apart when you remember that Apple has several trillion dollars at hand. It's not some shoestring startup.
IIRC, that could exist for MacOS in the form of Darwin.
With that said, kernel maintainers have recently indicated that some unused subsystems are likely to be removed soon, as AI is now finding (real) security vulnerabilities in them that nobody is willing to fix.
Looking through Apple’s financial statements, they theoretically could support these old systems. I’m not saying a cut doesn’t make sense, but just that economics-wise they could keep one guy for it
And that increasingly gets difficult to do. i386 support went down the drain in the kernel in 2012, i486 is probably going down the drain as well this year [1] and soon-ish another bunch of really really old stuff will go as well because it isn't maintained [2] - good luck finding someone still running IPX networks or ISDN hardware.
[1] https://www.theregister.com/2026/04/06/patch_to_end_i486_sup...
[2] https://lwn.net/Articles/1068928/
I am unsure if linux support has any bearing on it, though.
Because I noticed my old Core 2 Quad PC with Nvidia 8600GT that my parents use as their email and Facebook machine, doesn't boot with any linux newer than Kernel 6.1 even though I can get Windows 11 to boot on it.
So the myth around "Linux is great for old PCs", highly depends on what HW you have.
There's no fixes that I could find. My LLM research says nouveau dropped support for that Nvidia architecture on newer kernels. Bummer.
But by modifying it right? Because the core 2 does not support SSE4.2
You are deluding yourself if you think open source folks are better. You can't compile and run a modern version of GCC on Solaris 10 on SPARC, for example. And we just had a story here last week about removal of bus mouse support. It's only a mild exaggeration to say that lots of folks will check the commit activity on github and of a project doesn't have commits this week it should be banned from the internet and the universe.
Then you have the problem that many dev tools are not forward compatible. CMake is a huge issue. An ubuntu system from 2020 has CMake on it, but it won't compile anything that uses CMake that was released in recent years because the cmakefiles are incompatible.
Bus mouse support isn't removed because it's old but because it's been broken since 2015 and nobody noticed.
I actually wouldn't expect macOS to support actual floppy drives since the OS's list of supported devices doesn't include any that shipped with floppy drives. The fact that I cannot install the latest macOS on any devices older than 2019 is a related, but separate problem.
This is very different from legacy PC floppy drive controllers which spoke a completely different protocol, which was very complex and full of footguns
Legacy floppy controllers also had various legacy features almost nobody used, like soft deletion of sectors (IBM added this in the 70s for use with primitive database systems), or attaching tape drives using the floppy interface (nowadays if you buy a brand new tape drive, the interface options are SAS or Fibre Channel)
I'm mostly okay cleaning out a lot of legacy and unsupported devices. In some ways, and for people who want to support really old hardware it may not be great, but they're most likely stuck on older versions for other reasons.
I disagree. They are dropping support because nobody is maintaining them. There may very well be people still using these features, but they haven't been motivated or aren't properly skilled to offer to maintain them going forward, and haven't motivated some other skilled person via payments.
Rather, the core difference is that Apple does not offer a way to have external people take over providing support.
Support for 486 is another thing, but, frankly speaking, running a modern Linux kernel on a 486 makes no sense, either form a practical or preservationist / museum perspective.
> There are still some people who need to run 32-bit applications that cannot be updated; the solution he has been pushing people toward is to run a 32-bit user space on a 64-bit kernel. This is a good solution for memory-constrained systems; switching to 32-bit halves the memory usage of the system. Since, on most systems, almost all memory is used by user space, running a 64-bit kernel has a relatively small cost. Please, he asked, do not run 32-bit kernels on 64-bit processors.
https://lwn.net/Articles/1035727/
Supporting old hardware and software has a substantial cost that only grows exponentially. Companies exist to print money, not to cater to the smallest niches.
It would be great if they could support things, but I most definitely understand why they don't.
And then I went to Acronis True Image backing up to my Synology NAS, but that became unreliable too - oftentimes when I'd go to do a restore, the client would crash trying to read the catalog.
So, like you... CCC nightly to my Synology, with a Snapshot rotation on it - snapshot the previous night's backup at 8pm, and then kick off that night's backup at 11pm.
I've loopback mounted disk images over network filesystems for many years without any recurring issues outside of macOS. It's not rocket science, particularly if you have a reliable network connection.
I'm aware there's a long tail of possible issues that can come up, but most of the complaints I've seen amount to "I have a reliable connection and Time Machine is still a tire fire", which suggests that the problem exists outside of that particular set of edge cases.
(It seems to genuinely be that nobody at Apple really cares about network filesystems at this point - people in this thread talking up AFP makes me want to look at migrating _to_ using it for my mac's backups, because SMB on macOS randomly drops or hangs for no reason and Time Machine at least twice has just started stating the backup was completely unreadable, leading to me having to restore the backup filesystem from backups.
And attempting to use NFS on macOS somehow makes everything three times as buggy, like they special cased SMB shares to not be touched in some random "touch everything synchronously" calls throughout the OS but didn't do it with NFS shares, so Finder will now take seconds or minutes to do things that shouldn't involve that share, but as soon as you remove it, it stops doing so.)
TFA:
> Apple made SMB its primary file-sharing protocol in OS X 10.9 Mavericks, over 12 years ago, and has repeatedly told us that support for its predecessor AFP will be removed in the future.
The "new computer" out of box account creation and first sign in experience on both Windows 11 and MacOS are clearly designed to drive end users towards perpetual for life monthly recurring subscriptions for (Microsoft 365 Personal, OneDrive, iCloud storage, etc).
Imagine the difficulty for the ordinary non technical person (absolutely not a stereotypical HN reader) ever being able to stop paying for iCloud when they have 600GB+ of their family photos and videos and stuff backed up to it.
To be fair, non technical folks get a lot of value from this scheme too. I can't imagine many of my relatives successfully juggling backups and external media in a way that would actually keep their content safe in case their phone is lost/stolen/destroyed.
Right now the monthly fees for this stuff are rather modest, but I could see a future where the dominant players lock out competitors and use their market position to raise prices significantly.
- BigCo already is a zero-sum deal, they use Xcode-cloud as a service, which runs back on their servers anyway... (Google, Amazon, Azure, etc)
- It was not a long-standing product. Introduced somewhere around 2016~ish if I remember correctly. Only lasted a few major releases. Easier to kill than an established one (ie. TimeMachine)
They aren’t deprecating Time Machine. The old protocol is being removed.
The old protocol hasn’t worked well for a long time, at least in my experience
I've been working on improving an open source menubar that wraps restic. Right now it is a bit rough around the edges, but my plan is to have a simple onboarding experience for various backend services like B2.
Over the weekend, I added a "Smart backups" feature that uses all the same directories that the backblaze menubar app and timemachine excludes. This was the primary missing feature for me. It even generates and backups your Brewfile...
https://github.com/lookfirst/ResticScheduler
Also it's honestly really weird that they don't have iCloud backups for Macs yet. It seems like a no-brainer feature. I know I would easily switch to Apple over Backblaze as Backblaze's client is just terrible.
How big is this market? I'm not saying vibe code a product, but...
I have colleagues who are running AFP on BSD for continuous backups on their systems, and they have to reconfigure something new to be able to continue backing up their systems.
Oh, I was thinking only of software. Apple dropping AFP in the OS doesn't mean it can't work at all.
https://wiki.archlinux.org/title/Netatalk
Every single one of the blogspam sites (lifehacker, howtogeek, etc.) told you to use AFP/HFS+/Netatalk. I had so many problems with this. Time Machine would work well the first few times and then slow to a crawl. If there was a power outage, look out. The whole thing would be corrupted. It wasn't the network. FTP and scp worked just fine.
Eventually I found one blog that told you how to do it with SMB and ext4. It was that site that I learned about the much malignment of AFP and HFS+. SMB/ext4 worked like a charm. Six years later and not a single hiccup.
Relevant to the discussion is that the project comes with an AFP client as well. I have no experience with the client but I've used the Netatalk server for more than 15 years.
This runs Samba 4 on the Apple Time Capsule.
* https://en.wikipedia.org/wiki/AirPort_Time_Capsule
I think there's some population of folks that have been doing NAS TM backups over AFP, and they'll now have to switch to SMB.
Every OS update I try mounting with no ticket, get a panic, fill in the error reporting dialog with a nice “hope you had a nice holiday break!” message or whatever is seasonally appropriate, with the same simple steps to reproduce. It’s just kinda comical at this point.
My guess is kerberized NFS has absolutely zero users within Apple, and it’s likely hard to find an engineer there who even knows what Kerberos is anymore.
I used to work at Apple and I’d have filed a radar for it but now I’m just a customer so I’m powerless.
...the last version of Server shipped in 2021 (and the last real version shipped almost a decade before that).
In fact that’s probably the clue… everyone internally at Apple using krb5 auth with nfs is probably using the internal SSO software and the code path for “vanilla” Kerberos (ie. Ticket Viewer.app and so on) has zero testing. Maybe I’ll write that into the next crash tracer report I type up :-D
And yes, Im sure theres a very lonely radar bug for this. But even MM of revenue wont fix “edge cases” like this.
I filed a radar while working there on a bug that was introduced in 2009 and it's still not fixed because it was low in the stack and the person responsible for it said they didn't think it was wise to make changes that late in the beta cycle (it was close to the annual release). It's never been fixed. I stopped checking major releases about five or six years ago.
* https://www.samba.org/samba/history/samba-4.8.0.html ("vfs_fruit")
* https://wiki.samba.org/index.php/Configure_Samba_to_Work_Bet...
I don't recall when I stopped running netatalk on my NAS and switched to pure Samba, but I think it was before 2018.
Windows 8 is nearly a decade and a half old as well.
Time really does fly.
philosophically I would beg to differ about any premise assuming we can trust the castle and moat model. Even on home networks.
1. When I benchmarked it, AFP was significantly faster than SMB. Both with SMB2 and SMB3. Even when transport encryption was turned off.
2. On SMB2+, symlinks created by the client are not real symlinks. They're "Minshall+French" links which only look like symlinks to other SMB2+ clients. To the server and NFS mounts they look like flat files with the target path encoded in them.
3. It exposes a different precision for certain timestamps. Software that uses this metadata to decide whether a file needs to be updated will see almost every file as needing a resync.
It's been a year or two since I checked the status of these. The situation may have improved since last I looked.
They never supported it properly in the first place and then it just meh'ed out of existence.
I hope "the new Apple" is going to take software seriously.