Great news to have more options in the Enterprise Linux space in the future. Personally I’m going to keep running Alma at work since they’ve promised to keep working on security updates and watching the whole RHEL linux thing unfold.
Updating individual applications is a pain on NixOS. You’d either have to override the attributes of the package (which can get quite ugly and complicated and does not always work) or pull in a new commit of nixpkgs that has the version you want which requires the download of a ton of other dependencies that were compiled for that specific commit of nixpkgs.
Flatpaks solved this problem for me and helped reduce the download size every time I wanted to update something.
According to StatCounter, a web analytics company, by June 2023, Linux has reached a 3% market share in the desktop segment. This is a remarkable achievement considering its fierce competition from other operating systems.
I still favor native packages, but I don’t have a problem with Flatpaks. I’ll use them when a program isn’t available in the repo or there’s a compelling reason to have a never version of an application. I’m on Debian Stable, so I’m obviously not obsessed with having the newest, shiniest version of everything.
Flatpaks are my second choice when there isn’t a recent enough version in the repos. They’re fine but take 1. too much storage space, and 2. are usually slower
I have never considered speed. For example, it may be foolish to use flatpaks for Blender or Godot engine? Or perhaps is it the startup speed that is slow?
yes i’m talking about the startup speed. It’s not as bad as snap, but noticeably slower with some apps (it can be annoying for a web browser for example)
# is a standard shell prompt for root, and only for root. For commands executed by any other user, including sudo, use $.
In general it is a bad practice to use sudo in documentation because in many distros it is not available by default. I would use su for your example. However system users have no passwords, so you need to become root first, and only after that change user to avoid prompting a password. So I would write
Bad practice is not using sudo (I do use it), but assuming that everyone has sudo installed and configured the same way as you have.
Additionally, which distro doesn’t have sudo? I’m sure there are some but by far the majority of distos have and use sudo.
Almost all distros have sudo. But many of them don’t install it by default. Most popular distros except Ubuntu (I mean Debian, Fedora and RHEL clones) provide a choice to user at install time: set the root password or install sudo and enable it for the admin user. In OpenSUSE sudo is installed by default, however it is configured in slightly different way than usually. Etc., etc.
How is EndeavourOS? My main desktop is running Ubuntu (I stuck with it as I’m quite familiar with the debian package managers), but I have a laptop I’m looking to fart around in once my Pi arrives and I can move PiHole to it.
I was thinking Arch, but I’m open to giving EOS a try.
@BaconIsAVeg@Digester Unless you plan on using that laptop daily, I'd say to not put Arch on it. Stick to something you like, the differences between distros are mostly in the way they deliver updates and the existing packages that come with it.
I don’t really have a need to use a laptop at all, however it’s getting janky on my main machine when I want to try something new and break a ton of stuff, then I’m up until 4am fixing it using w3m from a terminal before work the next day.
It’s more of a sandbox.
Honestly, I don’t care too much about the underlying distro at this point. I switched from Gnome to bspwm last night with polybar and it’s like a whole new world that satisfies the itch I haven’t felt back since the early Enlightenment days.
@BaconIsAVeg I usually just use a virtual machine to try out new stuff before committing to it. Or you could try Vanilla OS if you want to have a bunch of stuff from other distros.
Unless you plan on using that laptop daily, I’d say to not put Arch on it.
Ha, you’re right. I did end up installing it on my 13" laptop, and after a few minutes without issues decided to #yolo it onto my main machine and blow away my Ubuntu install. Loving it so far, and yeah the frequency of AUR updates is impressive.
ExFAT works fine but I believe you lose journalling and other filesystem corruption recovery methods. Depending on the kernel version, NTFS3 is the NTFS driver bundled in the Linux kernel. I’ve tried it and it worked pretty well until it corrupted one of my data drives, and I’ve stuck with NTFS-3G since then, it’s been tried and tested for years at this point.
Nope, don’t like them. Nor snaps. I find the sandbox nature annoying and many developers don’t actually seem to understand it correctly anyway meaning you have to use flatseal etc. Then having to deal with some apps writing config within the sandbox and some writing it outside the sandbox…
My order of preference is generally I pick the “official” supported version as opposed to any community maintained ones. Then within that:
Install via the language’s package manager (cargo, npm, pipx, cabal etc.)
I’ve just had fewer issues with snaps. Honestly I don’t care for either of them so the difference between them for me is pretty slim but I just find Flatpak to be particularly annoying, Snaps just haven’t caused me any real issues other than polluting my device list with endless loop devices.
True. I have run into a lot of dumb issues with sandboxing, mostly in choosing a folder other than downloads for file interaction.
I have overlooked Appimage, and I will consider it. I am intrigued that you put it before native package. I had not considered using the package manager of the language it is built in, which honestly is probably the optimal way to install a package.
Alright, I have some reading to do. I love learning new ways to do things. I am glad I asked!
There is a bit more nuance to it I suppose - I like Appimages for “complicated” apps, i.e. big GUI apps like Inkscape where I prefer native packages for terminal tools. The nice thing about Appimages is that there just isn’t much in the way of integration and therefore its really easy to just try something out with no risk of installing a bunch of extra dependencies and no way of breaking your system - I use Appimagelauncher for managing them but have been considering swapping to something like Appman/AM.
The other thing that sometimes puts me off of native packages is having to deal with excessive numbers of PPAs or other repos when they aren’t in the main ones.
That is a great consideration that I have not looked into in awhile. It seems to be the ultimate third, or perhaps second, solution for getting software to just work. I will look into Appimagelauncher, and try out that version is native or flatpak fails me somehow.
Yeah, user submitted packages are such a risk sometimes.
I handle it by spinning up an lxd container to try new apps… then they have the whole machine to do what they like, and if the install doesn’t work or I hate the app, just delete the entire container.
lemmy was one of the harder ones to deal with because it needs docker… I have a special profile that runs docker in a container for apps like that (I never run docker bare, it f…s around with the firewalling and breaks stuff).
linux
Newest
This magazine is from a federated server and may be incomplete. Browse more on the original instance.