UPDATE

Solution. FreeBSD receives a stay of execution on this end. For now.

UPDATE 2

A few weeks ago I made the mistake of running # freebsd-update install before # pkg upgrade. This resulted in my entire DE being autoremoved. I ran # desktop-installer to restore it, but could not get past the KDE login screen when I was done.

Yes, the mistake was mine, but combined with this issue I'm done fighting the distribution. I shifted my mission statement to explicitly target distributions that have preconfigured DEs as part of their installers. Since no BSD meets this requirement, I comfortably replaced FreeBSD with openSUSE Tumbleweed.

The next time I try FreeBSD will likely be after I get a Mac, which will then allow me to replace OpenIndiana with TrueNAS Core (or whatever the free tier of TrueNAS is calling itself at that time.)

(TL,DR: Yes, the title is contradictory as I'm planning on deploying TrueNAS)

My dream has always been to run all major (server and desktop) OS kernel families:

1. NT (Windows) ✅
2. Unix-like ✅
   1. Linux ✅
   2. BSD ✅
3. Unix ✅
   1. Illumos ✅
4. UNIX™ (Coming soon)
   1. macOS

✅ = I currently run an OS kernel in this category

I've written before about why I might no longer run FreeBSD , but I think what has just transpired might be the last straw.

I just updated from FreeBSD 12.x-RELEASE to 13.0-RELEASE. Doing so completely broke my KDE setup, to the point that KDE won't even launch at all.

Setting aside the fact that a major OS being unable to sustain a major version update without KOing DE functionality in 2021 is completely ridiculous, the current workaround is to build the driver from source.

Building kernel modules from source produces a whole range of problems, not the least of which are being possibly out of step with repo packages from the same source, as well as complicating future updates.

This would be totally understandable if the OS in question were an Illumos one, such as OpenIndiana, whose core dev team has only 10 people. But this is FreeBSD, the OS that supposedly underpins Netflix, PlayStation, Switch, etc.

It's well known that FreeBSD's dev team don't care for DEs or the desktop use case. Now, one might argue that they aren't listening to their users. And, if one truly believes that's the case, then it makes sense for desktop users to run FreeBSD in the hopes that one day user demands will win out. Sure, you can use scripts to install DEs, but the problem with scripts is they tend to go out of date relatively rapidly (compared to proper ISO packages) due to having no direct upstream connection to the distribution. As such, the configs they result in are also not particularly robust.

There is no substitute for core dev team support of a feature.

Sadly, today, while visiting the FreeBSD forums to ask about my KDE woes, I discovered this thread, in which over half of the FreeBSD Forums members who voted in the OP poll indicated they had "Doubtful" or "No" interest in a FreeBSD KDE distribution.

That's ... in a word, insane. The poll has only 57 votes through nearly 4 months. That tells me pretty much no FreeBSD users are interested in this topic at all.

Clearly, there's absolutely no hope for DEs ever being 1st class citizens in FreeBSD. Ever.

And now that I've recognized that truth, the reasons for me to run a FreeBSD desktop/workstation have evaporated.

Fortunately, TrueNAS exists. Unfortunately, the machine most suited to running it is currently running OpenIndiana (which since my installation thereof in 2019 has proven itself largely useless due to severe lack of package support), so I'll probably wind up having to install OpenIndiana on my current FreeBSD machine and then throw TrueNAS on the current OpenIndiana machine.

I'm not the only person to reach this conclusion with FreeBSD. The project's devs and its community have an extremely rigid view of the distribution as a religious artifact of 1980s Berkeley software development. It sounds cute, but the problem with religious artifacts is they tend to be practically immutable (e.g. the cross, the US Constitution) even when that property is against the faith's long term interests.

I've read complaints from Project Trident's devs as well as pfSense and TrueNAS users (I'm still willing to give TrueNAS a chance because unlike many people I'm not trying to use it for VMs or jails). The bottom line is that FreeBSD is awesome right up to the point that you want it do something even minutely different from the status quo and need upstream support for that to happen. Then you get stonewalled as none of your asks, no matter how small or reasonable, are met.

So, it's deuces, FreeBSD. Honestly it doesn't matter if the driver bug gets fixed in the repo because thanks to the aforesaid the problem is guaranteed to repeat itself the next major version upgrade.

Clapbacks & Counterarguments

Fuck FreeBSD? FUCK YOU!

Yeah, there's a reason I didn't post this in a FreeBSD forum. You're never gonna get objective criticism of a faith within a place of worship for that faith.

Installing DEs on FreeBSD is easy LOL

Unless you're intimately familiar with how X11, windows managers, etc. all play together (which shouldn't be necessary to use a DE in 2021), this is true only if:

1. You use a script (the 2 major ones I'm aware of are instant-workstation and desktop-installer)
2. That script is up-to-date
3. The packages that script installs are:
   1. up-to-date
   2. actually support your hardware

It has been my experience that neither 2 nor 3 can be guaranteed.

You should learn how X11, windows managers, etc. work

Nobody has time for this when macOS, any of the gazillion Linux distros with working DEs, OpenIndiana, and Windows exist.

FreeBSD is an OS for professionals

TIL professionals apparently have a lot of time to waste.

If you don't know C, don't use FreeBSD

So eventually no one will use FreeBSD (ever heard of Rust?) Got it.