but I think it will take a lot of time to compile big packages in Gentoo.

Probably yeah.

And if I don’t compile the largest parts of the system by myself with appropriate flags for efficiency, Gentoo doesn’t make that much sense compared to Arch or Artix.

I don’t know if that’s the case. Immolo, AKA the Gentoo guy on YT, tried compiling Firefox for speed. But the results weren’t what you’d expect. Granted, efficiency =/= speed. So YMMV.

I have 5.7GB of RAM (the rest is reserved by system and GPU)

That is plenty. Sure, it’s not comfortable or anything. But it’s fine for strictly running your OS without delving into stuff like VMs, high-end gaming etc. Perhaps you might even pick/prefer tools/software that are known to be less bloat~y.

who still used a lot of binaries because of long compilation and the inefficiency (hah) of portage.

So, if what you desire is simply “Do what I want as fast as possible.”, then I agree that compiling is a no-go. But, the control gained on Gentoo by virtue of the extensive options that are provided through compilation is no joke.

Hence, I got to ask, what is it that you ultimately desire?

Btw, FWIW, if speed and/or efficiency is more important than control. And, if control is (mostly) only desired to benefit speed and/or efficiency, then perhaps the likes of Alpine and Void should also be considered for the long-term.

Atomic desktops enforce immutability, the core system is literally a ROM almost like stock Android.

Thank you for quenching my curiosity! The analogy to Android makes me worry that you might be associating stuff with atomic distros that are not (inherently) tied to them. Which, to be fair, happens a LOT, unfortunately…

secureblue imposes slightly less restrictions.

In short, as secureblue is ultimately derived from Fedora Atomic, it follows (most of) its conventions. Though, it’s most similar to uBlue in particular due to relying on their images initially. As such, all methods of installing software on say Bazzite apply to secureblue as well. Note, however, that secureblue prefers to keep it leaner for the sake of both security and simplicity. Finally, like Fedora Atomic and uBlue, it also allows you to customize the guts of your OS by creating/configuring an image.

However, AFAIK it is not lightweight enough for my setup. Pretty same as Gentoo, I guess.

If you can run KDE Plasma, then you should be able to run both NixOS and Gentoo.

my learning curve will be fairly steep

😅. Honestly, I think it’s exaggerated. But I’m only ankles deep in NixOS…

it lacks some cons of Atomic desktops

What would those cons be 😜? Btw, I’m fully aware of the arguments laid down by those averse to the idea of atomic distros. I’m mostly interested in the influence they have on a newer user. So, please, just reveal what you had in mind without searching up the cons 😉.

But some people in this thread are downvoting me for this. It feels like if I were hated for trying to delete Edge from Windows.

The KDE Plasma circlejerk is real 🤣.

I’m more focused on resource usage reasonability, efficiency and control.

And my aspiration to decide and control what happens in my PC

One day I’ll just come up with using DIY distros like Arch and Gentoo and building custom kernels, so I’ll be responsible for any kind of bloat there.

Or perhaps NixOS. It allows for congruent system management rather trivially. Add to that the impermanence module, and the amount of control you’ll have on your machine is simply unmatched.

It comes at a cost, though. NixOS is the most complex distro out of the reasonably popular ones^[1]. But, honestly, it isn’t that bad. If you’ve got experience with programming, you can dive right in (within a VM). And otherwise, after you’ve become comfortable with Arch or Gentoo, then NixOS becomes a logical step-up.

But the day hasn’t come yet, I’m still new to Linux.

Welcome 😊! I await to see what you’ll bring to the table 😜.

OP, even if I personally don’t entirely agree with your sentiment. I am fully aware it is a legit one and I’m actually even sympathetic to the idea.

As others have already provided solutions to your problem, I just wanted to share https://suckless.org/philosophy/ with you. I’m pretty sure this is either were you are right now, or the logical conclusion of your trajectory.

Have you ever met something else in Linux or it’s ecosystem, that appeared to be bloatware to you (and how did you disable it)?

Perhaps through sheer luck^[1] the Linux systems I’ve used have always been pretty minimal.

As bloat often comes with additional attack surface, the security-sensitive will be implored to go with minimalism anyways. As such, my current distro of choice; namely secureblue, is actively engaged with debloating the system. Recently, it has even started working on ‘debloating’ the kernel. Like, why should my system autoload parts of the kernel used to drive all sorts of old and niche hardware; like remote controls etc?

Still, there are stuff that I’m not using, but I’m too lazy to hunt them down 😅.

My headcanon is that they wanted to offer a modern middle ground between GNOME and KDE Plasma. Perhaps we might refer to it as “COSMIC before COSMIC” but without:

• being built on Rust,
• Wayland-first design,
• easy and well-thought-out tiling on demand.

Definitely. Though, for completeness’ sake, both rpm-ostree and (even) ostree offered something similar:

• rpm-ostree usroverlay for the former
• ostree admin unlock for the latter

Though, I don’t know if RakuOS’ hacking could leverage either one of the above for the persistent overlay…

Excellent insight, thank you (once again)!

While not much, this is the kind of endorsement I wanted out of this. Even though I was being deliberately horrid at communicating that 😜.

Hehe, that’s very close to my reaction when I first heard about it 😜. I wasn’t able to find any of the technical details either, so I approached them through one of their community channels and they’ve been very patient and helpful. So, IIUC, they leverage bootc usr-overlay. But where bootc usr-overlay is transient, thus making anything installed through dnf go away on every reboot. RakuOS has somehow hacked their way to make it persistent instead. For more details, I’d suggest making contact with them. Perhaps you can retrofit their solution to your own system 😉.

Alright, that was quite illuminating. I suppose I was definitely not grasping the full extent of the extensibility found on Guix. And, perhaps more importantly, how it’s a defining feature of Guix. Thank you; I appreciate it.

Perhaps I’m being too romantic, but just like how rde users were the first to catch a glimpse of guix home, so too it feels that today’s rde users are catching a glimpse of features that will eventually land on Guix proper.

Alright, that has been a bit more elucidating. Thank you!

I’m literally a newb to Guix, so please forgive me for my ignorance.

But while using (parts of) rde by regarding it as a channel is found within its documentation, I don’t think it’s the full picture. Like, rde is also a distro, at least by the admission of its creator. The same can not be said about nonguix. So, to be frank, I don’t think it’s just another Guix channel.

Having said that, I am still very new to all of this. So, if I’m incorrect and/or my understanding is lacking, then please feel free to correct/educate me on this.

This isnt a distro

I don’t think you know exactly what constitutes an entire distribution.

Then what is? And which authorities endorses that view? Or…, is it perhaps possible to arrive at that definition by (logical) necessity? If no such authorities exist and if it doesn’t follow by necessity, then how is your definition anything but arbitrary?

Unsure whether it fits with the rest, but I’d argue it is an innovative and very compelling ‘standard’ that is competing with everything else mentioned in this thread.

So, the basic idea is as follows: if it is so difficult to deal with the loss of the main package manager found on the mutable/traditional variant, why don’t we pursuit ways to not lose it in the first place and thus try to make it coexist (somehow) with the atomic model. Enter RakuOS’s hybrid design in which everything installed through dnf is overlayed persistently over the bootc-managed base system.

Thank you very much for the detailed and well-sourced write-up!

It has been my pleasure 😊. I really appreciate your kind words 🤍.

It kind of proves OP’s point though: distros do come with a lot of idiosyncrasies of “how things are done around these parts”.

Absolutely. But, I think it’s nuanced and the lines are becoming increasingly blurry. If something based on Fedora can become something based on Arch (and vice-versa), if almost any distro has multiple releases/channels/braches, if software for/from any distro can be installed on every other distro, then… at what point is it truly “around these parts” rather than “with those not-hardcoded system specifications”? Kinda like how DEs can be (un)installed, and how those come with implications on how some stuff is done…

FWIW, uBlue has been brewing for almost three years now for their CLI stuff: see this issue tracker and this blogpost from Bluefin’s creator.

The distrobox workflow overall has mostly been superseded by better alternatives^[1]. Though, for completeness’ sake, openSUSE’s atomic offering continues to heavily rely on Distrobox. But, in their defense, I think their atomic offerings are simply better^[2] suited for it.

Not the one you asked, but I think the answer lies in the bold part:

most of these will make new users unhappy or even question their sanity.

For example, I can’t imagine any of the uBlue projects causing major difficulties. Though, edge cases do exist; adding kernel mods can still be a bitch, even if there are efforts to improve this.

I just thought that the phrase “the distro you are using doesn’t matter” is used to combat the analysis paralysis that many new users experience.

And -to be frank- while Ubuntu and NixOS don’t even remotely resemble each other, I can’t be the only one that feels that most traditional distros do feel kinda same~y.

Is there something locked down like Bazzite but with long term LTS release cycle?

The only high confidence projects I know of are:

• Bluefin LTS
• Endless OS, also see its documentation

There’s also stuff like HeliumOS, stillOS and probably other images based (in)directly on RHEL Image Mode.

I suppose because it simply is 😅.

To be honest, I’d say they’re being pretty generous in this case. The category for “Advanced Users” also includes the likes of Debian, RHEL(-clones) and SLE, none of which throw you right into a TUI; unlike Arch* 😅.

Furthermore, while archinstall has done a tremendous job at streamlining the process, the lazy noob that wants to rawdog it, will probably give up on their attempt. Contrast that to the installers of every other non-“Experts” distro, which by virtue of its non-archaic UI would have fulfilled its purpose.

And the troubles go well beyond initialization:

• Rolling release cadence with minimal testing amounts to plenty of breakage. To put into perspective, even if it’s not that bad in practice; Arch will break more often than (almost) any other distro on that list.
• As the previous point is known to cause plenty of agony, users are implored to stick to these instructions found on the excellent ArchWiki to combat that. While I’m sure Arch users are thankful for the instructions, it’s crazy that it is even required. Note that it’s expected that your Arch system is current and up-to-date. So you have to go through that routine at least once a week.
• The amount of packages in its own repositories is relatively slim, all of the other big-shot distros have larger repos. As such, the community relies a lot on other repositories; use of the AUR (in particular) is very prominent. But, as recent news has shown, you shouldn’t blindly trust that. Instead, you ought to look into the PKGBUILDs to ensure it doesn’t do anything shady. While this can make installing software more painful than it has any right to be, updates often involve changes in the PKGBUILD(s). In which case, you’re expected to go over it once again 😅…

There’s more to it than that, but I hope the case has been made pretty clear. With Arch, it’s (almost) as if you’re babysitting the system to ensure it doesn’t shit itself. By contrast; distros like Debian, Fedora and/or openSUSE mostly just work.

In case you wonder why people put up with all that shit, Arch does occupy a (relatively) unique spot if you want the following combined:

• Latest and greatest.
• Very big (user) repository.
• Lean. It comes with almost no defaults. With Arch, there’s no such thing as debloating or anything.

Hence, if you’re looking to build your very own system from (close to) scratch to a highly customized setup that does exactly what you want…, then Arch it is.