What is the future of FreeBSD?

[Pap]

Well, systemd already made Gnome (49+) mostly no-go on systemd-free distros/OSes.

Gnome is worse than KDE anyway. Even if it was systemd-free I wouldn't use it, ever.

It integrated with everything, requires libsystemd.

Exactly. It is an extremely intrusive wanna-be-a-kernel crap, broken by design. But I have no intention to start a flame war about it. Whoever wants to use systemd-infected distros, by all means go ahead.

As long FreeBSD has nothing even remotely resembling systemd, and as long it has non-Wayland XFCE / IceWM / Openbox, I don't care. But... what exactly are we discussing here? Installing XFCE or something similar is very easy in FreeBSD. And even if someone thinks otherwise, there are scripts that will do it for you anyway. At least last time I checked, there was more than one available in the repos.

 

[Ilovehotdog]

if kde or gnome have so many problems, why not take openbox, xfce, icewm or other wm as default?
normal guy just need a "out of box" working environment。

 

[T-Aoki]

if kde or gnome have so many problems, why not take openbox, xfce, icewm or other wm as default?
normal guy just need a "out of box" working environment。

FreeBSD's default is "not using any GUI but old school command line interface".

But FreeBSD has a bunch of GUIs (DEs) in ports tree, and even some of them can be installed in-pararrel without conflicts. Admins can choose anything in ports / pkgs. This is the excellent point to be a "base OS" for distros.

On the other hand, anyone can create a "distro" easily based on FreeBSD and ports. So defaulting any of GUIs are NOT a FreeBSD's job, but jobs for devs of any FreeBSD-derived distros like GhostBSD.

Choosing "default in-base DE" for FreeBSD would narrow down (at least, biases) the candidates for downstream distros. It's toooooo bad!

Note that lack of device supports also narrows down the platforms that downstream distros can run. So working on it is far more important than choosing default DE of FreeBSD, as this directly affects downstream.

 

[bakul]

Choosing "default in-base DE" for FreeBSD would narrow down (at least, biases) the candidates for downstream distros. It's toooooo bad!

We can eat so many gourmet meals but rather than favor one we will just go hungry!

 

[T-Aoki]

Forgot to mention.

Making more DEs that work fine on FreeBSD "in ports" (not installed by default for FreeBSD itself, though) is a good thing, as this allows downstream to choose from wider range of DEs.

 

[MG]

Forgot to mention.

Making more DEs that work fine on FreeBSD "in ports" (not installed by default for FreeBSD itself, though) is a good thing, as this allows downstream to choose from wider range of DEs.

I think the DE is just some external programs but the primary graphics device of a computer should be able to show a pixel on all its display resolutions before the suppprt can be considered complete. Not having a default system DE integrated isn't an excuse to not support the graphics hardware in full width. That's really OS business, not 3rd party application.

 

[T-Aoki]

I think the DE is just some external programs but the primary graphics device of a computer should be able to show a pixel on all its display resolutions before the suppprt can be considered complete.

FreeBSD base is command line interface (CUI) centric and graphics are optional features since VESA extensions (for UEFI that doesn't provide VESA interface unless CSM is incorporated and activated, EFI framebuffer instead).

And on VESA extensions or EFI framebuffer (efifb), all text modes and graphics modes that BIOS / UEFI firmware reports the existence are supported, thus, x11-drivers/xf86-video-vesa or x11-drivers/xf86-video-scfb can work (both are software rendering drivers).
(The issue here, especially on efifb working as a backend of vt, is that there are some incompatible way to specify text modes / graphics resolutions for vt and not always working as documented. It should be fixed.)

Here, what mode to be exposed are on BIOS/UEFI firmwares, not on FreeBSD. For example, ThinkPad P52 with NVIDIA Quadro P1000 dGPU and 4k panel and disabling iGPU via UEFI configuration exposed 1920x1680x32, not 4k, while 4k is reported when iGPU is enabled. And when iGPU is enabled, none of documented way to specify resolution worked after loader turnes over to kernel, thus, texts are unreadably small, while worked fine when iGPU is disabled. And once X11 starts, NVIDIA drivers sanely detects 4k screen and works fine. This is because NVIDIA driver knows more about GPUs than exposed via UEFI firmware and still aware of configurations that are done prior to the driver is loaded.

 

[AlfredoLlaquet]

This thread is too profound for my taste. I will now lighten it up a little by providing some trivia. People mistakenly think that OS stands for Operating System, but, actually, it means Ordinary Suspect. This is due to it being the most probable cause of most crashes in a computer.

 

[LibreQuest]

This thread is too profound for my taste. I will now lighten it up a little by providing some trivia. People mistakenly think that OS stands for Operating System, but, actually, it means Ordinary Suspect. This is due to it being the most probable cause of most crashes in a computer.

Woah

 

[Ilovehotdog]

FreeBSD's default is "not using any GUI but old school command line interface".

arch, freebsd ,slackware


it seems only these are keeping the way.

even openbsd/netbsd/plan9 will ask user needing a wm as default in the stage of installing.

 

[T-Aoki]

even openbsd/netbsd/plan9 will ask user needing a wm as default in the stage of installing.

It would be OK if multiple options (vanilla twm, Mate, Xfce, GnuStep, fvwm, ... KDE Plasma, ..... Gnome) are provided for it.
If I recall correctly, on sysinstall (previous installer of current bsdinstall) era, installer had post-installation (before reboot) option to choose which package (pre-pkg era) the admin want to install on installer CD(!). I think this kind of post-installation option would be sufficient.

 

[MG]

FreeBSD base is command line interface (CUI) centric and graphics are optional features since VESA extensions (for UEFI that doesn't provide VESA interface unless CSM is incorporated and activated, EFI framebuffer instead).

And on VESA extensions or EFI framebuffer (efifb), all text modes and graphics modes that BIOS / UEFI firmware reports the existence are supported, thus, x11-drivers/xf86-video-vesa or x11-drivers/xf86-video-scfb can work (both are software rendering drivers).
(The issue here, especially on efifb working as a backend of vt, is that there are some incompatible way to specify text modes / graphics resolutions for vt and not always working as documented. It should be fixed.)

Here, what mode to be exposed are on BIOS/UEFI firmwares, not on FreeBSD. For example, ThinkPad P52 with NVIDIA Quadro P1000 dGPU and 4k panel and disabling iGPU via UEFI configuration exposed 1920x1680x32, not 4k, while 4k is reported when iGPU is enabled. And when iGPU is enabled, none of documented way to specify resolution worked after loader turnes over to kernel, thus, texts are unreadably small, while worked fine when iGPU is disabled. And once X11 starts, NVIDIA drivers sanely detects 4k screen and works fine. This is because NVIDIA driver knows more about GPUs than exposed via UEFI firmware and still aware of configurations that are done prior to the driver is loaded.

I usually start X.org to an empty screen on max monitor resolution. All open source only. No binary drivers. It doesn't need a lot of information. I think FreeBSD should be able to do this too because it's part of the graphics card capabilities. They made it complex but the owner bought it. It has a large stack compared to networking or USB.

 

[T-Aoki]

I usually start X.org to an empty screen on max monitor resolution. All open source only. No binary drivers. It doesn't need a lot of information. I think FreeBSD should be able to do this too because it's part of the graphics card capabilities. They made it complex but the owner bought it. It has a large stack compared to networking or USB.

You can, if the manufacturer of video card (or motherboard) properly exposes ALL resolutions / color depths via BIOS or UEFI firmware.
If not, the manufacturer should be blamed, not FreeBSD!

And as I've repeatedly stating here (this forums) and there (fediverse, MLs), UEFI should become hypervisor and all hardware features should be made available via its runtime / boottime services only (prohibitting direct hardware calls!). Period.

 

[MG]

You can, if the manufacturer of video card (or motherboard) properly exposes ALL resolutions / color depths via BIOS or UEFI firmware.
If not, the manufacturer should be blamed, not FreeBSD!

And as I've repeatedly stating here (this forums) and there (fediverse, MLs), UEFI should become hypervisor and all hardware features should be made available via its runtime / boottime services only (prohibitting direct hardware calls!). Period.

Period? I have no idea what you're talking about there.
My point in short: Why can't FreeBSD show something on a large resolution that the graphics hardware is capable of but X.org can, with a small amount of required data?

I'm not complaining about FreeBSD or something. Everything with packages is fine too. I only wonder what's in the way for full support. It would be nice to start a 450MB sized base-only system and instantly do 2d graphics. Scfb is similar. That uses the system console output as rendering framebuffer for simple graphics. Using that on several static pricing displays with a RPI0. By far good enough... But what's the problem with doing that on all hardware resolutions on a PC?

 

[AlfredoLlaquet]

Period? I have no idea what you're talking about there.
My point in short: Why can't FreeBSD show something on a large resolution that the graphics hardware is capable of but X.org can, with a small amount of required data?

I'm not complaining about FreeBSD or something. Everything with packages is fine too. I only wonder what's in the way for full support. It would be nice to start a 450MB sized base-only system and instantly do 2d graphics. Scfb is similar. That uses the system console output as rendering framebuffer for simple graphics. But what's the problem with doing that on all hardware resolutions?

You should try TempleOS.

 

[T-Aoki]

Period? I have no idea what you're talking about there.
My point in short: Why can't FreeBSD show something on a large resolution that the graphics hardware is capable of but X.org can, with a small amount of required data?

I'm not complaining about FreeBSD or something. Everything with packages is fine too. I only wonder what's in the way for full support. It would be nice to start a 450MB sized base-only system and instantly do 2d graphics. Scfb is similar. That uses the system console output as rendering framebuffer for simple graphics. But what's the problem with doing that on all hardware resolutions?

Now I'm puzzled about what's your point, then.
Anyway, there's some man pages about screen resolutions and in-base graphics supports. Maybe confusing, though.

• vidcontrol(1)
• vt(4)
• syscons(4)
• splash(4)

 

[MG]

Now I'm puzzled about what's your point, then.
Anyway, there's some man pages about screen resolutions and in-base graphics supports. Maybe confusing, though.

• vidcontrol(1)
• vt(4)
• syscons(4)
• splash(4)

In a base system, how can I draw a line on a 1920x1080 screen that both my monitor and graphics card support? (with or without kms driver)

 

[Ilovehotdog]

I think this kind of post-installation option would be sufficient.

Nobody wants to do extra work after clicking that big "Installation Complete" button. So, offering multiple default WM options during installation would be a welcome feature for regular users. The installer itself can stay text-based, but there should be a step with multiple options to pick a default WM — or no WM at all — when installing FreeBSD. This is Debian's approach for regular users, unlike Slackware. And you can see it in how CachyOS, EndeavourOS, and Manjaro are way more popular than Arch itself. Most users are just regular folks who switch to open source not for technical reasons, but because they don't like corporate stuff.

 

[Maturin]

In a base system, how can I draw a line on a 1920x1080 screen that both my monitor and graphics card support? (with or without kms driver)

In base system without any graphics kernmod loaded you have text mode, only. So, the only way to draw a line was to use a chain of '-' or '_' characters (ASCII art), or (not trivial) use a font with modified signs.

 

[fahrenheit]

In a base system, how can I draw a line on a 1920x1080 screen that both my monitor and graphics card support? (with or without kms driver)

I think that what T-Aoki was saying is that the drawing part is easy, without kernel modules you just need a VESA or EFI compatible system, use X11 making sure you have the correct X11 driver (vesa or scfb). You can then render 2d stuff.
Where things get complicated is on the 1920x1080x32b, correctly reporting what your system supports is a mess, so without drm you, get the default the loader gives you (say, 800x600) and you may not be able to change that without rebooting.

Otherwise, just do as Maturin said, use ASCII art on the console

 

[Alain De Vos]

if kde or gnome have so many problems, why not take openbox, xfce, icewm or other wm as default?
normal guy just need a "out of box" working environment。

kde has noproblems

 

[MG]

I think that what T-Aoki was saying is that the drawing part is easy, without kernel modules you just need a VESA or EFI compatible system, use X11 making sure you have the correct X11 driver (vesa or scfb). You can then render 2d stuff.
Where things get complicated is on the 1920x1080x32b, correctly reporting what your system supports is a mess, so without drm you, get the default the loader gives you (say, 800x600) and you may not be able to change that without rebooting.

Otherwise, just do as Maturin said, use ASCII art on the console

So, the complexity of the drm module prevents implementation of a basic graphical program without depending on Xorg?

 

[Alain De Vos]

i think is possible to draw in framebuffer mode without xorg. [ Must try it]

 

[T-Aoki]

So, the complexity of the drm module prevents implementation of a basic graphical program without depending on Xorg?

I don't think so.

Historically, (not 100% precise, though) graphics on Unix and its derivatives came with X Window system. So it was quite natural that almost all graphics apps used it.

There were other works nearby X Window like early implememtations of SGI IRIS GUIs and a bit later DisplayPostscript (aka DPS, used as a part of NeXTSTEP on NeXT WS), but SGI switched to X Window later and DPS are not widely used (if I understand / recall correctly, Apple dropped it and reimplemented Quartz on MacOSX). Wayland is far, far and far later.
So X Window is the long, long standing standard (through initial release to current X11) of Unix graphics. Note that Xorg, XLibre and XFree86 are implementations of X11.

And DRM/KMS is a "new comer" to boost performance that came a bit earlier than Wayland and used by Wayland.
Historical X Window driver model is recently called UMS (User Mode Switching) in contrast with KMS (Kernel Mode Setting). But X Window libraries hides the differences on implementing application softwares runs on it.

Because of the above, graphics displaying feature on FreeBSD using VESA or UEFI framebuffers other than displaying texts are quite niche features.
One thing came in mind is graphics/svgalib, but it mutually shouldn't work on UEFI boots and possibly not for vt, too (I myself never tried it, but it would be for BIOS booted sc driver with vesa.ko).

Or devel/sdl20 with proper video driver option / devel/sdl12 with VGL option, possibly?

 

[Ilovehotdog]

i think is possible to draw in framebuffer mode without xorg. [ Must try it]

haiku-OS do it when no GPU driver.

sometimes, it be error.

so, it is the plan B.

not the planA