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.
Every distro could learn from Arch Wiki
Even Arch Linux could learn from the Arch Wiki.
The Debian Wiki would actually like a word.
There is stuff in there that’s not found anywhere else. For example while researching driverless printing recently I found a huge page on the Debian Wiki but the Arch wiki only has a paragraph saying supporting printers should be detected automatically.
The Debian wiki is awsome. But it’s less noob friendly than Arch wiki.
The web UI looks like an old forum from 2000. Don’t get me wrong, a well written manpage style webpage is way better than an eye candy bloated scripted webpage (IMO) and I really like how detailed the Debian wiki is. But in today’s “mental standards”, the Debian wiki is not attractive enough for most new comer.
Also, It seems the Debian wiki is not as indexed as Arch wiki on the web.
Finally… I can’t access their wiki with my VPN ! :/.
But I do agree, The Debian wiki is a gold mine !!!
Can you send that one? I’m actually researching driverless printing right now
Who made the Arch Wiki? Was it done by the community? Genuine question.
Yup.
All distros, or none: flatpak has to improve in regards to launching an app from terminal. Following is a joke:
flatpak run com.github.iwalton3.jellyfin-media-playerWhy can’t the installation create aliases like
flatpak run jellyfin-media-player? And then highlight conflicts during?It would also be nice if it could alias to the normal command, for example, LibreOffice with CLI commands like lowriter or localc.
Did you know you can evoke LibreOffice from the terminal to convert one file format to another? It can do what Pandoc does, but also works on old .doc files. Flatpak’s weird CLI behavior makes it difficult to use though.
Ask the devs. I haven’t bothered asking so far. There’s fp https://github.com/DLopezJr/fp but I don’t like workaround if it’s easily fixed upstream and it’s not like they wouldn’t know that it’s bullshit. Maybe they can’t decide upon a solution. Or are waiting for another important and relevant update.
This is extremely simple to fix with scripts that can be automatically created on install time. Here is a quick script I just wrote. It will search for first matching app and run it. Just save the script as flatrun, give it executable bit and put it into $PATH. Run it as like this:
flatrun freetube#!/usr/bin/env bash # flatrun e # flatrun freetube if [ "${#}" -eq 0 ]; then flatpak list --app --columns=name,application else app="$( flatpak list --app --columns=name,application | grep -i -F "${@}" | awk -F'\t' '{print $2}' )" if [ -z "${app}" ]; then flatpak list --app --columns=name,application elif [[ "$(echo "${app}" | wc -l)" -gt 1 ]]; then echo "${app}" else flatpak run "${app}" fi fiEdit: Just updated the script to output the list of matching apps, if it matches more than one.
Yes and I did a similar script but “just create a script” is a really bad solution.
Apps should need to declare a shortname and flatpak should have a shortcut for those with a separated command like flatrun.
I personally don’t think that creating a script is a bad solution. The entire Linux eco system is based around composable components (especially when we talk about terminal commands). Most of the Flatpak applications are available through GUI menus (.desktop files) and that’s the focus of Flatpak. And I think it’s a design decision not to expose every application as a separate program in the $PATH by default. This way there is less of a chance to collide with anything random on the system, if they have the same name.
Having said this, I still agree it would be beneficial for most users if there was a way to automatically create scripts in a special
binfolder, that is available in the $PATH. The problem is, what application name should it have? What about different versions of the same program? The entire Flatpak concept was not designed for this, so creating a script for your personal use is not a bad solution.Repeating, apps should need to declare a shortname. I think my script currently has no mechanism for detecting duplicates
Please read my reply before you repeat. How should the different versions of an application be handled? What if the shortname is already taken? There will be collisions, which the longname tries to solve. Flatpak is not a repository where all names can be checked against, this is the job of a repository like Flathub. What about different versions of an application?
This is not a simple case of forcing to specify shortnames.
I think a good solution would to just have that script autogenerated by the flatpak, honestly.
That would mean the app has access to the path, which was explained as insecure in another place
That’s super. Thanks for sharing.
It’d be dangerous if an installed app claimed to be something like sudo or bash. Even if a mechanism was created for flatpak apps to claim a single shell command, there is no centralized authority on all flatpak apps to vet them. If there was for flathub, and each uploaded package was checked, that still leaves every other non-flathub flatpak repo which must implement the same vetting. Because there’s no way to guarantee to do it safely, and because flatpak devs are unwilling to compromise, this is just what we get.
However in the same way, compromised flatpak app can also put a malicious .desktop file in
~/.share/applications, which also allows execution of arbitrary command, even outside of the flatpak sandbox.User home permission is just incredibly dangerous on linux, I think we need special permission to explicitly allow access to these folders in home. Fortunately more and more app starts to support portal, which makes them much more secure.
Although, I do wish portal would have a access per session vs access forever option. For now if you open a folder through portal, the app was granted r/w permission to that folder forever.
flatpak run com.github.iwalton3.jellyfin-media-player
You can use
/var/lib/flatpak/exports/bin/com.github.iwalton3.jellyfin-media-playerinstead. and then create aliases or symlinks (for example in ~/bin/) for that.@lemmyreader @barbara it’s a bit annoying but I kinda like that I have to manually link it a bit. So I create sh scripts in the usr/local/bin that just execute the flatpak run command
Wow I was not aware of that folder! Thanks.
https://github.com/boredsquirrel/flatalias
Or my PR for that, that makes aliases on every login. I just have to fix it to work with user flatpaks as well: https://github.com/bjoern-tantau/flatalias/tree/patch-1
It would be pretty neat if they did like zsh does, where it asks you if you mean a certain command when you only type it partially.
you’re missing a directory from your PATH if you have to do that. flatpak Has friendly names
You can create a alisis
There’s a reason security people don’t use flatpak, but that’s not it.
The one thing I wish every distro would incorporate is the way Gentoo handles config file updates. If there are any changes you get the option of using a very simple side by side merge where you go through all the differences of the old and new configuration where you can decide which one to use going forward.
While you will get somewhat the same from apt, I like the Debian way of providing base config support in packages and have local config loaded by include statements.
As you don’t edit the default config and automatic updates can happen w/o user input and your config will stay safe
That’s the way it should be. But it depends on the software.
What really sucks about the Debian way is how it tries to start daemons in the post-install scripts and if that fails (say because the default config tries to use a port already taken) the entire package system shits itself and is unusable until you fix it.
the entire package system shits itself
Usually just the one package fails, unless you have other packages that have a dependency on it. I agree that it’s annoying though.
Well, it stays in that half installed state and interferes with any other use of the package manager.
I might be a special case as I Mostly use Linux for servers. But I have maybe experienced one such case on the last three years on our 50-odd servers
I’ve ran into that with one shitty vendor (I won’t/can’t give any details beyond this) lately. They ‘support’ deb-based distributions, but specially their postinst-scripts don’t have any kind of testing/verification on the environment they’re running in and it seems to find new and exiting ways to break every now and then. I’m experienced (or old) enough with Linux/Debian that I can go around the loopholes they’ve left behind, but in our company there’s not too many others who have sufficient knowledge on how deb-packages work.
And they even either are dumb or play one when they claim that their packages work as advertised even after I sent them their postinst-scripts from the package, including explanations on why this and that breaks on a system which doesn’t have graphical environment installed (among other things).
But that’s absolutely fault on the vendor side, not Debian/Linux itself. But it happens.
Pacman just dumps you a .pacnew, leaving the comparison to you (y’know, KISS). Your change isn’t touched, unless it’s .pacsave.
Pacdiff does this on arch-based distros
Fedora, NixOS and Void need a proper wiki like Arch
Most distros could also learn from Arch and create something similar to the AUR. Nix is going in the right direction.
And I guess almost all distros could learn from Artix and Devuan and reconsider if systemd is the right choice.
honestly I wished the arch wiki turned into a distro agnostic wiki. i have been using debian for decades and use arch wiki all the time but it would be nice to have a one stop shop for linux documentation. the Wikipedia of Linux run as a coalition.
NixOS is at least starting to work on a new wiki. The old one is gone and is only accessible from archive.org.
That’s great
Seconded. NixOS’s documentation has consistently been the worst I’ve read, always forcing me to go to the source code to try and understand what in the world is happening. It makes quick changes to new things nigh impossible. I had to resort to taking notes when I understood things about nix in order to retain the knowledge or at least link to where I could easily regain it.
The nixos wiki was marginally better and https://nixlang.wiki/ has been better. However the latter is less known so has less content. All in all, nix documentation is still bad.
Anti Commercial AI thingy
NixOS has the best concept and even pioneered it, but whether its implementation and documentation is perfect is a topic for debate.
However, it’s been quite long since I had to fiddle with my config and as such, the downsides don’t really affect one on a daily basis. In fact, I recently reinstalled my machine to change the root filesystem and it was an absolute breeze. If not for secure boot, it would have been absolutely trivial, and with secure boot it was easy and convenient.
As such, I consider the pains an investment into system that runs much better down the road. Though I’d love it if these pains were reduced.
NixOS has the best concept AMD even pioneered it,
I’m assuming “AMD” is a typo?
Anti Commercial AI thingy
Yes! Apologies, didn’t proofread what my phone produced from swiping
It would’ve been welcome and surprising news! 😄
Anti Commercial AI thingy
I’ll definitely check that out, thanks
Most distros could also learn from Arch and create something similar to the AUR.
i’ve seen Void’s
xbps-srctool compared to the AUR multiple times in /r/voidlinux (and i guess it’s like a decentralized AUR?? you can build+install pkgs from source using the package manager, sure, but there’s no one big diy xbps packages registry like aur.archlinux.org for Void) and while i don’t really see it, if you follow that train of thought, void’s pretty set in the “right direction” :Ddeleted by creator
I heard about it, but haven’t tried it out properly yet.
The Debian Wiki is so much better than the Arch one.
This has to be bait.
It is not
Absolutely not
Not approachable at all.
Just installed Debian today. Jesus the site/wiki is ugly
What’s wrong with it?
I mean… Gestures vaguely
What do you mean, I’m a web dev and that looks completely normal.
Its missing tons of images, CSS and unnecessary frameworks. So no, it is not normal
Sorry if my irony wasn’t too obvious. It certainly is not supposed to look that way. There are a lot of pages all over the internet that function just as garbage as this, especially on mobile. That’s why I meant it looks “normal” as in not out of the ordinary.
For me it’s mostly that the site sprawls in unintuitive ways. It’s possible to have a simple look while being easy to navigate, for example (and this is subjective, but still) https://www.openbsd.org/
I miss when this style of website was more popular for software projects. There are plenty of projects with modern websites that still manage to do it well, but there’s just something about the instant familiarity that comes with that type of layout.
I know what you mean, I remember when debians website was like this: https://web.archive.org/web/20021122032757/http://www.debian.org/
Is it just a generation thing, or is it objectively easiler to navigate?
I don’t even see any video or infinite-scrolling pages.
You probably shouldn’t be accessing a linux distro’s website from mobile but yeah the site does look weird and amateur
You probably shouldn’t be accessing a linux distro’s website from mobile
Well how else am I going to access it, I borked my computer mid-install :P
Yeah, just curl it into aplay like the rest of us, jeez
No excuse for websites that render poorly on mobile nowadays.
You probably shouldn’t be accessing a linux distro’s website from mobile
I don’t think it’s good to hand-wave a website’s poor user experience and instead blame the user’s device. The fact of the matter is that Debian’s website is not as responsive as it could (imo, should) be and results in a bad user experience. With mobile traffic being responsible for over 55% of the internet’s traffic, it can be generally assumed a user’s first experience learning about a distro will be on a mobile device. If that first impression is bad, that can spell bad news for that distro’s adoption/onboarding.
Looks fine to me.
I think more distros should have an easy way to set up disk level encryption in the installation
And know how to use an existing btrfs partition. And always [at least have an option to] show exactly what the automatic installer is going to do before I run anything. There’s gotta be a middle ground between “we’ll just surprise you” and “here, do everything yourself”.
OpenSUSE has a guided setup if you dont want a surprise or don’t know what manual setups requires. then prior to starting givea you a summary of what will be done.
Great, there we go, sounds like all distros should learn from OpenSUSE.
Each one has good parts, but I think openSUSE did a lot to make things easier for new users to linux
- Install, you see software summary, you can click and alter what patterns or packages you want included.
- auto snapshots when you enter package manager or admin tools, easy rollback with snapper or boot list
- a GTK front for all of YAST2-GUI components. All system, network, firewall, service, packages, boot and kernel config are available as GUI dialogs (as well as many others)
I usually use Fedora these days and I have few complaints but I sometimes miss the ArchWiki. Not that Federa isn’t well-documented — it obviously is well documented by nature of being a RedHat product — but people in the Arch community will sometimes make a whole page to document how they fixed a specific laptop model’s relatively unimportant hardware compatibility issue.
I’m on Fedora too and quite often end up on the Arch wiki. A lot of the stuff there applies on other distros too.
Give me immutable, declarative Arch.
NixOS on your mind too? lol
Yep
I think that’s what BlendOS is working towards. You might keep an eye on them.
Oh nice. This looks promising. I’m guessing it’s not totally ready yet?
It may be ready, I haven’t tried their latest version. Most of the functionality was there, but it had some rough spots. I’ve been meaning to go back and try daily driving it again.
What do you miss in NixOS (Unstable)?
I think a declarative, atomic LTS distro (e.g. Alma) would be quite nice for business use.
I’ve been messing about with NixOS for the past 2 weeks or so. While I think I know enough to plug in the right text in the right spots to get a system configured I feel like I understand nothing about the nix language and the syntax is extremely unintuitive to me. If another distro offered declarative configuration as well as something like Nix’s options I would easily swap away from NixOS at this point.
I feel like I understand nothing about the nix language
Pure lazy unityped lambda calculus, basically a lazy lisp with records instead of lists. Or a pure, lazy, lua.
Pure is important because reproducibility, lazy is important to not have to evaluate all of nixpkgs before you can build anything, lambda calculus well it needs to be turing complete, support things like functions in in some way though TC is only used very, very very deep down in the system. They literally use the y-combinator to do recursion, like when bootstrapping stdenv.
The syntax is unintuitive, yes, but aside from the semicolon cancer actually not that bad. My biggest gripe with the language is it not having a proper type system, like you put a list where a string is expected or the other way around and you get five screenfuls of backtrace through the whole evaluation stack and due to laziness the actual location of the error might not even be in there.
I gather that not everything is compatible with nixOS, and it’s better as a server than for development or as a general OS.
I didn’t know Alma was declarative.
Makes sense.
No, I wish for something like Alma, but declarative and atomic :)
It’s something we might see with the next EL release cycle.
rpm-ostreehas treefiles complete with the option for (experimental) lockfiles. There’s already config files for CentOS Stream to build CentOS Stream CoreOS, and those can be adapted for Alma. I think, atm, it’s more of an issue of general interest than technical limitations.Ah nice, thanks for pointing me to it!
Gentoo - patience.
But seriously. With theUSEflags, compiler options, you can understand software more from a developer’s point of view.
You can try to optimize software for your hardware.
Fully explore theconfigureoptions. With a binary package you have no control.How are those new binary applications coming along? is it feasible to mix. I don’t want to compile everything.
Quite useful if you don’t mess with the
USE. I can be mixed.
I recently tested the binary option, I set desired profile (eselect profile list) and it just worked™.
Some applications still require manual compilation, e.g.llvm,gcc,systemd.
Linux Mint could learn from Arch and document…anything. 3/5 of the Mint manual is removed about Ubuntu and the other 2/5 are about printers.
the other 2/5 are about printers
Relatable, everyone hates printers
Fedora’s installer is abysmal. There’s a number of installers it could learn from. They’re working on one at the moment, so I hope it’s good.
Enabling access to proprietary software should also install audio/video codecs. Or at least have a separate checkbox for it, like (I believe) Ubuntu has.
Fedora’s installer is abysmal.
I thought so too. It doesn’t have enough options for power users and too many for newcomers. It caters to a middleground that barely exists.
Enabling access to proprietary software should also install audio/video codecs.
The codecs are also the #1 thing that annoy me in Fedora. Because of shitty US patent laws the rest of the world has to suffer.
Why won’t they just use Calamares?
Calamares has poor integration with the rest of the ecosystem including their existing tooling. For example, it has no kickstart support, and no support for their immutable installs (afaik, anyway). It was less effort to put their existing cockpit tooling into anaconda and make a whole new web ui than it would be to add support for all their stuff into calamares.
Fortunately many flatpak browser now comes with codecs, like ungoogled chromium and librewolf.
The installer is the single one reason I can’t switch to fedora. I have several drives in my machine and I like to separate them, but their installer scares the shit out of me. I can pull it off for sure, but I just don’t want to take the risk
I think with Linux Mint the main User Friendly thing is its DE. But with Debian you can install Cinnamon DE as well. https://packages.debian.org/search?keywords=cinnamon
btw, I quite like the Debian website, colors and design.
I am sure you are aware of this: https://linuxmint.com/download_lmde.php
Yes. Nice that there is the Debian choice. And nice that Linux Mint refrains from using Snaps by default like Ubuntu.
That’s honestly its biggest advantage over Ubuntu + Cinnamon.
The Debian web site needs a good UX overhaul. Prioritize the things people are most likely to want, make them prominent and uncluttered, and present a logical flow from one task to its follow-ups.
Just a quick glance yields the simplest example: the download link is not the first or most prominent thing on the main page. Clicking “download” gives you the netinst AMD64 ISO, which is reasonable enough, but there is no indication of how to install it. Clicking “user support” takes me to a page with extremely verbose descriptions of IRC, usenet groups, and mailing lists. I think the fastest way to get installation instructions is to click the tiny “other downloads” link (after I’ve already downloaded the one I want!), and then a link to the manual from there.
This is not a good UX. This is a demographic filter. You can argue that’s appropriate for a technically-oriented OS. 9front explicitly makes itself unapproachable to dissuade casual users, but I think Debian can and should be more appealing to mainstream, casual newcomers.
The Debian web site needs a good UX overhaul. This is not a good UX. This is a demographic filter. You can argue that’s appropriate for a technically-oriented OS. 9front explicitly makes itself unapproachable to dissuade casual users, but I think Debian can and should be more appealing to mainstream, casual newcomers.
Your opinion, fine. So why do you want Debian to have more mainstream users ?
Why not? It’s a great general-purpose distro.
My point is that 9front’s user-unfriendliness is a feature (explicitly intended), whereas I think Debian’s is a bug (not intended or desired). I’m not psychic, though, so I could be wrong about the Debian team’s goals.
Why not? It’s a great general-purpose distro.
My point is that 9front’s user-unfriendliness is a feature (explicitly intended), whereas I think Debian’s is a bug (not intended or desired). I’m not psychic, though, so I could be wrong about the Debian team’s goals.
As far as I am concerned Ubuntu has since around 2004 already helped a great deal with getting more mainstream Linux users on board. With the new Debian stable release of Bookworm for the very first time non-free firmware came with the installation media and that could be useful for lots of people, but still I will not recommend Debian for people interested in Linux. I will tell usually them to go for Linux Mint or Ubuntu.
Here an example of what I think could do better website design (Not Linux but zsh) : https://www.zsh.org/ And this is also not too appealing to get more mainstream Linux users on board : http://www.slackware.com/ (One of the first Linux distributions. No SSL, but the site seems pretty functional).
Here an example of what I think can appeal to a lot of mainstream : https://bazzite.gg/ That may attract quite some people (though I personally do not like such site design at all) to use Linux.
Then again, people are different. I find the Arch wiki a fantastic resource. Today in a comment on Lemmy someone wrote that it is horrible.
I mostly agree. I usually recommend Mint to new users, largely because their web site and defaults are very beginner-friendly. Mint is the modern version of what Ubuntu used to be 10-15 years ago. At this point I don’t think Ubuntu has tangible advantages over Debian for new users.
I really like Slackware’s site. It’s not sexy, but it’s functional, organized, and easy to navigate. The Zsh site is counterintuitive to me with that sidebar-that’s-not-really-a-sidebar, and hyperlinks whose text requires the context of a header that is not aligned with them.
I just checked out Ubuntu’s web site for comparison, and…uh…now I feel like I owe Debian’s web site an apology. I guess the consumer desktop Ubuntu distro doesn’t actually have its own web site anymore? I mean, you can get to it from there, but it’s hidden under menus, and seems almost like an afterthought. Ubuntu’s main web site is bizarre right now, with a prominent green “Download Now” button that does not lead the user anywhere close to downloading Ubuntu, but rather directs them to one of a rotating selection of signup forms to download various technical whitepapers like “A CTO’s guide to real-time Linux”. That’s a radically different target audience than the last time I went to their web site (and also a weird design anyway).
I just checked out Ubuntu’s web site for comparison, and…uh…now I feel like I owe Debian’s web site an apology. I guess the consumer desktop Ubuntu distro doesn’t actually have its own web site anymore? I mean, you can get to it from there, but it’s hidden under menus, and seems almost like an afterthought. Ubuntu’s main web site is bizarre right now, with a prominent green “Download Now” button that does not lead the user anywhere close to downloading Ubuntu, but rather directs them to one of a rotating selection of signup forms to download various technical whitepapers like “A CTO’s guide to real-time Linux”. That’s a radically different target audience than the last time I went to their web site (and also a weird design anyway).
I guess this has to do with the fact that BDFL Mark Shuttleworth after putting so much money into Ubuntu finally wanted to see some profit (I think I read that Ubuntu was not profitable for a long time) and went in the same direction like RedHat Enterprise and Novell SUSE had been going. If you look at Canonical Juju https://en.wikipedia.org/wiki/Juju_(software) launched 12 years ago, and things like Landscape https://ubuntu.com/landscape which has been there perhaps more than 10 years as well, and now with Ubuntu Pro it seems clear to me that Ubuntu was not just meant to be a desktop Linux distribution. In fact, nowadays when I try to find an iso file for an Ubuntu installation I need to be careful not to end up at a download page for the Ubuntu server iso.
Anyway, maybe I should instead try out and be recommending Pop! OS to new Linux users soon. It seems very popular https://pop.system76.com/ ;-)
Slackware - if it ain’t broken don’t fix it. Gentoo - USE flags. Mint - user-friendly.
Slackware needs to learn how to be hip like arch. I’m the baby in our irc group, and I’m 40. All the cool kids are using arch BTW.
Never cared much about trends.
It’s nice to find another slacker in the wild.
Slackware is broken, though.
- Its releases are so far apart that the default installer stops working in between releases cause it can’t handle the changes to the repos.
- Its default software selection is outdated, makes no sense (multiple tools for the same task), and is grouped illogically. If I want to run Xfce, I shouldn’t have to install the KDE group to satisfy necessary dependencies. If I install the base group, all dependencies for using the package manager should be satisified. And Libreoffice shouldn’t be installable only via an unofficial, unsupported third party repo.
- Its documentation is so outdated it isn’t useful anymore:
https://docs.slackware.com/howtos:slackware_admin:installing_on_uefi_hardware
“Some modern computers have started to offer motherboards that use Unified Extensible Firmware Interface (UEFI) as a replacement for the traditional BIOS.”
Don’t use it.
I did use it for a while, then switched to something else.
Still have a soft spot for it in my heart, I just wish they’d modernize a little.
OpenSuSe - snapper for taking btrfs snapshots and rolling back. It’s basically a bulletproof way to do updates and recovery. Get a bad update or change a config in correctly you can roll back. Updates it automagically does this for you
Possible in Debian. The SpiralLinux guy (who also made Gecko Linux) has it set up on install.
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.
You mention that their kernel is bloated, would you mind sharing how you measure it compared to other kernels. Such as their kernel vs something more trimmed down. Is it a storage space savings or memory? I’ve never really considered the weight of a kernel when considering different distros so if you have some method I’d love to try and compare what I’m running.
I have no comparisons as I think all distros ship the complete monolithic kernel. Of course specific IOT devices or Android ship a very much smaller kernel.
Building the kernel is not that hard, as you have
kernel-develwhich has all the sources.You can use
make menuconfigand see what all is enabled (as far as I understood this) and change stuff before compiling.Monolithic kernels are pretty bad, see this excerpt of the interview with Jeremy Soller on RedoxOS.
So I dont mind memory or even less storage space, as the kernel poorly is not relevant at all here. I just care about keeping the root binary with access to all my stuff as small as possible.
I would love a system that detects the used hardware and then builds the correct small kernel for it. There are experiments making the CentOS LTS kernel work on Fedora, which would prevent many recompilations.
Building the kernel is not that hard, as you have
kernel-develwhich has all the sources.Yeah. Some myth that it’s hard to do is not why we end up with monolithic kernels. Like any case where you find yourself thinking “it doesn’t look that hard; I could do that easily”, it’s either harder than it looks or it’s done a certain way for an entirely different reason you haven’t figured out.
You should learn that reason.
There are many steps that need to be followed, I didnt have the time yet but it is possible. You need to sign the modules and kernel, package as an RPM, sign that maybe etc. Its not as easy if you do it right but also not very hard.
If you don’t mind me asking, then how do you know the kernel they use is bloated compared to any other kernel? A vast majority of the device-list stuff is loaded only when that device is detected with kernel modules. You aren’t actually running everything from the entire kernel, it just has support for the devices if it does detect them. which is basically the functionality you are asking for, ad-hoc device modules.
Monolithic kernels aren’t “bad”. That’s subjective. Monolithic kernels have measurable and significant performance benefits, over micro kernels. You also gain a massive complexity reduction. Micro kernels, historically, have not been very successful, e.g. Hurd, because that complexity management is extremely difficult. Not impossible, but so far kernel development has favored monolithic kernels not without reason.
If what you say is actually that easy, why wouldn’t all distro’s just do that during the install, and during updates with their package managers? I believe you could do this in Gentoo, but I don’t know if it has measurable benefits beyond what performance tuning for your specific CPU arch would give you. Since none of those devices you aren’t running are consuming any resources beyond the storage space of the kernel.
“Their kernel is bloated” :D I dont compare with anything, as a linux distros job is pretty much to make me forget other ways to get “the linux stuff” because they are so good.
(Imagine how good Linux support would be if everyone would be on the same distro family like Fedora rawhide/stable/oldstable/centos-stream/almalinux;rockylinux;rhel.)
it just has support for the devices if it does detect them. which is basically the functionality you are asking for, ad-hoc device modules.
If that is true, and if the kernel will never load anything not needed for my device, then I am fine with it.
I see how monolithic is less complex and also a huge performance benefit over having the handshake between userspace and kernel space all the time (a meta dev on #techovertea talked about that).
But I would still want to debloat the kernel from unused code, as it is there somewhere and may get activated and used (why would you blocklist kernel modules otherwise?)
Also compiling for x86_64-v4 would probably improve speed, and it is rediculous to have the entire distro built for 20 years old hardware, neglecting all the improvements from over a decade.
Here is an alternative Piped link(s):
this excerpt of the interview with Jeremy Soller on RedoxOS
Piped is a privacy-respecting open-source alternative frontend to YouTube.
I’m open-source; check me out at GitHub.
It wouldn’t be too difficult™ 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
hwcapsis 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
Secureblue removes a good amount of unused kernel component, and even some useful ones like bluetooth and thunderbolts, but you can always manually enable them.
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.
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.
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.
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.
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.
