I have not used Nix, so I may not know what I am talking about.

That said, I have been using Chimera Linux which uses the APK package manager. It works by maintaining a single file in /etc/apk/world that specifies all the packages the user wants on the system. This is used to calculate dependencies and install packages. When you “add” and “del” packages, all it is really doing is adding and removing from this list. If you remove a package, it will remove all the dependencies too unless they appear in the “world” file.

If you do not specify a version number for a package, you get the latest. But you can pin versions of you want.

If you copy the world file from one system to another, you get the same set of installed packages.

So, if I use git to backup my world file, maybe a couple of other entries in /etc, and the dot files in my home directory, I have pretty much everything I need to completely recreate my system.

Is it really worth all the extra complexity of Nix?

Well, if you use Wayback, I am not sure you can use Wayland applications. Hoping somebody can confirm or deny this.

I think you effectively would be ditching Wayland though as I do not think you can run Wayland applications.

I am trying to understand the difference between Wayback and running Xwayland in Cage.

I’m Wayback, will I still be able to run Wayland applications? Or am I literally just running an Xserver that uses Wayland for the DDX layer?

Not to correct you but, if people try to search based on your recommendation, it is “The Cathedral and the Bazaar”.

http://www.catb.org/~esr/writings/cathedral-bazaar/

Honestly, not even in this case (especially given the history). Kent has a kernel tree people can pull if they need to. If it is an emergency, point people there.

As somebody that uses this filesystem, I disagree.

If you want to use it as a server, Fedora is annoying because the support lifetimes are so short.

If you want the Fedora / Red Hat experience, consider Alma Linux. Skills wise, it is like using Res Hat Enterprise Linux (RHEL) which is an in-demand skill set.

Reading all the comments (between Kent and Linux), the problem is that the bcachefs dev thinks that his project (the filesystem) is the critically important one and that the Linux kernel needs to bend to his will.

I am a bcachefs user but it is pretty damn obvious to me that the production Linux kernel is more important than an experimental filesystem.

There is no reason that Kent Overstreet needed to do this.

I love bcachefs but I am so angry at him for making this happen.

The only way to fix Xorg is to break org. It requires a redesign.

The Xorg devs chose to do that by starting a separate project. The breakage has been in Wayland, now maturing, while Xorg was left stable. Xlibre wants bring this disruption to the X codebase itself.

The abacus is the only thing real in the picture.

That is 64 bit. Literally any modern distro should run on it.

Debian will not run on Pentium anymore. It is not performance, it is compiler options. You need a i686 (Pentium Pro). This means none of the Debian derivatives will either.

Adelie, Arch32, and T2 all still run on Pentium though I believe.

[edit: sorry, I saw Pentium 75 from the comment above - Celeron M should be fine]

You would be surprised. If you stay text only and use a 32 bit distro, it would run up to date versions of most CLI programs.

Adelie and Arch32 still support Pentium.

Booting to a GUI, there are still a few options. I think Velox would run on that. I bet Xorg with FVWM would too. You are not going to have much left for apps though. However, you could run a couple of terminals.

Adelie Linux (totally modern Linux distro) lists 64 MB as the minimum server memory requirement.

Do you use any of the other XFCE stuff with Niri? Or just the terminal?

MPV is a much lighter video player. Try that.

Punch cards. The “true” PC era.

“Stone” tablets? Luxury. Ours were dried mammoth dung.

Are you running Trinity or KDE?

Not sure why I get so much less unless it is that. Or are you saying you run Trinity 64 bit?

I agree that 32 bit is not often going to be 50% less in practice. Sometimes I think we should be running 64 bit kernels with 32 bit userland.