gentoo really does have some great tools. gentoolkit is full of useful utilities. eix is such an overpowered package search tool, I think most people never even learn how to fully use it
Gentoo is something I've always attempted intermittently, but I could never get off the ground. Pure skill issue. See, I'm actually autistic enough to run
make menuconfig and start configuring my kernel going off stuff I just rote memorised... but always forgetting a kernel module, USB, SATA, or something along those lines. Reboot after installing GRUB and my shit just hangs. I've seen Gentoo install guides where they just install a binary kernel and there's somthing that just feels...
wrong about that? Compiling from source is a pain in the ass, it takes a long time, you run the risk of forgetting compile time options, but that's the whole point of running Gentoo or compiling from any BSD ports tree. Gentoo is an entirely self-inflicted skill issue for me, and I refuse to take the easy way out by using a binary kernel or compiling a generic one
just so I can avoid learning how to make a truly custom one. I went through the trouble of picking a source distro, and I'll be damned if I don't sit down and compile Firefox. I better goddamn
need that software if I'm gonna install it by source, even with Portage and its myriad features I never learned in depth because I never got a working Gentoo system at all thus far.
Cheers for the correction. That said, I'm nowhere near optimistic about Wayland's future. Yes, it's definitely
far more useful between 2024-2025 than it was between 2014-2015. No, it's nowhere near ready for prime time and it ultimately never will be. Wayland's biggest stumbling blocks are twofold:
a) Fundamental implementation issues that are a byproduct of how Wayland the protocol is specified, and how compositors need to make up the difference from there. X is a bloated behemoth in terms of disk space, but even full fat X11 basically uses like 1GB of memory tops while keeping all the graphical primitives and libraries on standby. Wayland's design means that there will
always be more RAM and GPU usage because
everything must be redrawn and sandboxed the moment you click the button to make another window appear. If you move shit across your monitor or between monitors, shit gets redrawn. Absent a full Wayland 2.0 specification rewrite where the compositor gets standardised too, Wayland
cannot get over this hurdle.
b) The biggest representatives of Wayland are also its
worst. GNOME and KDE already receive
heaps of corporate assistance and paid developer hours working on these projects. It's why GNOME and KDE even have COCs in the first place. Not just from Red Hat but also Canonical, SUSE, etc. Freedesktop was already compromised by Red Hat, but GNOME decided to throw salt in the wound by coming up with their own "Human Interface Guidelines." The jump from Plasma 5 to Plasma 6 was a disaster for KDE where the Wayland push was hideously botched, tons of regressions emerged in the X11 session, and now they're nixing X11 altogether because they don't wanna maintain it. GNOME and KDE both have heaps of open bug reports for persistent issues on Wayland
despite corporate assistance. I know it's a running joke about enshittification, but this is the current standard of quality we have
with paid developer time. GNOME and KDE leadership need to be fundamentally overhauled in a hostile takeover situation where all the obstinate bullshit gets thrown out and actual QA and maintenance returns.
I ain't ever gonna talk shit about your experiences with FreeBSD because ultimately, it's a hardware thing and I've certainly had those problems before. Desktop PC tower with all AMD hardware currently running FreeBSD 14.3 with a striped ZFS pool using the entire portable hard drive I install shit to. It'll run anything from Windows 11 to friggin Haiku. I think yours was on a laptop (correct me; sounds like it because you mentioned wpa_supplicant, maybe you explained earlier and I didn't read properly), and unless you're running a Thnkpad TXXX laptop, it's a real crapshoot. Having said that... I really do think you're being unfair to FreeBSD. It's
more than capable of being a desktop system; many FreeBSD developers and contributors themselves daily drive FreeBSD as their desktop OS.
You're over here waxing poetic about powerful features and the thrill of learning them, but you're doing so in a Gentoo context. Meanwhile, you're overlooking how FreeBSD's ports tree was the literal inspiration for Portage in the first place... that's why it's called
Portage. FreeBSD has an assload of cool ass shit that it can do as a desktop, a workstation, a server, or anything else you can come up with. The trick is, like with Gentoo and even Arch, you gotta actually learn it on its own terms. "It" being FreeBSD, of course.
**
This is a cliché talking point, everyone says it when they learn about FreeBSD for the first time, but the "base system" vs. "ports" (i.e. external applications) distinction is
critical. If you don't "really" get it, you're gonna have a bad time.
Gentoo, Arch, Debian's minimal netinstall ISO, they all have a "base" of sorts, but it's
not the same thing as FreeBSD's base system. When you boot into a text console on Gentoo, Arch, or Debian, you're booting into a hodgepodge of software that's effectively "off the shelf." The Linux kernel is developed separately from GNU coreutils which is developed separately from glibc which is developed separately from groff which is developed separately from bash which is developed separately from yadda yadda yadda. All Linux distributions fail to make a distinction between "core system" and "external applications" because the
entire distribution is nothing
but external applications.
FreeBSD is a complete text-based OS. That text console you boot into for the first time when running FreeBSD has an entire set of Unix tools that are built to work together and play nice as a singular, unified whole. That's why you can't ever find a "BSD From Scratch" book, let alone isolate any given BSD's libc and package it as separate software. For the stuff they don't develop independently like GCC or GNU Readline, they still integrate it into the base system but it's a highly customised variant that
cannot be packaged separately. The base system is responsible low-level hardware interactions, it has all the systems and subsystems necessary for external applications to utilise, but it doesn't ship with anything else beyond that.
**
If someone says "FreeBSD doesn't support my graphics card," that's a technically correct statement built on a false premise because FreeBSD (i.e. the base system) doesn't even ship with graphical support. Graphics drivers and display servers, available in the Ports tree, are what make your graphics card work. Graphics drivers exist in the ports tree, so you'd need to install
drm-kmod or
nvidia-driver. then add something like
amdgpu_enable="YES" or
nvidia_enable="YES" to
/etc/rc.conf. Even then, all the goodies for a proper graphical environment are outsourced to the display server like X or Wayland. Installing either pulls in all the other crap necessary for graphics to function like Mesa.
Fun fact: NetBSD and OpenBSD both have X in their base systems because their design goals necessitate a full graphical stack available out of the box, altered permissions, dedicated user for X, etc. Therefore, you can make declarative statements on whether or not either OS supports your graphics card.
The whole point of this diatribe was basically to point out that
everything that you install via
pkg install whatever or
cd /usr/ports/category/program && make install clean, be it something comparatively simple like a headless LAMP stack or something relatively complex like a graphical environment with XFCE4, Firefox, VLC, and LibreOffice and
all their required dependencies, are considered external applications. The
FreeBSD FAQ used to say it outright.
FreeBSD FAQ from 2021 said:
1.4. Can FreeBSD replace my current operating system?
For most people, yes. But this question is not quite that cut-and-dried.
Most people do not actually use an operating system. They use applications. The applications are what really use the operating system. FreeBSD is designed to provide a robust and full-featured environment for applications. It supports a wide variety of web browsers, office suites, email readers, graphics programs, programming environments, network servers, and much more. Most of these applications can be managed through the Ports Collection.
If an application is only available on one operating system, that operating system cannot just be replaced. Chances are, there is a very similar application on FreeBSD, however. As a solid office or Internet server or a reliable workstation, FreeBSD will almost certainly do everything you need. Many computer users across the world, including both novices and experienced UNIX® administrators, use FreeBSD as their only desktop operating system.
Users migrating to FreeBSD from another UNIX®-like environment will find FreeBSD to be similar. Windows® and Mac OS® users may be interested in instead using GhostBSD, MidnightBSD or NomadBSD three FreeBSD-based desktop distributions. Non-UNIX® users should expect to invest some additional time learning the UNIX® way of doing things. This FAQ and the FreeBSD Handbook are excellent places to start.
The TLDR is basically:
1) We just give you the text console. The text console's got the tools for you to install stuff, we got an assload of shit in the Ports tree, tons of stuff there can do most of what you need it to do, but again: all you get from us is the terminal. If the handbook doesn't cover it as a courtesy, you're on your own.
2) If you have a critical need for X/Y/Z software, it ain't designed for FreeBSD in the slightest, and there ain't any option for it in the Ports tree, you're outta luck unless you wanna take a crack at porting it. Sorry, that's just how it works.
**
To be 100% clear here: I'm not talking shit about the Ports maintainers, let alone the FreeBSD developers themselves. It just so happens that it behooves the FreeBSD team to maintain a critical distinction between the operating system itself vs. the ports collection. Speaking of Ports, let's actually get into what they really are.
Traditionally, UNIX users compiled software from source code. If you have something on a PDP-11 and you need to make it run on a VAX or an Alpha, you'd modify the source code to make sure it compiles and installs correctly. In other words, you
port it over, hence the name "Ports." With time, the BSD family of Unices developed an entire tree of makefiles that would eventually metamorphose into the various ports collections across Free/Net/OpenBSD. The Ports collection on FreeBSD, to this day, is basically a giant collection of makefiles sorted by category. Binary packages are built directly from the Ports tree. The maintainers of the various ports in FreeBSD's collection do a ton of work to make sure shit buidls cleanly across i386, amd64, arm64, powerpc, and so on.
System V Unices like Solaris, AIX, HP-UX and Unix clones based on System V like MINIX, GNU/Linux, and non-GNU Linux distributions
never had any concept of a ports collection in the first place. That's why Debian, Fedora, Arch, OpenIndiana, even stuff like Android and Alpine have wildly different package counts across their repositories. There are definite differences in package counts between FreeBSD, NetBSD, and OpenBSD, but the differences in absolute number of packages isn't so stark as say... the difference between Debian's official repositories vs. Arch's official repositories.
**
All of this rambling, and I haven't even remotely scratched the surface of all the cool shit that FreeBSD has going for it. bhyve is super interesting stuff, it kinda reminds me of QEMU in a lot of ways. Linux has cgroups and Docker/Podman, those are definitely far more robust than FreeBSD's jails, but FreeBSD jails are still plenty adequate for similar use cases you'd fire up Docker/Podman for. FreeBSD users can even share jail setups via templates and third-party images (BastilleBSD is Docker-adjacent, IIRC). Also helps to remember that FreeBSD jails are significantly older than cgroups/Podman/Docker and designed to be much simpler. Docker/Podman's complexity means more attack surface. That's something else to think about, but I need to wrap this up.
Are there things that Linux does better than FreeBSD by leaps and bounds? Yes. Are there things that FreeBSD does better than Linux by leaps and bounds? Also yes. I daily drive Linux Mint and I just install shit onto a portable drive whenever I feel the ruge to break stuff. Daily driving FreeBSD's more than possible, I have a rudimentary graphical environment up and running on my portable drive, but I don't currently have the stones to do all that stuff to make Steam work, polish up XFCE4, etc. I'm actually with you on the same page when you and I both don't currently daily drive FreeBSD.
I just take exception to your vitriol against FreeBSD when you leave the bounds of hardware and start talking about how "FreeBSD sucks because I must do X/Y/Z to get A/B/C running, also lemme talk about how great Portage is, USE flags, and all the other stuff most people don't bother to learn about Gentoo."