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

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












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




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