You got me. It was super inaccurate to use "proprietary" here (though if i understand correctly, podman is another option that is FOSS).
License aside, though, I would still bet that relying on the Apple-specific version of something like this will cause headaches for teams unless you're operating in an environment that's all-in on Apple. Like, your CI tooling in the cloud runs on a Mac, that degree of vendor loyalty. I've never seen any shop like that.
Plus when this tooling does have interoperability bugs, I do not trust Apple to prioritize or even notice the needs of people like me, and they're the ones in charge of the releases.
It’s a shame because the TINIEST amount of web searching would’ve brought them DRM playback and video accelerated Firefox. It’s not a 1-to-1 experience like a ThinkPad running Linux but I think anyone using Linux as a daily pretty much knows there’s some things you gotta dig for.
"Availability varies depending on region. To start, Maps on the web is available only in English. Maps on the web will be available for additional browsers, platforms, and languages soon."
However, we see the -D option on the listening parent:
$ ps ax | grep sshd | head -1
1306 ? Ss 0:01 sshd: /usr/sbin/sshd -D [listener] 0 of 10-100 startups
As mentioned elsewhere here, is -D sufficient to avoid exploitation, or is -e necessary as well?
$ man sshd | sed -n '/ -[De]/,/^$/p'
-D When this option is specified, sshd will not
detach and does not become a daemon. This
allows easy monitoring of sshd.
-e Write debug logs to standard error instead
of the system log.
RHEL9 is also 64-bit only, and we see from the notice:
"we have started to work on an amd64 exploit, which is much harder because of the stronger ASLR."
On top of writing the exploit to target 32-bit environments, this also requires a DSA key that implements multiple calls to free().
There is a section on "Rocky Linux 9" near the end of the linked advisory where unsuccessful exploit attempts are discussed.
sshd.c handles no_daemon (-D) and log_stderr (-e) independently. log_stderr is what is given to log_init in log.c that gates the call to syslog functions. There is a special case to set log_stderr to true if debug_flag (-d) is set, but nothing for no_daemon.
I can't test it right now though so I may be missing something.
The parent comment guesses they were avoiding saying Android, but, in analogy with imessage availability on both macos/ios, there's linux/android. But, yes, when I wrote "I think" i can't claim that's what they meant, just that's my reading of it.
