• 0 Posts
  • 297 Comments
Joined 3 years ago
cake
Cake day: June 6th, 2023

help-circle


  • 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.







  • What I’m noticing more, is that you can keep a consistent 11.4MB/s, this feels relatively close to what you’d usually pull through a 100mbit/s link (after accounting for overhead). If that’s the case, it shouldn’t matter how the NFS client decides to chunk the data, for how much throughput there is to the NAS. Which means you’re looking at a broken NFS server that can’t handle large single transmissions.

    If it’s not the case, and you’ve got a faster network link, it seems that the NAS just can’t keep up when given >2gb at once. That could be a hardware resource limitation, where this fix is probably the best you can do without upgrading hardware. If it’s not a resource limitation, then the NFS server is misbehaving when sent large chunks of data.

    Basically, if your network itself (like switches, cables) isn’t broken, you’re either dealing with a NAS that is severely underspecced for what it’s supposed to do, or a broken NFS server.

    Another possibility for network issues, is that your proxmox thinks it has gigabit (or higher), but some device or cable in between your server and NAS limits speed to 100mbit/s. I think it’d be likely to cause the specific issues you’re seeing, and something like mixed cable speeds would explain why the issue is so uncommon/hard to find. The smaller buffers more frequent acknowledgements would sidestep this.

    Do note I am also not an expert in NFS, I’m mostly going off experience with the “fuck around and find out” method.



  • 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.




  • The exact numbers for when it messes something up, but keeps running, are unknown and highly ubpredictable.

    According to above post, about 10% of firefox crashes (more numbers found in the post) are caused by this stuff. It’s not unreasonable to say those crashes could’ve had the bitflip happen on content instead, changing maybe a character on the page or something.

    Note that it’s not 10% of users, as that’s reslly hard to figure out. Someone with bad RAM will likely crash more often.



  • 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.