I don’t know if it’s of any solace, Linux used to be a much more… ahem… “involved” experience a decade or two ago. This was more-or-less the norm:

I can’t really say what the newcomer experience is nowadays, but I can say for sure that even in the worst-case (as it was in the times when I started using it), after a couple months of furious issue-fixing and trying new things, you will eventually settle on a setup that works for you. Some people actually get addicted to all the problem-solving and start looking for more issues to fix; some start distrohopping to find a “more perfect setup”, getting their fix of issue-fixing in the process. If you’re not one of them, congrats, at that point you can (mostly) just continue using it, until you need to update your hardware, then process may or may not be repeated depending on your luck. If you really hate fixing issues twice, you can look in the direction of declarative distros like NixOS or Guix, but I will warn you that the two-three months of furious hacking is still very much a thing here, but after that you’re set more or less for life.

NIX IS FOR REPRODUCIBLE BUILDS. That’s fucking it, seriously. It’s literally on their website.

This post is specifically about NixOS and friends, though.

IT’S A HORRIFIC EXPERIENCE FOR NEW USERS TRYING TO RUN A DESKTOP. Steer clear.

There are thousands of users who run NixOS on their desktop, and thousands more users of home-manager (or nix-darwin) on macOS. If you are ready to put in the time and learn how it works, it’s wonderful - your entire distribution, the thing through which you interact with computers, becomes just another project in your ~/projects, rather than something you have to manually configure. You can’t forget “how to configure $X”, because it is all recorded in one place and done automatically when you get a new machine or update or whatever. It’s GNU Stow on steroids, for your entire system.

There are a lot of downsides for sure as well (mostly the learning curve, and having to fix the buggy bullshit in some software which only runs well in FHS), but if you are a software developer (or adjacent) and like Linux, NixOS is still awesome.

For context I’ve been using aerc as my email client for a while now, and was looking for something similar for calendars/tasks myself

I’ve tried:

• calcurse: fine but clunky, also a bit difficult to set up. The most mature option and probably the best one available, but I just couldn’t get used to the interface
• calcure: similarly clunky interface, glitchy/blinking rendering to the point of being headache-inducing, lacking features (couldn’t figure out how to look at all event attributes?)
• khal: limited in features (compared to calcurse) and slow when there are a lot of events (even when it’s only 2-3 per day), also there are some rendering bugs sometimes. Probably the most intuitive and clean interface of all, and good scripting opportunities.
• gcalcli: only Google Calendar (I also need support for arbitrary CalDAV), didn’t investigate further
• plann: no TUI as such, just CLI

A couple weeks ago I’ve decided to start writing my own. It’s still very much a hacky WIP but I’ll update in this thread if I ever decide to publish it. In the meantime, I hope one of the above works for you!

To be fair, systemd also fixed a bunch of issues (by making the boot sequence declarative and also consolidating a bunch of previously disparate services into a cohesive ecosystem); it also introduced new ones which are now difficult to fix due to compatibility. I still prefer it.

The article is clearly mostly manipulative bullshit. The arguments about “incompatibilities” between uutils and coreutils being used as an “extend” strategy is just bonkers, the point of uutils is to be a 1-to-1 compatible toolset, and there’s no reason to doubt the developer’s intention there. Even if they do introduce some extra features, most software projects that actually matter will not be using them, because compatibility with coreutils will remain important for decades to come.

The kernel of truth hiding in there is that Rust’s “preferred” licensing under MIT/Apache is indeed a problem, and it should have been GPL (or at least MPL) everywhere from the beginning, especially for libraries. This is probably the worst aspect of Rust indeed, but not enough to outweigh all the awesome technical parts of it.

helix . modal text editor similar to vim, but with less configuration required

Not only less configuration required, but also semantic navigation (jump around the AST directly with simple keybindings). I can’t use a code editor without it now.

OMG how did I not know this… It just might be time to switch to nushell/elvish.

What did you contribute to italian trains running on time?

Reading that email exchange alone, he’s clearly a right-wing nut at least. This needs to be called out at every mention of him, especially when he begs for money.

Thanks for confirming.

Isn’t this guy a right-wing nut/borderline fascist?

I agree with your overall point, that having a single consistent functional language for package descriptions and build scripts is a great thing, and that bash is awful, but your reasoning is somewhat flawed. The main drawbacks of bash are somewhat rectified in Nix because bash is very much contained/sandboxed, which prevents arbitrary damage to the system, and there are some nice defaults in stdenv too.

The Guile version supports a more powerful functionality, which is that evaluation of a package can have several extra results (called outputs). It is over a year that I read about that in the Guix documentation and yet I recognize it immediately.

Nix also supports multiple outputs (in fact this is where the concept of outputs in Guix came from)

the code tells me that it is removing examples.

You could also do that with Nix in an easier and more declarative fashion, either by adding a comment, or by doing this:

postInstallPhases = [ "removeExamplesPhase" ];
removeExamplesPhase = ''
  rm -f "$out"/lib/{basic-server,helloworld,postcollector}
'';

Scheme has much safer and more robust string handling. The code will not do harmful things if a file name contains white space or happens to be equal to ‘echo a; rm -rf /etc/*’.

Bash is just two double quotes away from doing this too. See code above for an example

Scheme strings handle Unicode well

Bash also handles Unicode well

If there is an error, it will not be silently ignored as is the norm in shell scripts which are not written by experts, but will throw it.

Nixpkgs stdenv sets set -eu which has a similar effect. If that code fails, the entire build will fail too.

the code has less redundancy. For example, the bash version mentions three times the subfolder “lib”, the Guile version only once. This makes it easier to refactor the code later.

This is also really quite easy to rectify in bash, see code above.

Bash code should definitely be

rm -f "$out"/lib/{basic-server,helloworld,postcollector}

Well, Nix language is also full of hacks, idiosyncrasies and stupid decisions. I say that as someone who’s writing it “professionally”, i.e. as part of my job. Scheme is way less “unexpected”. But there are other parts of Guix which are pretty weird or just bad, like the “channels”/“pins” management situation.

Yep. I feel like Guix is surprisingly awesome and polished in a couple places, but mostly it’s a very DIY distro, much more so than even NixOS.

One aspect of Guix I found to be really fascinating: That there is basically no conceptual difference between defining a package as a private build script, and using a package as part of the system.

This is true for Nix as well.

The two main advantages of Guix are the language (which is well-known and comes with lots of good tooling and other support) and the package bootstrapping.

There’s nothing technically preventing using TPM without secure boot. This is a limitation imposed by OEMs. In fact I have a separate hardware encryption key that I encrypt my (laptop) drive with, and even I don’t (can’t) know the private key. I only know the pin that is needed to unlock it. If motherboard OEMs implemented something like this on the motherboard, with the ability to decrypt the bootloader partition before booting into it, this would solve everything.

It has already happened a few times with other repos. Although AUR is especially susceptible because there’s no vetting at all, it’s a free-for-all that everyone can publish to within a few clicks. This will for sure happen again within a couple months, but better hidden the next time.

Secure Boot is a really contrived and, frankly, bad defense against an attack that is extremely difficult to execute in reality and does not happen often (are there any examples of a bootloader replacement against a home desktop in the wild?).

An actually good solution would be firmware support for LUKS-style FDE (with a password-encrypted key which then encrypts the rest of the disk), so that your bootloader is encrypted with the rest of your system and impossible to substitute without erasing the rest of the disk, until you enter the password. This way there’s no need for key enrolment into firmware, and firmware manufacturers don’t have to just trust MS. (the firmware of course needs to be protected too, by signing it with the manufacturer’s key; if you flash something unsigned, a warning pops up Android-style before every boot).

If you are hiding something from the state (like your sexual orientation or something), your energy is much better spent encrypting your communications online and keeping your identities anonymous. If you are already suspicious enough to try and pull a bootloader replacement attack on you, any authoritarian state which would do that in the first place will just throw you in jail and fabricate evidence as needed.

This should also be quite useful for plasma-mobile :)