hallettj

Ahhh, for some reason I had it in my head that rebooting cleared the syslog

To see logs from only the previous boot run,

journalctl -b -1

Also the Social Security Administration, despite being a huge operation, runs with less than 1% overhead. And they get those checks out month after month. Medicare’s overhead is under 2%, compared to an average of 12% for private insurance, and polls seem to show people are more satisfied with Medicare than with private insurance.

I know the complaint that government is ineffective and inefficient is a classic - but it makes me wonder what programs that refers to? Maybe something in the Defense Department?

Oh yeah, I should clarify that - and I might have overstated the issue.

When you roll back, either by selecting an old entry in the boot menu, or using the nixos-rebuild command you do get an exact replica of the packages from the generation you rolled back to regardless of whether you use channels or flakes. So that’s good.

The issue comes up in scenarios like these:

• Something’s not working for you with the latest nixpkgs. You roll back to, and that fixes things. But the next time you run nixos-rebuild switch you get packages from the current channel state again, the one that wasn’t working, and things break again.
• You want to roll back nixpkgs, but keep your latest configuration changes.
• You want to go back to an earlier state by getting the old version of your configuration files instead of using the generation manager. For example if you keep your configuration version-controlled with git, reverting to an earlier commit of your configuration history, and running nixos-rebuild switch

In all cases if you’re using flakes you can roll back nixpkgs by using an older version of the flake.lock file which lets you time-travel nixpkgs independently of changes to other configuration files. With channels you can’t manage the nixpkgs revision with your configuration files. You have to go through some manual steps to reset the channel to the nixpkgs commit you want. It can get more difficult if the commit you want was garbage collected from your local system in the meantime. See https://discourse.nixos.org/t/how-to-roll-back-channel-to-currently-active-version/43161

In my experience upstream nixpkgs rarely break things, and reverting to an earlier nixpkgs revision is not the best answer. But every once something happens, like a failure in hydra means some package isn’t in the binary cache, and it’s too much for me to build locally (this happened with Electron a few weeks ago), so I can’t use the latest packages until hydra catches up; or there’s some configuration update I need to make for the latest packages, and I don’t have time to work on that for a bit.

I think there are arguments for NixOS for a casual user despite the learning curve reputation. But there are also downsides to consider.

The pros:

• There is a good, user-friendly installer that makes it easy to get a working system
• From what I can see setting up KDE is pretty easy - there are configs online that you can paste into configuration.nix without modification
• NixOS is good for gaming with proprietary drivers and Steam - again it’s a matter of pasting a few lines of configuration
• Like with other distros it’s easy to recover if something breaks
• Unlike with other immutable distros you get a lot of options for tinkering with your system, and experimenting. You can dip your toes into the advanced stuff, going from casual user to Linux expert at your own pace, with the safety line of being able to roll back changes at any time.
• If you stick to the basics you can have a very stable, very update-to-date system without much difficulty.

The cons:

• To get the full safety of rolling back a previous point in time you need to ditch channels, and instead use pinned nixpkgs revisions. The best way to do that is probably using flakes - but whatever strategy you use you need to depart from the setup the installer gives you, and learn enough to remake your configuration.
• You’ll find contradictory instructions depending whether they’re written for use of channels or flakes.
• Going beyond the basics of installing packages, and using premade NixOS modules gets you into the infamous learning curve. For example I’m guessing that managing kwin scripts declaratively in Nix config might be an adventure. But managing them by hand the way you do in Fedora might be the same. (I haven’t tried this, so I’m not sure.)
• There is some stuff you have to know, like if you want to run binaries that weren’t built for Nix you want to set up nix-ld first.
• If you’re building software you have to learn to do things the Nix way because of the lack of FHS. That’s great for Nix fans like me, but frustrating for some.
• There is no graphical software center, nor automatic updates. You have to use the workflow of installing stuff by editing your config file, and get used to using search.nixos.org to find stuff. This is a pro from the perspective of having a stable system that can be rolled back to earlier states, but might feel less user friendly than a GUI workflow.

Even if you set up flatpak (which is easy to set up tbf) you’re probably going to be managing flatpaks using the CLI.

It would be easier for me to recommend NixOS if the installer set up a flake configuration with more niceties pre-installed, like nix-ld. The next best thing would be a de facto standard flake starter configuration for people to copy. But like I said, I think there is a case.