Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Networking changes coming in macOS 27

eclecticlight.co

Post reply on HN
Print view View original

211–220 of 248 posts

Re: Networking changes coming in macOS 27

#211

Post by dwaite »

yjftsjthsd-h wrote: post #176
gzread wrote: post #174

Earlier quoted context omitted.

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.

Re: Networking changes coming in macOS 27

#212

Post by mschuster91 »

_verandaguy wrote: post #53
ryandrake wrote: post #46

Earlier quoted context omitted.

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

The economics make the reasoning obvious, though. 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 the…

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

[1] https://www.theregister.com/2026/04/06/patch_to_end_i486_sup...

[2] https://lwn.net/Articles/1068928/

Re: Networking changes coming in macOS 27

#213

Post by procaryote »

throw0101c wrote: post #13

Time Capsule has been unsupported since 2018 (last shipped 2013): * 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.

I gave up on timecapsule because performance has gotten worse and worse year over year. I replaced it with a periodic rsync backup to a NAS that is in turn backed up in other ways

The upside is that it's dead simple when it comes to how the backup is stored. In 10 years time, having files in a filesystem will still work, but I imagine restoring an old time machine backup will require quite a bit of work

If you wanted to you could probably figure out how to do apfs snapshots before rsyncing

If you exclude pointless stuff like browser caches it's also pretty performant compared to timecapsule, and the transfer is properly encrypted

Re: Networking changes coming in macOS 27

#214

Post by dwaite »

applfanboysbgon wrote: post #138
Someone1234 wrote: post #130

Earlier quoted context omitted.

By the very nature of assigning development time to these antiquated features, you're assigning them away from other features, bug fixes, or requests that may have a larger user reach. Development is a finite resource, the argument here is to allocate them to hard-to-secure, outmoded, replaced, technology instead of anything future relevant. It doesn't make sense.

The person was specifically suggesting hiring extra developers for maintenance. While I'm familiar with the concept that "nine women can't birth a baby in a month", I don't think that applies so much to maintenance of old code paths. Apple makes over $100b in net profit per year, a truly unfathomable amount of money, they can afford it, and I think not only can they afford it but that it would benefit them. Even if o…

My estimate is that your lower count of people who could still be using Time Capsule is off by a factor of 20, but we'll continue with the idea that Apple could justify hiring a single engineer to be assigned full-time on the TimeCapsule, starting today.

This hypothetical employee would:

- update the TimeCapsule firmware from using AFP to using a brand new SMBv3 implementation, including both porting and making it "fit" within the constraints of 2013 hardware.

- be designing and implementing a migration system for both the TimeCapsule and the Mac to move to using the new implementation

- be responsible for all security analysis, QA, and documentation for the firmware and migration system

They also need to get it done by the first macOS version that has AFP removed, which will land in developer preview in six weeks and need to be feature complete in about 17 weeks.

If Apple hires a new developer capable of doing that, I don't want them to relegate them to supporting 13 year old hardware. I want them improving things that the majority of users actually need.

And that is the core problem with this sort of argument. Even with infinite money or the infinite possibilities of open source contributions, the availability of talent is still _always_ finite.

Re: Networking changes coming in macOS 27

#215

Post by dwaite »

saghm wrote: post #86
zimpenfish wrote: post #79

Earlier quoted context omitted.

> You greatly under-estimate how much work it is to maintain old code, particularly to maintain in securely. cf Linux removing old network drivers this week for the same reason (without the hand-wringing that this Apple announcement is getting!)

Is the code that Apple is removing support for open source? The Linux drivers could at least plausibly be picked up and used by someone who really wants to, so it doesn't seem to be a fair comparison

The AFP protocol was deprecated in 2013. The AFP server was removed in Big Sur, so over five years ago. This is removal of AFP client support.

Apple's source is not public, but the protocol is still fully documented if someone wanted to create a new client and server. https://developer.apple.com/library/archive/documentation/Ne...

However, they'd be better off just creating a driver and server around the open source Netatalk implementation.

Re: Networking changes coming in macOS 27

#216

Post by dwaite »

apparatur wrote: post #36
GeekyBear wrote: post #20

Earlier quoted context omitted.

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.

Hence "next". And by local I meant directly connected drives.

If the pattern continues, they'll announce deprecation this fall and remove the feature in 2039.

Re: Networking changes coming in macOS 27

#217

Post by rincebrain »

tonyedgecombe wrote: post #107
FireBeyond wrote: post #15

Earlier quoted context omitted.

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…

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.

Not really.

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

Re: Networking changes coming in macOS 27

#218

Post by ninkendo »

saagarjha wrote: post #207
jballanc wrote: post #187

Earlier quoted context omitted.

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

Apple was still using Kerberos when I was there not that long ago.

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

Re: Networking changes coming in macOS 27

#219

Post by donavanm »

ninkendo wrote: post #169
wazoox wrote: post #148

Earlier quoted context omitted.

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…

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.

Re: Networking changes coming in macOS 27

#220

Post by nubinetwork »

shantara wrote: post #26

>Apple made SMB its primary file-sharing protocol in OS X 10.9 Mavericks, over 12 years ago… …and yet SMB support in macOS remains slow and buggy to this day. I tried all combinations of server-side settings and obscure plist tweaks to make SMB navigation and search work as fast as they do on my Linux machine out of box before giving up. It is very obviously not a priority for their services revenue, so there’s no in…

I'm more surprised they made it the default... with a Unix backend, why didn't they improve/expand nfs?
Post reply on HN