I mean, yeah, this shouldn’t be seen as an announcement or whatever, but rather as a thing to discuss and potentially get involved in. KDE is a community project after all.

I mean, I do like the idea, but syncing such a database file is by far the smallest challenge about this (and could be easily achieved today with e.g. Syncthing or Rsync).

The far harder part is getting RSS readers to support the same file format. There is actually a small project (by basically a singular guy), which tries to accomplish this: https://github.com/39aldo39/DecSync
The desktop RSS reader it supports is GTK, though.

Somewhat of a technologically simpler solution might be to self-host FreshRSS.
Unfortunately, it is of course less simple to actually use, unless you have a home server and some sysadmin skills…

Well, I have it bound to Super+X, but you could do any of those. I just create a .desktop file for it and then it can be used like a normal application. And well, it is intentionally built so you don’t have to pass command-line flags or see the command output for creating the file.

So, this is the program I use: https://codeberg.org/trem/jot
It has basically three larger features, which is adding a file, removing empty files (because you sometimes might end up creating a file, but not using it) and then searching through empty files.
Honestly, none of these are particularly difficult to throw together in a Bash script yourself, if you don’t feel like using a random program off the internet.

Basically, for adding a file, this is a crappy version of it:

data_dir="$HOME/.local/share/notes"
mkdir -p $data_dir
date=$(date +%s)
file_name="$data_dir/${date}.md"
touch $file_name
xdg-open $file_name

And for searching through the created files, grep -iR -C2 $data_dir is virtually just as good, too. 🫠

Hmm, if I understand you correctly, this is about Windows blocking access to files while they’re being accessed by other processes. Kate is primarily built for Linux where this would not be a problem to begin with, so it is well-possible that it does not handle this gracefully.

But it does actually keep its own buffer for files. By default, you have to actively click in the UI before it will load the changes from the file. It does watch the file for file changes, but I don’t think, it has to keep the file open for that, since there’s kernel APIs to be notified for file changes on all mainstream operating systems these days.

So, uh, TL;DR: I don’t actually know, but I’m somewhat optimistic. 🫠

I have a tiny program/script that creates a file in a folder underneath ~/.local/share with basically just a timestamp in the file name and then it opens it in Kate. Certainly somewhat of a workaround, but it works quite well for me.

I would try to avoid driving over them when safely possible, because they make an annoying noise, which I wanted to spare folks living nearby from. ¯\_(ツ)_/¯

Yeah, I was gonna specifically pick out biology. Feels like the more you know about it, the cooler it gets to just head outside and look at critters. Kind of like Pokémon, but real.

Most developers I’ve looked at would happily just paste the curl|bash thing into the terminal.

I mean, I typically see it used for installing applications, and so long as TLS is used for the download, I’m still not aware of a good reason why you should check the Bash script in particular in that case, since the application itself could just as well be malware.

Of course, it’s better to check the Bash script than to not check it, but at that point we should also advise to download the source code for the application, review it and then compile it yourself.
At some point, you just have to bite the bullet and I have not yet seen a good argument why the Bash script deserves special treatment here…

Having said that, for cases where you’re not installing an application, yeah, reviewing the script allows you to use it, without having to trust the source to the same degree as you do for installing an application.

One thing that will become important pretty quick if you continue making these scripts is that it’s almost always better to wrap your variables in quotes - so it becomes yt-dlp -x “$a”.

Oh man, this reminds me of the joke that any program that’s more complex than Hello World has bugs – and folks still don’t even agree how to spell “Hello, World!”.

Of course, Bash is a particular minefield in this regard…

To be fair, Sarah Bond was in a similar position and is a woman of color, too.

Oh man, for some reason I thought the title was going to end with:

by boosting software and network service efficiency.

Of course, they’re just talking about offsetting the costs, not actually about reducing them. 🫠

Yeah, I’ve done that occasionally, too, but it adds a load of friction for moving windows between screens, in particular also when un-/replugging the screen, so it’s still painful enough that I don’t bother with a second screen.

I guess, it also plays a role that I do use lots of workspaces, so it’s 1) extra painful and 2) I don’t have as big of a need for a second screen, since I can just switch out what first screen displays very quickly.

Oh boy, feature freeze for Ubuntu 26.04 is on Thursday. Hopefully, they still include this update.

My work laptop unfortunately comes with Kubuntu LTS and I desperately want the virtual-desktops-only-on-the-primary-screen feature on there. Currently, I’m the guy that actively disables all but one screen, because my workflow does not work at all with the secondary screen switching in sync with the primary screen.

I still wouldn’t assume it to actually go further than that. It’s a limitation of the EWMH standard, which is used for controlling the placement of windows.

I don’t have in-depth knowledge of the standard, but I assume, it can only represent 1 desktop as the active desktop and stuff like that.
Maybe you could try to be clever by e.g. always reporting the active desktop of the active screen and stuff like that, but yeah, no idea if you can do that for all aspects of the standard, and whether applications will still behave as expected.

It’s mentioned as the second point in “But that’s not all…”:

An optional new login manager for Plasma

Are you thinking of the volume icon in the systray? For that, it’s pretty standard that scrolling changes the volume, yeah. @muusemuuse@sh.itjust.works is talking about the volume of each individual application, though:

(I have hardly used Windows for the past decade, so no idea, if it has it.)

Ah, no worries! Taste is hard to describe. 🫠

I’m not saying, that the taste isn’t strong enough for me. I’m saying that it actively adds a taste, which I can best describe as “hollow”. Falafel or hummus with cumin tastes worse to me than without…

Yeah, I was thinking that recently when I realized I’ve known

for as long as I can remember.

I’ve also known

before I was even old enough to watch the movies, too.

I’m sure they’re cool movies, with lots of cultural relevance, but they’ve been spoiled in every possible way for me, specifically because the older generation loves them so much that they can’t shut up about them.

Oh man, what the fuck. What I really don’t like about this is that you assume some sort of motivation when someone submits a PR. When they provide a feature implementation, a bug fix or a configuration change, you assume that the way things were before did not work for the contributor. That it was so problematic, that they invested quite a bit of time to scratch their own itch.

You simply can’t look at a PR in complete isolation and just evaluate whether its changes are positive or not. On some level, you’ll decide that, sure, if this user is better off with this change and it doesn’t break anything, then might as well merge it.
But there is no user here. It’s going to include pointless changes that just need to look plausible enough, so that this bot can bolster its credibility.