> Nouveau.

Which Nvidia card do you have, and at which clock speed does your GPU run?

> With the right hardware choices running blob-free linux is pretty straightforward.

Unfortunately no. Features like SSE are pretty amazing and have made CPUs really fast and efficient, but they're unfortunately also large attack vectors, so vulnerabilities like Spectre or Meltdown occur. You need proprietary microcode blobs to fix those security vulnerabilities in your CPU.

▲

lrvick a day ago | parent [-]

An Nvidia GPU is never going to run at maximum clock speed etc on open drivers right now, but the point is if you prioritize security/privacy/freedom you have choices.

If you are not running games (which you should not on a system you need to be able to trust) maximum clock speed from a modern GPU is not needed for most workstation applications.

I generally choose AMD GPUs for the best experience with open drivers these days on systems I need high GPU performance from.

> You need proprietary microcode blobs to fix those security vulnerabilities in your CPU.

Really? Which blobs do I need on RISC-V FPGA enclaves or my PPC64le Talos II workstation which has a fully open hardware motherboard and open CPU architecture?

I make different tradeoffs on different hardware to be sure depending on the threat model of the task I am working on. x86_64 is a bit of a shit show, but you still only have to trust your CPU vendor even there, as it is possible to have FOSS firmware/software for everything else.

▲

strcat 20 hours ago | parent | next [-]

> PPC64le Talos II workstation which has a fully open hardware motherboard and open CPU architecture?

The ISA is open source, not the whole CPU architecture and design. There are older open core designs from IBM but that's a different thing from the more modern and powerful Power9 and Power10 CPUs.

> you still only have to trust your CPU vendor even there, as it is possible to have FOSS firmware/software for everything else

A device with assorted closed source components including as part of the motherboard itself is hardly open beyond the CPU. Open source also doesn't mean you aren't trusting those vendors. With a fully open hardware design CPU, you're still trusting that it matches the open source design and you're trusting the open source design. The manufacturing process is also generally going to be proprietary.

▲

cherryteastain a day ago | parent | prev | next [-]

> generally choose AMD GPUs for the best experience with open drivers these days on systems I need high GPU performance from.

Do you count binary firmware as 'open' or not? If not, AMD is not 'open' either. If you do, Nvidia now also has open kernel drivers. Mesa developers are exploring ways to get the new Mesa Nvidia Vulkan driver (NVK) to run on top of the open Nvidia kernel driver, which should eventually make Nvidia drivers as open as AMD.

	▲	lrvick a day ago \| parent [-]
		The binary firmware on an external module over a PCI bus should not have the ability to manipulate my current operating system and exfiltrate data without being noticed, but it is a non zero chance which is why on all my x86_64 workstations I run QubesOS so most hardware components are well isolated from each other with hypervisors, in addition to only open source code in my operating system and kernel layers, which is best effort today on such systems. I generally only run gaming graphics cards on dedicated gaming machines, not on workstations I need to be able to trust. You can't use accelerated graphics in qubes anyway, specifically because graphics cards are hard to trust. My requirements from a workstation are: 1. MUST have 100% open source code loaded in system memory 2. SHOULD have open source software in the boot trust path (coreboot/tpm2 secure boot, etc) 3. SHOULD have open hardware to the furthest extent possible that meets my use case 4. SHOULD be fully auditable and tamper evident using at-home tools and methods (like the Precursor)

▲

Andromxda a day ago | parent | prev [-]

> maximum clock speed from a modern GPU is not needed for most workstation applications

Well at that point buying a GPU is definitely not worth your money. You're better off using a CPU's integrated graphics unit.

> I generally choose AMD GPUs for the best experience with open drivers these days on systems I need high GPU performance from.

Yeah I agree on that, I also purchase AMD cards exclusively now.

> Which blobs do I need on RISC-V FPGA enclaves or my PPC64le Talos II workstation

I assumed we were only talking about x86. But I also believe that POWER9 CPUs don't have SSE, prove me wrong. I guess you're running Linux? I'd be very interested in looking at the output of lscpu from one of these machines.

> x86_64 is a bit of a shit show

I fully agree there

	▲	lrvick a day ago \| parent [-]
		> Well at that point buying a GPU is definitely not worth your money. You're better off using a CPU's integrated graphics unit. Yeah I only use dead simple workstation cards or integrated graphics on my workstations, and AMD GPUs on my gaming systems which I don't trust at all (but still prefer to support companies that use open drivers) > But I also believe that POWER9 CPUs don't have SSE, prove me wrong. POWER9 has its own SIMD system (AltiVec/VMX/VSX) instead of SSE which is entirely its own thing. I have no idea of the performance tradeoffs here though for various use cases, as freedom is biggest factor for me. > I'd be very interested in looking at the output of lscpu from one of these machines. Here is an lscpu from an 8 core Blackbird though it will probably render poorly on HN. Architecture: ppc64le Byte Order: Little Endian CPU(s): 32 On-line CPU(s) list: 0-31 Model name: POWER9, altivec supported Model: 2.3 (pvr 004e 1203) Thread(s) per core: 4 Core(s) per socket: 8 Socket(s): 1 Frequency boost: enabled CPU(s) scaling MHz: 58% CPU max MHz: 3800.0000 CPU min MHz: 2166.0000 Caches (sum of all): L1d: 256 KiB (8 instances) L1i: 256 KiB (8 instances) L2: 4 MiB (8 instances) L3: 80 MiB (8 instances) NUMA: NUMA node(s): 1 NUMA node0 CPU(s): 0-31 Vulnerabilities: Gather data sampling: Not affected Itlb multihit: Not affected L1tf: Mitigation; RFI Flush, L1D private per thread Mds: Not affected Meltdown: Mitigation; RFI Flush, L1D private per thread Mmio stale data: Not affected Reg file data sampling: Not affected Retbleed: Not affected Spec rstack overflow: Not affected Spec store bypass: Mitigation; Kernel entry/exit barrier (eieio) Spectre v1: Mitigation; __user pointer sanitization, ori31 speculation b arrier enabled Spectre v2: Mitigation; Software count cache flush (hardware accelerated ), Software link stack flush Srbds: Not affected Tsx async abort: Not affected