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.
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.
Most distros could also learn from Arch and create something similar to the AUR.
i’ve seen Void’s xbps-src tool 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” :D
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 nixlang.wiki has been better. However the latter is less known so has less content. All in all, nix documentation is still bad.
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.
Debian-variants on cmake. When I install cmake, it installs all libraries’ cmake files without the libraries themselves. You read it right. The correct way to do this is to install only the base CMake files (Arch does this, and I guess all other distros). CMake configuration files for libraries should be packaged with the library (not CMake).
Whenever I use CMake, these distros can’t show me the supposed error message. They just pretend configuration progressed and stop at random moments because some headers are missing. You see a compiler error, see missing headers, perhaps wonder if your install is outdated. Google it, and find out through Ubuntu SO that it’s actually that a package is missing WTF. Without someone writing it on the web for all Debian packages, maybe you’d have never understood what’s wrong!
I don’t use Debian for C/C++ development anymore partially because it’s so horrible.
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
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 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.
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.
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: src.fedoraproject.org/rpms/kernel/tree/rawhideYou 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: discussion.fedoraproject.org/t/…/2
In general, though, Fedora would not want to leave any users behind. Instead, the proposal for hwcaps is currently being drafted: pagure.io/fesco/issue/3151With 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: github.com/fedora-silverblue/issue-tracker/…/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.
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.
It would also be kind of weird to compare to Arch, since Arch makes you configure so much yourself.
Like, my biggest complaint is that I feel extremely naked without automatic btrfs snapshots. Obviously, you could configure those on Arch, but that would require understanding significantly more about btrfs than I currently do.
I had to read up on it just now, but I don’t think, that works in my case.
So, the worse distro here is Kubuntu. Personally, I use openSUSE Tumbleweed.
My problems with Kubuntu are mainly:
The bundled KDE is out of date and unstable. KDE is integral to my workflow.
No automatic filesystem snapshotting. If I fuck up, that’s my system ruined.
And yeah, it seems like Distrobox is mainly useful for running CLI programs, maybe individual GUI apps, but not whole desktop environments. And it re-uses the filesystem of the host system, so that kind of precludes filesystem snapshots, too.
I think NixOS would stand to benefit a lot by taking inspiration from openSUSE’s YaST system configuration tool. I think that if NixOS had a well supported graphical interface for creating and managing the system config, it would become so much more accessible to a very wide range of users who never would have given it a try otherwise, which in turn would bring in tons of new users and developers who will want to improve nixpkgs, etc.
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 !!!
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 do not recall other distros failing to update due to GPG key issues but it has happened to me on Arch distros many times. It is the biggest pain when converting from something like Manjaro to something like EndeavourOS as well.
I really do not understand why this cannot be fixed.
Not my current distro but I love ChimeraLinux, they manage to put musl and BSD userland into a working wonderful distro. I wish more distros adopted musl.
Ask the devs. I haven’t bothered asking so far. There’s fp 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.
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.
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
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 bin folder, 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.
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.
flatpak run com.github.iwalton3.jellyfin-media-player
You can use /var/lib/flatpak/exports/bin/com.github.iwalton3.jellyfin-media-player instead. 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
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.
Oh you can complain about both. Use WinXP-tc with XFCE to get a pixel perfect clone of the XP start menu. Then start complaining that distros are moving to Wayland where WinXP-tc won’t work.
Add comment