yala

Hats off for the efforts provided by maintainers. But I feel as if that potential should be better utilized (in part) to achieve greater goals.

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?

Unfortunately, perhaps understandably so, popularity is very hard to measure on Linux. Though, while far from representative, ProtonDB's measurements do exist and provide us some insights. As for the distros found on the chart:

• Arch (base):
  • Endeavour
  • Garuda^[1]^
  • Manjaro
• Debian (base):
  • Ubuntu
    • Linux Mint^[2]^
    • Pop_OS!
• Fedora (base):
  • Nobara
• NixOS
• openSUSE

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.

1. 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).
2. 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!

Thank you for the update!

Could you elaborate upon your decision-making?

You can divide distros into two categories:

• 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:

1. Open a text editor and create a new script file. For example, you can name it "update_grub.sh".

2. In the script file, add the following lines:

   #!/bin/bash
   /usr/sbin/update-grub
   

3. Save the script file in a location where it can be easily accessed, such as your home directory.

4. Make the script executable by running the following command in the terminal:

   chmod +x /path/to/update_grub.sh
   

5. Next, you can set up a cron job to run this script automatically. Open your crontab file by running:

   crontab -e
   

6. Add a new line at the end of the crontab file to schedule the script to run after each kernel update. For example:

   @reboot /path/to/update_grub.sh
   

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

A bit late, so my apologies*. Just to be sure, the Writer is installed as a Flatpak right?

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.

TIL. Thank you!