If it can’t be done in the GUI, it’s not worth doing.

Anything can be done in the GUI, specifically often a lot of things not worth doing. The question is if it makes sense doing something in a GUI and if (since we’re talking about FOSS here) someone is willing to spend their valuable time developing an app they won’t use themselves, that does the same thing but worse and in a GUI.

Also this was about Linux beginners, not this mythical “basic user” that supposedly doesn’t care enough to learn, but enough they want to switch away from whatever crap they were served by Apple or Microsoft.

I’ve been using Gentoo since 2008 as my main distro. Some Arch and Ubuntu on the side. Gentoo for me sits right in the middle of Arch’s pragmatism and the customizability of something like NixOS/Guix.

Portage on its own is a game changer. And forget about the compiling and ricing, that’s not the main benefit, which are:

• USE-flags to manage dependencies and only install what you want with the feature set you want
• downgrading/masking packages at will with dependencies still intact (on other distros this might work for a time, but things will silently or colossally break unexpectedly)
• fully flexible choice between stable and testing versions
• managing config updates via dispatch-conf and getting notified about pending config updates after each operation
• getting news of breaking changes or migrations directly through the package manager via eselect news
• applying custom patches to package automatically by dropping them in a config folder
• using portage bashrc to modify packages on the fly, with hooks for each step of build and installation
• Writing ebuilds and deploying them in an overlay is the most straight forward and easiest way to do custom packages in Linux
• setting up custom portage profiles to share a branching tree of configuration between systems

I also think the philosophy of the devs and maintainers is entirely different than on Arch. Take the difference of the above mentioned news via the package manager to Arch’s philosophy of “you’ll notice the breaking changes by the system breaking” maximum simplicity at the cost of many more sharp edges for the user. I can’t count how many times I had to revisit the /etc/pacman.d/mirrorlist, manually reset the keyring, clean up optional dependencies by hand, manually reinstall the AUR-helper etc. While on portage, when it says you’re good, you’re good. And anything you need to do in addition, it will tell you.

That said, while the system is very maintainable and pragmatically customizable, and with the official binhost, compile-times aren’t a big issue anymore, the learning curve certainly is very steep. More than any other distro, Gentoo is what you use when you want to get your hands dirty AND reap the reward in a system that runs like a well oiled machine.

Ultimately, as I said, I want to move away from KDE/Plasma. If I were to build a replacement for Khotkeys and go through the whole contribution process, possibly including some maintenance commitment and years of bikeshedding, I’d be more invested into KDE, not less.

Sadly no. I know this one and there is a couple of similar applications out there that all work pretty much the same, using a virtual uinput device to do low-level remapping of key to key. You can do macros or chords with these, but that’s not what I’m after, and in any case, I prefer to do remaps and macros like that first on my QMK keyboard directly if possible, then XKb second.

Khotkey on the other hand could (among other things) remap keys per window. For example you could say that for key presses sent to Firefox (which has no built-in way to redefine hotkeys), make Ctrl-W not close the window but do this thing instead, or use these keys to move between Ctrl-f search results. These remaps would then affect Firefox and only Firefox, while with apps like the one you linked, remaps would always affect the entire system.

Another feature was freely configurable mouse gestures that can work in any application and do different things in each application.

The reason we don’t have anything on wayland is that there is no generalized way for third party apps to intercept, modify, redirect or inject key events. Even global-hotkeys are still lacking in support and lackluster and complex in implementation. This is by design and there are good reasons for this, but it leaves the job of implementing this functionality (as so much on wayland) with the compositor, i.e. here Plasma, Kwin or some other module that’s tightly integrated with them.

End of 2025 and still missing a replacement for Khotkeys. Plasma is still great all in all, but after almost two decades on KDE I feel like I’ve outgrown it and tried to switch away a couple times now. Time to stop procrastinating and getting on with writing my own wlroots compositor.

The other main issue for me is dealing with moving or copying things around.

I don’t think anyone needs to do a lot of file-management on the command-line. GUI file-managers are perfectly fine for home-directory stuff, USB-drives, network directories etc., but you’ll run into problems when accessing system files. There’s also TUI file managers like Midnight Commander which some would probably consider the best of both worlds. I personally prefer dired on Emacs (and Emacs in general to most terminal based applications).

As I said in the beginning of my comment, you can do 99% of your daily Linux desktop usage in the GUI, and you don’t have to be used to or fast with the terminal. I just want new users to get rid of that fear, so that when they need to do something with it, they’re not giving up or putting it of, but read and try their way through it and maybe learn something cool. Every Linux user (managing their own system) will need it once in a while and that’s probably not going to change in the near future.

And a lot of common things can be printed/written on cheat sheets or getting stickers with common commands to put on the side of the case or stuck to a desk in easily glanced at locations.

I’m a developer and pretty experienced with the terminal, but I still do this. Not printed out or anything, but for each program with complex switches (like ffmpeg, qemu, docker, git, curl) I have an entry in my personal Wiki (also Emacs: org-roam) giving me a quicker overview over things I’ve already figured out in the past than a man-page can provide (it doesn’t hurt though that Emacs has a pretty great man-page viewer too).

H265 is not libre.

H.265 is also not software but a specification that ffmpeg implements, and the implementation is libre. Additionally there’s also x265 a decoder/encoder that also implements it, that ffmpeg can use, but that is also FOSS.

But they can be distributed together because it’s non-commercial.

To be clear: ffmpeg does not ship any proprietary blobs in order to decode H.265. It’s implementation of H.265 is fully FOSS as well.

They won’t have h265.

This is plain wrong and repeating it doesn’t make it any better. A libre distro with only libre software can decode H.265 just fine. In multiple ways.

But any completely non-commercial software that wants to bundle h265 in has cart blanche to do so.

I’m trusting your claim here, that that’s the case, but even then, it would be more like: Any completely non-commercial software can ship a FOSS H.265 implementation with a bundled royalty free license.

If you don’t want to bundle a license, you don’t have this problem to begin with, you can let the user worry about that, which the user can then just dismiss without legal consequences (in any sane legal system).

I guess some distros felt that was legally murky for them and others aren’t comfortable with non-libre software.

Let’s get something completely straight: ffmpeg is completely, 100%, no-restrictions, free as in libre software. This has nothing whatsoever to do with “not being comfortable with non-libre software”. That’s just FUD at best.

Legal considerations about patent/license trolls in corrupt neoliberal hell-holes might be justified for commercial projects. Most distros however seem to be getting away just fine by assuming end-users get their license for the codec/patents somewhere else if they even need one.

H.265 is a pretty major one. E-AC-3 for audio.

With regards to patents or not being free software? Because ffmpeg includes those and is definitely free software. You also need x265 for encoding I think, but that’s also free software.

It’s not hard.

Sure. I was just surprised it’s still a thing at all. None of the distros I use have this problem (Gentoo, Arch, Ubuntu, Libreelec).

It depends on the distro and how it feels about shipping non-free software.

Wait, what codecs (commonly used by Linux distros) aren’t free software?

As far as I know the original issues back in the day was with patents, not licenses, especially with MPEG. And because it was patents (which I think aren’t even valid in most jurisdictions except the hell-hole called USA), the issue was mostly with what commercial distros wanted to ship to their customers, not what the end-user could legally use. These days I thought we’re using mostly patent-free codecs or people realized they aren’t really enforceable anyways. Fedora maybe kind of makes sense, since its users are basically free beta-testers for RHEL, which is mostly US-based and commercial, so would be the most likely to be affected by patent-trolls.

Contrary to what others write*: Yes, the terminal.

It’s not that you can’t get by without it on many distros, for most things. But for even for medium and non-techy users, getting the fear of the terminal out of the way early will make their journey much, much smoother. It doesn’t have to be much, no shell scripting or anything, just the basics, conceptually what a terminal is, what the shell is, how to execute stuff, maybe chmod +x to execute, other utilities like ls, cp, mv, mkdir. maybe symlinks/ln. That’ll be enough to take away the fear if they see any “Now do this in the terminal” advice online (which they absolutely will, let’s not delude ourselves), and maybe enough to get them to notice that “huh, sometimes the terminal is more convenient, they weren’t bullshitting when they said that”.

*) Since you asked about “beginner Linux users” and not users that “just want to use their computer and not think about the OS at all”, I’m pretty confident about that assertion.

PS: I really think that’s not too much too ask. I remember my mother learning DOS commands back in the day for a regular desk-job. Everyone can do this, it’s not difficult, people just have to let go of a few false preconceptions drilled into them by the industry (MS, Google and Apple).

How to install video codecs

Is that really still a thing on modern distros? I haven’t had to think about that in literally decades (on Gentoo).

Why does it matter to you? If the developers are fine with the license and how the code they write can be used under it, that’s their prerogative.

That’s a bit short-sighted. On the level of the individual project you are right, it’s the dev’s choice. And I think permissive licenses also have a place with security critical software like crypto libraries, where everyone benefits from secure libraries being used as much as possible, even in proprietary software.

But on an ecosystem level, this trend to permissive licensing is very worrying, because if it reaches a critical mass, it opens us up to EEE scenarios. Android is already bad enough, only made bearable by Google having to release much of the source code. Imagine what it would be like today if Google had succeeded with their Fuchsia efforts. So we should at least be wary and give a little pushback to this trend. It’s valid to question if everything under the sun has to be rewritten and if it does, why does it have to be permissive licensing? What’s the end goal?

It works via SANE and so should work with all the standard scanning apps in Linux. Personally I prefer GUI apps because they give me lots of additional control (I use KDE’s Skanlite).

However SANE itself ships a command line tool, but that needs to be triggered on the device that uses the scanner. However, I noticed that when the GUI app is active, I can start the scan with the button on the scanner, so there might be something that can be worked out to always have the scanner connected and pressing the button scans into a network share (or something like that), but that’s outside my experience. If it works with any other SANE scanner, it should work with AirScan.

I have an Epson EcoTank ET-4850 and it works really well. And even though that’s not under $200, cheaper ink might make up for it.

Regardless of the model, what you want is a printer that supports CUPS driverless LAN/WiFi printing and the Apple AirScan protocol (also driverless) for scanning (which the model above supports both). If configured right, CUPS will just detect your printer and it will just work, no installing drivers, no choosing models etc., same with SANE for your scanner, without defining backends.

USB-devices are always a gamble where even minor model-number differences might entirely break support. Better make sure to check on the compatibility list and scour the mailing lists and forums for some crumb of information that your specific and exact printer model is supported and someone verifies it’s working. Ideally test before buying, or not rely on USB.

I’m really curious, what’s your favorite shell?

Emacs eshell+eat

It essentially reverses the terminal/shell relationship. Here, it’s the shell that starts a terminal session for every command. Eshell is also tightly integrated with Emacs and has access to all the extended functionality. You can use Lisp in one-liners, you can pipe output directly to an emacs buffer, you can write custom commands as lisp functions, full shortcut customization not limited to terminal keys, history search via the completion framework (i.e. consult-history), easy prompt customization, etc.

There’s also Tramp, which lets you transparently cd into remote hosts via ssh, docker containers, SMB/NFS-shares, archive files, and work with them as if they were normal directories (obviously with limited functionality in some cases, like archives).

And probably a lot of stuff I’m missing right now.