It might be more expected for you but I’m going to differ.
for an article (or a link to a image), it takes you there instead.
… and then you can’t get to the discussion.
The RSS-2.0 definition of <link> is
The URL to the HTML website corresponding to the channel.
so clearly, it should point to the lemmy post. No other RSS feed that I know of has this problem.
Fortunately, emacs can flex around this, but duh! Where can I raise a bug report?
waybar is good
scrcpy for android connectivity; syncthing to get files to and fro android (and any other linux system)
clipman for clipboard manager
wallpaper - whatever for? with a TWM you rarely see the background
emacs - because it’s life (I jest)
Can’t believe no-one mentioned voidlinux yet. It’s very tasty.
I daresay there’s a way to do something like this with fzf
Maybe check here: https://linux-hardware.org/
waypipe - yes. But also wayvnc - I’ve been using wayvnc for a couple of years to export a headless wayland session from a file server. FOr my sins I use vncviewer on XWayland to consume it as it still seems to be the fastest.
To imply that systemd is merely an init system is ingenuous at best and dishonest at worst - systemd is so much more than an init system, as that article mentioned. Since the article was written in 2014 systemd has grown massively in scope, even more than the author feared.
It manages DNS, home directories, system services, seat managment, cron, system logging, booting… the list is ever growing. As such many people fear it is becoming too dominant through making more and more software dependent on it. It is not atomic - it is very difficult to have just one piece of systemd as its parts are tightly integrated and inter-dependent.
One could even claim that systemd failed in it’s original remit - to make startup as fast as macOS by running tasks in parallel and by deferring service startup until they are actually needed. The result has been a not very performant init system - many init systems are faster eg runit, dinit. The systemd people now claim that speed is not a design goal.
It is, however, open source and very widely adopted. Most people don’t care - they just want to run their browser and word processor.
I followed up on github as you suggested and a very nice young man took a look at it and said that the code already does work the right way (at least the way I and their little poll think it should work). But, it turns out that the fix (from 2021) has not been deployed - it’s to be in the next release.
So I don’t know what will happen now - I’ll continue to use my workaround, so I’m happy enough.