Comments by "Jeff Huffman" (@tejing2001) on "Brodie Robertson" channel.

  1. I think you've missed a lot of the issue with systemd (not that I blame you... most people who hate systemd express themselves very poorly). To preface this, I use systemd. I'm just not entirely happy about it, and still on the lookout for something that sets off fewer warning flags in my head. Systemd (the project, not just the init system) takes an approach to low level system management that assumes monoliths are good. Using systemd tends to be an all-or-nothing affair for the most part (not systemd-boot, but that's the exception, more than the rule). If you use one part of systemd, you kind of end up having to use the rest of it, too. The pieces all interlock without understandable, stable interfaces between the components to allow interchanging them. Functionality sprawls across the interconnected pieces, and the sheer quantity of obscure features is downright disturbing to anyone who understands the value of the unix philosophy, and bothers to really look at what's going on. Systemd-init also has a couple of really excellent ideas at its core. The event/transaction system it uses to manage services has changed how people think about ongoing state in their systems in general, and given them a much more powerful language to express how they want their system to behave. The idea of treating many different sorts of system state with the same concept of "units" has a lot of power. The dependency relationships that are possible among units, though not very consistently structured, are very expressive, allowing you to ensure things you had no hope of ensuring before. Having an "init" for each user allows user-level configuration to gain these same benefits as well. It's no wonder it took over, despite the issues. So I use systemd. It has some really nice features, and the cost of using anything else is just really high right now. But I continue to keep my eye out for a solution that gives similar benefits, but is more modular, keeps the agility to replace components fairly painlessly, and avoids lock-in and feature creep.
    17
  2. It's too bad you didn't mention NixOS here. It has immutable system files, generated declaratively, and atomic updates and rollbacks, but it's not image based and doesn't involve containerization. It's also quite configurable, especially if you're willing to learn the nix language a bit. I'd say it's perfect for exactly the sort of people for whom the image-based distros are too much work to customize to their liking. Got some special patches you want to compile a certain package with? That's fine, just add a few lines in your configuration and it's done. Oh, you want to run a custom shell snippet in the initrd? Sure. Easy enough. You can even throw home-manager in the mix and have large portions of your user dotfiles managed declaratively and immutably, too.
    7
  3. You can specify absolutely anything by surrounding it in single quotes (apostrophes, same thing), then replacing each single quote in the filename with '\'' (singlequote, backslash, singlequote, singlequote). Most people don't realize you can start or end quoting mid-word, but it does work, and allows you to escape the single quotes with backslashes, and everything else with the single quotes. This is the method used by many programmatic "escape for shell" routines.
    3
  4. Decent summary of the issues. Since I use a chromium-based browser, rather than use an electron app, I just run my browser with `--app=<webapp_url>`. It integrates into the desktop basically the same as an electron app, but it shared the browser's resources, and gets sandboxed away from my system. I also don't have to deal with updating it. (Discord is somewhat infamous in distro maintainer circles for releasing a new version and instantly requiring everyone to switch to it, with no grace period for it to make it into package repos...)
    2
  5. AI's tendency to hallucinate, as it's often called, just completely invalidates its usefulness in a code generation, code explanation, or reference replacement role, for me. I operate as a programmer by understanding exactly what's going on, so low-quality data sources are worse than useless. Where I do think it might have some value is in catching mistakes. For that purpose, it can have a notably higher error rate and still provide value overall. At least to a sufficiently capable human. Who knows if its error rate is even low enough for that yet, but I could see it getting there, at least.
    1
  6. I knew a guy who once accidentally overwrote the first few hundred megs of the partition currently mounted on /. He specified the wrong partition, and by the time he canceled the command, the damage was done. The system still kinda-sorta worked, some stuff was on the unaffected portion, other stuff was cached in RAM, but he was scrambling to try to find executables that still functioned that he could use to extract important files >.<
    1
  7. If you like the configurability of gentoo, but don't want to compile literally every package on your system, there's also NixOS. It provides the same level of customizability as gentoo, being a source-based distro, but because of the reproducibility demands it makes on build processes, it can transparently use cached build results from the main nixos organization. So you only run compiles for things you actually change. With NixOS, you also actually create configuration files as part of your system build process, from a single declarative config (which is actually written in a full-fledged programming language). So your entire system, as you've customized it, aside from your genuinely stateful data (what programs need to actually change at runtime), can all be built as part of a single process, and atomically updated and rolled back. The stateless nature of this process, combined with the organization of having all your tweaks documented in a single place, can be very freeing. That said, NixOS is quite different from normal distros in order to accomplish this. You need to do a lot more things differently due to the extra layer involved in creating all your config files, and in fact general linux binaries will not even run on nixos without some special tweaks, due to it not having an ld-linux.so in the normal place.
    1
  8. Regarding installing things by piping curl into sh (which you brought up briefly), it's not necessarily that bad. Nix uses this method for its standard install script, and that rubbed me the wrong way, but try as I might, I couldn't come up with a concrete reason this was any less secure than other potential ways of installing that software. The shell script is entirely contained in one big code block, so the shell will actually not execute any of it if you get an incomplete download, because of the bracket mismatch causing a parse failure. If curl has an error of some kind, that goes to stderr, and stdout gets an empty string, causing sh to do nothing. The url is https, so you're not vulnerable to a man in the middle attack. Assuming you trust the website creators enough to run their code on your system (which you do*, *obviously*, if you're trying to *install their software), there's no reason not to pipe something downloaded from their site into sh, if appropriate care has been taken regarding these details. All of this only applies to a one-time event of software installation from a trusted source, however. Doing this on an ongoing basis is... bad. I agree this example was horrible advice. The source was sketchy, it was totally unnecessary, and very open to lots of things going wrong.
    1