@dushman >Any x86 machine comes preloaded with proprietary code.
I believe you meant AMD64, as who uses 32 bit CPUs anymore?

Yes, the BIOS EEPROM chip more often than not comes with a proprietary BIOS.

>Even if you run Parabola your mobo will still run its proprietary BIOS and so on.
Yes, but you at least didn't have to accept a proprietary software license, as the software merely came on the hardware you paid for, so you can at least run it without having to agree to anything.

Still, it would be better not to have a proprietary BIOS, in that case you can get a good motherboard like the KGPE-D16 or the KMCA-D8 and install: https://libreboot.at/

If you libreboot those motherboards, the BIOS EEPROM chip contains 100% free software and the hardware is stable enough for server use.

I'm typing this message now on a librebooted KGPE-D16 with 6282 SE's running only 100% free software.

>Build a RiscV machine or gtfo.
RISC-V is a architecture design, so on its own, it's about as useful as trying to display something on a design for a screen - you clearly need to manufacture the screen first: https://www.gnu.org/philosophy/free-hardware-designs.en.html

A few example RISC-V implementations in HDL are provided, but the problem is using those implementations.

There are a few RISC-V SoC's currently available that are fast enough to run GNU, but every single one has proprietary patented extensions, proprietary bootloaders and/or other proprietary components.

As a result, the only current way to use RISC-V in software freedom is to load up a hardware design for a RISC-V SoC onto a proprietary FGPA.

The only line of FGPA's fully usable is freedom is the iCE40 line - which are really designed for low power rather than speed, although they aren't that slow.

There are a few toy RISC-V CPU examples for certain iCE40 FGPA models with enough LUTs, but those can't really do much beyond run example .elf's that use minimal memory.

For a RISC-V setup of the sort to be usable, one would need to design a SBC with a fast enough FGPA to implement a usable processor, with external RAM chips and other FGPAs for peripherals.

I've concluded that'll eventually be the only way forward, but as there aren't any suitable FGPA's available currently, so I'm sticking with AMD64 computers that operate without me having to provide any proprietary software.

@meso >yet my computer doesn't actually run any proprietary code.
You haven't loaded up any proprietary software onto your hardware, or accepted any proprietary software licenses, which is good for your freedom.

There is a sad fact that most computers contain many different chips with different functionality, some of which have internal EEPROM, which means that those chips technically run software that can be replaced (but in practice the chips are flashed once at the factory and never need to be updated again, as the functionality implemented within is typically mostly trivial and therefore can usually be gotten right at the factory).

Those who really love running all the proprietary software love to get on a high horse and mention the existence of such software, but such is really equivalent to a circuit - as you're not asked to accept a proprietary software license and it's never changed. The question is if that circuit has malicious functionality.

It's a sad fact that even with all the good work GNU has done, many things in computing are still proprietary, but rather than giving up completely, one should just work on developing free software replacements and install it as it becomes available.

Before there was no free compiler, so GNU had to use proprietary compilers. Once gcc was released, there was no reason to use a proprietary compiler ever again.

The same was when there was no free kernel that booted, but once Linux was released as free software in 1992 (temporarily but still), there was no reason to use a proprietary kernel ever again.

In the past there was no free BIOS's for (fast enough to be usable) computers, so even rms had to use a computer running a proprietary BIOS, but rather than give up, he tried for about 8 years to find a way to avoid a nonfree BIOS in a commercial machine: https://stallman.org/stallman-computing.html

Eventually the Lemote Yeeloong because available, which has a free init program, so he got one of those.

A free init program was developed for certain thinkpads not long afterwards, so rms now uses thinkpads.


It's not really ideal that my computers HDD or SDD, EC or SuperIO, RTC, keyboard, mouse and monitor technically run proprietary software, but I don't provide that, or agree to any proprietary software licenses for such software and I will be glad to flash GNU HDD/control onto my HDD if that becomes available, but for the moment, there are worse freedom issues that have a higher priority for me.


While ideally you should be able to replace each proprietary part of your computer as GNU replaced Unix, unfortunately some hardware implements digital handcuffs to tyrannically stop you from doing that.

Nothing can be done to fix tyrant hardware unless you are/know a skilled cryptographer and there's a vulnerability, as a result, the only practical choice is to use hardware that doesn't cryptographically enforce the running of proprietary software - thankfully plenty of such hardware is still available.

>hardware is by design proprietary, it really can't be any other way unless it was big enough to inspect with the naked eye.
Indeed, material compositions and manufacturing techniques are almost always kept proprietary, so even if you supply a free hardware design to a manufacturing company, the hardware that comes out at the end is proprietary - as you don't know how they made it.

Hardware features like circuit layouts are typically large enough to inspect with the naked eye and reverse engineered just via thought, but you can't be sure that you didn't miss a sneaky proprietary part of the layout.

The only way to have non-proprietary hardware would be to go mine all the raw materials yourself and handcraft all the manufacturing equipment yourself, which clearly isn't feasible.

The closest you can get to hardware freedom is FGPAs - although the FGPA itself is proprietary, you can load a free hardware design onto it and the hardware design operates as desired (many FGPAs may have malicious functionality, but good luck to any FGPA manufacturer trying to backdoor GNU/SoC reliably if the version being used was released after the manufacture date).