deleting all the dependencies of VLC

You mean like libc.so? Bold move, bold move.

Unless you’re running BSD or some other genetic Unix probably not as everything GNU is newer than that. GNU is 80s, original Unix 70s, in the 60s you still have giant minicomputers with very little standardisation, including ISA, and before the 60s there were not even compilers.

A decent chunk of software traces lineage back to then, even if the old code has been retired: vi is the screen terminal mode of ex with is a more featureful ed which got most of its features from qed which is 60s software. Cutting-edge: You didn’t have to punch holes any more, you had a keyboard and a printer. Someone figure out where dd has its argument syntax from so we know whom to blame.

Well, I’m using KDE and I set up a library eight months ago and… yes there’s a bug. Just checked. Not entirely the same but related to this:

https://github.com/ValveSoftware/steam-for-linux/issues/9797

There’s an official workaround mentioned there.

I guess KDE updated their portal protocol version some time in between and steam got doubly confused. Probably not a KDE bug, in particular because this kind of stuff is happening for many, many portal implementations.

And it’s not a dolphin window (with me) btw it’s a qt filepicker. Says “portal” at the end in the title, kde logo to the left.

add a secondary storage device to my steam library.

You mean have more than one steam library? That’s a steam setting. Nothing to do with KDE. Gnome, Debian or Fedora.

The flatpak works,

Oh. There’s your issue. Don’t run steam as a flatpak, there might be sandboxing issues.

EDIT: MF did you read the page you downloaded stuff from:

Note: To add a game library on another drive, first you need to grant the app access to it:

flatpak override --user --filesystem=/path/to/your/Steam/Library com.valvesoftware.Steam

That’s not going to work radarr is a daemon. Well at least it’s not going to work as intended, you might be able to start the thing as a user, but it’s likely not what you want to do, you want the thing registered with systemd and start up and shut down with the system. We don’t nix-shell -p sshd either.

The trouble with the *rr stuff isn’t libraries, it’s as far as I know all written in .NET, but system integration. Setting up users and permissions, starting the daemon, if necessary punch a hole in the firewall.

I, too, watched Linus’ rant about diving software and that neither distros should be required to package random-ass applications, and app developers shouldn’t be forced to package for random-ass distros. That’s why we have flatpak. There may or may not come a time where such a thing also exists for daemons but it’s not the top priority, also, if you’re running radarr you’re not just a random user, you’re at the very least a power user. Random users direct their browsers to a website, click a link, which then opens qbittorrent. Which btw also has a rss feature. You don’t need a daemon process to do all this stuff, I doubt radarr sets up a system process or whatever it’s called in windows, either, you can do it as a user. The whole design of the thing assumes that you run it on a server, and, therefore, know how to run a server.

As such, two observations: First, that radarr is not a good example subsurface is (and precisely what Linus was talking about), secondly, power users know even less what users actually want than devs.

And presumably you want that fixed. To do that, you have to figure out who needs to do work. In one way or the other, that’s going to be the devs.

We might be using different connotations of “blame”, here. Like, I’m using the git blame one.

The bottom line is that Linux is harder to use in a lot of scenarios.

And who’s at fault? The devs. To wit, the radarr devs. Really, the minimum there should be calling what they describe “manual installation” and saying “we don’t package our software for distributions, consult your distro’s package manager radarr might be available”. It’s a daemon so it’s not like they can ship a flatpak, deamons need system integration.

The whole sonarr/radarr/prowlarr/whatever-rr dev folks don’t seem to be particularly Linux-affine in general. I consider it windows software that happens to run under linux, developed by presumably windows users running linux on their seedbox because if there’s one thing that’s worse, even for windows-heads, than learning a bit of linux then it’s using windows in a server role.

Yeah that’s just radarr devs not actually packaging the thing.

Compare the nixos instructions. Which, mind you, is not a distro for beginners, the faint of heart, or generally people who are neither functional programmers nor devops, but that’s how easy it is when you package shit properly.

I think you should double-check what I linked to: To the xdg desktop protocols, that’s a dbus thing, it’s not a wayland extension much less the core wayland protocol. It’s the same protocol flatpack apps use to do stuff, figures that APIs that are useful if you’re in a sandbox are useful in general.

X does not handle global hotkeys. It gives everyone full access to everything and then expects them to not fight for control, which took decades to actually happen, before that the desktop would often break down as clients were fighting. Any client can warp the pointer, capture all keys, watch how you enter a password in another window, say it’s the one which should be on top of all the others, it’s a nightmare.

Judging by the types of misunderstanding you have I must assume that you’ve never written a single line of X or wayland related code. Know, therefore, that you are completely unqualified to hold the opinion you have, much less hold it strongly.

I’m not sure what you mean with “all of wayland”, here. The protocol is ludicrously small and minimal. It’s a way for programs to say “I have a graphics buffer, please display it and also give me some input like mouse motions plz”. Everything else is extensions because there’s devices (e.g. in automotive) that need only that, and nothing more, no windowing no nothing. You certainly don’t need global hotkey handling if all you ever run is one full-screen client.

Whether the compositor wants to implement windowing logic (say, tiling vs. floating, what happens when you right-click a titlebar) itself or outsource that to another process is not wayland’s concern.

KDE didn’t go that way because kwin was already an integrated compositor and window manager when it only ran on X, the smaller projects do seem to tend into that direction but they haven’t agreed on a common standard, yet.

I’ll quote myself, as you didn’t seem to have read it:

They can’t just log all your keystrokes globally because that’d be a keylogger. Also there’d be no way to resolve conflicts between shortcuts.

Go ahead, tell the X devs that their new protocol is worse than the old. That, instead of improving on things and creating a thing that won’t become unmaintainable, they fucked up royally and made things worse. I’m waiting.

If you want to go and continue maintaining X then go ahead, noone’s stopping you.

Or maybe you accept that the people who have been maintaining it for decades know a thing or two about the thing, and you’re just whining from the sidelines.

KDE locks the screen out of the box, in fact looking through the GUI options I currently see no way to do a screensaver without locking. Though granted you don’t need the compositor to do that anyways.

What’s true is that not just any program can lock the screen under wayland, it has to be the compositor or a program the compositor grants the power to do so. That’s so that “press alt-tab to login” type prompts can reliably sniff out keyloggers.

xmonad doesn’t, though using xmobar is common.

Trying to replace KDE’s task bar is quite more involved than exchanging all those minimalist bars for tiling wms, it’s way more tightly integrated. It is a separate process even on wayland, though, so the API to e.g. get live video previews of windows is exposed, in principle anyone can use it as long as KDE spawns you as a task bar and thus grants you access to the API. Which is probably just a matter of changing an obscure config file somewhere, they never hardcode such things.

And if you’re comfortable with them changing the API under your feet because they probably didn’t submit it on the standards track because, as said, the whole ecosystem isn’t exactly mature, DEs themselves are still figuring out how to best do things and to establish a standard they actually have to agree on a common approach. There’s no taskbar stardard for X btw, either, or at least xmobar is being fed a proprietary format string via fifo every update. It’s basically just a fancy text box.

Security aside if there’s no central management you can have multiple apps listening for the same keybinding, I wouldn’t call that “simpler to work with”. It may be easy in the short term, but the dark side of the force always is.

Everything lands on the compositors. Features that existed for the past few decades in X and are deeply integrated into the ecosystem were relegated to second class citizens or just ignored

There were ten years that the desktop environment people wasted, where all those interfaces could have been created but they only started in earnest once the x.org devs put their foot down and said “nope we’re serious x.org is unmaintainable we’re not doing this any more”.

And no, X didn’t solve any of those problems – what it did was provide completely unrestricted access to everything to anyone and it took multiple decades before different clients would stop fighting each other over control over the desktop. That clusterfuck was one of the things that x.org devs wanted to avoid, but they, not being DE devs, also didn’t know what DE people actually needed. So they asked. And, as said, didn’t get an answer.

Dual GPUs are no issue for x.org it’s just that automatic configuration assumes a somewhat standard machine or it gets confused. Should I tell you about the days before automatic configuration, of hand-editing XF86Config to tell the X server that no, I didn’t have a serial or ps/2 mouse but an USB one, and it had three buttons and a mouse wheel? Of seeing a list of monitor timings with the comment “CHOOSING THE WRONG THING MIGHT DESTROY YOUR HARDWARE”?

xrandr is actually quite recent (or I may be ancient), being able to do all that stuff at runtime was a godsend.

In practice wayland is way more composable that one would, at first glance, expect, and even accidentally so, because DEs are made up of different components often sharing common interfaces, so the cosmic task bar will run under the sway compositor and suchlike. Not just “run” as in “not crash” but “actually display tasks based on information from the compositor”. I expect further standardisation there once the ecosystem matures a bit more. Just because you can include a task bar directly in the compositor process doesn’t mean you have to, and the same goes for window rules, window decorators, whatnot.

You’re aware you just called the x.org developers Elon, do you?

x.org is just as much a freedesktop project as wayland is or dbus. Or, before they spun off, flatpak. Wayland grew out of the x.org devs deciding that the thing has become literally unmaintainable. The recent pain is caused by downstream devs (including kde, gnome etc) noticing quite late that the x.org people were actually being serious, if they had provided input earlier then the gazillion of protocol extensions that people are whining about now (such as global hotkeys) could’ve been finalised literally ten years ago.

x.org still gets a couple of patches – for xwayland. At some point they’re going to rip out the whole graphics driver stack and replace it with a wayland compositor, that compositor plus xwayland will be the X server. You’re free to build a PC with a good ole S3 Trio but don’t expect future x.org releases to support it.

Have a look here. Not sure how they do it the proper way would be to run the desktop environment as a subcompositor of autokey.

Meanwhile, though, do try CLI automation. It’s the Unix way.