To add to the other commenters reply;

When Jolla does something, like make new software or patches, most of that is proprietary. They’re creating their own thing, and nobody outside Jolla can benefit from their work. That’s fine, but pretty much equivalent to any other corporate-owned mobile OS in terms of freedom, like Google’s Android.

There’s more open options, but they all have their differences. Ubuntu Touch (or really anything on UBPorts) has some components you would also find on Linux, but still uses the OEM kernel and proprietary Android device drivers. This means that devices are much more likely to work, but you rely on the OEM to maintain support for the device on Android. postmarketOS (and others, like Mobian) try to build most things from scratch instead. This means less hardware is supported, and functionality is often not great. However, all development is open, and they’re trying to ensure there’s little to no reliance on OEMs. This theoretically makes for much better (community supported) future proofing.

WhatsApp requires that you have a mobile device (Android or iOS) connect through the official client at least once every two weeks. They also monitor for “suspicious” API usage, and will ban accounts for using their service wrong (though it is very uncommon and often temporary).

The only mostly FOSS third party solution I am aware of is the mautrix-whatsapp bridge. The developer of that bridge also created Whatsmeow, a WhatsApp Golang library.

mautrix-whatsapp requires a mobile device to connect using the official WhatsApp app. It pretends to be a WhatsApp Web client, and allows you to send and recieve WhatsApp messages on Matrix. The bridge (effectively) requires hosting your own Matrix homeserver, so it’s not a simple solution.

Check whether your BIOS settings show the system clock UTC or adjusted to your timezone.

Windows stores hardware clock time in your local timezone. Other operating systems usually store it in UTC. If you’re dual booting, this could cause issues.

It’s also possible that saving the current time to the hardware clock in silverblue/secureblue is misonfigured in some way.

This is an absolutely bottom of the barrel machine nowadays. You’ll be able to run Linux on it, but nothing is going to run “fast”. Especially not a webbrowser with modern websites.

If you’re actually considering using this machine, the two most important upgrades you can make are SSD instead of HDD, and a bit more RAM (8GB if possible). With the ~2011-2012 CPU (judging by the release date of the iGPU listed) and the mentioned upgrades, you should have a usable (although slow) workstation for light tasks. Without the upgrades, be prepared to wait for things to load.

Individual AppImages still highly depend on system libraries, I’ve seen them often fail to run on older distros, for example due to an out of date system glibc.

Flatpak is not owned by RedHat or systemd. You can use flatpak while avoiding systemd components.

a solution to a problem most people don’t have

I’d say the timeless problem of “I just want to run this app, why doesn’t it work” is solved with Flatpak. People who can compile software themselves are the exception, not the norm. For an average user, an app store that “just works” is great. And for a developer, only being required to target one common runtime simplifies things.

… Are there others?

What about KDE connect for using phone as remote input instead of some proprietary app?

Lets ignore the “is it possible” and imagine what would happen if it was. Whatever entity forks AOSP would start off with (next to) no userbase. The platform “Android” will remain Google’s AOSP, including some proprietary components. Whenever Google decides, they can enforce apps on the Google Play Store to use a new version of the Android system API. This is often a breaking change; apps that update won’t work on older Android. There is nothing stopping Google from creating complex breaking changes that tie into their proprietary components, killing off any attempt at running Google Play Store apps on older or “fully FOSS” Android. Even if a hard fork of AOSP existed, it would not remain compatible with the vast majority of applications.

So even if this could happen, it won’t. Nobody is going to invest in hard forking a project that is going to be killed off by Google’s monopoly.

The much better (long term) option is to stay completely outside AOSP, like with mobile Linux distros such as postmarketOS. Right now, it is underdeveloped and not an option as a daily driver for most. But over time, this is the only feasible option that can give control back to the user.

Heavily leaning towards malware; normal software tends to name itself the same on disk and in ram, this seems to be it trying to hide itself.

Since there’s now nothing to go off of for how this got on your system, the best course of action is to back up your documents and reinstall your system fresh. To avoid malware in the future, stick to the built-in app store and system repositories where possible.

This doesn’t really say much; this could be legitimate software thinking it crashed, or it could be malware trying to hide itself.

Try seeing if sudo find / -type f -name windows tells you anything about where it’s installed. This command searches through / (all files) to find a file (-type f) that is named windows (the same as the process name).

Assuming this is malware, depending on the complexity it might be really hard to remove. The best course of action is much like on Windows; Backup your personal files, figure out how the malware got on your PC (so you can avoid it next time), then reinstall the operating system.

For backing up personal files, stick to documents, media, etc. Do not include executables (like installed games), and be very careful with config files (and system files), basically only back these up if you know what’s in them is legitimate.

You can find more about the process in the /proc/4212/ directory (this is the number on the left in top). By running ls -l, you should be able to see where the exe symlink points to, which tells you where the program is installed. This might give you a clue as to where it came from (or it might not, depending on how the malware is made). If you suspect it is not malware, due to information on your system, look it up online before trusting it. I have personally never seen a root-owned ““windows”” process, which is why I’m heavily leaning towards this being malware.

If you feel like you know where the malware came from, or you’re stuck and are struggling to find out more, you should reinstall your operating system to get rid of the malware. Malware can have different levels of complexity, what you’re seeing on the surface might be the whole thing, or it could have more complex systems to reinstall itself after removal. Which is why reinstalling your operating system is the safer option.

Iirc, the XZ backdoor was specifically targeting RH and Debian, which for some reason link libsystemd into OpenSSH. Afaik even upstream Arch was unaffected, not just Artix. The exploit code, though non-functional, still made its way onto your system (assuming you updated when it was in a release version).

I’m not defending systemd though, it’s clear that Poettering’s goals do not align with the rest of the Linux community. I’m saying that Artix not being affected by the XZ backdoor is not a good argument for why to use Artix or avoid systemd.

It’s like saying “Linux doesn’t get malware” because most desktop malware targets the OS with the largest desktop userbase, Windows. This alone doesn’t suddenly make Linux “better”. That doesn’t mean there aren’t other reasons to avoid Windows.

The smaller/newer distros have no evidence of staying around for years, so it’s hard to judge whether they’ll be around in another couple years. Distros like Bazzite are definitely interesting, but you can’t reliably predict whether it’ll get updates in 10 years. There are stable community-led distros that have been around for a long time, like Debian.

Personally, I have nothing against crawlers and bots

If they’re implemented reasonably, web crawlers aren’t the issue. The problems with them mostly stem from laziness and cost cutting. Web crawlers by AI comapnies frequently DDoS entire services, especially Git forges like Gitlab or Forgejo. Not “intentionally”, but because these crawlers will blindly request every URL on a service, no matter the actual content. This is cheaper for the AI company to implement this way, and scan through the data later. But this also leads to the service having to render and serve tens of thousands of times as much content as is actually present. They are made to try and hide themselves doing so, which is the biggest reason we see “modern” PoW CAPTCHAs everywhere, like Anubis or go-away.

Robots.txt used to work, because search engines needed there to be an “internet” to provide their services. Web crawlers pre-AI were made knowing that taking down a service made another website go down, which lessened the overall quality of search results.

I’ve had LLM webcrawlers take down my whole server by DDoSing it several times. Pre-LLMs, a git forge would take maybe a couple hundred MB of RAM and be mostly idle while not in use. Nowadays, without a PoW CAPTCHA in front, there are often over 10.000 active concurrent connections to a small, single person Git forge. This makes hosting costs go through the roof for any smaller entity.

Is the video player application itself muted in pipewire? What’s the output device set to?

You can check these things with an application like pavucontrol. Pipewire (and pulse) have a default audio device, but individual applications can set a different audio device if they want to.

Another great category of utilities for pipewire is virtual patchbays. If you’re looking for something simple, helvum or qpwgraph are geat. For all the technical details in a GUI, coppwr provides a good experience.

Arch isn’t exactly intended for beginners, and the “windows is more bloated than Linux” thing applies for pretty much every Linux distro.

If you’re willing to spend a significant amount of time learning and tinkering, a distro like Arch could provide what you need. However, if you’re just starting out, you might want to start with something easier. Distros like Linux Mint or Fedora are plenty lightweight compared to Windows, and they require much less learning to get started actually using your computer.

As for “which distro allows you to use the cheapest PC”, this mainly comes down to how much effort you’re willing to put in, not necessarily the distro you use. At a certain point, a desktop computer will “just work” for basic desktop tasks, the distro doesn’t change much there.

If I had to pick one, Arch. I already use it a lot, so it’s familiar. I know my way around the package manager and how to create packages, so even when things aren’t available for Arch out of the box, I can make it work.

It’d be kind of a hassle trying to keep anywhere close to 100% server uptime, but for my own personal stuff that shouldn’t be that big of an issue, as I can fix it when I have the time.

For desktop, I basically can’t do stable release. I frequently mess with new projects requiring the latest versions of everything, which is a near impossible task on stable-release distros.

It’s the task of your CPU scheduler to ensure your system doensn’t freeze, even over 100% CPU usage. If it’s completely unresponsive, it’s more likely you’re running out of memory instead.

In my experience, the Debian installer is just confusing. Once you’re past that, the userbase is smaller than Ubuntu’s. Their repos are different too, meaning software packaged for Ubuntu isn’t guaranteed to work on Debian. Ubuntu itself is pretty terrible for its own reasons, so when asked for a desktop Linux distribution “close to Ubuntu” I’d put Mint first. (For general recommendation, I’d probably say Fedora now.)

Debian 13 is still relatively new, so the problems of it being out of date aren’t showing yet. Debian 12 just before 13 released had tons of these issues, like glibc being too old for some binary programs, or the kernel not being new enough for some “gaming” features.

For reference, I am on Arch Linux. I feel I have a good understanding of how to manually install Linux. The Debian installer confused me in many ways, the main one being that “language and region” are closely tied, and selecting en_US “language” forces you to choose an American timezone later in the installer. In general it was a slow install process too. This is something other “user friendly” distros handle much better. A default live environment, a quick installation, and options being there, but having the defaults automatically correct (like timezone).

Like (almost) every other distro, Debian has its own benefits and downsides. These make it a good fit on desktop for slightly more experienced users, or users familiar with apt. This means it isn’t in the list of distros I’d generally recommend to people when they’re not familiar with Linux.