Control over your data is part of anonymity. Sure, everyone will know the service belongs to you, but you'll be in total control over who knows what exactly. To most people not in the eye of the law, that is most of the anonymity they require.
Also, services like TOR exist. Both on the hosting and user side.
If you think TOR is anonymous then I have a bridge to sell you. It's far more likely a fed is going to record your activity on TOR than on a standard open web connection.
The point of TOR is that while it can be detected, at the entry nobody knows what you're sending to whom, and at the exit nobody knows who is sending what. The fed sniffing my TOR connection can't really do anything with it.
Either adding your script directory in front of the PATH, or creating `alias` that provide a full path to your script where a conflict exists, makes a whole lot more sense to me.
I've never had this collision problem yet, despite appending my script directory to the end, but I'll use either of the above solutions if that ever becomes a problem.
One rarely actually needs to shadow binaries. Some cases could indeed be covered by introducing an alias that binds the binary's name to call a different copy of that binary.
You use shadowing to fix issues where you install some software that expects you to have a sane and ~recent version of some tool like git, but you don't as your system provides that binary and unfortunately it is either not sane (not GENERALLY sane [while it could be sane for system scripts]) or not recent enough. In that case the program's function would simply fail if it would call the system's binary and you shadow the binary with your version to fix that.
> adding your script directory in front of the PATH
That's a poor advice for the scripts you call relatively frequently. Instead, (as a general approach, we aren't discussing some particular script) don't use shadowing for scripts: just pick a non-conflicting script name and append the script's dir to $PATH.
The only situation where you'd need to type a full path is when you have a name collision. But the suggestion to not worry about collisions with unknown system binaries also said to put the script folder first. In that situation running the script doesn't need a full path, and you won't be running the unknown system binary. So you won't be typing full paths.
Please explain the non-explicit suggestion you see, because I don't see it.
It's clear that "adding your script directory in front of the PATH" means a one time edit to .bashrc or equivalent, right? In normal use you're not typing it.
I learned to deliberately declare paths pretty early on in my adventures at the CLI. I don't leave room for accidental alternative execution. It might be overkill, but it gives me a sense of security and that's why it's there. Don't worry, I probably made a terrible mistake somewhere else that completely negates my attempts at a correct shell environment.
I think they mean you don't need ruffle if you can just export to web. The programming environment can be anything, but adding ruffle in the middle when it really doesn't need to be there, does indeed feel a bit tacky. Flash used to be necessary to add functions to browsers that were otherwise impossible, but these days you can do anything in a browser.
Yes indeed. The web with webgl/webgpu and wasm and all the other webapis has enough power to replace what flash could do since a long time. Just doing it by hand is messy, but as a target plattform it is good enough.
I was considering forking the base book and maintaining it, as I have kept an eye and occassionally built the project over the years (I use it a lot for package management/bootstrapping/cross compilation experiments), but it appears there already is one: https://lists.linuxfromscratch.org/sympa/arc/lfs-dev/2026-02...
I believe maintaining the base book is the most important part, BLFS has some really good hints but a very significant amount of packages have few differences, collecting these in a separate hints file or similar would help a bit, at least for things that don't hard-depend on systemd like gnome.
eudev was just a copy of the udev part of systemd, with some patches to build on musl, and work without systemd.
All of that has been upstreamed now, LFS has instructions on how to build udev from the latest systemd release, without building systemd itself.
The problem is mostly that programs started depending on aspects of systemd that are both very complex, and difficult/impossible to implement without ending up with systemd. Systemd's components don't play well with established standards (sometimes not running standalone at all), which contributes to the feeling of having to buy into the whole ecosystem just to use a small part of it, just for that one bit of a certain program that now depends on it.
This has happened with gnome's display manager, and now gnome-shell is threatening to cease functioning without systemd, as well as on systems that systemd doesn't run on such as the BSDs. KDE's new login manager is now doing the same, so in many respects, people's fears have been validated.
Is that "logout" referring to a user explicitly logging out from a desktop environment? I can't imagine it would apply to a closed SSH session, or at least it wouldn't make sense if it did.
> It is now indeed the case that any background processes that were still running are killed automatically when the user logs out of a session, whether it was a desktop session, a VT session, or when you SSHed into a machine.
And the reddit comments include a link to a tmux issue where the suggested solution is for tmux to add systemd as a dependency (https://github.com/tmux/tmux/issues/428). Includes some back-and-forth about how all sorts of software would have to change in similar ways to accommodate systemd, instead of systemd just playing nicely with decades of established practice.
I had no idea about that. Does seem a bizarre choice for systemd to do that.
I admin a whole bunch of headless servers and so am often SSHing to them and running long running jobs. Some of them run VNC sessions, and I certainly wouldn't want a VNC session to kill of other SSH sessions by the same user. At least with VNC, I almost never "logout" - they're often autostarted (by systemd) and just get killed when the machine gets rebooted.
reply