this post was submitted on 10 Jan 2024
22 points (92.3% liked)

Linux

48328 readers
632 users here now

From Wikipedia, the free encyclopedia

Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).

Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.

Rules

Related Communities

Community icon by Alpár-Etele Méder, licensed under CC BY 3.0

founded 5 years ago
MODERATORS
AgreeableLandscape@lemmy.ml
nooter692@lemmy.ml
MarcellusDrum@lemmy.ml
cypherpunks@lemmy.ml
cyclohexane@lemmy.ml
d3Xt3r@lemmy.nz
22
which distrobox image to chose? / which package manager? (lemmy.ml)
submitted 10 months ago* (last edited 10 months ago) by beta_tester@lemmy.ml to c/linux@lemmy.ml
9 comments fedilink hide all child comments
 

The first obvious answer may be the one you are comfortable with but that may be none for a new computer/ linux user.

The one where those package are available. Or even multiple ones.

With atomic (immutable) distros this question will arise more often as the question of which image becomes more important than which distro to chose.

I use dnf but I could also use apt or pacman. What are the relevant advantages of the package managers? What's the reason to use apt over dnf? Nix? Simply package availability?

you are viewing a single comment's thread
view the rest of the comments
[–] throwawayish@lemmy.ml 13 points 10 months ago* (last edited 10 months ago) (5 children)

I will simply list a couple of the images^[1]^ I've used over time and provide some personal insights (in alphabetical order):

  • Alpine; when I'm restricted in bandwidth and/or disk space. FWIW, apk is even faster than whatever is found on Arch.
  • Arch; if I just need a certain package and can't be bothered to look up if it's available on any of the others. Yup, the AUR strikes yet again. Furthermore, if I'm troubleshooting and I find myself on the ArchWiki, then in order to prevent edge cases from happening and thus the provided solutions to not work on the non-Arch distrobox; I rely on the Arch distrobox. It doesn't hurt that pacman (or any of the AUR helpers) are blazing fast. However, if I intend to rely on said AUR packages over longer periods of time, then I often do look for an alternative distrobox to grab the package from instead. While the AUR is excellent for the amount of packages it has, the security standards aren't the best. Thus, if you're security-conscious, then it's better to rely on AUR packages sparingly, unless you're willing to get into the nitty gritty and check how they're built, how the package is maintained and if its maintainer(s) is reliable.
  • Bazzite-Arch; my go-to for gaming.
  • Fedora; as I'm already on Fedora Atomic, relying on Fedora distroboxes makes the most sense security-wise. Fedora is also known to take security very seriously themselves, so in general this is just very pleasant to rely on for security reasons. The only reason why one should not rely on Fedora for security reasons would be if they're already on something from openSUSE (like Aeon/Kalpa/Tumbleweed etc). In that case, going for an openSUSE distrobox makes more sense for security. Furthermore, if the package I need is one that's widely accessible, then I also rely on Fedora distroboxes. Lastly, currently, my development environments are all Fedora distroboxes. I might eventually change these to Wolfi distroboxes or simply rely on Nix, but that's still WIP for me.
  • Ubuntu; I've had to rely on these a couple of times to use software that's known to target Ubuntu. Most recently it was with Matlab IIRC.
  • Wolfi; For the security-conscious, this is probably the best choice. Unfortunately, I've only experimented with it so far without too much success. Thankfully, the Bluefin project has made some good use out of it. So I'll try to emulate their ways in the near future.

Notable mention goes out to Davincibox. Unfortunately my laptop doesn't have a dedicated GPU, so I can't make use of it. But it's something I'm keeping my eyes on.

NixOS is not a supported container distro, but I do have Nix installed through The Determinate Nix Installer. It's somewhat underutilized currently, though 😅.

  1. The images will be the toolbox ones if available.
[–] WilfordGrimley@linux.community 2 points 10 months ago (2 children)

In an immutable setup on Fedora (trying to main Bazzite) is the correct way to use zsh and oh my zsh as my main shell to use rpm-ostree to install it, or should I be using distrobox or Nix/Fleek?

[–] throwawayish@lemmy.ml 1 points 10 months ago

Good question! However I think it's wise to concentrate on a particular word/phrase before actually answering your query.

In an immutable setup on Fedora (trying to main Bazzite) is the correct way to use zsh and oh my zsh as my main shell

Currently, it's not always clear if there even is a correct way of installing some of these (more) edge cases. Therefore, I wouldn't be surprised if you'd see 'seasoned' Fedora Atomic users that have all tackled these in very different ways while being satisfied with (not only) their own solutions (but also approve the respective solutions of their peers).

As for your query, I would say that starting to use Fedora Atomic and pointing out correctly some of the more common ways to install software while being aware of the ambiguity that exists with the chosen installation method for this specific piece of software is already very commendable. So I would like to congratulate you on that!

But, you shouldn't be afraid to stick to what's easy (aka don't allow good to be the enemy of perfect). If the extra time required for changing your base system doesn't bother you at all (which happens automatically in the background anyway), then layering it (thus installing with rpm-ostree) is probably the easiest method while protecting you from a lot of possible edge cases you might have to deal with otherwise. Traditionally, zsh (and other shells) were layered (thus installed with rpm-ostree) and uBlue itself included (perhaps still does) just commands to change root shell to zsh, fish etc. This might have changed in the last few weeks, but I think it should still be a safe bet. FWIW, I have never had any troubles pertaining to my zsh installation and any of its plugins (might as well link the managed zsh-config I rely on).

load more comments (1 replies)
load more comments (3 replies)