freebsd-update-probe VS musl-sem-ext

https://github.com/tux2bsd/freebsd-update-probe

freebsd-update is broken, it does internal spaghetti which prevents it from doing the most logical thing first: "check upstream for updates"

I created a work around, it works well.

I don't use FreeBSD, but it's good for a hobby OS. Has a few cool ways to do things (seperation of OS vs external software & /etc/rc.conf). The project is coasting on ZFS success.

They HATE me at the FreeBSD Forums. I don't think a single one of them truly understood what freebsd-update-probe actually achieved.

I'm not a programmer.

FreeBSD related shameless plug: https://github.com/tux2bsd/freebsd-update-probe

It makes the update process efficient like it should have been (when there are no updates).

I gave FreeBSD a try:

I provided a workaround for a problem with freebsd-update, summary and tool can found here: https://github.com/tux2bsd/freebsd-update-probe

FreeBSD separation of OS vs other applications is great.

FreeBSD pioneered ZFS integration but are coasting on that success.

The FreeBSD forums, linked from the FreeBSD website are insular. FreeBSD zealots LARPing as the true "true" BSD / Unix enthusiasts.

If you want to try FreeBSD just use the Handbook. The FreeBSD community is childish and won't list that FreeBSD can run on KVM (the mere fact it can, I'm not talking in depth instructions).

I loathe nearly all man pages, they are written in a manner that is as over the top and an absolute chore to digest. I believe it is a form on programmer one-upmanship, it is largely unnecessary and stalls common usage massively.

I made this recently and tried very hard to make it so that the vast majority of people that could use the command line could grasp what it did, usage is trivial:

https://github.com/tux2bsd/freebsd-update-probe

I guess what I'm saying is I like documentation written for humans (which you do).

A few years ago, the company I work at switched to using Alpine-based docker images for most containerized things. One side effect was that our Ansible playbooks (running from inside one of these containers) would fail with inconsistent network timeouts when targeting a couple thousand servers. It turned out that the issue wasn't with the network nor with Ansible. The way that Ansible invoked some library functions for keeping track of SSH connections caused it to create a bunch of POSIX semaphores via sem_open().

glibc had a dynamically allocated data structure to keep track of semaphores, but musl libc only had a fixed-size 256 element array. When the semaphore limit was exhausted, Ansible would fail to keep track of the connections, resulting in a network timeout error message. I fixed the problem by forking musl's semaphore functions, making the array resizable, and loading the implementation with LD_PRELOAD: https://github.com/chenxiaolong/musl-sem-ext. Worked perfectly for 6 years until we decommed our data center :)