It’s been a while since I last gave it a try, but I remember frequently ending up in strange states where a window wouldn’t want to tile properly. Windows would also frequently end up overlapping or extending beyond the screen, in ways they just wouldn’t when I was using Sway, Hyperland or Niri. IIRC mouse dragging and mouse resizing windows was extremely jank too.

Most of this is KWin’s fault as far as I know, it’s built for stacking window management and there’s only so much you can fix with scripting around it. It’s also the reason for the bad multi-monitor experience; the way it interacts with workspaces in particular is in my opinion not useful and never what I want.

Additional cons:

• Layouts break easily
• Multi-monitor is close to unusable

Extensions aren’t apps. Imagine all mods would break if a game is updated and you’d have to wait… oh yeah you do, because that’s how these things work.

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.

You’re welcome, glad I could help :)

FN keys are usually handled at a firmware, sometimes BIOS or driver level. This makes them completely inaccessible to keyboard remappers (they have no idea when it is pressed), which is why none of them can do this.

This Stackexchange answer looks like it should contain the information you need, but I don’t have a 2014 MacBook to test it.

You could make the same kind of articles for the old coreutils if you really wanted to. Just creatively “rewording” the bugfixes from the recent 9.8 release:

• GNU Core Utilities Are Causing Failures [when copying between NFS and non-NFS filesystems with ACLs]
• GNU Core Utilities May Cause Data Corruption [with copy ranges larger than 2 GiB]
• Correctness Bugs Found in GNU Core Utilities [tail --pid may race with reused PIDs]

I feel like the reactions regarding uutils are a bit… off in general. There seem to be a lot of people who are pathologically negative towards open source projects for, frankly, bullshit reasons, like vague complaints about “Rust evangelism” (what?) or how permissive licensing is against the spirit of open source (WTF).

Phoronix isn’t helping with these clickbait articles which border on content farming and their failure to moderate their comments of course, but these negative attitudes seems to cut across sites, also including Lemmy, Reddit and even Hackernews.

The uutils team seems to be doing well but it makes me sad to think about any aspiring open source devs without corporate backing reading such drivel.

You could always swap out crons, syslog, init systems, and it would not affect Gnome.

That just isn’t true. Both GNOME and KDE already have hard dependencies on systemd-logind. GNOME hasn’t supported non-systemd Unixes since 2015! The only reason it works is that the elogind project provides a systemd-logind implementation decoupled from the rest of systemd. The GNOME team has elected to give users of elogind (despite not being officially supported) advance warning that they’ll have to do some amount of extra work in the future if they want to ship GNOME 50. Honestly I think that’s quite fair of them.

There are more GNOME features that don’t work without systemd even if it launches, like application isolation using systemd scopes. Fundamentally this is about not having to reinvent the world. Why should every DE have bespoke implementations of user, login and service managers instead of just using the ones that 99% of user systems already have?

Nu’s find builtin isn’t a GNU find repacement. I think what you actually want is ls piped into where:

ls **/* | where type == file

I do question the choice to alias a well-known program with a builtin that does something entirely different. You can also use ^find to avoid calling the builtin. I would’ve expected \find (bash-like) or command find (fish-like) to work as well, but alas…

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.

That’s not entirely true, unless you choose to nixify everything. You can just have a basic Nix configuration that installs whatever programs you need, then use stow (or whatever symlink manager you prefer) to manage the rest of your config.

You can’t entirely forget that you’re on NixOS because of FHS noncompliance but even then getting nix-ld to work doesn’t require a lot of effort.

No C program is written to satisfy a borrow checker and most wouldn’t compile with one, so adding it would require rewriting the world anyways. At that point why not choose a language that, in addition to being memory safe, also drastically cuts down on other kinds of UB, has sum types, sane error handling, a (mostly) thread safe standard library, etc.?

The mentioned performance governor runs the CPU permanently at maximum frequency, which is obviously bad on battery powered devices and on devices with lacking thermal headroom. I think it might cause problems in virtualized environments as well but I’m not sure about that.

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.

To be fair showing the overview on startup makes perfect sense on vanilla gnome, it’s only dumb if you install one of the two specific extensions that partly replace it.

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.