Re: [Netatalk-devel] [Netatalk-admins] Request For Opinion: Deprecate FCE

[Daniel M. <da...@mi...>]

Chris,

Yes, very helpful. Thank you. I am convinced to keep the FCE feature in the upcoming 3.2 release cycle.

I sincerely hope Apple doesn't kill off their AFP client in macOS any time soon. It's been a huge boon to be able to seamlessly do file sharing from very old Macs or even Apple IIs with the latest macOS clients using netatalk as a bridge software.

As a side note, we actually got netatalk working fine on macOS hosts again earlier this year, serving AFP volumes on APFS file systems. Apple of course did away with their atalk kernel module for OSX 10+ years ago, so it's TCP/IP-only.

Cheers,
Daniel
On Wednesday, November 15th, 2023 at 2:15 PM, Chris Devers <cd...@ed...> wrote:

> On Tue, Nov 14, 2023 at 11:39 PM Daniel Markstedt <da...@mi...> wrote:
>
>> For the example of the video production software:
>> Do you know for a fact that this software was sensitive to the Netatalk FCE events specifically?
>> Or do you assume that it was based on the overall health of the system?
>
> I’m a little reluctant to get *too* specific on a public mailing list, but yeah, the mainstream professional media software that people use for producing TV, film, advertising, streaming, etc media all frequently seem to use such capabilities.
>
> My sense is that when the applications detect that they’re writing to storage, they have mechanisms for determining whether the storage is local or remote, whether it supports various semantic operations, whether it supports things like normalized Unicode encoding for filenames, etc. And among the capabilities that get checked would be for things like file locking and filesystem change events, and depending on whether or not such functionality is determined to be available, certain features get enabled or disabled, as appropriate.
>
>> I guess what I’m trying to get at is whether Netatalk’s FCE is an “industry standard” as it were, or if software had to be coded specifically to be Netatalk aware, i.e. be modified for an enterprise rollout that included Netatalk.
>
> I haven't gone spelunking through the source code or the network packet traces, etc, but my sense is that the behavior tends to be as above: there’s a check for whether the storage is local or remote (more things, like Spotlight & Trash support, get turned on if the volume is “local”), and if the storage is “remote”, then the applications may tend to proceed not based on whether the volume is AFP/SMB/NFS/etc, but based on whether particular options, like filesystem change events, appear to be working or not.
>
>> I wouldn’t want to force enterprise users to stay an old Netatalk version, and miss out on security and stability improvements.
>
> Yeah, this is always the tension: upgrade or patch one thing, and everything else may need to update, too; hold back on updating one thing, and everything else can also be held back. Either way makes life harder for sysadmins.
>
>> If someone is serving a fleet of older Macs and can’t realistically migrate to Samba, I want Netatalk3 to remain a viable choice.
>
> I think Apple are the primary drivers here, as AFP already can't be served from new Macs booting from APFS volumes, and the company has been signaling that macOS is likely to drop AFP client support in the future. Anyone still using AFP “professionally” has to be aware of this, and must be making plans to migrate to other options, if they haven't already done so.
>
> With video production, it can be the case that, for example, somebody buys a specialized piece of equipment, like a video ingest box, and maybe that piece of equipment is very expensive. It's sometimes the case that these products are sold but don’t really have upgradeable software or firmware, so they’re originally designed to work with particular Windows or Mac OS X / macOS versions, and they don’t necessarily work with later versions. Products like this can put people in a bind, because they have a workstation that’s older, but still doing useful work, and the replacement cost might be prohibitive, so they keep it on an older operating system version, and in turn might also have to hold back upgrades of other systems — like the AFP file server — because then they’re going down the rabbit hole of having to come up with a new matrix of compatible versions of everything they need to manage. Also, periods of downtime due to upgrades & testing can lead to lost revenue, which can further lead to a reluctance to make any changes if the status quo is “stable enough”, “secure enough”, etc.
>
> My sense is that anyone in a situation like this realizes that it's not a great scenario, and they’re eager to migrate to something better — like Samba, if possible, but other options exist as well. But the transition process can be disruptive, so there’s an instinct to stick with tools (such as AFP and its existing FCE support, even if it’s imperfect) that are known to be “good enough, for now”.
>
> Helpful?