Seamonkey (which I'm using to write this) is one option. Built for all platforms, no Mozilla tracking/ad/pocket-partnership nonsense. Unfortunately the team is small and Gecko has been changing a lot lately.
Long term the gemini protocol and browsers like lagrange might be the only option - its just too hard to build a modern standards supporting web browser these days (even Microsoft has thrown in the towel and adopted Chromium for Edge).
They removed webstart - which is fundamental to how the apps we use are distributed. I believe that reason alone is why the distributor has stuck to Java 8/OpenWebStart.
Note that Wine runs Windows binaries, whereas what this project aims for is source compatibility. That at least means you aren't at the mercy of ABI versioning, though you wouldn't be able to 'run' a macOS app you found online.
I find the creators livelihoods lines to be attention grabbing and muddying the waters about what this argument should be about.
The Netflix exemption should be available to all apps - that point is what the Epic lawsuit should be about (they've confused the issue too by talking about having their own app store). Apple could then fight for developers to use Apple Pay on its merits in the marketplace.
In the case of Fanhouse, the rules were well known (and disliked) when they started. They should have created their product as a web app - their particular use case is one where the technical limitations of a web app wouldn't have been much of an issue.
If they felt so strongly that their product had to be in the Apple App store to succeed, they are justifying Apple's 30% cut.
> * It drastically improves the upgrade process -- I never need to look at a 3-way diff of /etc/init.d/apache2 again
lol. I had to trash an Arch Linux box because it failed to upgrade systemd from 208 to 211. Everytime I upgraded the system hung trying to mount filesystems so I had to roll back.
The post was on 'the good parts' of systemd, so complaining about balance seems unfair.
I will call out one aspect that the author deemed a 'good part' as in my experience its a bad part: journald.
Usability: journald requires administrators to learn a new command to access their journals - everytime I have to use it I need to look up the syntax again. Compare with logs in /var/log and you can use all the standard unix tooling (text editors, tail, grep etc).
Reliability: in my use journald has made my servers more unreliable. Two CentOS 7 VMs, setup at the same time. On one journald works just fine, on the other approximately once a month journald would stop logging. It wouldn't start logging again until you noticed and rebooted the server. The real issue this exposes is that on a systemd machine, journald doesn't just log for itself, it also supplies the logs to syslog. So on this server when journald broke, there were no logs whatsoever.
This issue was apparently common on the version of systemd shipped with CentOS 7. The fix was to disable log compression in journald. What it highlighted to me was the inherent issues in an all encompassing system controller like systemd, in that if there is a bug somewhere in there you lose not only the added bells-and-whistles its intended to provide (journald in this case) but also the old previously reliable functionality (syslog).
In my mind the fix for this is a redesign of systemd to make it an optional layer on top of the reliable functionality rather than a low level system component that everything else needs to depend on. In the case of logs journald should consume logs from syslog, not provide them to syslog.
My main issue with ZFS is the integrated nature - like systemd for filesystems.
My 'alternative' for ZFS isn't BTRFS (awful performance characteristics for my workloads) but LVM coupled with ext4 and mdraid. I get snapshots, reliability, performance and a 'real UNIX' composable toolchain. I miss out on data checksums.
His comment was more on the wisdom (or otherwise) of running an out of tree filesystem. I think its hard to disagree with him. He went on to say you would never be able to merge the ZFS tree with Linux. Again he's the one who would know what code gets in Linux. His only actual comment against ZFS was that benchmarks didn't look great - which is unsurprising given all the extra work ZFS is doing wrt data integrity than other filesystems in production use.
This is why FreeBSD rebasing its ZFS fork on ZFS-on-Linux made me so scared for the future of FreeBSD. Their one major advantage over Linux and they didn't have the developers to maintain their fork themselves.
This guy really doesn't get the point - he's testing an embedded part with 16GB RAM against an overclocked desktop part with 64GB RAM (and a load of the benchmarks are garbage collected so the extra RAM is significant).
Its also the case that none of these benchmarks are Apple specific - users buying a Mac Mini for development are likely to be developing in Swift for which the M1 has special optimizations.
Need to wait for Apple to release a part for an iMac or MacBook Pro to inform his conclusion that x86_64 is going to be able to outperform Apple's ARM chips going forward.
Long term the gemini protocol and browsers like lagrange might be the only option - its just too hard to build a modern standards supporting web browser these days (even Microsoft has thrown in the towel and adopted Chromium for Edge).