My general impression is FBSD isn’t foremost a GUI desktop but instead a foremost cmd system with a GUI add on that requires tinkering.
Apart from the tinkering part, it is.
But that's not FreeBSD. That's Unix. And all unix[like] including all Linux, are the same in that point. You only may get a different impression, when you pick some turn-key OS that autoinstalls a DE.
On Unix the main UI is the terminal, the shell. Anything else is optional.
FreeBSD is a multipurpose OS, which means, it tries to serve different kinds of computers and purposes. While a single user desktop computer with a DE is just one possible purpose. To respect different kinds of purposes, it comes only with what's needed for all purposes, and the ability to
easily add all the optional packages needed to fulfill a certain purpose.
A turn-key OS, like many Linux distros also like some BSD derivates, does it otherwise. It serves a single purpose, only: A single-user desktop on a x86-machine, fully autoinstalling with a GUI.
This may suggests, the TUI (terminal) was optional, but in fact it's not. It's still the same principal: The terminal is the core main UI in all unix[like], and a GUI is an extra toppiece placed upon it. It's just the user is passed by most of the shell stuff and set infront of a GUI directly. There is no GUI-only OS. Windows tried, but failed, because there are always things sooner or later you need some kind of a CLI for. And better a real shell in the first place, than that thing what Windows provides.
But FreeBSD does it not much otherwise. The only difference is, you need an extra step each to get a machine for a certain purpose, like a single-user desktop. If you wanna GUI, tell it to install X.org. Then it detects the hardware, installs the right drivers, and X.org. If you are not satisfied with twm, which comes with X.Org, but want another WM or even DE, tell it which one to install, and it installs it for you. Then pick the software packages you want to have, and tell it to install them.
No rocketscience, just a couple of more steps, that's all.
Serving one purpose only is the requirement for fully automating the installation process - to spare the user the strenuous effort of deciding which software to use, pick and install it by himself.
The price you pay for that, apart from getting a single-user desktop machine, only, is you don't get your individually tailored machine. You get a pre-picked and preset DE, everything already designed in advance, pre-picked software packages, pre-configured look-and-feel, etc. For that, you also have to compromise even more: If you wanna use a certain distro, you have to live with the DE it comes with. Or you want a certain DE, you can only pick from the few systems that delivers that. You have to live what others picked. If that's okay for you, and for the most it is, then it's fine. Problem solved. But if not, e.g. you try to use another DE/WM instead of the default one, in most cases the tinkering starts, real tinkering. Because your are going to mess with a system that's not intended for this. At the latest you run into lots of trouble, when there is an update. Because many turn-key OSs are not capable to deal with their users modifying core fundamentals about it by themselves. That contradicts the core idea of a turn-key OS.
Perhaps this is mistaken or not but I shy away from FBSD as a GUI desktop because I don’t want the hassle of tinkering and compiling.
Understandable. If you're not one of the masochists I mentioned in my last post above, nobody wants to tinker.
About the compiling part I also have two experiences:
Linux - I hardly got something compiled successfully on any Linux distribution I ever used at all. All I always only got have been zillions of error messages and abortions, mostly because of missing dependencies. Trying to build those first produced even more of the same mess. It was like the Hydra from greek mythology: Each head cut off produces even more heads to be cut off. THAT was tinkering to me. Tinkering without seeing an end of the tunnel. Very unsatisfying.
I will never forget my first compilation experience I had on FreeBSD: I compiled X.org, a pretty large one. Compilation took a while. It always does. That's why there are already compiled binary packages to be used directly. Can't remember, was on my old machine almost ten years ago. Three or four hours the compilation took. But it went through. Compilation finished. No abortion. Working executables produced directly at the very first time. I was flabbergasted. I always presupposed that to be as the normal case, but I never experienced it. I directly also compiled a new kernel. Completely pointless for my case back then. I simply wanted to see if it also worked. It did. To me that was crucial to decide for FreeBSD: It works.
The point ain't compilation time. The point is, if the compilation runs abortion-less through, or need additional tinkering. When FreeBSD version and the port tree are congruent, matching, then all port's compilations run through. And that's exactly one of the essential core ideas of FreeBSD: To provide a congruent, matching set of system and ports. That's what you get, when you use RELEASE.
But you don't have to compile anything at all. Just stick to packages. When you don't do no modifications but simply compile the default you get the same result as with the packages anyway. So compilation is only needed when you modify something with a package, or for a very few exceptions (see the forums). But they are not the default, and anyway no big deal at all whatsover. Just do
make install clean BATCH=yes (maybe without the 'clean') and just let it run! If your versions match, it will run through, and being installed - everything fully automated working.
Don't become panicky by all the troubles you read here. Trust the Handbook. Apart from some people here doing special things, sometimes even real freaky stuff, there is lots of experimenting with development versions et al going on.
Most of the issues posted here are caused by simply just don't read the Handbook, or failed experiments, fumbling, tinkering with CURRENT instead of just using RELEASE, mixing ports and packages of different versions, getting sources from elsewhere than just simply using the ports, or doing some things they got by some AI chatbot, not knowing shit what exactly they are doing... fatfingering causes troubles, of course.
Just read and stick to the Handbook, and FreeBSD runs fine.
Very seldom there are real issues caused by flaws of the system. And if, then when a new major version is fresh out. Just stick to your old version - it's supported for at least three more months. Why the hurry? - and see how things work out.
I'm still running 14.4. It still is supported. Why shall I upgrade now? Because there is a new version? It will gives me the same service as I have now: It runs my Apps. So, why? For what? Security? 14.4 still is supported, so it provides the same safety as 15.1.
I see myself as a user, not a developer. My primary target is not to run the most recent version, but to have a reliably working machine without tinkering. And that's
exactly what I have.
I also see all the troubles with 15 here. Most are caused by not reading the announcements, nor the according documentation. I will upgrade, when 14 is EOL. That will be at the end of this year, in four months at the earlist. Enough time for me to figure out, how I do the upgrade, what will come, and what needs to be done, if something goes wrong. I'm pretty sure I will not run into neither surprises, nor tinkering.
My tip was:
Do a clean, new installation of a RELEASE, then just do what's in the Handbook, only:
pkg install drm-kmod for Intel and AMD GPU, or
pkg install nvidia-drm-kmod for NVIDIA
pkg install xorg
add your user to the video group, so not only root is allowed to have access to that resource
pkg install xfce xfce-4.20_2 Meta-port for the Xfce Desktop Environment
And for the rest, like get your user have access to USB flashdrives, also stick to the Handbook.
I bet you have a up and running XFCE on FreeBSD within less than 2 hours, and no tinkering.
