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

I am all in for rust in the kernel and base system, this is a requirement by various industries, so why not make FreeBSD a more attractive option? And I am all in for pkg base.
What industry needs unnecessary languages in their operating system? Why not add COBOL, ALGOL, BCPL, and Fortran if you want more languages in base. ;)
 
It is important that pkg for base and pkg for applications (ports) still remain separate in these plans. Unlike in Linux where they are the same.

The importance is that getting into unresolvable dependency hell in applications still allows you to blow away the whole application tree and reinstall it without have to touch the base system, much less forcing a reinstall which is what Linux is facing in these situations.
This is a key point for me. Right now ports check for "what version" (look at kmod stuff). If a system using pkgbase presents a single coherent answer to that (go back and read my concerns about what does freebsd-version say on pkgbase) then "ports do what they always do" "Version x.y.z I build this way, otherwise build that way"

Using the same tool to mange things is different from "mangling dependencies".
If pkgbase keeps dependencies to only kernel and userland there should be no effect on ports.
But that has to be a hard, very hard, Great Wall of China boundary.
 
> X window mgr

There is no default. I could be totally wrong but since words typically have meanings, I try to follow the links first.

1. https://github.com/FreeBSDFoundatio...dates/2025-06.md#kde-desktop-installer-option
2. https://github.com/FreeBSDFoundation/proj-laptop/issues/25

Which leads you to:
"alfonsosiciliano has some work already started here: [3.] https://gitlab.com/alfix/desktopconfig"

From which you can view some Proof-of-concept code which has a few entries like: KDE, Gnome, and XFCE (seems like a nice start).
4. https://gitlab.com/alfix/desktopconfig/-/blob/main/desktopconfig?ref_type=heads#L358

And now if we go back to #2. we can see alfonsosiciliano is planning on implementing his proof-of-concept code which offers more than KDE.
5. https://github.com/FreeBSDFoundation/proj-laptop/issues/25#issuecomment-3073196118
 
for a base installation of Debian Linux, with X11 and a window manager (not a DE), there are over 1700 required packages to install! There are many reasons for this bloat, but again, the time for making sane decisions in that platform has long since passed. Use Linux as a warning, not an instruction manual.
But if that base install offered X11 and WM AS AN OPTION, not mandatory, one does not install the 1700 packages.

This is what puzzles me: it sounds like FreeBSD 15 is offering KDE as an option, not Mandatory, so why the fuss?
If 15 is "Always install KDE regardless of what the user wants" then you have an argument. But offered as an option at install time, default to "do not install"? Why the fuss?
 
But if that base install offered X11 and WM AS AN OPTION, not mandatory, one does not install the 1700 packages.

This is what puzzles me: it sounds like FreeBSD 15 is offering KDE as an option, not Mandatory, so why the fuss?
If 15 is "Always install KDE regardless of what the user wants" then you have an argument. But offered as an option at install time, default to "do not install"? Why the fuss?
One more of my complaints is that KDE is licensed under the GNU GPL. CDE is under the LGPL. I don't have an issue with weak copyleft, but I do have one with strong copyleft. The foundation is effectively promoting the GPL. Git was fine, as there are permissively licensed git drop-in replacements avaliable, but there is no way to have BSD-licensed KDE.
 
My knowledge of linux is from the mid/late 90's and what I see on videos every now and then. When it comes to FreeBSD, I can install it and follow the handbook for things I want to learn to do. So I would hardly call myself a "power user" in either case.

That being said, someone help me understand the issue more clearly.

One of the things I love about FreeBSD is that the ecosystem is a cohesive whole. You install a package/port, set up your config files, and for the most part, that's it and it runs. From what I've seen in Linux, there's a lot of "If you want to use software W and you're running distro X then follow instruction Y, but if you're using distro Z then instruction A needs to be used, and if you're running distro B, then good luck because (insert some arcane linux stuff I dont know) causes it to break"

Is this migration to pkgbase creating a potential for this type of "fragmentation" in some way because of the way FreeBSD can be installed/upgraded? Is that the potential pitfall of this?
 
I am also very sad to see the sets go and be replaced by a few hundred packages.

I fell like the complexity will just go up with this change - instead of maintaining one archive (or set of official binaries look at it how you want) the devs will have to maintain hundreds of packages and drag them thru arch-testing. Which means many more moving parts and more chances for problems to occur and delays to be had.

I can't understand how freebsd-update was so hard to maintain that it had to be dropped - FreeBSD could set up official/reference sets of binaries and use something like rsync in a freebsd-update-equivalent script on the user's side to get those sets of files up-to-date on the user's system. Depending on what files get sync-ed warn that a daemon needs to be respawned or a kernel rebooted. job done?
 
Is this migration to pkgbase creating a potential for this type of "fragmentation" in some way because of the way FreeBSD can be installed/upgraded? Is that the potential pitfall of this?
Try to use a modern Linux distro for a while and see how you feel. Fragmentation, updates breaking things, forced system updates when updating software, build failures uninstalling half your system, and everything else wrong with Linux. Spin up a VM and see how much it sucks!
 
Try to use a modern Linux distro for a while and see how you feel. Fragmentation, updates breaking things, forced system updates when updating software, build failures uninstalling half your system, and everything else wrong with Linux. Spin up a VM and see how much it sucks!

I can add that to my "things I want to do" list.

I'm not doubting that such a thing exists from what I've seen in linux videos. My fear from what I've read in this thread is that kind of problem is exactly whats going to happen with FreeBSD because of this change.

I have a soft spot for FreeBSD. Version 4.3 was my first exposure to it and I was pleasantly happy that "it just worked" on my hardware (as opposed to my linux experiences a few years prior). It's been about 20 years since I last worked with FreeBSD until recently but its like catching up with an old friend. I'd hate for things to go down a path where things aren't a cohesive ecosystem the way I think they are now.
 
One more of my complaints is that KDE is licensed under the GNU GPL. CDE is under the LGPL. I don't have an issue with weak copyleft, but I do have one with strong copyleft. The foundation is effectively promoting the GPL. Git was fine, as there are permissively licensed git drop-in replacements avaliable, but there is no way to have BSD-licensed KDE.
Ahh. This is a reasonable argument, but one that could probably be made against a large percentage of ports.
The alternative would be "what WMs/DEs are licensed under BSD/MIT?"

If a goal of offering this install option is "Give the user a reasonable GUI" I'm not sure how much licensing plays into/should play into the choice of "what".
Realistically:
A new user presented with CDE, twm, KDE, which will be most productive in a short time? I'm asking this as someone who has used CDE (on commercial systems) and twm.

About the only BSD licensed DE I'm aware of is Lumina (from the ixSystem folk); functional but not "complete". Suffered from "single maintainer", but it worked mostly.
I think a bigger question is "why DE vs simple WM"? DE gives single point of configuration for things like themes/colors/icons but that only applies to applications created for that DE. Think terminal window: every DE has it's own "terminal" that you config from a single place (Settings), but you start up good old xterm and nothing applies unless you tweak .Xresources.
 
I found this on the official 15.0 release notes. This is a nightmare. It seems like, to compete with Linux, the Foundation wants to turn BSD into Linux. I hate the idea of pkgbase being the only way to update FreeBSD. That is the main reason why I fled the Linux world. Furthermore, the KDE integration is also so Linuxy. I also hate the push for rust and zig and whatever is the new fad. FreeBSD is abandoning its UNIX roots to chase trends and imitate Linux. I probably will not end up switching to OpenBSD (atleast for the forseeable future), but this new route is concerning, to say the least.

Do some research instead of flailing sensational nonsense like this. Clearly you don't understand what's going on.
 
One more of my complaints is that KDE is licensed under the GNU GPL. CDE is under the LGPL. I don't have an issue with weak copyleft, but I do have one with strong copyleft. The foundation is effectively promoting the GPL. Git was fine, as there are permissively licensed git drop-in replacements avaliable, but there is no way to have BSD-licensed KDE.
Are you redistributing it to care about the license? Otherwise you're just creating a tempest in a teapot... Relax. KDE is optional.

If you don't like pkgbase you can continue building the world. And with pkgbase there's no danger at all because with ZFS boot environments you have a nice rollback.
 
A new user presented with CDE, twm, KDE, which will be most productive in a short time? I'm asking this as someone who has used CDE (on commercial systems) and twm.
First off, multiple options should always be provided, second, many people feel mor comftorble and can get more work done in twm. I am the type of person that almkst exclusively uses the command line, so that should still be an option, which I know it will be. What about other DEs?
 
Try to use a modern Linux distro for a while and see how you feel. Fragmentation, updates breaking things, forced system updates when updating software, build failures uninstalling half your system, and everything else wrong with Linux. Spin up a VM and see how much it sucks!
I don't disagree with this on a Linux system, because yes, I've been bit, but assuming that FreeBSD is not going to learn from Linux distro mistakes I think is a bit short sighted.

If FreeBSD pkgbase confines itself to the "freebsd-update" world, that would maintain the separation between a "port" and "base". Just because the same tool would manipulate both does not mean they are tied together.
 
  • Thanks
Reactions: jsm
If FreeBSD pkgbase confines itself to the "freebsd-update" world, that would maintain the separation between a "port" and "base". Just because the same tool would manipulate both does not mean they are tied together.
That would be OK, but I am afraid it will end up a very different way.
 
When did Rust enter this chat? Certainly not from the official side or the OP.

Please bump one of the existing Rust threads instead.
 
First off, multiple options should always be provided, second, many people feel mor comftorble and can get more work done in twm. I am the type of person that almkst exclusively uses the command line, so that should still be an option, which I know it will be. What about other DEs?
Don't disagree, but "where does it stop". Should the installer offer the option of every single DE/WM that has a port? If "no" then how are you choosing which ones to exclude?
To me the "multiple options" are "KDE or nothing" which is acceptable to me.
 
Don't disagree, but "where does it stop". Should the installer offer the option of every single DE/WM that has a port? If "no" then how are you choosing which ones to exclude?
To me the "multiple options" are "KDE or nothing" which is acceptable to me.
It seems like the choice of KDE is to appeal to Linuxers, not UNIX users. To appeal to everyone, they should offer KDE and CDE.
 
That would be OK, but I am afraid it will end up a very different way.
Ahh, then perhaps that is where the users should exert pressure on the project? "I don't fully agree with/buy into pkgbase but if that's the project future then keep it to this hard boundary" sounds like a reasonable argument.
The Project has goals/ideas/intentions, but if the community never provides feedback the Project never knows.

I'm not sure how many "Official Project people" read threads here, but there must be ways of providing feedback.

I'm thinking we are starting to follow Alice down into the rabbit hole on this thread, at this point I'm willing to wait for 15 to finalize things.
 
Ahh, then perhaps that is where the users should exert pressure on the project? "I don't fully agree with/buy into pkgbase but if that's the project future then keep it to this hard boundary" sounds like a reasonable argument.
The Project has goals/ideas/intentions, but if the community never provides feedback the Project never knows.

I'm not sure how many "Official Project people" read threads here, but there must be ways of providing feedback.

I'm thinking we are starting to follow Alice down into the rabbit hole on this thread, at this point I'm willing to wait for 15 to finalize things.
I think more anti-FBSD15ers should join the mailing lists and throw the othet argument around, just so the devs can see the other side.
 
Back
Top