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.
I also think we could learn website design from… looks at notes …everyone else.
whacks you with a rolled up newspaper No! Bad. Wrong.
There is a beauty to simplicity that’s lost on so many. I can load a Debian wiki page over a dial-up connection at the south pole. The design is uncluttered and uncomplicated. That goes for every page on debian.org
I often see Mint recommended to new users, but rarely Debian, which has a goal to be “the universal operating system”.
I always took “universal” to be in the sense of “universal remote”: it’s not universally adopted, it’s universally applicable. The fact that it’s the upstream of so many major distros (including Mint) indicates that it’s accomplished that.
Making it “new user” friendly necessarily requires restrictions and choices made by the maintainers for the ease of the users, which negates the “unversality.”
I agree that there is beauty in simplicity. In my opinion, OpenBSD has the best website.
It’s not about using fancy effects, it’s about the sprawling logical layout and making it hard to navigate. It used to be better around 2005, when it had the left navigation index. I remember people said it was ugly then, but imho they changed the wrong aspects of it, removing the structure without adding simplicity.
For example, a new user reading this page l10n.debian.org will be confused. It only makes sense to me since I’ve already translated a bunch of debconf-po-files. These are my opinions, but you are welcome to disagree. Also, please don’t hit people with rolled up newspapers, it’s rude.
Alpine & OpenBSD with CLI installers, minimalism, lack of bloat and strong KISS philosophies, they remind me of what Arch Linux used to be – I don’t want any crapware if possible (dbus, systemd, polkit, logind etc). Just nice and simple.
The only one I have installed is dbus, unless you want to manually patch it out it’s pretty much everywhere (Gentoo is nice for this).
I’ve used Void over half a decade or so, runit is nice, but I think I like the Alpine ecosystem more, plus Void has some oddities to me.
For instance, in the repositories no forks of big projects like Librewolf instead of Firefox, no crytos like Monero, also xbps has both caps and non caps for naming for projects, it’s nice to not have to use caps to install things. I know you can get around most of this with stuff like flatpak :)
I tried Chimera and liked it but again Alpine has a larger ecosystem, it’s more established in that respect both from containers and router/server use.
I’m also pretty used to Alpine’s quirks at this point, I’ve run it a quite a lot on my laptop with a funky DIY ZFS install and also run-from-RAM quite a lot on USBs. Having a stable branch is nice too, although I never really had many problems on Void either!
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.
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.
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.
Alpine, by its use of musl over glibc doesn’t support DNS over TLS because the musl creator believes its better for user experience. It is in theory but if the other end uses it, you are out of luck and will likely spend days troubleshooting why one bit of software refuses to connect.
If you want Debian but user-friendly, just use Mint, Debian is easy enough to install. It’s like asking Gentoo or Arch to drop a easy installer, it would break the point of using it.
Would it detract from Debian if it had an installer which was more intuitive to new users? As long as they don’t remove the options to configure, I see no harm, only benefits. To me, the thing about Debian is that it’s a community. If a distro wants to be elitistic, sure, that’s up to them, but I don’t see Debian having that goal.
You could check out Spiral Linux for an “easier” installer. It has the option to use the Calamares installer from the live USB instead of Debian’s default. Also comes preloaded with back port repositories and, I think, Nvidia drivers.
I like that Spiral Linux is “plain” Debian, without extra repos. What I’m thinking is more along the lines of “why is Spiral Linux needed to begin with?” Sometimes downstream distros serve a niche function that warrants its own distribution, but sometimes I feel that if upstream improved, the need wouldn’t be there to begin with.
I don’t know. It’s difficult for me to answer because I’m so used to the Debian installer. But, for some reason the general opinion is that it’s difficult for many compared to some other distros.
More difficult because Debian rely more on the terminal than mint. The terminal is not a accessorie like on Windows, it’s part of basics Linux uses. In my opinion it’s important to learn how to be familiar with
I think text based interfaces is a strength of unix-like systems, valuable tools to be used when the situation calls for it. It might be a lot to ask of new users to be familiar with terminals before they have even installed the system though. If Mint can get the same result with a GUI, I see no reason why Debian can’t offer that option too, and let users discover bash and TUI when they have a working system.
When you’re beginner it’s normal to not be familiar with terminal, that’s why i recommend Mint as a first distro. What im saying is that We already have Mint as a beginner-friendly distro, we don’t need Debian to be as simple as Mint, also they included non-free firmware in their iso it’s pretty enough imo.
Gentoo and Arch do have easy installers (Arch via the Arch install script, Gentoo… Well, they provide stage 3 already built, a genkernel option, and even binary distribution now, which greatly simplifies the process)
Honestly, that one had me scratching my head too, I doubt I’d ever use the precompiled binaries on Gentoo myself
The stage 3 tarballs and genkernel, though, make an install that could take a week or more down to a few hours; having successfully built a system from a stage 1 with customized kernel, that’s not an experience I feel a burning desire to go through again
The Debian website is trash and I’m glad to see it acknowledged. People always take criticism of the website as if folks are saying it looks ugly. No. The layout is just icky.
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) 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.
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.
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.
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 !!!
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.
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.
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.
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.
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.
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
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.
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)
Add comment