FreeBSD Foundation Flounders on 15 with Rust, pkgbase, and KDE

Follow the links please!
Ok, I read
 
You can do that now and install almost any desktop Linux has.

You can install GNOME now.

The point is spending the time to add this to the installer and whatever time/effort is involved in supporting that along with the question of whether KDE will now represent FreeBSD.
I do think KDE is a better choice over Gnome to represent FreeBSD. It probably has less difficult issues to fix out of the two to be better supported. My experiences testing KDE with FreeBSD have always been better than Gnome and this is leaving preferences aside but focusing on what just works.
 
I have been using GNOME3 on FreeBSD for a number of years after getting used to it on 'Ubuntu GNOME'. Sadly, GNOME have stated that they are dropping support for non-systemd operating systems for GNOME49. I guess unless the FreeBSD Foundation intends to fork it and maintain a non-systemd version, the news means that all of us that use GNOME3 on non-systemd operating systems have a choice to make very soon. It does not surprise me that KDE is being readied for the installer.
 
I have been using GNOME3 on FreeBSD for a number of years after getting used to it on 'Ubuntu GNOME'. Sadly, GNOME have stated that they are dropping support for non-systemd operating systems for GNOME49. I guess unless the FreeBSD Foundation intends to fork it and maintain a non-systemd version, the news means that all of us that use GNOME3 on non-systemd operating systems have a choice to make very soon. It does not surprise me that KDE is being readied for the installer.
GNOME was ruined anyway with the switch to the new desktop in GNOME 3. It looks like Windows 8.
 
I've done some more thinking about autodetect:

X11 DDX driver selection provides the clearest example of an automation gap. On Linux, X.Org:
  1. Queries sysfs for available graphics hardware (My point is this doesn't seem like the type of thing that should be put on downstreams)
  2. Matches PCI IDs against its driver database
  3. Automatically loads the highest-priority matching driver
  4. Falls back to generic drivers if specific ones fail
On FreeBSD, X.Org:
  1. Performs basic hardware detection
  2. Cannot determine which driver to use
  3. Requires explicit driver specification in xorg.conf
  4. Fails to start NVIDIA for example without manual configuration
So with wayland at least half of this is solved except for the kernel module autoloading without rc.conf intervention. Unfortunately there are no virtualization or fallback options for wayland making it a non starter for me to test any development in Virtual Machines. Wayland also does not support app menu protocol yet, and the PR has been opened for 5 years making it a major blocker for my desktop environment being developed exclusively for BSD's.

So as a result, user tries our community flavor of GhostBSD but cannot even test with fallback because to be fair GhostBSD's tool is not doing the right thing to offer a selection or fallback for unsupported intel device ID's.


It is in this case a GhostBSD problem with the xconfig tool causing the intel driver to be selected rather than providing a fallback option. The xconfig tool does not have a database of known hardware ID's to know if intel should be auto selected or fallback should be chosen. Even if a better xconfig tool were made there is also more uses cases than just 1 time setup like changing graphics cards, or migrating drives with installations to new hardware. I would hope that what the user says here is not true that FreeBSD see's this situation only as a GhostBSD problem, and that some of more proper automation is being considered for FreeBSD itself in a future roadmap. I am not sure who they emailed. I am appreciative of the efforts to port newer graphics, and wifi. It just seems there is a still gap in automation here as well that I believe addressing would make a bigger impact than more tools for manual options. Even embracing initgfx from NomadBSD would seem like a better option than that but strongly feel this automation needs to be handled within FreeBSD facilities to be truly proper.
 
That's good, bc they isolated a system which wants to be dependent on systems from other ecosystems.
I guess unless the FreeBSD Foundation intends to fork it and maintain a non-systemd version, the news means that all of us that use GNOME3 on non-systemd operating systems have a choice to make very soon.
The Linux community would fork it, if they have the ability and desire to do it.
It does not surprise me that KDE is being readied for the installer.
KDE functions better of full scale desktops. I don't want KDE for a desktop, but I would use applications from it without the desktop. I rather be able to pick and choose which KDE applications to use, without needing dependencies for the window manager. So far, I can do without those. I use lightweight window managers, bc they're faster, and I don't have a need for those features.
 
I think it would be nice to see an option for multiple different DE with the installer along with other programs. The programs are available and having these options available if you are connected to the internet would be really cool. Including them in the install media would really not be necessary since the internet is very high speed these days. A script for auto detecting hardware and configuration shouldn't take up too much space on install media. But I think that would be very handy and reduce a lot of set up time for users like myself. I don't have any systems that use only a terminal or terminal applications. So having the option to install those things during initial installing and having the configuration be automated would be very nice.
 
I think it would be nice to see an option for multiple different DE with the installer along with other programs. The programs are available and having these options available if you are connected to the internet would be really cool. Including them in the install media would really not be necessary since the internet is very high speed these days. A script for auto detecting hardware and configuration shouldn't take up too much space on install media. But I think that would be very handy and reduce a lot of set up time for users like myself. I don't have any systems that use only a terminal or terminal applications. So having the option to install those things during initial installing and having the configuration be automated would be very nice.

Again.

You can literally select “No” and go on with your life. This ridiculous thread needs to be closed already.
Please! ...and deleted.
 
OK folks. One more comment and then I'm unsubscribing from this thread.

I don't think anyone is arguing that add-ons are a good thing and that the OS becomes more comprehensive when it supports a variety of apps and add-ons. What I take exception to is the concept of anything beyond kernel and coreutils being part of the base installation. KISS!!!

If it's a matter of semantics as to where/when you can choose applications suites during setup, then my VOTE is to do so after initial installation (from console) using a utility to do such, or Dog forbid...COMPILING CODE! Don't complicate the initial install in any way shape or form. I know everybodiy is so focused on gaining market share, but to quote some others on here who I seem to share a synergy with...if you cannot figure out how to run an installation program from the command line then do we really want you in our "community"? and no, I'm not shunning neophytes, as they are welcome to ask questions which raise their knowledge and capabilities...BUT! I have little tolerance for the folks who think all computers should be point and click and that they don't need to know anything more than that. If that is their mindset then they should play in windoze or Mc-puters.

I lurk on here because there is a generally more professional and capable subscriber base than you run into in the "anything goes as long as it feels good" linux community.
 
I do not understand why this community seems to have so many that seem unwelcome to constructive criticism. I will not post here further since whole tone seems often toxic anyway.
 
I do not understand why this community seems to have so many that seem unwelcome to constructive criticism. I will not post here further since whole tone seems often toxic anyway.
Seems legit; do not try and be a voice of change, just let it slide.
I, myself, am choosing to post more. I wish we could have discussed more. l8r sk8r.
 
I do not understand why this community seems to have so many that seem unwelcome to constructive criticism.
99% of the members on this forum are just users, not FreeBSD core members, not FreeBSD developers, not Foundation members, just users of FreeBSD. So all you're getting here are opinions. Some certainly more valid than others, but very few people here can actually do something with the critique.
 
If it's a matter of semantics as to where/when you can choose applications suites during setup, then my VOTE is to do so after initial installation (from console) using a utility to do such, or Dog forbid...COMPILING CODE! Don't complicate the initial install in any way shape or form.
Hey, I agree with this. Remember how BSD wants to keep everything simple, this should be it. The installer should only be modified for installer things (as like, use pkgbase or base.txz). The simple text installer is also enough. There is no need to change things if they arent broken. TUIs can be great :)

In my case, I downloaded FreeBSD 15 current and tried it out. The "pkgbase" installed worked just fine, but it was a bit slow. Maybe it was overloaded for my area, or it's just slow. I would prefer a "base.txz" install in my case haha. In general, FreeBSD 15 testing needs to be more relevant in this forums, since we are users, we also get to decide the future of FreeBSD (as long as we follow proper testing and channels).

Anyhow, probably unsubscribing as well ^^
So all you're getting here are opinions. Some certainly more valid than others, but very few people here can actually do something with the critique.
Few people can receive the critique, and fewer still can make constructive critique.
 
What I take exception to is the concept of anything beyond kernel and coreutils being part of the base installation. KISS!!!
The installer is fine about how it is.
If you cannot figure out how to run an installation program from the command line then do we really want you in our "community"?
If that includes an nurses like installer, for the most part.

I'm unaware if the base install already has different versions for fonts needed for different languages known as Internationalization. If it does, that removes 99% of the need.

After that, Accessibility, which means for physically and mentally impaired, is the only reason that a KDE install would be needed.

For anything else, there's no excuse that someone can't perform a basic install with an ncurses like installer.

Here, pkgbase makes more sense. It makes it easier for an organization to provide a fork specifically for Accessibility, in the install medium and install.
 
I'm gonna just wait for the 15-RELEASE (Due out Dec. 2, 2025), and then do my critiques/praises.

After all, if somebody doesn't like what they see in the 15-CURRENT (15-STABLE is still a month away at this point), they are always welcome to download their own copy of the development branch, and mess with that copy to their heart's content.

You want GNOME as part of the installer? Sure. It's your hardware, your time, your expertise. Download your own copy and see what it takes to get that done. It's all Open Source. If you can do the programming work, great, please do it, and post the screenshots in the Screenshots thread.

People who are actually capable of doing that are NOT the ones doing the critiques - did anyone notice THAT?
 
You can literally select “No” and go on with your life. This ridiculous thread needs to be closed already.
I respectfully disagree.

From a user viewpoint, you can indeed simply say "no". That doesn't worry me.

What worries me is that the FreeBSD community (meaning volunteers, and/or the foundation and its paid staff) think that it is worthwhile to put effort into the installer to automate installing a GUI or DE. I am of the opinion that it is not worth doing. If the reason is that one wants to attract more (desktop) users to FreeBSD, that won't help the FreeBSD project at all, since it will mostly bring distro hoppers, and folks who expect FreeBSD to be "just another flavor of Linux" or "just like Linux", and the current FreeBSD isn't either of these things at all. Serious FreeBSD users who want to use a desktop can install one themselves, and according to what I read here, it's quite easy.

I have no problem with other groups (for example GhostBSD) creating a FreeBSD derivative that is targeted towards GUI/DE users, in particular towards less patient or less knowledgeable ones who need a canned quick-install solution. If it serves their purposes, that's great for them. But I don't think making FreeBSD into that canned quick-install solution serves FreeBSD goals, which can be well summarized by "the power to serve".

What I'm mostly missing in this discussion (and in particular this thread) is "cui bono". Why is the FreeBSD community moving towards pkgbase? I've read some wiki pages about "how to use pkgbase", but I'm missing the justification, requirements, and analysis of it. My educated guess is that it simplifies both building/maintaining the installers, and managing the files that go into base, and that would be a desirable goal.

Similarly, the only justification I've seen for adding a GUI/DE (specifically KDE) to the installer is "attract more users", and I don't see that as a desirable goal without thinking through what type of users it would attract, if any, and how that would further the project's goals.

99% of the members on this forum are just users, not FreeBSD core members, not FreeBSD developers, not Foundation members, just users of FreeBSD. So all you're getting here are opinions.
It would be interesting to read the opinions of the developers and foundation leadership. I wonder whether that can be found on the mailing lists.
 
if you cannot figure out how to run an installation program from the command line then do we really want you in our "community"? and no, I'm not shunning neophytes, as they are welcome to ask questions which raise their knowledge and capabilities...BUT! I have little tolerance for the folks who think all computers should be point and click and that they don't need to know anything more than that. If that is their mindset then they should play in windoze or Mc-puters.

I lurk on here because there is a generally more professional and capable subscriber base than you run into in the "anything goes as long as it feels good" linux community.

I think you and I think the same way but different wording.

The handbook makes things quite easy and is an excellent springboard for more learning. So, I don't think the target is whether or not you can run an installation program from the command line, but whether or not you choose to read/learn to do so. If 99% of your desktop usage involves an office suite and a browser, I don't think the learning curve for FreeBSD is that steep thanks to the well annotated procedures via the Handbook.

To get FreeBSD installed and running with a DE, assuming no prior OS knowledge outside of Windows/Macs, is chapters 1, 2, 4, 5 and 8 from the handbook. Granted, I've only installed FreeBSD on 4 distinct machines since returning to FreeBSD, so perhaps my smooth experience is an anomaly, but on the 3 that have tier 1 support I went from bare metal to a running box with XFCE by following the instructions from those chapters (edit- it was actually 2 of the 3, the 3rd needed an ethernet driver tweak I did have to google for but it was such a minor thing I forgot about it). No outside support/troubleshooting needed. Thanks to packages the process was extremely smooth and efficient. Someone choosing not to have the desire to do that is absolutely fine- it simply means FreeBSD may not be an appropriate OS for them, and that is OK!
 
I'm gonna just wait for the 15-RELEASE (Due out Dec. 2, 2025), and then do my critiques/praises.

After all, if somebody doesn't like what they see in the 15-CURRENT (15-STABLE is still a month away at this point), they are always welcome to download their own copy of the development branch, and mess with that copy to their heart's content.

You want GNOME as part of the installer? Sure. It's your hardware, your time, your expertise. Download your own copy and see what it takes to get that done. It's all Open Source. If you can do the programming work, great, please do it, and post the screenshots in the Screenshots thread.

People who are actually capable of doing that are NOT the ones doing the critiques - did anyone notice THAT?
You make very valid points.
 
I would like to start by saying that I respect all the opinions expressed here, both for and against adding a GUI option. I'd just like to add one detail that perhaps better explains the big picture of this implementation.

I am fundamentally antisocial (in a good way; I don't really like being in crowds), so I'm not particularly happy that installing an optional GUI would attract a large number of people. The downside is that there would potentially be more users "testing" the operating system and ports. Some of them might abandon ship before the bugs are fixed, but there would also be turnover, and new users would be attracted. This, in my humble opinion, would be a benefit for the Project.

As for the installer itself, I also think it should remain TUI. Or at least, if you choose NO when prompted to install a GUI, the installation will proceed in TUI, the same way it now is. Otherwise (if it's not too much of an effort for the developers), xorg (or wayland, I'm not familiar with it, I don't even know what it is) will be installed and the installation will continue with the graphical interface (even TWM). Clearly, the developers need to evaluate the workload to achieve this and decide whether it's worth it or not.

As for pkgbase, I have no idea how it works.

Whatever path the Project takes, I'm happy with it.
 
I don't see why there couldn't be a separate image or iso installer named GUI that offers a gui auto configuration option. It's even possible that this would be preferable.
Edit: alternative would be just naming the image or iso with kde in the filename and assume a graphical install.
 
Will the KDE which is installed optionally by the installer be different (better?) from what is currently avaiable in ports/packages?

I mean: Will it, e.g., be better integrated into the system? For example: Can I click on an USB-stick icon and it will mount and open it in a File Browser. (Edit: this does not work out of the box, e.g., in XFCE, which is what I am currently using). Something like that.

If that KDE becomes a polished, true official "FreeBSD Desktop", I would probably use it.
 
Back
Top