SoylentNews is people
SoylentNews
One of the things lacking from the FreeBSD installation routine is the easy installation of a full desktop experience, from X11 all the way up to a login manager, desktop environment, and its applications. It seems this might finally change for FreeBSD 15.0, as the FreeBSD Foundation's Laptop Support and Usability Improvements project is working on adding support for this to bsdinstall, the FreeBSD installer.
Based on a goal set out in this GitHub issue, the way this will work is that through a set of dialogs (which you can check out on GitLab) in the FreeBSD installer, the user can select to install KDE, which will then guide the user through installing the correct graphics driver and adding users to the video group. Once the installation is finished, the computer will reboot and load directly into SDDM, allowing you to log into the installed KDE Plasma desktop environment.
[...] Future plans for desktop users in the FreeBSD installers are more elaborate, and will include additional desktop environments to choose from, the ability to install sets of desktop applications during FreeBSD's installation, and yes, even opting for Wayland instead of X11, because FreeBSD developers know which way the wind is blowing.
This is excellent news, and will make installing a FreeBSD-based desktop a lot easier for a ton of people. Work isn't fully completed just yet, but even if the developers miss their FreeBSD 15.0 target, it'll just move on to one of the follow-up releases.
(Score: 4, Informative) by hazelnut on Thursday July 31 2025, @01:40PM (1 child)
I remember the same things. The only difference is I also remember why it went away.
Back in the 90s we had the generic frame-buffer VGA driver and one other generic driver. They lived together sufficiently that both could be loaded and the one that worked would run. So it was far simpler to get a GUI going.
Then we got the more robust dedicated GPUs and support for the nVidia, AMD, and Intel discrete graphics. These do not live well together. So you have to know which Graphics driver to install. Adding to that, these drivers are tied to the specific kernel version. This leads to a catch-22 with the package manager. You have to upgrade the GPU driver package along with the kernel or the screen doesn't work.
So we end up with having to coordinate every single person that runs a FreeBSD graphical desktop to update on exactly the same day along with their packages every time there is a release. There's a few other options but none of them are easy for the end-user. I'm guessing the people behind the FreeBSD desktop project figured out a better solution that makes it viable.
(Score: 4, Interesting) by Mojibake Tengu on Thursday July 31 2025, @03:42PM
You do not need to use those drivers in FreeBSD at all. Although you really must, in Linux.
On FreeBSD productions machines, which do not need video accelerators at all, mostly headless servers, I use only EFI framebuffer (now default installation) for console.
It suports Unicode in console (which is something Linux is incapable to do). That is enough for maintaining servers with filesystems and databases using UTF8 even locally on temporarily connected head. To me, this is a main factor for not using Linux in production at all.
And for Xorg, instead of video accelerator drivers on pruduction machines for office use, I set up scfb driver. That one is unique to BSD, not available on Linux. It takes EFI framebuffer as used above and makes a xorg device upon than. Works on any hardware with correctly made EFI.
Fundamental bonus of this: it is rock stable, absolutely. True BSD quality.
It can run desktop for years without crash or glitch, proved. In compare to that, even modern nvidia drivers (NVIDIA supports FreeBSD natively by official releases) crash about twice a year if run continuously while typical Radeon amdgpu driver crashed as often as twice a weekly, in latest years.
Inferior quality of accelerated drivers is direct result of post-modern situation when children use just some terminal notebooks for writing those drivers instead of real computers with infinite uptime. They may hit the wall by front when upcoming wave of LLMs comes to users.
This scfb driver is impossible to reimplement in Linux because of Linux's logically flawed KMS mode switch model, necessity of initramdisks and other minor technical barriers.
The kinder you are, the easier it is for wicked people to morally coerce you.