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

[Jeff H. <jef...@gm...>]

"huge boon"

Agree!

I use afp between my linux server and my 2019 MacBook Pro running macOS
Venture 13.5.2. It seems to be superior to smb, which one other device
uses. I don't know if my Linux-macOS context uses the feature you describe
but I would be very unhappy if I had to switch to smb for all of my
devices. For a 6 month period or so, when I couldn't get this product
compiled on the linux server, I had to use smb everywhere and I was none
too happy.

On Sat, Nov 18, 2023 at 5:46 PM Daniel Markstedt <da...@mi...> wrote:

> 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?
>
>
> _______________________________________________
> Netatalk-devel mailing list
> Net...@li...
> https://lists.sourceforge.net/lists/listinfo/netatalk-devel
>