I guess, those don’t work for hidden/minimized windows.

Perhaps worth considering a bspwm-like workflow. Rather than minimizing windows, you put them onto another workspace. Just absolves you from dealing with the whole concept of minimized windows…

Lots of “modern” languages don’t interop terribly well with other languages, because they need a runtime environment to be executed.
So, if you want to call a Python function from Java, you need to start a Python runtime and somehow pass the arguments and the result back and forth (e.g. via CLI or network communication).

C, C++, Rust and a few other languages don’t need a runtime environment, because they get compiled down to machine code directly.
As such, you can call functions written in them directly, from virtually any programming language. You just need to agree how the data is laid out in memory. Well, and the general agreement for that memory layout is the C ABI. Basically, C has stayed the same for long enough that everyone just uses its native memory layout for interoperability.

And yeah, the Rust designers weren’t dumb, so they made sure that Rust can also use this C ABI pretty seamlessly. As such, you can call Rust-functions from C and C-functions from Rust, with just a bit of boilerplate in between.
This has also been battle-tested quite well already, as Mozilla used this to rewrite larger chunks of Firefox, where you have C++ using its C capabilities to talk to Rust and vice versa.

A few years ago, I set up a home-server with music and some pictures on there, and recently I noticed that my storage disk was getting full. Then I saw that the disk only had 16 GB and wondered, where the hell I got that small of a disk from.

So, I go to plug in a bigger disk and can’t even find the original disk at first. Turns out my whole storage capacity was one of these bad boys:

And yeah, I’ve got about 1800 songs, clocking in at 5.8 GB, so even that tiny storage would easily be enough for a much larger collection.
And I do also have them replicated on my phone, for listening on the go. (Don’t even need an SD card in my case.)

Presumably, that ampersand needs to be replaced with &…

The description in the ticket isn’t too bad:

allows users to make a window disappear and keep only its title bar visible.

It really just hides the window contents. In effect, it is similar to minimizing a window, except that it doesn’t spring into your panel and rather stays in place as just the window title bar without the contents.

It is a niche feature, if you couldn’t tell. But it isn’t some KDE specialty feature; various other desktops and window managers also support it. I think, it was more popular in the early days of graphical user interfaces, when we were still working out, how we want to do panels and such.

And conversely, I do think it makes more sense as a feature on big screens like you can have today, where your panel might be quite a bit away.
Don’t think, window shading will make a big comeback just yet, but yeah, probably enough existing users that use it, so that it would be cool to support that workflow.

recreational coding

Well, good news, it actually is fun to dick around in the Nix configuration and see those changes manifest on your system.

The purpose is similar, i.e. configuring a system, but I’d say Ansible works best, if you need to make a few small changes from an existing distro, whereas NixOS rather takes the approach of controlling everything about the operating system.

And in many ways, controlling everything is actually simpler.

As the other person said, the bit about Arch is just the preamble.
But you can use Nix Home-Manager on Arch (or other distros), if you’re so inclined, which will give you that reproducibility for the stuff in your home-directory.

In some ways, this is like backing up and restoring your dotfiles, but it allows you to template those dotfiles and depending on the program, it offers simple ways to populate the dotfile templates. For example, KDE applications don’t generally offer very legible dotfiles and so configuring e.g. a panel via dotfiles is kind of a pain. To help with this, there’s Nix Plasma-Manager.

Copy Link to Highlight is my favorite addition.

To be fair, your “SUUUPER stable” is another person’s “not really going anywhere”…

Yeah, I also recommend this. Particularly with laptops, it’s good to have a full-fledged desktop environment, since you’re more likely to need WiFi, power management, easy display configuration etc…

That is a good tip. Unfortunately, I am too fish to understand it. 🙃

I just type ps and in 9 out of 10 cases, my shell suggests ps -ef | grep <process-name>. So, it’s actually less for me to type than “pgrep”…

Ah, that was a brainfart. I do use pkill primarily. I just use the other command, when I’m not sure what the process is called…

Yeah, I especially don’t understand it here, because it’s a graphical tool. You don’t have to keep backwards compatibility.

Even if you’re worried about people depending on the format that’s being piped, you could keep only the piped format stable. We have the technology.

Yeah, I would often just grab htop because I had no idea how to read the CPU usage out of top.
For example, for me it says:

%Cpu(s):  0,4 us,  0,4 sy,  0,0 ni, 98,8 id,  0,0 wa,  0,3 hi,  0,0 si,  0,0 st

Now that I look at it, I can guess that us and sy are supposed to be user and system time. And I guess id is supposed to be idle.
I have no guess what the other numbers might be, though. And well, I would often like to see the CPU usage per core.
Now I know that I can just press 1t and get effectively the same view as in htop.

I might learn top’s filtering workflow, too. But so far, I always killed processes with ps -ef | grep <process-name> and then kill <pid>, which isn’t particularly more cumbersome, so will see…

What terminal emulator are you using where ctrl-c copies instead of sending SIGINT when text is selected?

I know that the terminal emulator built into the JetBrains IDEs works that way…

I can’t really sell this as a solution, as it requires quite a lot more involvement than a simple configuration file should, but I use Nix Home Manager with Plasma Manager for this.

This is part of the tooling you’d use on NixOS, but you can use it on other distros, too, and it generally works fine (although I’m not sure, if the current version of Plasma Manager still supports Plasma 5, in case you’re still on a distro with that).

Basically, it allows you to define e.g. keyboard shortcuts like this:

    shortcuts = {
      ksmserver = {
        "Lock Session" = [
          "Screensaver"
          "Meta+Ctrl+Alt+L"
        ];
      };

      kwin = {
        "Expose" = "Meta+,";
        "Switch Window Down" = "Meta+J";
        "Switch Window Left" = "Meta+H";
        "Switch Window Right" = "Meta+L";
        "Switch Window Up" = "Meta+K";
      };
    };

It then fucks up the formatting, so that it looks like KDE expects, and throws it into ~/.config/kglobalshortcutsrc.
(KDE does actually have a text-based config, it’s just borderline unusable.)

Well, and you can do this with lots of other Plasma options, too. Here’s their official example: https://github.com/nix-community/plasma-manager/blob/trunk/examples/home.nix

I’d argue that it’s Android’s DE for Linux.

Works fine for me. ¯\_( ᵔ ~ ᵔ )_/¯

A colleague always complains that KDE looks like Windows. She does also get jealous, though, when she sees me using poweruser features.