For example, I'm using Debian, and I think we could learn a thing or two from Mint about how to make it "friendlier" for new users. I often see Mint recommended to new users, but rarely Debian, which has a goal to be "the universal operating system".
I also think we could learn website design from.. looks at notes ..everyone else.

  • rollingflower@lemmy.kde.social
    ·
    edit-2
    7 months ago

    Fedora Atomic Desktop, mainly KDE.

    • Fedora adds their pretty useless Fedora Flatpak repo, that is more secure but has unofficial packages, an additional runtime in RAM and a very small set of apps (they need it due to "legal problems" when preinstalling apps. Like... just dont preinstall them but add a startup page to install them manually?)
    • There is no good way to use NVIDIA as it needs proprietary drivers and some tweaks. Ublue fixes that. Same with other out-of-tree stuff. Not really their fault, but be aware that atomic Fedora has basically no proprietary NVIDIA driver support.
    • i think their kernel is extremely bloated, I would prefer having separate ones for only intel, amd, nouveau and also removing all the legacy hardware drivers nobody uses
    • an x86_64-v4 (or at least v3) variant would be really necessary (my 2012 Thinkpad is v3)
    • they will likely prefer to use flatpak firefox, just like ublue does, ignoring the inability to sandbox processes at all. This is the list of issues that need solving until Firefox "can be shipped as flatpak"
    • they use toolbx (with that silly rename from "toolbox") instead of distrobox. Distrobox has way more critical features like a separate home, which prevents breakages through conflicting dotfiles. Toolbx is the worse product.

    Also, their traditional KDE variant is very bloated, which is why I updated this guide

    But overall its still my favourite distro. Has a nice community, all the desktops you want, SELinux (which is btw required to make Waydroid somewhat secure) and their atomic stuff is an awesome base thanks to ublue.

    • biribiri11@lemmy.ml
      ·
      7 months ago

      It wouldn’t be too difficult(tm) to fork their kernel and make custom configs of it. Here’s the git repo that holds their rpms and their respective kernel configs, it’s just that nobody has cared enough to create/propose “slimmed down” specialized kernel images: https://src.fedoraproject.org/rpms/kernel/tree/rawhide You can just clone the repo and point COPR to it, then automatically build custom kernels.

      Awhile ago there was a proposal to move the x86 microarchitecture level. Here’s recent discussion on that proposal: https://discussion.fedoraproject.org/t/what-happened-to-bumping-the-minimum-supported-architecture-from-x86-64-to-x86-64-v2/96787/2

      In general, though, Fedora would not want to leave any users behind. Instead, the proposal for hwcaps is currently being drafted: https://pagure.io/fesco/issue/3151 With hwcaps, default installs will be x86_64 v1, but will be upgraded to “optimized” packages if available upon updating. This makes packaging a bit awkward, though. Packagers already need to maintain packages for multiple versions of the distro. In fact, they need to support F38, F39, F40, and rawhide atm. Needing to maintain an extra 3 builds for each package on top of x86, x64, aarch64, ppc64le, and s390x is a bit of a burden, so success might be limited.

      Distrobox, while feature-rich, is still a bit hacky (though it’s still more reliable in my experience than toolbx). You’re not the first to want this, though: https://github.com/fedora-silverblue/issue-tracker/issues/440

      • rollingflower@lemmy.kde.social
        ·
        7 months ago

        Yes thar is the direction I am going to. But they just disable kernel modules from running, I dont know if that is as complete as simply not building them.

        But if its possible, then everyone with amd or intel should block nouveau, and vice versa. Just keep it small.

        • baseless_discourse@mander.xyz
          ·
          edit-2
          7 months ago

          Yeah, this is the old philosophy of the "run anywhere" philosophy of linux (or computers in general) that got us here. Another problem with stripping down kernel drivers is that swapping hardware component will require rebuilding the kernel, which regular user will definitely not be happy about.

          • rollingflower@lemmy.kde.social
            ·
            edit-2
            7 months ago

            It would be a problem because of how it is currently done.

            I imagine an install ISO to have a monokernel, build the kernel-building-system and detect the needed drivers. Save the config and build the matching kernel from that.

            Now if you want to swap hardware, there is a transition tool within the OS that allows to state the wanted hardware component and remove the old driver from the config.

            Or you switch to a monokernel and run the hardware detection and config change again.

            Or you use the install USB stick (which you already have) which already uses a monokernel and has a feature to detect hardware, change the config on the OS, build and install the kernel to the OS.

            This is a bit more complex than for example what fedora plans with their new WebUI installer. Poorly such a system also doesnt work that well with so many kernel updates.

            • baseless_discourse@mander.xyz
              ·
              edit-2
              7 months ago

              I am not an expert, but I feel like rebuilding the kernel is probably too slow for most user.

              And kernel already dynamically load the kernel module, then disabling them would practically make sure they will not be loaded.

              I feel like we don't need to go down to micro-kernel to solve the problem of loading too many drivers.

              • rollingflower@lemmy.kde.social
                ·
                7 months ago

                What I really like about stuff like RedoxOS, COSMIC, typst, simpleX, Wayland and others is having stuff built from a modern perspective with modern practices.

                Linux is ancient now, and its a miracle that it is thriving like this.

                If dynamic loading really is that robust, it probably doesnt matter. But I dont know how big the performance increases are and I really need to do benchmarks before and after.

                There are btw also some experiments on making tbe CentOS-Stream LTS kernel run on Fedora. Which would be another great way of getting a more stable system.