Atemu

Swap is rarely hit, especially if set up with zram.

This is not a good thing btw. Any unused anonymous page takes up space that could instead be used for file-backed pages that make your system faster.

Multiple swap tiers beyond zram/zswap

Swap is not tiered storage!

Priorities control order of preference, not tiers. If you run out of space on a higher priority, it will not move that swap’s data to a lower priority swap. It will keep all of it exactly where it is and new data will hit the lower prio swap instead, no matter how hot it is.

Intel Optane

Cool tech but it’s dead and was quite niche even when it was alive.

zram write-back device

Not a thing you actually want to use for swap. It’s not an automatic writeback that is integrated into the Linux MM in any way. (Probably has some use-case for non-swap zram purposes though.)

Large HDD swap partition used as a third tier swap disk

This makes no sense at all unless you are extremely space-constrained on the NVMe and absolutely must not OOM – even if progress stalls to an absolute crawl.

swapped pages can be moved around by the user (or a tool), by turning swap devices off and on.

This is neither feasible nor desirable. You don’t have enough granularity to do anything useful by doing so.
Even if you had, it’d work against the MM because it resurrects pages as “hot” that have been cold for a long time.
In any situation where swap is important, making the kernel think cold pages are hot is the very last thing you want.

I too wish it were but tiered/transcedental memory is not a thing in Linux and these hacks do not change that fact; they merely look similar if you don’t look close enough.

I cannot think of a single use-case where this would be preferable to a decently sized physical swap with zswap XOR just zram swap (if physical swap is infeasible).

This testing compares apples to oranges. Differently sized swap and quite obviously different workloads. Given how very much compress ratios depend on the specific data that is compressed, this experimental setup cannot produce valid results.

This is exacerbated by your swap being full. Zswap is more of a cache in front of your actual swap; it requires physical swap to function. If the physical swap is full, it cannot receive more data! Zswap not doing very much when the swap is full is totally expected behaviour because it simply doesn’t. The solution to that is to size your swap sensibly. (Admittedly, this does not appear to be documented clearly.)

zswap uses the exact same allocator as zram these days (zsmalloc). It’d be very surprising if it had different space efficiency characteristics. It’s not impossible (could be a bug) but claiming so would require quite certain evidence IMHO.

RE: LRU inversion: the problem with not caring about it is that it’s not a visible problem until it very suddenly is. Your system will not gradually degrade but very suddenly and unpredictably hit a wall that it cannot get itself over.

There’s https://gitlab.com/android_translation_layer/android_translation_layer which can already run BeatSaber apparently.

I think games specifically might be easier than most other apps as they are probably often little more than a 2D canvas displaying a regular Linux app with quite limited use of android-specific APIs.

Inconsistent time before sleep is likely the kernel waiting for IO to sync to disk.

Not going to sleep at all implies a serious issue that prevented the kernel from doing so. Check your logs!

Suspend reliability greatly depends on the firmware of your specific device as it controls the wakeup.

On my Framework 16 for instance, it is very reliable these days. I can’t remember the last time it woke up unexpectedly and I’m not sure whether it happened even once since the firmware update that fixed a major oversight in keyboard wakeup (waking when a key was pressed through a closed lid).

In Hyprland, how it works is that you define the screen lock command (e.g. swaylock) in hypridle and that gets wired into logind somehow such that you can loginctl lock-session.

I then (also in hypridle) define a before sleep hook that locks the session.

I believe the proper way to do this would be to run your lockscreen as a systemd unit that is WantedBy and Before suspend.target. This would in theory take care of making it idempotent and reliably show the lockscreen before initiating suspend.
A friend of mine has this sort of setup and, while it is reliable, the lockscreen is still racy and sometimes only triggers after suspend. Might be the lockscreen unit not signalling its readiness to systemd properly though.

Thank you!

I’ve found the Seedstudio thing after posting this too and it looks like the thing I’d be looking for!

What’s your experience w.r.t. coverage?
Obviously that highly depends on where exactly you are – you certainly aren’t going to have coverage in the outback – but I’m mostly concerned with places where people actually go and would take my bag/laptop/bicycle to. 'Stralia is going to generally be quite different from Germany too of course but it would be a good reference point from which I could extrapolate.

Are there any (ideally waterproof) compact devices with long battery life (months~years)?

On the website I only found a long list of supported devices with brand name search and protocol type. grep showed no LoRaWAN devices though?

My use-case is theft tracking. I only need the device to be able to locate itself after a theft actually occurred and I request it remotely. (Perhaps also periodically with very low frequency.)

Because the only way to have a functioning NixOS system is to have it be reproducible. That’s the only way it works; Nix is reproducible by design.

The ability to reproduce a system implies the ability to replicate it.

In this comparison, the devil is in the detail.

With Ansible, you have an initial condition onto which you add additional state through automatically executed steps dictated by you until you (hopefully) arrive at a target state. This all happens through modification of one set of state; each step receives the state of the previous step, modifies it and passes the entire state onto the next step. The end result is not only dependant on your declared steps but also the initial state. A failure in any step means you’re left in an inconsistent state which is especially critical for the case of updating an existing state which is the most common thing to do to a Linux system.

In NixOS, you describe the desired target state and the NixOS modules then turn that description into compartmentalised bits of independent state. These are then cheaply and generically combined into a “bundle”; wrapping them into one big “generation” that contains your entire target state.
Your running system state is not modified at any point in this process. It is fully independent, no matter what the desired system is supposed to be. It is so independent in fact that you could do this “realisation” of the NixOS system on any other system of the same platform that has Nix installed without any information about the state of the system it’s intended to be deployed on.
This “bundle” then contains a generic script which applies the pre-generated state to your actual system in a step that is as close to atomic as possible.
A good example for this are packages in your PATH. Rather than sequentially placing the binaries into the /usr/bin/ directory as a package manager would when instructed by ansible to install a set of packages, NixOS merely replaces the bin symlink with one that points at an entirely new pre-generated directory which contains the desired packages’ binaries (well, symlinks to them for efficiency). There cannot possibly be an in-between state where only some of the binaries exist; it’s all or nothing. (This concept applies to all parts that make up a Linux system of course, not just binaries in the PATH. I just chose that as an easy to understand example.)
By this property, your root filesystem no longer contains any operating system configuration state. You could wipe it and NixOS would not care. In fact, many NixOS users do that on every boot or even use a tmpfs for /.

(Immutability is a property that NixOS gains almost by accident; that’s not its primary goal.)

Cucumber/Gherkin also has translated keywords (even Emoji… smh) but there it actually makes sense because you actually write it in natural language.

127.0.0.1

microG also doesn’t avoid Google as it is still running proprietary Google code

What proprietary code?

has more privacy/security weaknesses

Source?

Gotta love them tree NFTs.