[AshamedCaptain]

What is sad is that even though Linux now has hardware support that is miles ahead of Windows, we've exchanged one problem with another, because nowadays most of the hardware I see is only supported on Linux and nothing else.

Even on PCs, latest generation AMD graphics cards (already >1yr old) are not supported in _anything_ other than Linux (and Windows). This is just sad.

[craftkiller]

FreeBSD uses a compatibility layer to run the Linux graphics drivers, though it lags behind Linux. So if FreeBSD currently does not support the graphics cards, it will soon. It looks like they are currently porting over 6.11: https://github.com/FreeBSDFoundation/proj-laptop/issues/41

[AshamedCaptain]

It is the _only_ OSS operating system that supports AMD cards from this decade, and it does so by having to emulate the Linux kernel API, and yet _still_ it lags years behind Linux itself. I've chosen this example for a reason -- this is exactly what I'm sad about.

[0x457]

That and WiFi being stuck at 802.11g is what made me switch. It was a very sad day for me when I uninstalled FreeBSD from all of non-server machines.

[craftkiller]

That certainly _used_ to be the case, but it looks like 802.11ac is supported in iwlwifi since FreeBSD 14.3: https://man.freebsd.org/cgi/man.cgi?query=iwlwifi&sektion=4&...

And it looks like they're adding 802.11ac support to some realtek drivers too: https://www.freebsd.org/status/report-2025-10-2025-12/#_linu...

[0x457]

Not to sound like goal post mover, but once you tried 802.11be @ 6GHz, you never go back (assuming what your AP connected to can handle it).

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.

[skydhash]

I wouldn’t mind faster wifi speed, but reverse engineering stuff has always been slow (i.e Asahi Linux, and they only have a few device to investigate)

[craftkiller]

eh I've got 802.11be @ 6ghz at home (u7 pro AP and QCNCM865 client) and it is truly impressive, but I only notice the difference once every 1-2 years when I'm transferring a full-disk image over the network for backup. We've long passed the point where the speed improvements matter for daily usage (browsing the web, streaming video, remote desktop, installing updates). For those use cases, you wouldn't notice a slowdown on 802.11ac and I'd argue even 802.11n would be fine.

The one exception I can think of would be video content creators since they end up with large amounts of raw video that would benefit from transferring at much-faster-than-streaming speeds.

And I guess steam downloads if you don't plan ahead at all, but if I'm planning to play a game later, I'll tell steam to install it hours or days in advance.

[rjsw]

Ethernet works fine for me at home, only use WiFi when travelling.

[delta_p_delta_x]

> now has hardware support that is miles ahead of Windows

[X] doubt.

[jasonjayr]

Windows is cleaning up a lot of legacy drivers. A bunch of printers (+ scanners) that predate updates to the printer driver framework in recent versions of windows just don't have functioning drivers anymore, despite being perfectly functional.

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

[bluebarbet]

Most devices that you can buy for under $400 now run on ARM chips (frequently Mediatek). We're talking tablets (with keyboards), convertibles, even outright laptops (i.e. "netbooks"). These things qualify as computers. They are replacing traditional laptops, just as those replaced desktops.

And they do not run Linux out of the box.

[yjftsjthsd-h]

If we're looking at sub-$400 computers, especially on ARM, it seems like we have to include the large segment of ChromeOS devices that only run Linux out of the box (or at all, generally).

[bluebarbet]

Referring to Intel Chromebooks (i.e. laptops), that segment is now dwindling in size much as its predecessor (Intel Windows netbooks) did a few years ago. Most low-end ChromeOS devices now run on ARM. And Android is nipping at their heels.

[trelane]

> Intel Windows netbooks

Netbooks were originally Linux. MSFT created a special licensing class just to try to undercut it. It wasn't great, but because Windows and Microsoft licensing, it quickly took off. People realized Windows on netbooks sucks, thought that meant that netbooks sucked, and eventually netbooks died. Until, arguably, ChromeOS arrived.

RIP, Linux netbooks of yore. I do miss you so.

[yjftsjthsd-h]

Sure. And all of those devices run Linux. Some of them even run other Linux OSs decently; one of my daily drivers is an ARM Chromebook running postmarketos.

[ux266478]

Most devices in that class I see run some vendor flavor of Android or ChromeOS and not Windows, so definitionally speaking they do run Linux out of the box.

[bluebarbet]

Yes but it's a bit academic. The problem is that getting a FOSS distro of Linux onto low-end general-purpose computing hardware is harder now than it was a decade ago. I speak from bitter recent experience.

[ux266478]

Oh, I know perfectly well what you mean. The move to the SoC paradigm has serious implications for the future of computing freedom. I can't imagine how we might be able to fight this crap, realistically.

[AshamedCaptain]

There is only one area where windows excels: recent PC-based hardware. For everything else, primarily including anything that is not PC, and anything that is from more than a decade and a half or so ago, Linux is miles ahead, and there's no discussion possible.

Whether this is any helpful to us is another story.

[ux266478]

Why do you think so?

[cevn]

It's sad because it removes choice from users over what OS to run. People that only use windows are going and throwing their old computers away.

[ux266478]

I think of it more in the reverse, the choice being removed is the hardware you can use. It has been the case from the dawn of computing that you start from a usecase (which correlates to software, which maps to an operating system) and then look at your options for hardware. The more specific your usecase, the more specific your software, which correlates to a specific choice of hardware. There is no, and can be no, "have it all". It's a fundamental principle of mathematics, the postulates you choose radically change the set of proofs you have access to, and the set of proofs you choose entail the axioms and structures you can take.

Now it can be better or worse, and right now it's never been better. There was a time when your language, your shell and your operating system were specific to the exact model of computer (not just a patched kernel, everything was fully bespoke) and you have a very limited set of peripherals. That we suffer from more esoteric operating systems lagging behind the bleeding edge of extremely complicated peripherals is a very good place to be in. That there's always room for improvement shouldn't be cause for sadness.

[AshamedCaptain]

> Now it can be better or worse, and right now it's never been better. There was a time when your language, your shell and your operating system were specific to the exact model of comput

No, it is not. There was a small period of time between the 90s and the 2010s where you could grab almost every 386 OS and have your hardware mostly decently run for it, and if not, drivers would be easily written from manufacturer specifications. That time was definitely better then than what we have today, or what we had before then. I am writing this as someone who was written serial port controller drivers for the BeOS.

> That we suffer from more esoteric operating systems lagging behind the bleeding edge of extremely complicated peripherals is a very good place to be in.

This is the wrong logic, because operating systems become esoteric since they can't support the hardware, and hardware becomes complicated and under-specified because there's basically only one operating system to take care of. You may _think_ you have no reason to be sad if you're a user of Windows or Linux, but you have plenty anyway.

[ux266478]

> There was a small period of time between the 90s and the 2010s where you could grab almost every 386 OS and have your hardware mostly decently run for it

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.

[AshamedCaptain]

> 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.

Not at all; I excluded this early era because you could _not_ be sure to find an OS that would support your graphics card at all, other than maybe what the BIOS supported. I am talking about the 90s because GPUs already had plenty of non-BIOS-supported features, like multiple CRTCs, weird fixed acceleration pipelines, weird coprocessors with random ISAs, and yet you could still find operating systems with 3rd party drivers supporting them.

It is a _perfectly_ distinguishable era. See how many OSes support 3D cards from the era like i9xx. Heck, FreeBSD itself qualifies, but also BeOS and many others.

In addition, I am talking about the _kernel_ part, which by any logic should be ridiculously simple. E.g. this is not a compiler to a random ISA or anything like that. It is what in Linux you would call a DRM driver, and the only reason they are complex and millions of LoCs is that they are under-specified, by AMD and the rest. Most of lines of AMD driver code in Linux are the register indices for each and every card submodel (yes, really, header files!), when it is clearly that before they would just have standarized on one set and abstracted from it. Compare AtomBIOS support in cards from a decade ago and cards from today. It is literally easier today for a 3rd party to implement support for the more complicated parts of the GPU (e.g. running compute code!), which AMD more or less documents, than it is to support basic modesetting support as it was in the 00s. This has happened!

Hardware may be more complicated, but interfaces needn't be more complicated. This, I believe, is a symptom, not the cause.

> 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?

You do not find it sad that there is no longer any operating system other than Linux supporting any amount of hardware, simple or not ?

Also, you call every non-Linux OS as "esoteric" as a counter-argument to my point , yet you try to use support for definitely esoteric hardware (which would be even hard to acquire!) as an argument for your point, whatever it is ? When I'm complaining that I can no longer rely on FreeBSD, literally the 2nd open OS with most hardware support, on supporting basic hardware (!) from this decade, when on the past I could more or less rely on _all_ BSDs supporting it, as well as a myriad other OSes , the argument that "oh well it never supported hardware that it is impossible to find in stores anyway, so I don't care" sounds pretty hollow.

Certainly even slightly deviating from the popular hardware has always resulted in diminishing returns, but today it is much worse, _except_ for Linux.