Wtf is clash verge? Just use wireguard directly. Set it up in the KDE network manager app and it'll automatically apply to all software on the system

Most light themes I've encountered don't seem to grasp the concept of 'contrast'. I bet if you were to survey light theme users, you'd find that most of them have nonstandard/weird settings on their monitors. Chrome dev tools, Xcode, and Visual Studio's light themes are all great though, as they have proper contrast and don't look like rainbow vomit.

But one other issue with light themes is that for some people (myself included), it makes 'eye floaters' stand out more. I'm fortunate that my case isn't terrible, but I can see it being a serious problem for some people, especially older developers.

You can, and should do that. Here's what that looks like: toolbox run -c <toolbox-name> <command>

All of my development tools are in a toolbox, including my IDE (Sublime Text). I created a standard .desktop file so that I can launch it like any other application, and it works perfectly, with a proper Icon and everything. Example:

[Desktop Entry]
Version=1.0
Type=Application
Name=Sublime Text
GenericName=Text Editor
Comment=Sophisticated text editor for code, markup and prose
Exec=/usr/bin/toolbox run -c devel /opt/sublime_text/sublime_text %F
Terminal=false
MimeType=text/plain;
Icon=/home/user/.local/share/applications/SublimeText.png
Categories=TextEditor;Development;
StartupNotify=true
StartupWMClass=sublime_text

To run something on the host from inside a toolbox, you can use flatpak-spawn:

$ toolbox enter ...
$ flatpak-spawn --host <command> <args>

You can even use that to (awkwardly) run something in another toolbox using the same command above:

flatpak-spawn --host toolbox run -c <other-container> <command>

Sublime text specifically has support for custom build commands. Sometimes, I'm using it to develop something in a different toolbox than the one sublime is installed in. So in my custom build script for the project, I add a check to enter the correct toolbox before executing the build. Here's what that looks like:

TARGET_TOOLBOX=example
source /run/.containerenv
if [ "$name" != "${TARGET_TOOLBOX}" ]; then
	echo "SWITCHING CONTAINER $0 $@";
	flatpak-spawn --host toolbox run --container ${TARGET_TOOLBOX} /usr/bin/env zsh -c "$0 $@";
	exit 0;
fi

#proceed with build...

This container/toolbox workflow is far superior to anything else, as it makes it trivial to quickly test whether your code works on a different distros/versions. It all just works with your existing tooling/local workflows once you learn how to work with the tools. There really is nothing you can't do.

...and that's for development, which is the most difficult scenario for this type of thing. For regular every day users, immutability just works without requiring people to learn anything new besides reaching for flatpak instead of apt/dnf/pacman/etc.

Discover is probably the worst app in the entire KDE suite. It's the only aspect of the Linux desktop that frustrates me, and I'm nearing 10 years of full time Linux desktop usage.

Oh, you accidentally opened Discover? Now you gotta sit and twiddle your thumbs while it updates/downloads a bunch of stuff very slowly with no way to interrupt it. It also locks the system package manager, so you literally cannot do anything else package management related until Discover slowly decides to finish doing something you never asked it to do.

Here's a good article with some context around the F-droid situation, and why Signal is full of crap.

I think it’s also important to understand that signal is also a company that, at some ooint, needs to make money from somewhere to do this awesome thing and they won’t get that limiting themselves to an obscure app store that maybe 1 in 100 users even know about.

Signal is a non-profit and backed by a billionare. Tbh idk what their financials look like, but they don't seem to be in a difficult funding situation at all.

I also highly doubt that Google would modify the signal binary with a backdoor...

They definitely wouldn't do it for everyone, but if the FBI comes knocking at their door and tells them that they need to access a specific person's Signal chats, deploying a backdoored update to that individual is easily within Google's power. It's extremely likely nobody would notice, unless maybe the target is a security researcher or something. And IMO even if the info does come out, most of the blame/consequences (if any) would fall on the government, not Google.

Considering everyone is being labeled a "terrorist" nowadays by this whackjob administration, this type of scenario seems increasingly likely to me.

It's a very high quality code base too, but not for the faint of heart.

No F-Droid, no trust. It doesn't matter how strong the cryptography is, if Google or the government can trivially deploy a backdoored version. It also brings into question Signal's own credibility/trustworthiness, as this is an obvious and well-known flaw that they've refused to rectify, and have made bogus arguments to justify their decision.

Sidebar stats say this instance gets 23 users/day, which seems absolutely tiny and within the capabilities of 4c/16gb cloud instance.

We were maxing out every part of the server whenever any even slightly significant number of users were on the fediverse.

Idk anything about how lemmy/fediverse works, but does that mean tiny instances like this get hit when the rest of the network is experiencing high load? Seems problematic.

EDIT: btw, thanks for the free service and the effort you put in to keep it running!

This doesn't appear optimal. The correct way to melt a CPU is to make use of as many functional units as possible in parallel, while avoiding pipeline stalls and cache misses. I'm not a Rust guy, but skimming through the code it seems like the only work it's doing is some integer math, so it's not even touching the FPUs. Also I see while running.load(Ordering::SeqCst). Idk if Rust's memory model is similar to C++, but does that mean it's using atomic operations? That's going to create a lot of unnecessary cache coherency traffic that works against the goal of melting. Each thread should have its own counter not shared with other threads, and it should only spawn enough threads for the number of physical cores (not logical cores) on the system, and ideally pin each thread to a single core to prevent the OS from acting like a firefighter.

The gpu parts I'm not sure about. There's might be some special consideration required when dealing with integrated graphics though.

Final nail in the coffin.

Nix has one great idea and one terrible idea. Until at least the configuration language is redesigned by someone with good taste (and sanity), I'm not touching it. The amount of effort it takes to get back into the nix headspace in order to maintain anything is just not worth it. Docker and Podman are trivial by comparison, and the benefits of Nix do not justify the headaches. I Nix on a personal server for a few months, but migrated back to Podman after I found myself spending way too much time trying to find documentation and make sense of crackhead JSON.

In my work I get to use Conan which kind of implements some of the same ideas as Nix/Guix. It's designed for a different use case, but the benefits are similar and I love using it. It also has a learning curve, but Python is a real programming language at least. Guix may have the right idea too, but my experience with FSF projects is that they choose ideology over practicality every time, so I'm not eager to dive into it.

Qualcomm seems to be in a tough spot nowadays, so maybe they'll be open to playing nice with others for once? One can dream.