Radicle 1.0 – A local-first, P2P alternative to GitHub

The familiar model of "centralised" Git hosts like Github come bundled with their own protocol-specific permissions models. E.g. if you were to imagine a team working from a simple .git directory hosted on a local SMB/whatever LAN share, the permissions model would be file permissions on the networked filesystem.

Blocking users committing to an "owned" branch on SSB would require implementing an ACL-tracking & ownership model attached to namespaces (likely branch prefixes here by convention) - very doable, nothing about the protocol prohibits it architecturally. So if it ever becomes one of those "good problems", it's not an inherently concrete design decision.

Homebrew assumed it was being installed on a single-user-at-a-time system, and it didn't want the risk of a bug in its ruby scripting being exploited somehow by insisting on running as root, and it chose /usr/local to install to as it was already in the path... all of these are anathema to Linux users.

* A package manager should leave /usr/local alone as its purpose is to host the user's own software, not distributed software (that's /usr) or vendor software (that's /opt)

* A package manager should run as root, or run its install-the-files portion as root, because it should require the user's admin authority _at that time_ to be permitted to install software that will be in the path of _other users of the system_. If the user takes ownership of the system directory instead, then all their other processes can mess with it too, not just the package manager.

The right thing to do is to install to e.g. /opt/homebrew, and then require users to add /opt/homebrew/bin to their own PATH, which is what Homebrew now does. It only did it after Apple fought against them by using System Integrity Protection to prevent users changing the ownership of /usr/local -- for a while Homebrew told users to write "sudo chown ... /usr/local/*" rather than "sudo chown ... /usr/local" to get around that, and that's what we see here.

The right place for this software on Linux is under /opt or /srv, and it should have the equivalent of "sudo make install", where root is required to install the software to the right place (and after installed there, it can't be modified by regular users), and root is _only_ required for that install step, nothing else.

EDIT: I'm unable to reply to the person whose question I answered, but I'd commend the GP for spotting the macOSism, and recommend everybody be alert to these sorts of tells and impedence-mismatches. You can often spot experienced Windows users doing "Windowsisms" in Linux... and vice-versa! You can see people writing Rubyisms in Python, Cisms in Java, and so on. There's a risk that if they don't adopt the appropriate native idioms for the language/environment/OS, they will introduce subtle bugs, sometimes security bugs. Be on the lookout for this.

That doesn't really make the argument that it's a macOS user who wrote it though does it? It just makes the argument that it was potentially inspired by Homebrew, which has existed on Linux for half a decade.

I didn't really read the rest of your spiel in detail. I asked why you have an opinion about a person I didn't ask for a breakdown of package management and software installation best practices for the last few decades.