But I couldn't get it to see the external monitor. I fought this for hours. I finally reached my patience threshold and tore the fucking LCD off the case. It hurt the hands a bit but was cathartic. Amazingly, it booted and saw the monitor, magically. I was astonished. With or without the broken screen, it wouldn't boot. But going psycho on it fixed it. Proof in the wholesomeness of violence, maybe not. But...

it's not running BSD. It's now my mom's desktop, and it's running Void. Works great, and I love the Ryzen 4700, with 16gb ram and atheros wifi chip. Delicate, but capable of some extremes :)

> X220/X230

These are pretty solid with dual batteries. Also popular for OpenBSD and 9front, the latter of which I run on an x230 (it stopped charging the removable battery :-/) You can get about 2 hours off the internal and 6~8 with a big fat removable battery, maybe more if the OS and drivers can properly throttle hardware power settings.

I have an X1 carbon 5th gen and it's quite light but not useful for 9front without some Ethernet driver tweaking (likely some phy bits need twiddling.) Instead I tossed Debian on it and run 9front in a VM if I need a local CPU. So far it just seems to work including Ethernet (via a dongle) and WiFi.

Is this just an artifact of FreeBSD primarily focusing on server hardware rather than consumer/end-user stuff?

In the old days I kept a couple Realtek USB adapters around that would almost always work out of the box or with ndiswrapper

Some years ago, I was workig with FreeBSD on an old laptop. The laptop had a wireless adapter that ostensible should be supported, but was not.

After some digging, I realized the driver was just missing some PCIe device identifiers. I added them to driver and bam my WiFi is working without issue.

I tried to submit a bug report and patch, and it got positive feedback at first any changes even got committed. But then I learned why it’s better to not even try.

Apparently this was a known issue, but only in the heads of the FreeBSD wireless developers. They had their reasons for not adding the device, but the reasons did not appear to be documented in mailing lists or docs until my thread. At that point I realized it’s not worth it to try and contribute to such large projects as I just lack the decades of institutional knowledge of the system.

Anyway, I’m not sure it ever got released. I believe there’s an umbrella bug somewhere left after the version my patch supported went out of support.

FWIW, I’ve done both, FreeBSD with a virtualised OpenBSD for WiFi, and currently I run Arch so I can do gaming, with FreeBSD virtualised for development. I’m kind of looking to go back to my previous setup.

But the comment you're replying to said there weren't many good technical reasons to prefer freebsd over linux. I think that's broadly true.

I still really like freebsd though. Unlike linux, one community is responsible for the kernel and userspace. That makes the whole OS feel much more cohesive. You don't have to worry about supporting 18 different distributions, which all do their own thing.

All these devices work out of the box on linux, more or less.

Whether this is any helpful to us is another story.

I've been using Linux and BSD in one form or another since 2003, and I definitely used wpa_supplicant on the command line to connect my Thinkpad to WiFi. And you're right, it did suck. It was not a 9/10 experience by a long shot.

I doubt anything can get the scale of Linux and not have some mess.

"Only two remote code execution vulns in the default install" isn't saying much, because the default install has essentially no functionality. Similarly, RCE is not the only kind of vuln.

Let's just say it is not the mainstream consensus that OpenBSD is meaningfully more secure than an up-to-date linux. This may have been true in 1995, but it's generally acknowledged by people who know what they're talking about that OpenBSD's reputation for security is overstated.

Yes this is my opinion also. BSD seems more suited to people for whom fiddling with the OS itself is the point, rather than the OS being a tool to get other things done.

I fall firmly into the latter camp. I'd rather chew glass than manually set flags in rc.conf

That's my problem with FreeBSD on non-servers - eventually it's supported, usually via Linux shim, but it's too late. By the time FreeBSD started to support (on CURRENT) GPU that forced me to switch, I already upgraded twice.

Glad it's getting better.

I remember doing those kind of things nearly two decades ago now, I don't expect to have to do that in 2026. If people want to, that's fine, but the parent comment is right here: giving it 9/10 without working wifi is ridiculous.

WiFi on a laptop is table stakes. I'd rather use an operating system that works without dongulation.

  One such example security solution is memory integrity, which protects and hardens Windows by running kernel mode code integrity within the isolated virtual environment of VBS. Kernel mode code integrity is the Windows process that checks all kernel mode drivers and binaries before they're started, and prevents unsigned or untrusted drivers or system files from being loaded into system memory.

Link: https://learn.microsoft.com/en-us/windows-hardware/design/de...

And prior to that, you could grab every OS running on IBM clones and not have to worry about graphics drivers at all, because graphics acceleration wasn't a thing. The era you refer to had already introduced software contingency on hardware within x86. This disparity was further compounded in the mid-2010s as GPUs exploded in complexity and their drivers screamed into tens of millions of lines of code, eclipsing kernels themselves. This is not distinguishable from the introduction of graphics drivers in any generalized manner. They were driven by the same process.

An important thing I want to point out as well; you're doing a lot of heavy lifting by limiting the pool to x86 computers, which is already giving up and admitting to a very strong restriction of hardware choice. Don't take that as pedantry, it's a very well hidden assumption that you've accidentally overlooked, or in the case that you think it's irrelevant, I'm letting you know that I don't consider it irrelevant in the slightest. When I think of computers, I'm not just thinking of x86 PCs. In the 90s I'm thinking of SGI workstations, Acorns, Amiga, Macs. I'm thinking of mainframes and supercomputers and everything else.

> This is the wrong logic, because operating systems become esoteric since they can't support the hardware

On the contrary, I assure you that this logic rests on faulty premises. As a general principle it's clearly false since most operating systems (which are long forgotten) predate it by decades, and in the specific context of Linux winning over FreeBSD, it's still not applicable as that happened smack dab in this era you describe.

> You may _think_ you have no reason to be sad if you're a user of Windows or Linux, but you have plenty anyway.

I'm a user of Linux, FreeBSD and 9Front. I just don't (and never have) bought hardware at random. You can reason your way into sadness any which way, but rationalization isn't always meaningfully justified. I just don't find it sad that my second desktop can't have an RX 9000 whatever in it. Where's the cut off line for that? Why not be sad that I can't jam a Fujitsu ARM processor into a PCIE slot as another type of satellite processor? The incompatibility is of the same effect, but I don't see you lamenting or even considering the latter, as though mounting a processor to a PCB is somehow fundamentally less possible than writing a modern graphics driver.

> PostmarketOS is a bit simpler (or at least better documented) but it is not a full Linux distro.

By what definition is PMOS not a "full" distro? It's Alpine plus some extra stuff, including device tweaks and out-of-the-box desktop environments.