When people say that linux adds a second life to bad hardware, they don't just mean making 8 gb of ram usable again. They also mean stuff like this, using dying hardware to it's last breath.

Related: https://lorenz.brun.one/dealing-with-bad-ram-on-linux/

You can mark the failing parts of ram as explicitly bad so Linux avoids them, just like with hard drives. Another way to get more lifespan out of this hardware.

I run a single node cluster.

My single node has 256 gb of ram and 24 cores. I do this because, if you want a lot of ram/cores/storage, it is cheaper to get a used "tower server" type device and then upgrade it as you go over time, than it is to buy entirely new devices for every bit of ram you want to add to the cluster.

I like kubernetes because I like configuration as code, gitops, the way it abstracts over components so I can swap components out easily, the way that helm charts are an easier way of orchestrating containers, and a bunch of other things.

Clustering is merely one of many benefits of kubernetes, one that isn't particularly important to me. Although, my opinion on that has changed somewhat recently. Waiting for a reboot is annoying, since I am rebooting the whole thing and I have to wait for each service to go down or come up before the machine reboots properly. But if I was running kubernetes as a virtual machines inside incus with multiple nodes, I could update each node one by one without the whole thing going down. Or, I could snapshot them, allowing me to reboot the host without waiting for kubernetes. But these things are mostly just somewhat nice to have, rather than a core feature I really require.

I recommend taking a look at this page: https://wiki.archlinux.org/title/Dm-crypt/Encrypting_an_entire_system

This is probably what you want: https://wiki.archlinux.org/title/Dm-crypt/Specialties#Encrypted_system_using_a_detached_LUKS_header

Or this: https://wiki.archlinux.org/title/Dm-crypt/Encrypting_an_entire_system#Plain_dm-crypt

Which describes how to do what you want on Archlinux. You will have to find some of the analogous docs for Guix.

Okay, upon careful reading, it looks like the option you linked might not be what you want. What you might need is to tinker with the initramfs and the bootloader (explanation on archwiki here*) to find the key from the USB.

Guix does have options for the initramfs: https://guix.gnu.org/manual/devel/en/guix.html#Initial-RAM-Disk-1

You may also have to configure kernel parameters via the bootloader: https://guix.gnu.org/manual/devel/en/guix.html#Bootloader-Configuration-1 (but I didn't see an option for kernel parameters in there.

There is also this for setting kernel parameters: https://guix.gnu.org/manual/devel/en/guix.html#System-Control-Service , but I suspect sysctl is too slow and will activate too late for your needs.

*You should probably read this page if you are unfamiliar with Linux boot process. It works the same on Guix, it's just configured differently.

Even used stuff is expensive nowadays.

Anyway, you can buy these used refurbished small form factor business PC's.

These things: https://www.servethehome.com/introducing-project-tinyminimicro-home-lab-revolution/

I was recently at a tech conference and I met a guy who was selling 16 gb ram one's for 30 usd, since they had managed to track them down that cheap in bulk somewhere. What happens is that corporations or govt get rid of them due to warranty expiry, so they need to be offloaded somewhere.

You probably won't be able to find them that cheap but it's definitely more affordable than new stuff. It used to be cheaper but I mostly see 200 usd in my searches.

Yes. Nix is fine as long as you do "supported" things. But the moment you step outside of that, it's a nightmare and you have to be or consult an expert.

The lack of gpu acceleration is a dealbraker for making nix a flatpak alternative. And you can get it working but then it breaks the desktop integration unless you do more work and yeah.

This is not true. Flatpak does sign the packages, after the build on their end, similar to what F-droid does.

Flatpak refuses to install unsigned apps by default.

Now, they don't have per developer digital signatures that would ensure that a program is directly from the developer. But those lowkey suck, those are for proprietary software where we can't do reproducible builds to ensure that the build matches the source code.

For proprietary apps, it's more difficult since often the build works by downloading the package, which can be a deb, an rpm, or a targz or etc and extracting it inside flatpak's build process. For example, steam does this.

So you would have to figure out how to make flatpak sign and verify each form of distribution that it is abstracting, in addition to actually getting the developers to sign their stuff.

Yeah. But it's written in java so it's gonna stay working forever.

Were these numbers generated using compsize or a similar tool that asseses deduplication, symlinks, and compression properly?

I get much different numbers than I use one or the other.

gdu:

gdu ~ Use arrow keys to navigate, press ? for help

***
/var/lib/flatpak
***
    2.6 GiB ████████  ▏/runtime
  471.7 MiB █▍        ▏/app
  114.4 MiB ▎         ▏/repo
    9.1 MiB           ▏/appstream
  164.0 KiB           ▏/exports
        0 B           ▏.changed

compsize:

[moonpie@nefertem flatpak]$ sudo compsize -x /var/lib/flatpak
Processed 73225 files, 31115 regular extents (70649 refs), 35977 inline.
Type       Perc     Disk Usage   Uncompressed Referenced
TOTAL       64%      1.9G         2.9G         6.4G
none       100%      1.3G         1.3G         2.6G
zstd        35%      596M         1.6G         3.8G

Only 2 gb's are actually being used, even though some tools might be reporting 6.4 gb.

And this is with these runtimes installed:

Name                                               Application ID                                     Version                               Branch                  Installation
Freedesktop Platform                               org.freedesktop.Platform                           freedesktop-sdk-23.08.34              23.08                   system
Mesa                                               org.freedesktop.Platform.GL.default                25.0.7                                23.08                   system
Mesa (Extra)                                       org.freedesktop.Platform.GL.default                25.0.7                                23.08-extra             system
Mesa                                               org.freedesktop.Platform.GL.default                26.0.5                                25.08                   system
Mesa (Extra)                                       org.freedesktop.Platform.GL.default                26.0.5                                25.08-extra             system
Codecs Extra Extension                             org.freedesktop.Platform.codecs-extra                                                    25.08-extra             system
GNOME Application Platform version 49              org.gnome.Platform                                                                       49                      system
Breeze GTK theme                                   org.gtk.Gtk3theme.Breeze                           6.6.5                                 3.22                    system

So you can get app which weights 4mb with runtime which weight 250 more than app itself.

Except for the fact that the runtime is reused across apps, meaning that another app which uses up that runtime won't be taking up any extra space.

Appimages weight much less but lack sandboxing.

You can sandbox them with something like firejail or bubblewrap.

I hadn’t tried nix but it also lacks sandboxing.

Similar, you can sandbox with bubblewrap. But you gotta write nix code to do it because ofc:

https://github.com/fgaz/nix-bubblewrap , https://github.com/nixpak/nixpak , https://sr.ht/~alexdavid/jail.nix/

I've tried to use them before though, definitely not as easy as flatpak's flatseal sandboxing in comparison. Also, nix apps on non nix distros aren't GPU accelerated.

Yes. Notably, the english version of wikipedia has a page of a list of bread.

The french version of wikipedia does not have that page. Further, many things are classified as bread in the english version of wikipedia, but as pastries in the french version.

I remember having an argument about this and I cited the english pages, and then they pulled up the french page and translated it for me. Lmao.

99% of cybersecurity news is what I call "cyberslop" and probably actively harmful to consume.

The vast majority of it is either so trivial that somebody else handled it, and you don't need to do anything. Like they often overhype a malware that doesn't do any novel techniques to get onto your systems and has already been added to the antivirus database anyways.

Or it's so grand in scale that you can't do anything, like nation states doing nation state things. Interesting yes, but it's ultimately a waste of my time to consume because it's not actionable.

Only a tiny fraction of news is actually actionable. It's usually stuff like cve's or zero days and the like. I just only really pay attention to those and ignore everything else.

Better, is probably to subscribe to an actual vulnerability feed so you don't have to go through the news cycle.

I use nix to get many cli apps (on arch/cachyos), but the flakes and non flakes split makes things very tough, and causes this annoying documentation split. And then certain things can only be done via flakes and vice versa.

I try to limit my use of nix to using home manager to ONLY install packages, but even then there are annoying things.

Like for example, many users may gravitate towards nix-env for installing packages, not understanding that oops, you aren't actually supposed to use nix-env. nix profile install is better and more supported, but it's flakes only. Flakes are off by default, and must explicitly be enabled because they are still "experimental" despite them being extremely popular. The official documentation is often hesitant to touch flakes because of this, so there is this horrific documentation split where a bunch of different unofficial docs cover flakes in varying manners.

Or, another thing is that nix apps on non nix distros have no gpu access/hardware acceleration. I have a home manager config to enable that: https://github.com/moonpiedumplings/home-manager/blob/main/home.nix#L32

And then I couldn't figure out how to make that work on aarch64 (asahi) so I just had to disable it,

But it is something that is insane to make someone learn how to do for just installing programs. But the latter issue doesn't affect nixos.

Anyway, I like nix. I use home manager, but for packages only, and I use it for my development environments.

Maybe. But they, and many others overestimate the amount of size flatpaks take up.

Flatpaks use a "runtime", a shared set of libraries and programs flatpak apps use. With one flatpak app, there is just one runtime. But with 2, 3, 10 flatpak apps, there are still only going to be 1 (to 3) runtimes on the system. This is not the same for something like appimage.

In the blog, they compare the size of deepin calculator across formats. But this is not a fair comparison. A more fair comparison would involve comparing the app size without the runtime, or comparing many apps installed.

In addition to this, if you are on btrfs, further deduplication and compression is done. This (and symlinks) won't show up in many disk and space usage analysis tools. To get a more accurate measure, use compsize instead of traditional tools. It will show you how much transparent compression (when btrfs compresses files but you can stilll access them normally), symlimks and the like are saving space.

Anyway, I am interested in more cross distro package managers though. Flatpak, docker, and nix cover a lot of things but have their annoying edge cases and paper cuts, especially in comparison to snap in some ways for some apps.

Edit: linglong appears to reuse system libraries, which would probably lead to significanr space savings at the cost of portability across distros