I think you can mount an ISO image under your running system and make changes. I found a couple of guides that might be helpful:

How to Mount an ISO File on Linux

Edit and repack .iso bootable image

I haven’t done this before, but I think you can chroot into the mount directory, and run package manager commands in the mounted image to install another package.

Or I have an alternative suggestion that might or might not be easier. I’ve been hearing a lot about immutable/atomic distros, and people designing their own images. You could make your own ublue image, for example, with whatever you want on it.

A promising looking starting point is github:ublue-os/startingpoint. Ignore the “Installation” instructions, and follow the “ISO” instructions instead.

Or I saw recently an announcement of a new way to build atomic images that is supposed to be easier than ever, BlueBuild

LEDs should last for tens of thousands of hours. There may have been a manufacturing defect in OP’s case.

It scrolls smoothly, it doesn’t snap line by line. Although once the scroll animation is complete the final positions of lines and columns do end up aligned to a grid.

Neovim (as opposed to Vim) is not limited to terminal rendering. It’s designed to be a UI-agnostic backend. It happens that the default frontend runs in a terminal.

I realized I made an implicit assumption that I didn’t explain. You can use Nix without NixOS. But the configuration you’re looking at is specifically a NixOS configuration. The shortcuts for setting up nextcloud services are based on the NixOS module system. You could get the same setup with Nix without NixOS, but you’d have to reproduce some of the functionality that is provided out-of-the-box in NixOS. My answer is one way to use the functionality from NixOS without fully installing NixOS.

I think there’s a way that might be easy-ish. In short what the services setting does is to get necessary packages, write configuration files, and install systemd unit files. You can build a NixOS configuration, and symlink or copy the necessary systemd units and configuration files. I think that would work, and would not interfere with other stuff on your system.

NixOS configurations must be built with nixos-rebuild - you can’t use nix-build by itself. You can put your configuration wherever, and run:

$ nixos-rebuild build -I nixos-config=./configuration.nix

That will build everything in paths under /nix/store/ without touching anything else on your system. It will create a symlink in your working directory called result/ with a fully-built, bot not installed, NixOS. If you were running NixOS you would run nixos-rebuild switch to update symlinks to point to all of this stuff. But you’d skip that step.

result/etc/systemd/system/ contains systemd units. There will be a lot of stuff there that you don’t want. You’d need to selectively symlink or copy units from this directory to your /etc/systemd/ tree.

The units use full paths to binaries in /nix/store/ so you don’t need to do anything extra to install software packages.

You might need to symlink or copy configuration files for your services. Those should also be somewhere in result/.

If NixOS and Debian use the same systemd target names your services should run automatically on boot. If not you might have to do some fix-up, or run systemctl commands manually. I think you’d need to run some systemctl commands to start and stop services if you want to update without rebooting.

You can probably do all that symlinking just once if you symlink everything through that result symlink.

Edit: Although, taking a closer look at what services.nextcloud does I see that it does a lot, like initializing databases and creating user accounts if you choose to use a local database. It might be a lot of work to chase down all of the configuration that you would have to copy over. Running NixOS is definitely going to be easier.

I don’t know if it’s your cup of tea, but Neovide provides smooth scrolling at arbitrary refresh rates. (It’s a graphical frontend for Neovim, my IDE of choice.)

Well you’re really feeding my Nix confirmation bias here. I used to use Ansible with my dot files to configure my personal computers to make it easy to get set up on a new machine or server shell account. But it wasn’t great because I would have to remember to update my Ansible config whenever I installed stuff with my OS package manager (and usually I did not remember). Then along came Nix and Home Manager which combined package management and configuration management in exactly the way I wanted. Now my config stays in sync because editing it is how I install stuff.

Nix with either Home Manager or NixOps checks all of the benefits you listed, except arguably using a “known” programming language. What are you waiting for?

AFAIK the best thing you can do to improve your coffee-freezing process is to prevent moisture from getting into the beans when you thaw. If you let it, moisture from the air will condense on the cold beans. So keep the beans in a closed, airtight container until they come to room temperature. (Airtight because water vapor is air.) So yeah, jars are good for this. Or sealed freezer bags should work too.

I haven’t used Krita. But I can tell you that those wrappers are “options” defined by NixOS modules. There is documentation for writing them in the NixOS Manual.

Built-in NixOS options are documented in the Configuration Options Appendix with links to implementations which provide helpful examples when writing your own options.

Well ok, they both use symlinks but in different ways. I think what I was trying to say is that in NixOS it’s symlinks all the way down.

IIUC on Fedora Atomic you have an ostree image, and some directories in the image are actually symlinks to the mutable filesystem on /var. Files that are not symlinks to /var (and that are not inside those symlinked directories), are hard links to files in the ostree object store. (Basically like checked-out files in a git repository?)

On NixOS this is what happens if examine what’s in my path:

$ which curl
/run/current-system/sw/bin/curl

$ ls -l /run | grep current-system
/run/current-system -> /nix/store/p92xzjwwykjj1ak0q6lcq7pr9psjzf6w-nixos-system-yu-23.11.20231231.32f6357

$ ls -l /run/current-system/sw/bin/curl
/run/current-system/sw/bin/curl -> /nix/store/r304lglsa9i2jy5hpbdz48z3j3x2n4a6-curl-8.4.0-bin/bin/curl

If I select a previous configuration when I boot I would get a different symlink target for /run/current-system. And what makes updates atomic is the last step is to switch the /run/current-system symlink which switches over all installed packages at once.

I can temporarily load up the version of curl from NixOS Unstable in a shell and see a different result,

$ nix shell nixpkgs-unstable#curl  # this works because I added nixpkgs-unstable to my flake registry
$ which curl
/nix/store/0mjq6w6cx1k9907vxm0k5pk7pm1ifib3-curl-8.4.0-bin/bin/curl  # note the hash is different

I could have a different version curl installed in my user profile than the one installed system-wide. In that case I’d see this:

$ which curl
/home/jesse/.nix-profile/bin/curl

$ ls -la /home/jesse | grep .nix-profile
.nix-profile -> /nix/var/nix/profiles/per-user/jesse/profile

$ ls -l /nix/var/nix/profiles/per-user/jesse
profile -> profile-133-link
profile-130-link -> /nix/store/ylysfs90018zc9k0p0dg7x6wvzqcq68j-user-environment
profile-131-link -> /nix/store/9hjiznbaii7a8aa36i8zah4c0xcd8w6d-user-environment
profile-132-link -> /nix/store/h4kkw1m5q6zdhr6mlwr26n638vdbbm2c-user-environment
profile-133-link -> /nix/store/jgxhrhqiagvhd6g42d17h4jhfpgxsk3n-user-environment

Basically symlinks upon symlinks everywhere you look. (And environment variables.)

So I guess at the end everything is symlinks on NixOS, and everything is hard links plus a set of mount paths on Fedora Atomic.

If you put an FHS on the actual system you wouldn’t be able to install multiple versions of the same package, updates wouldn’t be atomic - you wouldn’t get the big selling points of Nix.

When science kills the mystery, semantics keeps the debate alive!

To answer your other question, yes there are still single-cell organisms evolving into new species all the time, in the ocean and elsewhere. That includes new multi-cellular species evolving from single cells all the time. But it takes a long time to develop from cell, to clump of slime, to something with legs. So you might not notice the changes if you aren’t super patient.

Or were those separate questions? Are you asking if chickens descended from single-cell organisms? Yes they did. With a lot of steps in between.

For some more detail see https://dev.to/martiliones/how-i-got-linus-torvalds-in-my-contributors-on-github-3k4g

“Atomic” is a catchy descriptor! Atomic distros for the Atomic Age! It could be an umbrella term since NixOS and Guix are atomic, but instead of images and partitions they use symlinks, and patch binaries to use full paths for libraries and programs that they reference. So there are image-based distros, and I guess expression-derived distros which are both atomic.

I haven’t tried image-based distros. This post fills in some gaps for me. Thanks for the write-up!

It’s like Ned Flanders says, “Oh, January 1st! Better get going on those taxes Neddy.”

Although they’re not in the search, they are in the manual so you can find them searching that page. This one is listed as,

security.pam.services..fprintAuth

But it does take some inferences to find this, and to realize that you can put doas in place of ``

I did some digging around in the manual, and I tested this option which seems to work:

security.pam.services.doas.fprintAuth = true;

On my machine that adds this line to /etc/pam.d/doas:

auth sufficient /nix/store/fq4vbhdk8dqywxirg3wb99zidfss7sbi-fprintd-1.94.2/lib/security/pam_fprintd.so # fprintd (order 11400)

Edit: Note that the NixOS option puts in the full path to pam_fprintd.so. That’s necessary because NixOS doesn’t put so files in search paths.

Without doing more research I don’t know how to add arbitrary options to pam files in case you run into something that isn’t mapped to a NixOS option yet. The implementation for the pam options is here; there might be something in there that would work.

There is a bug report with some discussion here: https://github.com/ValveSoftware/steam-for-linux/issues/8076

Here is a source with lots of detail on how carbon emissions compare: https://www.theguardian.com/business/2023/dec/23/do-electric-cars-really-produce-fewer-carbon-emissions-than-petrol-or-diesel-vehicles

The tl;dr is that EVs have lower lifetime emissions. If the relevant grids use low-carbon sources then emissions are far lower. (But not as low as bicycles.)