The linked article does a great job explaining the process of creating a theme assuming you have the SVG files. If you are asking how to create SVG files, then just use any vector editor (like Inkscape, for instance). You can find plenty of tutorials on how to create vectors through online video tutorials.

Your number is on a list of real numbers with real identities associated with them that was sold to them. Data brokers sell this information daily. They already know your number is real, but in order to comply with the law, they have to provide you with a legitimate option to opt out, so you will actually stop receiving correspondence from them if you ask them to stop (it is legally required). If not, they could be subject to a fine, but you'd obviously have to file a complaint with the relevant regulatory body for that.

If you do not attempt to opt out, they cannot be fined for spam if this is part of a legitimate donation campaign. If you don't reply, they will continue sending messages to you in the future. It costs them almost nothing to do, so even if they didn't know your number was real, they would do it anyway. Most of the people who donate from these messages don't reply through text message anyway. And if this were an actual scam, then there is nothing they gain from receiving a text back so long as you do not open their link. But again, in order for legal action to be taken (since these political reach outs are legal and not spam so long as there is an option to opt out), you must first try to opt out.

EDIT: Feel free to block the number after opting out. If they are legitimate (though the name is really fishy), then opting out will remove your number from all of their solicitors' lists, so you won't get texts or calls from different numbers working for the same campaign. Again, replying doesn't give them anything even if it is a scam, as your number was obtained from a real list sold to them by a data broker; they already know the number is in service. Just don't click the link in the text, and don't reply with anything other than stop.

sudo is not a fairly simple program. Last I checked, it had ~177k lines of code. It provides functionality far beyond what is needed of an average user. doas is a simpler alternative (also using SUID) at ~3k lines of code. It comes from OpenBSD. There is absolutely a problem when it comes to SUID binaries. If you can find a way to exploit the permissions given at the start of the SUID binary before user authentication occurs (since the UID is set before the binary runs), you have yourself a full privilege escalation vulnerability. systemd is very well integrated with the distros that use it, being the first process to run after the kernel is initialized. There will never be a point at which systemd is not functioning, but the rest of your system is perfectly fine. It is an absolutely necessary part of the system (assuming your distro uses it), and if it goes down, you have to restart your system. As such, I don't see any validity to the statement "you want to always work, even (especially!) when other things get borked". What exactly do you see as being an issue with run0? What specific part of its implementation do you seem to have a problem with? It's just a symlink to systemd-run, which is already very well tested and has been around for a long time. It's also far simpler than sudo, and removes the attack surface of running an SUID binary of its size. What "points of failure" do you see here, exactly?

SUID stands for Set User ID. An SUID binary is a file that is always run with the UID of the owner user (almost always root). Note that this does not require that the user running them has root permissions, the UID is always changed. For instance, the ping command needs to set up network sockets, which requires root permissions, but is also often used by non-root users to check their network connections. Instead of having to sudo ping, any normal user is able to just run ping, as it uses SUID to run as the root user. sudo and doas also require functions that necessitate them running as root, and so if you can find out how to exploit these commands to run some arbitrary code without having to authenticate (since authentication happens after the binary has started running), there is a potential for vulnerabilities. Specifically, there is the privilege escalation, which is one of the most severe types of vulnerabilities.

run0 starts using systemd-run, which does not use SUID. Instead, it runs with the permissions of the current user, and then authenticates to the root user after the binary has already started to run. systemd-run contacts polkit for authentication, and if it succeeds, it creates a root PTY (pseudo-terminal/virtual terminal), and sends information between your session and the root PTY. So this means that in order to achieve privilege escalation with run0 as root, you have to actually authenticate first, removing the "before authentication" attack surface of sudo and doas.

TL;DR SUID binaries will always run as the owner (usually root), even before any form of authentication. run0 will start with the permissions of the current user, and then authenticate before running anything with root permissions.

Well, since doas has a Linux implementation, stealing that name would cause lots of issues to users who already use it or want to use doas instead of run0. This will be a default part of systemd; not a new package. The reason it's called run0 is because it's just a symbolic link to systemd-run, and instead of executing as an SUID binary, like sudo or doas, it runs using the current user's UID.

Excluding Fedora because it's "too close to RH" doesn't make any sense at all. Fedora is not controlled by Red Hat, and Red Hat has no interest in a consumer desktop platform that they can't sell. Fedora's development is managed by FESCo, a community elected board that represents the interests of the community. They are kept intentionally separate from Red Hat's development, and don't tailor their development to Red Hat's wants or needs (in fact they often do the opposite, as Fedora pushes for change in the way things are done, not stability, as can be seen by the exclusion of X11 from Fedora 40, for example). That stands in direct contradiction with RHEL's goals. The features that are pushed by Red Hat developers would not be approved if they stood against the wants of the community, so anything Red Hat does contribute benefits the community as well. Red Hat's entire business is in enterprise solutions, as their business model relies on them selling support for their software. There is exactly $0 in potential revenue from Red Hat trying to take over Fedora, it just doesn't make sense. They can't sell anything, and since Red Hat doesn't employ all of the thousands of active contributors, such a takeover would simply result in a new fork. In fact, it would be against their interests, as Red Hat actively benefits from the developments of the community. Taking over control of the project would lose them all of the constant volunteer work put in by the community, which costs far less for them to sponsor than it would to employ a team a fraction of the size on salary. I've discussed this topic at length many times before, so I'll just link to a few comments that explain the situation in more detail (including how the project is funded, managed, and separated from Red Hat).

https://lemmy.world/comment/7490965

https://lemmy.world/comment/7494803

The best fit for your criteria is Fedora. If you want uBlue spins, you're still getting Fedora, just a more opinionated version. All of the major development of uBlue's images comes from Fedora though, as they don't maintain their own distro, they just repackage Fedora.

I'm also going to echo the sea of comments praising KDE support on Fedora. I just switched to Kinoite/Fedora Atomic KDE (for the Fedora 40 release) after using Fedora Workstation for about 5 years, and I've loved the experience. My only gripes have been from adjusting to an atomic distro, and have had nothing to do with KDE implementation. It seems that Fedora works very well with KDE, though I suppose I don't have a whole lot of experience with other distros using KDE.

If you want to use KDE with a standard desktop experience, just use the KDE spin (the standard mutable version). If you're interested in atomic distros (not trying to convert you, it's very much a personal preference), then they have the atomic KDE spin as well. I don't think you'll be missing anything by using KDE on Fedora, and unless you wanted to experiment with GNOME, there's no reason to really switch. Workstation and the KDE spin are both maintained at about the same level.

It seems you've chosen a DE that is not particularly well-suited to this task. Cinnamon is meant to be simplistic, and offer an easy transition from Windows with its Windows-like layout. It is purposefully less customizable than many other DEs. I second the recommendation of KDE Plasma, as this is actually available as a shortcut without any extensions, but if you wish to customize your DE deeply like this, KDE is incredibly customizable. You can do essentially anything you want in it and get it to look however you want.

Since you said that you're trying out Mint, now would be a good time to switch distro so you don't get attached to something that doesn't suit your needs. Switching desktop environments can cause lots of issues, so it's often best to just pick a distro with the DE you want. My personal recommendation is Fedora's KDE spin (though there are discussions of Fedora's default workstation switching to KDE in the future). If you're invested into Debian, then I don't really have any experience with Debian-based KDE distros, but I'm sure someone else could recommend you something. To be clear, the benefit of recommending Mint as a starter distro has gradually diminished as other distros have become more user-friendly. Fedora is a perfectly fine distro for someone new to desktop Linux (especially since you're already experienced on the command line); you'll just have to look up how to install Nvidia drivers if you have an Nvidia graphics card. AMD commits their driver to the Linux kernel, so no need to do anything if you have an AMD card. Try out some distros in a VM before you commit to anything though; it's much less commitment than installing so it's far easier to test distros out and see what best suits you.

There's no useful information to glean from this image other than the fact that we finally found someone who uses light mode on Discord.

Chromium-based browsers have inherently weaker extensions due to Manifest v3 and many other targeted attacks on adblockers. If you want a browser that works far better and provides a much higher level of privacy, use Mullvad Browser (worked on in collaboration with the Tor Browser, just without Tor integration) or LibreWolf. Both are Firefox forks with Firefox telemetry removed and anti-fingerprinting measures. You don't need and absolutely should not install any extensions beyond the default installed in those 2 browsers (except perhaps a password manager), as that will dramatically damage the fingerprinting protection they provide. Both will have a much higher level of protection than you could ever realistically expect from any Chromium-based Browser.

From the article, it seems that there will be a DRM-free version available on the game's website for Linux (and that will be the only place to get the Linux native package). So no need to go through Epic. Plus, most Epic exclusives eventually end up on Steam anyway, it's just a matter of time.

Just to clarity the relationship between Red Hat, IBM, and Fedora, Fedora is only sponsored by Red Hat. They make all their own decisions, and while they receive financial support from Red Hat and Red Hat owns the Fedora trademark, their decisions and development are independent of Red Hat (and by extension IBM), with the single exception that they cannot risk violating the law (i.e. copyright infringement), else it risks Red Hat legal trouble (and Fedora would risk losing their sponsorship as a result). Red Hat benefits from Fedora's development by the community, given that Fedora is RHEL's upstream, hence why it continues to sponsor Fedora. But it isn't Red Hat that is in charge of Fedora's development, it's FESCo, which is entirely community elected, and does not stand for the interests of Red Hat, but rather for the interests of the community.

Eliminating Fedora from contention in that regard is essentially like eliminating Debian because you don't like Canonical, who makes Ubuntu, a downstream of Debian.

Add on top of that the fact that IBM and Red Hat are major contributors to the Linux kernel, and you absolutely cannot avoid connections to them while using Linux. I mean, that's quite frankly a ridiculous exclusion criteria in the context of Linux. If you're looking to avoid an operating system OWNED by Red Hat or IBM, then Fedora should not be included in that list. Neither of them have any say or pull in the development of Fedora, which is a completely community-driven project (no, owning the trademark doesn't change that fact; if Red Hat tried to take over, the Fedora community would simply fork the project, rebrand, and continue on their own). Besides, Red Hat has no interest in controlling Fedora, because it doesn't benefit them. Their only interest is in enterprise applications, which is not a good use case for Fedora. The only operating systems Red Hat actually has any control over are RHEL, CentOS, and any derivatives of those operating systems like Rocky Linux, Oracle Linux, and such (though Red Hat's control over derivatives was only the result of those projects being downstream, not actual ownership).

So with that in mind, I'd recommend the Fedora KDE spin if you want a normal, stable, snap-free, no DIY required distro with KDE, or if you want the immutable version, Fedora Kinoite is what you'd be looking for. And Fedora has the major advantage over Debian-based distros of actually receiving package and kernel updates regularly, so you can stay up to date and enjoy new features, all while maintaining stability.

Fedora Kinoite is absolutely the best immutable distro fitting your criteria. Anything else will have a much smaller community and less support as a result. rpm-ostree has great documentation, and all of the Fedora Atomic Spins have a huge userbase available in case you ever have questions.