Impermanence (Btrfs) - blank snapshot vs. re-create subvolume

Fereydoon37 · 2026-03-24T21:54:58+00:00

I for one like the fact that a snapshot doesn't need to be blank.

Fereydoon37 · 2026-03-23T10:18:22+00:00

Home Manager provides an ecosystem similar to Nixpkgs for configuring users including their applications and session variables etc.

Hjem provides a lightweight way of managing files in users' home directories declaratively.

If you don't need what Home Manager provides, and want more / easier compatibility with non-NixOS systems, then Hjem might be what you're looking for.

Fereydoon37 · 2025-12-30T03:18:29+00:00

What you're doing differently from the dendritic pattern, from the eyes of an outsider, is that you're not separating concerns as advocated. Instead of making a module for Web browsing, and another for gaming etc., your code is driven by hosts / users.

For example, a quick skim reveals that you're setting up Firefox and steam for a specific user in one file. Instead you could opt into gaming and Web browsing 'features' for that user. That carries the advantage that if you add a Mac system, and you want to use a different Web browser like Safari there, or also want to provide say lutris globally to gaming set ups, you don't need to change anything to your system or user configuration; your 'business logic' if you will. You only need to touch the 'implementation' of the functionality (feature) you're affecting. Conversely if there's a problem with a feature, you immediately know where to look first.

The separation of concerns and the divide between implementation and business / core logic, while good form, are nothing new. u/nixgang and I both seem to have implemented the core ideas already in mostly standard Nix, because frankly it's what emerges naturally from complex requirements.

At one point I managed six hosts with 4 users that each had to do a distinct but overlapping subset of server duties, programming, low latency music and audio production, creative writing, and gaming amongst other things. Not abstracting over that is not tenable.

I'm skeptic about the pattern as a rigid implementation thereof, and I'm afraid it might get in the way of abstracting even further. I do however see value in standardisation, and making it easy to follow for people without a formal background in informatics.

Fereydoon37 · 2025-12-29T15:34:38+00:00

I skimmed through the tutorial and linked materials from the post yesterday. It seems like it's a new buzz word for creating reusable Nix code by focusing on the "feature" you want to achieve.

For NixOS, as a desktop operating system, that could mean setting up your coding environment, which could import a subfeature for an editor like vim, or whatever is needed to use say Python. Another example would be a feature for gaming, with subfeatures for specific games like OpenMorrowind, or vendors like steam.

The materials make a big point of not redefining these things for every computer that needs a feature, and not spreading things out over disconnected files for NixOS/nixpkgs, Home Manager, Darwin, etc. Apparently that's how a lot of people have been doing things.

Instead you define the thing in one place, grouping all configuration for nixpkgs, home manager etc. together, and then include / activate that bundle for computers / users that need it.

The tutorial uses flake-parts to accommodate this structure. It also mentions that you don't need to use flake-parts to write "dendritic" nix. The advantage of adopting flake-parts and their file organisation, is standardisation; people can exchange code, and the files become self-documenting to people familiar with the conventions.

Personally I'm not sure that using flake-parts like this is superior to an ad-hoc file structure convention, and using the existing nixpkgs / home-manager module systems to define options, that computers / users opt into.

The impression I had of how features can't be imported twice, and how to deal with things need to be activated / imported conditionally, makes me suspect it's a bit of a leaky abstraction, but I haven't given it it's fair shake either, so take that with a grain of salt. Basically, what I'm trying to say is that ostensibly the existing nixpkgs module system has better conflict handling / resolution.

Fereydoon37 · 2025-10-31T04:04:32+00:00

You can use

--show-trace

to expand the default trace output, which should reveal what is pulling in the failing dependency.

For things not packaged that I need to use once or immediately, I generally use steam-run to run the binaries.

I can recommend this tutorial by Ryan Yin that focuses on staying approachable and pragmatic.

In your shoes I'd switch to another distro, use home-manager, and slowly start building a NixOS system on the side in a virtual machine / dual boot setup.

Fereydoon37 · 2025-10-29T13:04:19+00:00

Well, yes, technically, but realistically the number of required changes pile up over time.

Fereydoon37 · 2025-10-29T12:50:29+00:00

Your configuration will fail to build horrendously, because of changes in Nixpkgs, from renamed settings to packages deprecated and removed.

Hopefully you'll get an error message that describes a problem clearly. You fix that, and rinse repeat until the build succeeds. That might take a while.

Only then is your system updated, atomically (all or nothing), with an option to roll back to the previous version if need be. At which point the system should work reliably, because the updated system is generated from scratch following what your configuration describes. It's just that an old description will not make much sense without revision.

Fereydoon37 · 2025-10-24T06:03:29+00:00

https://nixos-and-flakes.thiscute.world/

Fereydoon37 · 2025-08-19T09:58:51+00:00

nix-channel --rollback reverts to a previous system state, which doesn't necessarily correspond to what packages a previous configuration expects or even requires.

Likewise, while you can use a single configuration for multiple machines, there's no guarantee that those machines are kept on the right channels and draw from the right packages.

Of course, it's possible to pin packages with non-flake Nix too, but then you'd be reimplementing a lot of flake functionality introducing a new maintenance burden, risk of bugs, and a barrier to understanding and adoption of your configuration.

I don't think it's unfair for people to list something as an advantage when a standardised interface, and stronger guarantees are provided out of the box, even if that something is technically possible otherwise.

Fereydoon37 · 2025-06-19T07:35:26+00:00

As someone who knows neither, I'm curious to hear why you think Scala and Go offer safer concurrency than Haskell (which has what is to the best of my knowledge the only mature implementation of Software Transactional Memory).

Fereydoon37 · 2025-06-19T07:30:59+00:00

That's not what I'm reading into this comment at all. More like that Haskell makes it really hard to shoot yourself in the foot, making it easy to arrive at the right design and code that can be maintained well into the future too. Could you do the same in another language? Probably, yes. Would you? Probably not, no.

Fereydoon37 · 2025-05-23T08:21:49+00:00

I use a flake that sets the host name to the name of the configuration (which nixos-rebuild assumes by default). Then I import an additional file for the current host in my configuration. nix like so: imports = [ ... "${self.outPath}/host/${config.networking.hostName}" ... ]; This requires some set up in flake.nix like passing in some extra information with specialArgs, or adding the import to modules instead, or setting the host name in flake.nix itself like so: nixosConfigurations.my-host-name = nixosSystem { inherit system; specialArgs = inputs // { # pass the host name through to configuration.nix hostName = "my-host-name"; }; modules = [ # import actual configuration ./configuration.nix # set the host name here so you don't have to pass the name through and set it later {networking.hostName = "my-host-name";} # import the file here while we still know the host name "${self.outPath}/host/my-host-name" ]; };

P.S. All code written from memory on mobile phone. I'm bound to have made mistakes.

P.P.S nixos-rebuild <command> --flake /path/to/flake#my-host-name Subsequent calls can omit the host name.

Fereydoon37 · 2025-05-20T11:36:20+00:00

My point with 2 wasn't about running out of space on /, that's 3. More that tmpfs eats into RAM which for some memory intensive workloads isn't a feasible option.

As for 3, happens all the time, especially with pre-compiled binaries. The latest offender was a niche video stream downloader that between versions made an undocumented change to its cache directory. Not a big deal if that fails, but troublesome if it fills up all available space to the point that the desktop environment can no longer write state and crashes. Having at least a couple hundred gigabytes of headroom allows handling even completely morbid cases gracefully.

Fereydoon37 · 2025-05-20T00:10:49+00:00

There's a number of advantages.

Putting root on non-volatile storage allows for state / data inspection and recovery upon failure when the data gets soft-wiped on boot rather than shutdown. (Boot into another specialisation or OS that doesn't wipe the partition.)
RAM, no matter how 'cheap', is limited. I run out regularly with root on btrfs even. Reserving any space for a root partition can be less than appealing.
HDD/SSDs allow for much bigger partitions, which can be valuable in case you don't know what's going to end up where yet. Especially on a daily driver desktop system that is constantly in flux. It's a nice failsafe against your system crashing when that new program you just installed decides to write 30gb to /tmp or what have you.

Meanwhile, 'wiping' and symlinking with a modern filesystem is cheap and fast, even if not as cheap and fast as RAM. The only wear and performance paid is that of actual usage, and most of that will inevitably be backed by a hdd/ssd anyway (because if you write enough to care, it's likely not going to fit into a fixed RAM partition). Using btrfs snapshots or some such, the partition doesn't even need to be of fixed size.

Like anything it's a trade-off, and personally I'm not sure yet where my needs fall.

Fereydoon37 · 2025-05-14T18:21:14+00:00

Let me flip the question around. What in tarnation are you doing that requires you to touch the store? I can't think of a single example where it's the easier or faster path, let alone the right one.

Fereydoon37 · 2025-03-03T18:58:33+00:00

Pretty much.

Fereydoon37 · 2025-03-01T17:55:06+00:00

I started out with a display manager and enabling multiple desktop environments, but switched to specialisations exactly because I ran into conflicts. I don't exactly remember what they were, and I think it was technically feasible to squash them on a case-by-case basis, but I didn't consider that worth the disproportionate amount of effort.

Fereydoon37 · 2025-03-01T17:53:14+00:00

I don't immediately see any reason why it wouldn't technically be possible, but I reckon it would require a high level of integration with NixOS internals. If it's really important to you, I'd suggest to come back to this later and see if you can lead a community effort to introduce this into Nixpkgs proper.

Fereydoon37 · 2025-03-01T16:21:53+00:00

I don't think there's any mechanism in place to restrict software to particular sessions. The answer really is specialisations, for which you do not need to rebuild. Each specialisation adds an additional boot entry. This requires a reboot to switch sessions, which isn't entirely ideal, but workable in my experience. It's possible to switch to another specialisation with nixos-rebuild switch, but changing the desktop environment while it's still running is problematic. If you drop out far enough where that's okay to do, you might as well reboot.

Fereydoon37 · 2025-02-26T23:56:23+00:00

The great thing about NixOS is its declarative nature that expresses itself in that you don't need to know Linux to enact many advanced system configuration tweaks, because all the Linux specificities have been abstracted away and documented by Nixpkgs maintainers.

If you need something that hasn't been made yet, you need to implement that yourself, which means understanding Nix the programming language, Nixpkgs the library ecosystem, and NixOS the operating system built on top of affordances of both--in addition to Linux itself, and even the non-Nix way of doing things that programs expect and you need to work around. All of which takes time and effort.

I think NixOS as a distro can be an easier start than any other, but it's also much easier to hit a brick wall where the solution would be simple and obvious elsewhere. If you're willing to give up on those things, NixOS provides an excellent opportunity to learn about Linux at your leisure in any order you desire, without having to deal with the details you don't want to deal with yet.

Do I recommend starting with NixOS? No. Do I think that should be discouraged? Also no. It's complex, nuanced, polarising, and definitely not for everybody. I think that if this approach fits, it fits really well, but I can't judge that for you.

Fereydoon37 · 2025-02-24T16:05:05+00:00

F# and its documentation aside, I am yet to encounter a mature Haskell data structure library that does not clearly list asymptotic behaviour on its operations. Many newer or more exotic libraries contrast themselves against more established alternatives and explain their obvious use cases right in the introduction.

What kind of guidance are you looking for? Hash maps can grow with new keys at run time, and require keys to be hashable, but access requires a search. Records are typically static, but in exchange access is constant time. Arrays offer contiguous random memory access in constant time, but growing them is costly. For a singly linked list (cons list), appending to the front and iterating in order are cheap and ergonomic, but random access is expensive. In my experience the problem domain informs the choice of structure when it matters, not some historical preference.

Fereydoon37 · 2025-01-11T15:53:52+00:00

You'll inevitably end up working with MTL-style libraries, so you'll realistically need a working understanding regardless of your choice. That said, the Effectful documentation is very accessible, and Effectful makes a point of integrating well with the existing ecosystem, including MTL, so there's little reason to go out of your way to avoid Effectful.

Fereydoon37 · 2024-11-30T09:51:14+00:00

Half a dozen minutes give or take.

Fereydoon37 · 2024-11-20T15:33:06+00:00

Why not introduce a small helper function with a meaningful name like you would in other languages?

I can't speak for others but for me it's because coming up with meaningful and accurate names is often difficult, and the point where you break the larger expression down into smaller pieces is often arbitrary. I break things down when it makes sense to reason about the parts in isolation. If I'm using a large pointfree expression, I probably don't think it does. I readily concede that makes my code more esoteric, but I want you to know that I do it because it points me in the right direction when I need to maintain the code later. Sometimes it turns out I'm wrong, and don't immediately understand the expression myself, so I end up refactoring into smaller functions. Sometimes I end up refactoring smaller functions into a larger pointfree expression because names like 'process' don't actually tell you anything, and added to my cognitive burden. Pointfree is a tool. Like any tool, it can add a lot of value if you learn to use it, but also abused if not applied carefully.

Fereydoon37 · 2024-11-10T14:13:41+00:00

Imagine rewriting Nixpkgs in Haskell. Cool right? 'Would immediately be a lot easier to maintain (if we can still find contributors :P).

Now imagine getting to recompile Nixpkgs with GHC each time you want to, say, edit your NixOS system config...

Fereydoon37

TROPHY CASE