Since this installed a malicious dependency from NPM (and later with bunjs) in the pre install script, it would need at least complex correlation to catch. Maybe building and installing all AUR packages, which would cost far too much for the Arch team.

Individually and automatically scanning only the PKGBUILDs (the stuff actually on the AUR) would likely not have caught this.

That doesn’t mean it’s a bad idea to run a basic scan over every change, but it wouldn’t magically “fix” aur malware.

Not OP but a couple things:

• It’s a full controller, no “only one joystick” like the 2015 model.
• The quality of the IO is great, like the TMR joysticks, good trackpads, gyro, and nice haptics.
• If a PC runs Steam, it supports all the controllers features (in Steam). This isn’t always the case on DS5/xbox controllers.
• The “puck”, despite looking insignificant, makes the experience much better. Unlike Xbox with AA batteries or DS5 with USB-C charging, and both of those with Bluetooth wireless connectivity (by default). The Steam Controller (2026) is fully “pick up and start playing”.

Whether it’s worth the price depends on what you value in a game controller, and how much. For me, the “extra” inputs (mainly back pedals, touchpads, gyro) and accurate sticks (TMR instead of potentiometers) are worth it.

KDE Connect

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.

Hoping for another Moonlight/Sunshine moment! Already running Vaultwarden, rbw, and Keyguard. Just need a simple FOSS browser extension for autofill and editing entries.

For context, Moonlight was created first as a FOSS Nvidea gamestream client. Then Sunshine was created as a FOSS server implementation. Later, Nvidia dropped “official” support, now the two projects are a FOSS stack built atop a formerly proprietary protocol.

… Are there others?

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

Writing this from my Fairphone 5 running postmarketOS (Linux).

Biggest downside right now is no phone calls, but that’s being worked on.

For me it was the inappropriate description on the last post. This is not an NSFW community and I didn’t want to read that.

The point is how expensive it is. For your 1 request, you wait 2 seconds, and the power draw is a minor inconvenience. For the massive botfarm, it adds up to days of CPU time and a significant portion of the electricity bill.

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.

Poettering only very recently left microslop

Yes, or like we saw in the demo, someone’s arm disappears, a ball becomes a blurry shapeless blob, and many others.

This tech is the same tech that powers other ““Generative AI””, meaning exact the issues with asking for a hand and getting one with 7.5 fingers can now happen in real time, in video games supporting DLSS 5.

It is straight up an AI slop filter over top of a game. There’s not much more to say about it.

Lots of things wrong with this but one I haven’t seen yet is that CachyOS literally depends on ArchLinux, yet is more “independent” than it?

These are terrible axis to try and plot operating systems, and limiting yourself to such low resolution with no overlap doesn’t help.

Hell yeah! 10x speed improvement for free!