PorkrollPosadist [he/him, they/them]

Hexbear’s resident machinist, absentee mastodon landlord, jack of all trades

Talk to me about astronomy, photography, electronics, ham radio, programming, the means of production, and how we might expropriate them.>

  • 5 Posts
  • 39 Comments
Joined 4 years ago
cake
Cake day: July 25th, 2020

help-circle




  • Anecdotally, I never had performance problems with Nvidia on Linux. Just other annoyances, like it taking a very long time for them to properly support Wayland (historically poor performance in XWayland, moot for several years now, but the workaround of just sticking with XOrg was workable), needing to compile out-of-tree kernel modules (usually managed by the distribution, but annoying if you need to run bleeding kernels for other reasons), and having it’s own proprietary OpenGL / Vulkan implementations instead of running Mesa3D at full performance.

    When I switched to AMD, I noticed little things, like the screen doesn’t flicker when I activate a second monitor, and having monitors with different refresh rates worked. Gains from Wayland working as intended, mainly.


    • Only one big problem here: the Ryzen 9 5900X is an AM4 Socket CPU but the motherboard you have selected has an AM5 socket. This board will not work with the AM4 CPU or the DDR4 RAM. The DDR4 RAM is correct for the CPU though.

    • The CPU requires a dedicated cooler, typically an all-in-one liquid cooling kit (though fan kits exist as well). If you do not already have one, you will need to obtain one. Intel CPUs typically include a basic fan and heatsink, but recent AMD CPUs have more intense cooling requirements and these are left to the aftermarket. AIO kits usually come with a handful of adapters for both Intel and AMD, but you want to make sure a bracket for the AM4 socket is among them. I had an old AIO system when I built my new AM5 machine, but AM5 didn’t even exist when this AIO kit was manufactured.

    • Not a major problem, but worth consideration depending on your intended workloads: With 16GB DIMMs you will max out at 64GB of ram, which is A LOT, but with 24 threads, that’s a bit over 2.5GB per thread. With two DIMMs (as shown), that’s a bit over 1GB per thread. You will struggle to use that CPU to its full potential when it comes to doing things like compiling somewhat complex software. In practice, I have found 4GB/thread to be required when compiling things like Chromium (QtWebEngine), and about 2GB/thread for things like Firefox. If you are not compiling (major) software from source code or running Gentoo this likely isn’t a problem, and you can always limit the number of jobs to work with the amount of memory you have available in the odd case where you end up doing things like this.
      That said, I can’t seem to figure out definitively what the maximum RAM limit is for this CPU or chipset. If it is not greater than 64GB, there is no point of getting DIMMs any larger than 16 GB. The X570 chipset (fanciest, among several in the AM4 family) apparently supports at least 128GB, but this will also depend on hardware support in the motherboard. Just because a motherboard has this chipset doesn’t mean it supports all of its maximum capabilities (i.e. PCIe lanes, memory, overclocking, etc)

    I never used DDR4 personally, but from what I hear, the difference between DDR4 and DDR5 is marginal, but DDR5 comes with the added headaches of “training.” It can take upwards of 15 minutes for a DDR5 machine with a lot of memory to boot for the first time. I was nearly ready to RMA my memory before I figured out this was happening, and I had to flash a UEFI firmware update to ultimately get 128GB working.




  • Most of this software can be installed without sudo by changing the prefix in the (pre-compile) configuration step. The prefix usually defaults to /usr/local, which requires root, but you can change it to (e.g.) /home/your_user_name/.local and install without special privileges. You need to add the directories to PATH/LD_LIBRARY_PATH etc. but then it works practically as an overlay on top of your distribution-provided packages without any permanent side effects or impact on other users.

    You’re right that most instructions don’t explain this, though. They just kind of assume GNU Autoconf / CMake / Meson is intuitive to mere mortals.


  • Generally no. If you are installing software from trusted sources (I.e. your distribution’s package repository) and applying security updates in a timely manner, there is very little to worry about. If you are processing untrusted files and forwarding them to third parties (I.e. you’re running a mail server) there are tools like ClamAV to check for KNOWN viruses.

    It is entirely possible to install viruses if you are running software from untrusted sources. This includes viruses designed for Windows by running sketchy things in Wine/Proton. These are compatibility layers, and if they are working correctly that includes compatibility with malware. Isolation is explicitly not a design goal of these projects. If you run a Windows ransomeware in Wine, you WILL lose your data. If you run a naive Limewire worm in Wine, Limewire WILL autostart and spread the worm.

    Always be careful with pirated software. It doesn’t hurt to run ClamAV on a torrent before trying to use it.