Re: Is GNOME on FreeBSD a good idea? Asking for a friend

On 10/2/25 10:58, Frank Leonhardt wrote:
> Someone (not me, honest), really, really wants to run GNOME on FreeBSD 
> and was complaining to me that it won't run the latest version because 
> of systemd. I think he's been reading Linux web sites or some such, but 
> then again systemd sounds like a plausible problem.

   My apologies ahead of time for the wall of text; some may be relevant 
to you while some only relevant to your 'someone'. I tried to keep it 
organized in sections and tried to not drift off topic much. If you are 
reading through a paragraph and think "don't care/not relevant", 
skipping to the next paragraph likely loses only the uninterested topic 
of the paragraph.
   I haven't tried Gnome in many years as I didn't like it when I tried 
it and I haven't heard of them making changes that interested me to try 
again. That was based on a user interface experience that I didn't find 
preferable.
   This isn't based on getting into sillyness and irony like their 
claims of using a computer after Windows 10 goes EOL as if they are 
'the' choice to keep old hardware going when they link to endof10.org. 
Removal of x.org support to go to Wayland as a requirement does drop 
support for some Win10 compatible devices including my FreeBSD desktop 
from 2012 with a GPU likely from 2011 if I recall; or at least it has 
seemed Wayland incompatible in my FreeBSD testing and Linux users 
mention similar Wayland compatibility issues on some hardware. "Our 
software has no restrictions on use and respects your privacy" stops 
being true if they remove support for previously working systems but I 
think they meant other things besides hardware they choose to support as 
'restrictions'.
   Other sillyness/irony is claims that Flathub is 'the Linux app 
store'; 'the' should be 'a' to make it accurate and FreeBSD doesn't 
support Flathub (at least directly/natively) though We aren't Linux so 
its very likely that Gnome has no interest in talking about us as they 
only talk about the subset of Linux they actually support as if that is 
all LInux is...you can really scratch your head more and more the more 
you read just their main webpage. If the 'not you, honest' is concerned 
about such things before considering it fully supported then its 
probably still considered not complete to them.
  My understanding is historically Gnome has lagged behind due to 
porting difficulty from a number of Linuxisms and that is systemd is one 
of them but not the only reason.
   Gonme is up to 49 as of 2025-09-17. Freshports has us listed as 
getting 47 as of 2025-06-11 though it came out 2024-09-18. We were at 42 
before that which we got in 2022-05-20. As that indicates, we have spent 
a lot of time being much more out of date than we currently are.

> The Handbook says it will do it:
> 
> https://docs.freebsd.org/en/books/handbook/desktop/
> 
> Apparently it needs the HAL demon and other stuff enabled that you 
> wouldn't normally have, although it's not clear from the handbook 
> whether this installs and configures automagically with the port. He's 
> new to FreeBSD (I'm just new to the concept of a graphical desktop on 
> it). I believe consolekit2 is used to replace that part of systemd that 
> GNOME requires.

   I'd be surprised if Gnome 'needed' hal daemon and other friends but 
didn't set them as a dependency of x11/gnome. If it is "needed" and is 
missing, its a bug. You could work around such a bug by installing and 
setting up the missing dependency. Some 'needed' dependencies may be 
system dependent (graphics driver); this is not a bug that one is not 
also installed for you (or complicated enough there is no current proper 
solution to automatically check that it gets satisfied properly) but any 
common/always needed dependencies should get included.
   Some possibly optional dependencies and dependency choices may 
require a selection at build time; the packages will only use one 
choice. At that point you may need con consider building from source to 
get things exactly how you want them. If something cannot work at all 
without doing so, I'd consider it a bug but some ports have conservative 
options that cause this exact case; contact the relevant maintainer to 
see if an adjustment to the defaults can be made.
   There is a slight deviation in that ports sometimes have 'flavors' 
where multiple packages are generated with differing build options; this 
system still has some limitations in its use to form complete dependency 
trees when multiple flavors get involved so rebuilding may still be needed.
   Some complicated systems will guide a user through what is supposed 
to be done with package messages. In my opinion that system still needs 
a lot of work to be practical as some ports give general warnings to 
first time installers in case they have an old configuration needing 
changes (a bug; we have a way to give the message to a user 'only' when 
upgrading across a version boundary), presenting some general 
good-to-know things like particular bugs/limitations of the port (we 
should formally decide how these are to be stored/presented/accessed by 
all users of all ports), and the all-too-common mention of 'this port 
has no maintainer' (such equivalent port output should be grouped 
together and only mentioned once with a list of ports it applies to 
instead of repeating the message over and over). If you navigate the 
'noise' successfully or fully then you should be able to pick out 
relevant messages of things that must be configured; some configurations 
that dependencies mention are not always required for use with all 
dependent packages so you may overconfigure some things.
   It is great that the handbook filters you past some of that by saying 
what is needed as a how-to. Just as the package messages are not 
perfect, the handbook is sometimes incomplete or outdated in its 
guidance. Its a bug when that happens; please open a PR if one doesn't 
already exist so people can be aware of and fix the issue.

> I thought about digging out a spare monitor, connecting it to a server, 
> locating a mouse and trying it out out but it's really not my thing so 
> the thought didn't linger, especially if someone else knows the current 
> state of play.

   If you want to avoid putting it into a server, you can consider a 
virtual machine on your non-FreeBSD desktop/laptop and give it a quick 
spin through there or even try a `pkg install -n x11/gnome` to see what 
version would be installed and if your server doesn't have hal and 
friends you could confirm if they would have been installed at that 
prompt too. I don't know how to get a list of dependencies from a 
non-installed pkg through pkg's commands. A convenient listing is at 
freshports.org but is only direct dependencies so is not a complete 
list. If you have a ports tree, you can run `make package-depends-list` 
which might get the desired listing; the ports tree dependency 
'listings' are sometimes not correct/complete depending on the command 
that was used and if you (manually) recursively do it inside every other 
dependency. Even though getting a listing properly is hard, the ports 
tree does follow dependencies as they are entered per port and will get 
them right for building/installing even if -list outputs do not. I tried 
to test but my version of FreeBSD-stable-14 still has a 'longer pipes 
regularly break' issue so collecting the output isn't working here at 
the moment.

> IIRC something called KDE Plasma was going to be bundled with the 
> installer for 15. Is it in the latest Alpha and is it a good plan (not 
> generally, but for my friend)? I can't find much info so I was hoping 
> someone hereabouts would have tried it. The official project pages are a 
> bit lacking for GNOME and KDE, but IME this proves nothing. Except, 
> perhaps, bundling KDE with the installer isn't as realistic as the 
> announcement suggested. (https://wiki.freebsd.org/Gnome https:// 
> freebsd.kde.org/)

   KDE is big with many programs making a rather complete set of things 
to be bundled for a consistent/complete experience. Some of those 
programs irritate me with sloppy programming and the bundle of software 
has been growing ever bigger and runs ever slower on my system, and with 
more observed bugs than ever to where startup times, memory+CPU 
consumption, etc. have reached a point that alternatives interest me. I 
had started with KDE 3 (or was it earlier.
   I think it was an effort to bundle it again that caused the split but 
in recent months a lot of KDE dependencies were moved into kde-gear so 
you may want that if you want to install a complete KDE experience. 
These have been deemed too big and will not put on the installer images. 
Unless you have no network, it should be easy enough to install KDE 
after instead of during install as the handbook guides you.
   On FreeBSD, you are not required to use kde or kde-gear 'meta' 
packages and can always install the pieces individually that interest 
you for a much less bloated experience. It is quite uncommon that KDE 
users use everything KDE offers, but it is nice to have it there without 
having to look at 'what programs does KDE have to do task xyz'. If you 
go that route and ever see anything broken, please make sure a PR exists 
or gets created as your issue may impact non-kde users who also try to 
separately use that KDE program without all of KDE installed.
   We used to have the installer guide 3rd party package installs during 
install time but that was lost with the migration from sysinstall to 
bsdinstall. I haven't tried 15's installer recently to see if there is 
progress in that area for either local media packages or internet 
packages but at least some minor work had to be done as they split parts 
of wifi (just firmwares?) back out into the ports tree.
   freebsd.kde.org is dated enough that I'd say its irrelevant. From 
homepage to browsed links it is still back in the days before we removed 
kde5 and now refer to kde6 as kde (think upstream wants to drop 'kde' 
and go to 'plasma' or just 'k' but that started with kde5 many years 
ago). In any case, I'd disregard that site unless you find much more up 
to date information than I did as FreeBSD is kde6 only now (some 
individual kde5 programs are around but no kde5 meta desktop).

> NB. Personally I wouldn't know the difference between KDE and GNOME if I 
> saw them.

   My observations was that KDE had better defaults for a UI, more 
options to change the UI into anything (Gnome was intentionally 'very' 
limited and I doubt that to ever change). I wanted, more 
environment-specific based software, and better interaction among 
programs throughout the environment (having one contacts database for 
separate programs like an email client, messenger, etc. with a backend 
that was organized to do so. Not sure how true it is but 20 years ago 
when I gave it a much more detailed look that was all definitely a 
thing. If Gnome and friends didn't catch up and if KDE and friends 
didn't break what they had too much then it could still be relevant. I 
think gmone was trying to be more of an older mac layout with its one 
top menubar and such last I looked but don't know if that is right and 
current; unnecessarily dynamic user interfaces are generally a bad 
interface for both new and old users so I tend to avoid them.
   I have spent a lot of time on KDE over the years though I don't use a 
lot of what it offers. I have also used e16 which was a much lighter 
experience. At the moment I am on i3; some good and some bad but I think 
tiling window managers + me only get along so well and defaults are not 
good in my opinion though I am trying to learn there first but it seems 
very efficient which is a major plus. There is an 'issue' in that i3 
didn't tell me to install 'optional' things it uses as part of its 
default config so I had to manually install dmenu to get a working 
[whatever_key]+d and the status bar with network state+battery+hdd/RAM 
space+time/date was broken until I installed i3status. Awkward to 
install things when learning by error and awkward to find when they 
aren't all related by port category or name but I've made some progress. 
Even without these parts it was a usable system and depending on user 
customization they may not be used/needed at all so its nice to not see 
a forced dependency but a message would be nice. I think I also found a 
possibly unnecessary double patching happening during building that I 
may be able to open a PR to remove but need to look back at notes.
   We have a lot of good choices available and they go well beyond what 
the handbook suggests; only problem is I know of no good way to search 
for them and no good comparison short of try each one comparatively.

> Thanks, Frank.
> 
> 
>