Furthermore, a CLI instruction is DE-agnostic. So you don't need to cover the same topic with explanations for at least 3/4 desktop environments. GUI instructions also change a lot faster than their CLI counterparts; so by providing the commands one provides the method with the best longevity. Overall, it's just so much more efficient.
The main difference at this point isn’t what you can do with them, but how they’re set up by default
Excellently distilled most of my post.
I wonder if distros are interested to further blur the lines themselves; like how Debian and Fedora both enable Flatpak by default.
To be honest, I think the homogenization is a net positive.
Definitely. But I feel like we fail at capitalizing on this. Though, in all fairness, the fact that derivatives have lost (some of) their significance does convey to me that we're currently in a major shift. I just wonder where we'll end up and if there's anything we (as a community) can do in order to accelerate the process.
Thank you for touching upon the human-side of things! I wonder if my original point could be distilled to "Can we, humans, simply act more rational?" 😅.
Traditionally; definitely. But if the purpose of package managers is to acquire packages fit for use with the distro, then the position of alt packaging formats (e.g. Nix) and/or solutions that make use of container technology (e.g. Distrobox) at least provide some food for thought.
Like, if I choose to install Debian (Stable) and openSUSE Leap and then proceed to install all my packages through distro-agnostic ways accessible on both distros (e.g. Flatpak, Brew, Nix etc.), then wouldn't you agree that these systems become remarkably close to one another?
Note that Flatpak is not a distribution, but a packaging format.
BoilingSteam's article in which their thoughts and reflections are written can be found here.
While it's technically not labeled, the blue-colored columns found right below openSUSE belong to Garuda; as can be seen here (from an earlier iteration of the graph).
Technically, Linux Mint also has their Debian Edition. But, the vast majority of its users should be using the one based directly on Ubuntu.
Update 2: After trying out EOS, Arch, Manjaro, OpenSUSE Tumbleweed and Universal Blue, among many other options, I’ve come to the decision that I’m okay with sticking to Mint for now on my main desktop and setting up UBlue Aurora on my work laptop, but might consider switching to Kubuntu or Fedora if I want something similar at work and at home (one of my main draws away from Mint was that it didn’t offer a KDE option), or to OpenSUSE Tumbleweed if I must have a rolling distro for some reason. Thank you all for your guidance, and happy distro hopping!
Independent distros; these are not forks of other projects (at least not in their current iterations). We may also refer to these as upstream-projects.
Derivative distros; these are forks from the earlier mentioned projects. We may also refer to these as downstream-projects.
E.g. Zorin OS is a derivative of Ubuntu, which itself is a derivative of Debian. After the gargantuan effort it takes to make Debian possible, Ubuntu's maintainers 'grab' Debian, apply a set of changes and ship it as Ubuntu. After which, Zorin OS' maintainers grab Ubuntu, also apply a set of changes and ship it as Zorin OS.
Of course, not all derivatives are created equal; sometimes a single change is applied that by itself constitutes the fork. And other times, the changes are so massive that they blur the lines between independent and derivative; Ubuntu's changes to Debian is a good example of this.
Derivative distros can't simply change everything as they see fit; some things are simply essential parts. In most cases, these include:
the release cycle of the base; rolling-release vs point-release, but also LTS vs bleeding edge and everything in between
the (base) packages of the base
But what other factors/aspects that are important for the average user to know about each ‘base’?
I was about to write a long ass dissertation, but it became very unwieldy. Consider asking for specific bases and perhaps I will respond for those.
On a final note, it's worth mentioning that differences between different distros have never been as blurry as they're today. With e.g. Distrobox, one can install whatever package from whichever distro they want. Thus, we aren't as tied to the packages provided by the base distro as we were used to. Furthermore, most distros have different 'variants' that allow access to different channels or release cycles. E.g. for those who want Debian packages but bleeding-edge; there's Debian Sid etc.
Sure, a lot more can be said; like how corporate interest plays into all of this. But what has been mentioned above should suffice for now.
Fam, with all due respect, reconsider how you go about interacting with the community for support.
We love to help, so don't get me wrong. But you have to allow us to help you. Paramount with this is communication; so consider responding to questions asked by those who reach out to help.
Like, I'm not exaggerating when I say that your issues would have already been resolved if you had been (more) responsive.
Alright. I'm just guessing at this point. But could you give it more permissions through Flatseal and see if that resolves it? I'm not behind my laptop currently so can't look at it with you*. But I may come back at it within a couple of hours.
There's also the herd mentality; i.e. peeps like to up vote something that has already been up voted and down vote something that has already been down voted. I was the first to up vote; with my vote it became +2 -7. So, since then, it has received 4 up votes and 6 down votes. Which is at least an improvement.
The point I wanted to make is that there's more to it. I wouldn't simply refer to it as symptom of toxicity and call it a day.
ChatGPT gave the following. Follow at your own risk. Most important is to check if the file locations are compatible with Fedora.
To automate running the update-grub command after each kernel update, you can create a script and set it up to run automatically. Here's a more direct approach:
Open a text editor and create a new script file. For example, you can name it "update_grub.sh".
In the script file, add the following lines:
bash
#!/bin/bash
/usr/sbin/update-grub
Save the script file in a location where it can be easily accessed, such as your home directory.
Make the script executable by running the following command in the terminal:
bash
chmod +x /path/to/update_grub.sh
Next, you can set up a cron job to run this script automatically. Open your crontab file by running:
bash
crontab -e
Add a new line at the end of the crontab file to schedule the script to run after each kernel update. For example:
bash
@reboot /path/to/update_grub.sh
Save and exit the crontab file.
With these steps, the update-grub command will be executed automatically after each kernel update, ensuring that the new kernel version boots successfully.
Technically not a distro, but give Bazzite a try. It's probably the most hands-off gaming experience on Linux. Valve employees also make contributions to it.
I'm aware that MX works on a lot of excellent GUI tools that are shipped with it. Which is great, but perhaps necessary; because they ship a systemd-less distro. Which, in the end, might cause more work than it should. (I'm aware this is in part caused by software just assuming that systemd is installed by default.) And while I think it's a noble endeavour to maintain a relatively easy systemd-less distro, I don't think it's enough to justify a recommendation to a relatively new Linux user. Would you mind sharing your thoughts on this?
Furthermore, a CLI instruction is DE-agnostic. So you don't need to cover the same topic with explanations for at least 3/4 desktop environments. GUI instructions also change a lot faster than their CLI counterparts; so by providing the commands one provides the method with the best longevity. Overall, it's just so much more efficient.