At some point it won't matter that you run OpenWRT on it. Obvious case in point: at a certain point it doesn't matter that you run Linux instead of Windows on your Intel PC, because it'll still be subjected to Intel ME, Intel AMT, Intel SGX and god knows what else.
On a PC, Intel ME and the like can be accessed remotely only through an Intel NIC, which can be avoided by using a PCIe Ethernet card from another manufacturer, if the motherboard does not have such an interface on it. Even many of the Intel Ethernet interfaces are supposed to have the remote access disabled from the factory, but you cannot be certain about this.
A more serious problem is caused by the laptops having Intel WiFi, which is difficult to replace. With such a laptop one would have to disconnect the internal antennas and use an external WiFi dongle, to be sure that remote control is not possible.
It was a cool statement 25 years ago when the author was young. This "blurb" of an article gives me the impression that in some ways she thinks she still is.
Ok pitty, I was about to install it on a 486DX4 with 32MB RAM for use as a webserver, maybe I will link a blog with my findings about it later here on HN.
>> Hard disagree, the Openbsd installer is the gold standard to which all other installers compare poorly.
> No not really. I recently took my friend through it and there is several places where it is pretty easy to screw something up. Whenever people say stuff like this, they are usually accustomed to the quirks.
Like what places, and how are they pretty easy to screw up on? I'm genuinely curious, as to me it's the cleanest and most straight-forward console installer I've ever experienced. I managed to get it done the very first time I, 25 years ago, with zero *nix experience, decided to try OpenBSD. Also, you can always exit the installer and restart the process. You're not "screwed" unless you reboot at the end without having reflected over your instructions.
> Like what places, and how are they pretty easy to screw up on? I'm genuinely curious, as to me it's the cleanest and most straight-forward console installer I've ever experienced.
To you it is. I installed on 3.8 and it was not straightforward. I used to go to university with a guy that used OpenBSD and he even said the installation at the time was straight forward. So it isn't just me.
I can't remember specifics as it was about 4-6 months. It was something to do with drive labelling IIRC, it was super confusing and I think I just ended up removing drives temporarily.
> you can always exit the installer and restart the process.
Nope. I tried that. It did not work.
> You're not "screwed" unless you reboot at the end without having reflected over your instructions.
The installer is a plain *sh script. You simply ctrl+c to break out and return to the shell, then run "install" to start the script again. I can't see why you would end up with an installation medium containing a different installer than everyone else.
> The installer is a plain *sh script. You simply ctrl+c to break out and return to the shell, then run "install" to start the script again
I ended up in situation where that wasn't possible. I wasn't sure how that happened. But it did.
I have done many installations over the years on real hardware and VMs. It only happened once, but it can happen.
I could also bring up the issues with the auto partition layout that is suggest which can make impossible to install any larger of software after installation. Or how the disks can be confusingly labelled in some cases (especially in VMs).
The point being communicated is that it isn't as straightforward as many people claim.
I first started mucking about with it in like 3.8/3.9, and you had to do something which was very archaic (even for 20 years) with calculating partition size, so it has improved.
> I can't see why you would end up with an installation medium containing a different installer than everyone else.
I don't appreciate how you worded this.
I am not lying about my experience. I just can't remember the exact set of steps of what happened because it happened several months ago now.
Network performance has gotten steadily better during the last three or so years, to the tune of most network drivers today seeing around 2x throughput compared to a few years back.
I have a retired mid-2010s Celeron platform which managed about 300 Mbit/s on OpenBSD 7.1/7.2. With OpenBSD 7.6 it reached well over 700 MBit/sec. I also have an early 2020s Atom platform which saturates its 2.5GbE interface without any problems. Not all of the network drivers perform equally but the network stack improvements have all the same made them take pretty big leaps.
Softupdates was never an approach towards journaling. It was removed because it caused more problems than it solved and because its complexity stood in the way of future work to improve FFS2.
AFAIK there's currently no news about plans on getting journaling into FFS2 or bringing one of the other modern file systems onboard. The most "modern" choices you have on OpenBSD is FFS2 and ext3 (supported through OpenBSD's ext2 driver but without journaling).
My own experience with FFS/FFS2 the past 20 or so years is that it's been wholly robust through the relatively few power outages and other incidents I've had. While I wouldn't mind it becoming snappier I do prefer that its fully synchronous. I've never used softupdates.
FFS/FFS2 has been reliable for me, but unfortunately don’t have reliable power. It does frequently require fsck -y on boot. It’s not the most pleasant with my headless units requiring a serial cable.
My solution has been a huge UPS so they never turn off. Softupdates prevented this issue for over a decade (?), so hoping we get HAMMER2 or something down the road.
I’ve been running OpenBSD continuously since 3.4, and no other OS beats it in simplicity IMO. The upgrades have ticked along quickly and flawlessly year over year. I wish more systems would take a page out of that book and implement something like sysupgrade.
No idea. Despite no confirmations yet on whether space debris was involved, it felt relevant to share because of the overlapping nature and time frames.
reply