Lazier than you think! You almost nerdsniped me into seeing how fast I could whip up a crawler but then I checked the search and found out it can find comments and use a custom date range.
I'm not a card carrying FSF member but that seems like a deliberate omission from the admittedly brief history. However also fairly off-topic as criticisms go.
A maintainer willing to reject contributions is a good sign to me - BDFL with a vision prevents mission creep and associated ills. The right to fork alleviates most of the negatives.
> I personally use a boot-stub based booting method with my own SB keys
Same here - stub, kernel, initrd and embedded cmdline all in a signed UKI on the ESP. I do encrypt my root however, so I wouldn't go as far as "painless" for the grub->efibootmgr switch (but I also switched initramfs generator so... always keep a rescue stick around).
But it's all about ownership and trust. I control the keys - hence I am the owner of my computer - and I don't trust e.g. Microsoft[1] to not eventually try to fuck me over. But that's not the important part.
> Also, I don't understand where remote attestation entered the conversation here, and I also don't see why that can't be a community based thing (al la let's encrypt is now everyone's CA) where you can choose your providers or even roll it yourself.
Remote attestation is mentioned five times in TFA and is where this can get really pernicious - indirectly limiting user choice because $safety_critical_industry (e.g. banking) only allows "the corporate keys" (likely including a few Linuxes too, but something like Gentoo couldn't be). They'll even have very good and completely valid security reasons for not allowing arbitrary user keys, but they'd lock me down to approved choices remotely. A reverse AGPL if you will.
Of course, workarounds will exist: "just multiboot", "just use multiple devices", "just choose the bank that allows you to whitelist your key" (assuming there is one, it's nice to dream) - but user freedom is reduced without malicious intent being strictly necessary anywhere in the process.
That's focusing on the negatives with my paranoiac hat on, of course.
> I've read that the PCEngines struggles to keep up with network traffic in excess of 100Mb/s.
For reference, quick iperf3 TCP tests on my APU2 (cpu[0123]: AMD GX-412TC SOC, 998.27 MHz; em[0123] at pci[1234] dev 0 function 0 "Intel I211" rev 0x03):
LAN host <-> APU: ~410 Mbps
LAN host <-> APU (over WireGuard): ~140 Mbps
However, I've put em[123] together as a veb(4) switch without pf involvement and two LAN hosts will get almost the full gigabit between them over that. Would need something bigger if I had a faster uplink or more complex LAN requirements.
A large part of it is just that it's "home" after finding it at the right time in my skill curve - probably could've been Arch as well.
The Arch wiki might be a bit better and we all benefit from it to some extent, the Gentoo wiki is also good and honestly I don't use either that much anymore.
The great differentiator is portage. I never run into "maintainer built the package without xyz support" - sometimes I'll run into "stupid user disabled xyz support when installing" but that's just a config change and easier to accept since I'm the stupid user. In theory they might've missed adding a USE flag for that feature and I'd have to overlay my own ebuild or live without it. Custom source patching is built in and package versions can be (un)blocked via package.mask/.accept_keywords.
Version 4.3 broke something? package.mask: =pkg-category/pkgname-4.3 to downgrade to 4.2 and still automatically get 4.4 when that shows up. Mask >=4.3 instead and nothing will change (but eventually dependencies might force you to fix it, of course).
Compilation is pretty fast on a modern computer. Significantly slower than binary packages sure but it's mostly with browsers and maybe qemu/compilers that you really feel it (and several of those do have binary packages, e.g. www-client/firefox-bin, dev-lang/rust-bin). On my old laptop this turned into an excuse to experiment with distcc and nfs for speedups (Core2Duo with 4GiB RAM is a bit weak for encrypted ZFS + compiling gcc, and also it's fun).
Compilation times is still the strongest con but having compilation as a first-class citizen is what enables most of it and the big stuff you just run in the background.
(For the unaware, do note that "compiling myself" means "emerge pkgname" or "emerge -auvDNU @world" and includes dependency tracking, not "./configure && make" and manually hunting things down.)
I did run Arch for a while around 2010 but it didn't take. It's nice to find a permanent home - I've been on Gentoo since 2013 and an acquaintance has been on Slackware since the 90s.
Those three seems to be where us tinkerers end up.
...and that's a feature. There's nothing wrong with Arch doing its thing, there's always Debian/Ubuntu/Fedora/Manjaro/whatever - and Gentoo for those with taste.
Yeah wlan is by far the weakest point of OpenBSD networking - especially
as an AP. Slipped my mind completely actually. The way most do it is to have separate APs.
Setting up an OpenBSD router is almost trivial - it's all there in the base system. dhcpd, unbound, net.inet.ip.forwarding=1 and a forwarding rule in pf.conf and you're good to go. Then the tinkering starts, of course (even wireguard's available in base). Do run a few benchmarks - my APU2 can't really live up to gbit IP throughput (iperf3 speeds were about 500 Mbps, no performance tuning ). Luckily the veb(4) software switching does reach 1 Gbps locally and my uplink is only 100/100.
However I also believe that's only because they haven't considered
the potential impact of constant surveillance from everything you own
sent to third parties who will keep the data forever.
...or maybe they just trust faceless strangers more than I do.
https://hn.algolia.com/?dateEnd=1700092800&dateRange=custom&...