EchoDelta_9

joined 2 days ago
[–] EchoDelta_9@programming.dev 1 points 48 minutes ago (1 children)

Arch was my first choice

Could you please elaborate on that? Like, how did it become your first choice?

[–] EchoDelta_9@programming.dev 5 points 11 hours ago (2 children)

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?

[–] EchoDelta_9@programming.dev 2 points 16 hours ago

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.

[–] EchoDelta_9@programming.dev 1 points 16 hours ago

Ah okay. Thanks for clarifying! But isn't that a problem with most repositories? I believe Flatpak's verified is one of the few exceptions.

[–] EchoDelta_9@programming.dev 1 points 1 day ago (3 children)

Likely no official packages.

Would you mind explaining what you mean with this? Thanks in advance!

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...

[–] EchoDelta_9@programming.dev 3 points 1 day ago* (last edited 1 day ago) (2 children)

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^[There's sysext with its (WIP) manager, Brew Tap to tap into homebrew casks and some peeps even use coldbrew. And last, but definitely not least, nix support has improved over the years. And if you just want to use dnf, RakuOS' innovative hybrid design allows just that; an image-based core you can't touch (like the other 'immutables'), but dnf works and is applied through a persistent overlay.]. 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^[Fedora's container images are tied to its major release versions. Hence, every 7-13 months you're required to set them up from scratch if you'd like to continue using them 😅. Even if this process can be streamlined, it's IMO very cumbersome regardless. In openSUSE's case, the containers are based on Tumbleweed. Which, has a rolling release cadence. Hence, it was meant to be used indefinitely.] suited for it.

[–] EchoDelta_9@programming.dev 1 points 2 days ago

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.

[–] EchoDelta_9@programming.dev 76 points 2 days ago (2 children)

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.

[–] EchoDelta_9@programming.dev 2 points 2 days ago

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

The only high confidence projects I know of are:

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

[–] EchoDelta_9@programming.dev 1 points 2 days ago

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.

Unless...

  • you enjoy compiling software. In which case, enter Gentoo.
  • you're fine with learning a functional DSL for the sake of setting up your system, in which case, enter NixOS. But that's definitely harder than Arch Linux is.
view more: next ›