That’s true from a technical perspective. But in reality devs (especially ones who aren’t making “Linux apps” but are doing things like porting a previously Windows-only game to Linux) will occasionally ship a broken Wayland client. The compositor could then still give that a basic titlebar with window buttons like KDE and Cosmic do, or alternatively it can refuse to do it and make the novice user annoyed at the system as a whole.

I’m not really convinced that requiring all Wayland clients to draw their own decorations was the correct decision in the first place, but even if we accept it, I think there’s still a convincing case for fallback SSDs.

Now if there was just an official API from all window managers that can check this configuration

This actually does exist. Reasonable Wayland Compositors will negotiate with their clients on whether they should use CSDs or SSDs. To an extent Qt does this: It prefers SSDs but it can draw CSDs if the compositor can’t draw SSDs (or signals that it doesn’t want to), which is why proper Qt apps are perfectly usable on GNOME Wayland despite missing SSDs.

It would be possible to go even further and make apps that display menu and tool bars on compositors that prefer SSDs (like Plasma/KWin) and nice GTK-style decorations on others. It just happens that most apps either really want to draw their CSDs (mostly because they’re made for GNOME, a.k.a. anything using Libadwaita) or they don’t really have a use for them (like regular Qt apps).

The biggest drawback of not providing any SSDs even as a fallback is obviously… what if the app just doesn’t draw CSDs? ~~There are many new Linux users who try to get something like DaVinci Resolve running and then can’t maximize it because it doesn’t have CSDs. For these users it just makes using Linux feel broken for basically no reason.~~¹

This is also a burden for application developers. Maybe the DaVinci Resolve devs should just fix their app (from what I heard it’s a massive PITA in all aspects imaginable), but is it really reasonable to also expect e.g game devs to add dependencies on libdecor or whatever solely to unbreak window mode on GNOME Wayland?

¹ Edit: I have since learned that Resolve actually does draw CSDs, it just doesn’t draw the window buttons. That’s certainly a choice… I think the overall point isn’t too affected but this specific app isn’t a good example since it would still be broken if GNOME had fallback SSDs.

That’s a largely unrelated topic… You can have theming without SSDs (as seen in most standalone compositors and also kind of Cosmic) and you can have SSDs without theming (at least in theory, I’m not aware of a project actually taking this stance).

There’s apparently a ZSH plugin for this with a quite a few stars, though I haven’t used it and can’t speak for how well it works. In other shells what you want just doesn’t exist to my knowledge, though it should be possible to script it with enough effort.

The problem is that in the terminal you always have at least two layers of input handling in the terminal emulator and the shell. And these layers talk to each other by emulating a 70s VT100. This leads to some issues, in no particular order:

• Terminal emulator keybindings will step on shell keybindings, and the shell will never know about it because it can’t actually see the keys being pressed.
• Even if the terminal doesn’t care about a key, it might be impossible or error-prone to detect anyway. This applies to surprisingly regular keys like Tab.
• As you’ve noticed some terminals try to get clever and do things like making Ctrl-C copy if you’ve selected text. The shell doesn’t know about this either.
• Most shells and TUI apps have selection modes. These are independent from terminal selections.
• There’s no standard way of using the clipboard in Linux, but multiple different ones that may or may not work.

All of these problems gets worse if you add multiplexers like tmux by the way.

Now it would be possible to write a bespoke terminal emulator and shell combination that unifies selection and makes all the reasonable keybindings actually work. There are attempts at this, such as the Emacs Eshell. Unfortunately Emacs people don’t quite share your idea of what reasonable keybindings look like (and it’s also a little bit broken, though for mostly unrelated reason).

Ultimately though the main reason this is an unsolved problem is that most Linux users just get used to the regular Readline line editor that all commonly used shells ship with. Complex edits can always be done in your $EDITOR (via C-X C-E in Bash).

I’m not a btrfs expert but AFAIK high unreachable space usage is usually a result of fragmentation. You might want to defragment the filesystem and see if that helps.

I will note that btrfs makes estimations of used/available space very difficult by design, and you especially can not trust what standard UNIX tools like df and du tell you about btrfs volumes. Scripting around du or using ncdu will not help here in any way. You might want to read this kernel.org wiki article as well as the man pages for the btrfs tools (btrfs(8) and particularly btrfs-filesystem(8)), which among other things provide versions of df and du that actually work, or at least they do most of the time instead of never.

There’s an argument to be made that system software like filesystems and kernels shouldn’t get too smart about validating or transforming strings, because once you start caring about a strings meaning, you can no longer treat it as just a byte sequence and instead need to worry about all the complexities of Unicode code points. “Is this character printable” seems like a simple question but it really isn’t.

Now if I were to develop a filesystem from scratch, would I go for the 80% solution of just banning the ASCII newline specifically? Honestly yes, I don’t see a downside. But regardless of how much effort is put into it, there will always be edge cases – either filenames that break stuff, or filenames that aren’t allowed even though they should be.

The usual problems with parsing ls don’t happen here because Nu’s ls builtin returns properly typed data. You can work with it in pretty much the same way you would work with it in Python, except that Nu has a composition operator that doesn’t suck ass (|), so you don’t have to write as much imperative boilerplate.

I have a number of reservations regarding Nu (the stability of the scripting language, unintuitive syntax rules, a disappointing standard library) but this particular argument just doesn’t apply.

Pano perhaps? It doesn’t show up at the cursor but you can search in it, the keyboard works the way you would expect and it auto inserts on selection.

How was it an obvious data breach? The attack was done via Codebergs notification system. It’s no different from the notification you got from me writing this comment.

In this case it’s more of a switch away from the last cool new thing. Totem (like Music) was built around a media library navigated from within the app. By default Totem doesn’t even support opening videos from the file manager, which is something you would probably expect of a video player. It also crashed for me when I tried using it as intended so I’m not surprised to see it replaced by an app that really is just a video player.

That said many apps get replaced not for feature reasons but just by being GTK3, and they tend to get replaced by their own forks to GTK4 (such as the upcoming replacement of Evince). Why their devs choose to upgrade toolkits this way I cannot say.

Insightful article. I have to confess I never realized the accessibility situation was this bad.

I also want to highlight this excerpt from the comments:

Making things accessible isn’t hard technically. But it requires coordination and people to care about it enough to work on it at the expense of other features. If [I] developed an application on a team and said I had ‘one security guy that works on that stuff as long as it doesn’t interfere with the rest of our work’ I’d be dragged over the coals and have my project forked by the public.

But with accessibility? There’s really no sense of priority or urgency despite it being broken for years and not putting much effort in to fixing it.

It’s prettier than a TTY and you can pick whether you want a Wayland or an X11 session without having to know the correct startup commands. You can pick between different desktops too. And a Display Manager can offer on-screen keyboard and touchscreen support while a TTY can’t (at least GDM does, I’m not sure about SDDM off the top of my head).

Aside from that whatever command you are using in the TTY to launch Plasma might or might not be the same commands SDDM uses, which might or might not lead to issues in setting up the environment. If your environment is fine and you don’t care about having to use a physical keyboard then of course you can remove it. It’s not exactly load bearing.

To be fair that’s not the entire story, since you need to actually resolve the conflicts first, which is slightly scary since your worktree will be broken while you do it and your Linter will be shouting at you.

You may also want a dedicated merge tool that warns you before accidentally commiting a conflict and creating a broken commit.

Oh and non trivial resolutions may or may not create an evil merge which may or may not be desirable depending on which subset of git automation features you use.

Using git status often is definitely good advice though.

I’m running KDE Plasma with the revived Krohnkite for auto tiling. Plasma 6.2 seems to have fixed most of the bugs from 6.0 and 6.1, at least the ones I’ve noticed.

I was using Sway/SwayFX for a few months but was missing some KDE Gear apps like Dolphin and Okular which I couldn’t get to display correctly. KDE is afaik the only desktop with a working Qt theming engine right now, so I can’t really see myself switching (unless maybe if they break Krohnkite again).

I agree.

The GDPR conversation is hilarious. Sure they’re a US based company, but after 5 years of operation I would’ve expected them to have consulted a lawyer about this at some point. Forgetting (assuming it’s not “forgetting”) about the required documentation is not the worst thing in the world morally but it doesn’t exactly make them look competent either.

Indeed, that all looks fairly innocuous. Just in case, you are sure that you didn’t just accidentially kill or killall rclone or bash?

Perhaps wrapping the script in strace might help debug where the offending signal is coming from.

TimeoutStopSec applies to the ExecStop command, TimeoutStartSec would be the culprit here. I’m not sure why there would be a default timeout of specifically 1:39 minutes though.

Does your script fork at some point (and might exit before the rsync job is completed)? Because then you need to use Type=forking instead of simple or oneshot, otherwise systemd will start trying to clean up child processes when the script exits.

Edit: Actually considering the time span involved Type=forking will not solve your issue because it will timeout, if this is the problem you need to change your script to not do that.