sysV init or sysV rc? OpenRC can work with any basic /sbin/init or provide its own. If you rely on sysV rc scripts there is probably some backwards compatibility, or at least was in older versions, but I don’t really see the point in it. What distro does even still use sysV rc?

These days OpenRC even has user-services. And writing a simple OpenRC service file is barely more complex than a systemd unit file, maybe even simpler, because it’s readable bash, not some declarative DSL.

Obviously there is in no way feature parity between those two, that’s the point, personally the one thing I’d like to have is something similar to systemd’s timers (which I actually prefer to old-school cron) built into OpenRC, but most other things I can live without.

Little Snitch is literally used for blocking ads as well as other network traffic. My main point was that you don’t have to use it for blocking the other traffic, because Linux systems won’t have unwanted traffic to begin with, since you have full control over it. And for the ad part, there’s better solutions than network-level filtering if you have control over your browser.

So is it more that you don’t know what I’m talking about or that you don’t want to, for whatever reason?

I have both yay and paru on the two Arch systems I manage, because pacman tends to break those occasionally through dependencies and that way I don’t have to do the whole makepkg bit again and instead can update the one with the other. I still find it asinine that these aren’t in the repos or the functionality isn’t integrated in to pacman, but since Arch’s entire philosophy is based on simplicity, I guess the chosen solution to secure user packages is security by obscurity.

(I only still use Arch on those systems because I haven’t gotten around to migrate them to Gentoo yet, after implementing a binpkg repo and custom profiles many years ago so compiling on the weaker machines is essentially unnecessary, btw.)

Librewolf (with some overrides and a source patch) on the desktop and Fennec on Android. Before Librewolf I used upstream Firefox with the Arkenfox user.js, but Librewolf made that obsolete.

I haven’t looked into Fennec’s current version in detail, mostly because I use the browser so rarely on my phone and my main consideration is not getting ads when I do, but they might still use SafeSearch and stuff like that, so if you’re aware of any better alternatives that are in F-Droid please tell me.

Also, you only need that stuff in the first place if you don’t have control over the operating system and your browser (like on Apple or Microsoft). For me, using a Firefox-based browser with uBlock Origin on both phone and desktop is enough so I don’t have to ever see ads, and I just don’t install spyware in the first place.

That’s what I always loved about Gentoo. Users are interested to have a system with systemd: Gentoo supports it and got you covered. Users are interested to have a system with OpenRC: Gentoo supports it and got you covered. There’s even a couple of people who want to use runit or s6 (and maybe others I’ve missed) and they’re there in the official repos, but depending on your needs you’ll have to do some work on top of that. Similar story with device managers, tempfile managers etc.

It smelled like an easily recognizable mentality from the start, and your last comment just confirms that for me. I’ve seen it elsewhere and I try to stay away from it where I can. But I wish you luck and joy using your chosen set of tools though. It’s great there are alternatives for everything in FOSS.

It comes down to my ADHD brain being unable to handle the context switches with windows popping in and out, staged diff views, unstaged diff views, and the mental model of which state everything is currently in. Whereas with the CLI I type out the whole operation in advance and get a nice history of the steps I have taken before, with magit I need to build up on the fly with interactive feedback I have react to, or at the very least can get distracted by. My “just slow me down” maybe sounded like “I am so fast, magit can’t keep up”, whereas I meant it more like “I can’t keep up with magit and constantly have to recheck things and correct mistakes”. For example my preferred workflow is relatively git (add|reset|checkout) -p heavy, where I can make sure the changes that get staged match exactly what I want, with undo/redo working as expected since it’s just a normal text buffer, whereas with magit I’ll go into the diff and press s/u on lines/regions with things just popping in and out of existence and I have to go over to the opposite diff and reparse that to fix a mistake I made.

It’s very similar to other GUIs in that way for me. Or modal editing for example: I can’t for the life of me keep track of what mode the editor is in at any moment. With vim/evil I even had the muscle memory going at one point, but I would constantly type commands in insert mode and text into normal mode leading to all kinds of random things happening. I could be the fastest typist in the world and vim would still slow me down. However Emacs is perfect for designing a workflow to mitigate this, since it allows me to harmonize and simplify many of the keybindings to do similar things in all modes, customize window management (display-buffer-alist) to be less distracting and disable other distracting commands I don’t need entirely.

I’m a huge Emacs user and while I love some of the convenience features (editing the rebase-history, smerge-vc-next-conflict, etc.), but I rarely use magit, one of Emacs’ killer features, because I just still prefer the CLI over it. I usually know exactly what I want to do and menus, popups and hotkeys, no matter how good they are, just slow me down.

That article doesn’t actually criticize the structure of git’s CLI, just the way the application operates and the philosophy behind it. fossil’s CLI actually seems to take a lot of inspiration from git, except it’s way less complex, because fossil doesn’t “need” that complexity (i.e. can’t do it).

From a cursory reading, I disagree with most philosophical points made. Many of the scenarios and user testimony are complete nothing-burgers. I haven’t tried it for any length of time, but I think I prefer a fast, optimized, flexible tool over an integrated everything-but-the-kitchen-sink opinionated kind of thing that forces you into doing things their way or the highway, no matter how good it actually is. But as OP said, this is about the CLI, not the applications.

I think git is the obvious choice, both in ergonomics and flexibility (custom commands). But maybe I’m just using it so much I don’t recognize the sharp edges as much anymore.