← Home ← Back to /g/

Thread 107010680

12 posts 8 images /g/
Anonymous No.107010680 [Report] >>107010694 >>107010752 >>107010839 >>107011268
Why all the hype over Arch? Gentoo runs way smoother and is actually open source and compatible with most hardware. All you need is hardened Gentoo w/ Secure Boot, a custom open source RISC-V desktop SBC w/ verilog and mainline Linux support / UberDDR3 / MIAOW GPUs / proven open PHY stack / iCE40 FPGA, an open ath9k 802.11 Wifi PCIe, a Modos paper display and a flash drive w/ decryption key to turn it on. Use VexRiscV chips. Will still need a SiFive development board (like a SiFive HiFivePremierP550) for writing and programming the board, and soldering equipment + microscopes.

Also, "fully Libre'd Thinkpads" don't exist. Even if you wiped the firmware to the SoC, you still have the display, which is proprietary, the hard drive which is proprietary (to which there's only one company on Earth that manufactures open source hard drives, and that's Raptor Computing Systems which uses them for their Talos PCs that costs $15,000, and even if you were using an open HD, you'd still need Faraday protection to prevent sidechanneling) and so on.
Anonymous No.107010694 [Report] >>107010751
>>107010680 (OP)
I don't want to compile for 3 fucking days
Anonymous No.107010751 [Report] >>107011271
>>107010694
are you using a pentium 3 or something?
Anonymous No.107010752 [Report]
>>107010680 (OP)
I don't bother with a hardened profile. Or secure boot. Or any MAC system. No SELinux, no AppArmor. (I did consider setting up either Tomoyo or its fork Akari but I wasn't willing to go that far just for weeb meme points) Plain x86-64 on a consumer mobo, No RISC-V """dev boards""" or Talos II POWER 9 stuff. On my desktop I didn't even bother with disk encryption.

It's just a good distro that can do whatever you want your distro to do.
Anonymous No.107010834 [Report]
stop the larp dunning-kruger retard
Anonymous No.107010839 [Report] >>107010851 >>107010855
>>107010680 (OP)
You will also need:

>Banana Pi BPI-RV2 and Wio Lite RISC-V board integrates a RISC-V microcontroller (VexRiscV, again) for modem/router functionality
>FPGA/Soft-MAC Wi-Fi modules for fully open 802.11 networking experiments; setup includes an FPGA development board (e.g., Lattice iCE40 or TinyFPGA), and software stack such as Open80211, connected via USB or GPIO to SBC and optionally bridged to RISC-V boards
>SiFive FE310 as an open-hardware USB-to-UART/SPI/I2C bridge replacement, plus a Bus Pirate (open-hardware) when you want a flexible serial/GPIO bridge
>Connect your ethernet cables to your proprietary default ISP hardware and you can now use IP over DHCP to establish a private network connection

You'll also need open source USB keyboards/mouse you can buy that'll match the GPIO mapping (+compatible USB ports) to use for this setup that are safe from assembly-level malware (like STUXNET they used as an exploit in Iranian hardware), or NSA keyloggers. Like Keyboardio Model 01 for the keyboard and a Ploopy kit for the mouse. Also, use OLKB / Planck / Preonic / other OLKB boards — open PCB designs that run QMK (battle‑tested open firmware); widely supported, easy to build/flash. Flash via a programmer (e.g., Atmel ICE, JTAG, OpenOCD) — don’t rely on vendor binary updates. QMK and Keyboardio firmware repositories make this straightforward. Flash via a programmer (e.g., Atmel ICE, JTAG, OpenOCD) — don’t rely on vendor binary updates. QMK and Keyboardio firmware repositories make this straightforward. Use read/verify signatures: sign your firmware images and enforce verification (where the bootloader supports it) before enabling HID. If the MCU/bootloader can be fused to read‑only or locked after flashing, do so. Keep hardware debug interfaces accessible during verification so you can read flash contents and check checksums before locking.
Anonymous No.107010851 [Report]
>>107010839
To touch up:
>USB filtering / policy: use USBGuard (or an equivalent) on Linux to whitelist only approved USB device classes/vendor:product IDs before accepting HID input. This prevents a malicious composite device from exposing hidden endpoints.
>udev rules: create udev match/deny lists to prevent unexpected USB descriptors from being used.
>Isolate critical input: use a separate, minimal host (a tiny microcontroller you control) as the keyboard-to-host translator; the MCU forwards only standard HID events — no mass‑storage or DFU endpoints. The FE310 as a bridge is perfect here.
>Prefer wired over wireless for security (no RF sniffing/remote firmware attacks).
>Disable unused USB ports in firmware / physically block them with port locks.
Anonymous No.107010855 [Report] >>107011066
>>107010839
stop the larp dunning-kruger retard also nice job copy pasting the same thing twice from a.i hallucinations

Flash via a programmer (e.g., Atmel ICE, JTAG, OpenOCD) — don’t rely on vendor binary updates. QMK and Keyboardio firmware repositories make this straightforward. Flash via a programmer (e.g., Atmel ICE, JTAG, OpenOCD) — don’t rely on vendor binary updates. QMK and Keyboardio firmware repositories make this straightforward.
Anonymous No.107011066 [Report] >>107011442
>>107010855
Did I make a mistake? You're npt even attacking what I'm saying. You're just throwing buzzwords.
Anonymous No.107011268 [Report]
>>107010680 (OP)
How's 2014?
Anonymous No.107011271 [Report]
>>107010751
No, I just use Chromium.
Anonymous No.107011442 [Report]
>>107011066
Nobody is going to debate your A.I. nonsense buddy. Get a grip