What is the future of FreeBSD?

Alain De Vos said:
Who cares about login managers. Ubuntu users ...
Even with "ly" or "gdm" , you can start KDE wayland ...
At no time systemd needed. Trust me i use redcore-linux & artix-linux. They don't have systemd. But KDE works fine. And will.

& as far as i know no rust in "linux zen kernel" nor in "freebsd kernel". You sound like A.I.

Future, systemd on linux will integrate with virtual terminals. But FreeBSD , will have solution.
Click to expand...
Display managers aren't relevant, but is there any other way to initiate the graphical screen that Wayland-KDE uses, and leave it on program exit? Why is this not just a graphics library that applications can use as option? It should be possible to play a movie from the VT screen. It only has to switch to the correosponding screen resolution and back to default when it's done...
 
MG said:
Display managers aren't relevant, but is there any other way to initiate the graphical screen that Wayland-KDE uses, and leave it on program exit? Why is this not just a graphics library that applications can use as option? It should be possible to play a movie from the VT screen. It only has to switch to the correosponding screen resolution and back to default when it's done...
Click to expand...

Display managers and login managers are plenty relevant. Or would you prefer to start KDE from command-line every time? And to play with that long line of text? How about choosing the encryption method for the password? How about choosing the API to call to get anything graphical going on your machine at all?

If you can get lost in the details of the freaking login process, it's easy to give up on the desktop just beyond it, because it's not worth the effort. Right?
:rolleyes:

I'm just hoping that FreeBSD will not engage in petty geopolitics the way Linux did, because that does more harm than good.
 
astyle said:
Display managers and login managers are plenty relevant. Or would you prefer to start KDE from command-line every time? And to play with that long line of text? How about choosing the encryption method for the password? How about choosing the API to call to get anything graphical going on your machine at all?

If you can get lost in the details of the freaking login process, it's easy to give up on the desktop just beyond it, because it's not worth the effort. Right?
:rolleyes:

I'm just hoping that FreeBSD will not engage in petty geopolitics the way Linux did, because that does more harm than good.
Click to expand...
Not using any since ages. I absolutely hate the infinite loop thing that they all seem to need to keep their fake-important daemon role. It's just startx for me.
 
claudiuschan said:
From my limited knowledge, FreeBSD is always been focus on being a server grade OS for stability, security and throughput.
Click to expand...
FreeBSD has always focused on stability, security and throughput. Being good for servers makes for good slogans and mottos.
claudiuschan said:
Hence, GUI applications including desktop will be provided via ports and probably will never be landed onto the base system
Click to expand...
Because FreeBSD does not make choices for you. It's a feature not a fault. Install the desktop you want, not the one chosen for you.
 
Ilovehotdog said:
What is the future of FreeBSD?
I used to see FreeBSD as a base system much like Arch Linux—one that gives users all the choices but doesn't provide an official desktop environment. Recently, however, FreeBSD 15 announced (and subsequently delayed to 15.1) that it would ship with an official KDE desktop. On the other hand, the KDE project stated this year that it will be dropping support for FreeBSD.
So where does this leave FreeBSD going forward? Will it remain a foundational system that leaves everything to the user, or is it moving toward becoming a more standard, desktop-integrated system like Debian? Could it even evolve into something more akin to Ubuntu, Zorin, or Deepin, with official support for new technologies such as AI?
On a related note, I’d also like to clarify: does FreeBSD actually have a plan to officially support a KDE desktop, rather than leaving users to install or compile it themselves as is currently the case?
Click to expand...
Your question or observation is completely desktop centric. And as such, completely irrelevant to me. I have multiple FreeBSD machines, none of which have a desktop or GUI. One doesn't even have a physical console attached.
 
I boot into text mode. I then type startx. I have a little script to choose the window manager, but I almost always use dwm so it's just startx. On my other system with a GUI, I've been running the Wayland sway. I have another silly script that just starts seatd, and I run that, then just type sway. It's configured to start with a background image and waybar. But generally, I leave both machines in dwm and sway respectively, so I don't even have to do that, just if, for some reason, it needs a reboot. I've not needed a login manager for a really long time.

This also holds for a multiboot laptop with a couple of Linux installs. In all of them, I boot into text mode and type startx afterwards.
 
cracauer@ said:
What process with what details is that supposed to be?
Click to expand...
Try writing a login manager from scratch, then you'll know what those details are. I once looked at Wayland-based greeters and realized they are more complex than what I can handle. Even a relatively simple web-based login page is still some work to get right, with the browser taking care of a LOT of details already. And stuff like SDDM is something I can watch, but not actively participate in, and fix bugs - that takes more knowledge of relevant details than what I have.
 
cracauer@ said:
Just using startx or xinitrc has a disadvantage: if the X11 server crashes then the terminal would return to the shell that is logged in.

`exec startx` is one way around that.
Click to expand...
Xorg keeps on running detached from the terminal if you have that?
I add a read A as last line of ~/.xinitrc. It can be the window manager too but that can still crash.
 
I take 4 hours to get the situation which be still not so good enough.
this is why normal people always like default.
mmexport1777989697743.jpg
 
MG said:
Xorg keeps on running detached from the terminal if you have that?
I add a read A as last line of ~/.xinitrc. It can be the window manager too but that can still crash.
Click to expand...
Why would you say that? Why would exec (and an exec() call) detach a process from the terminal? No, to detach from the terminal a process must fork, the child sets itself as the session leader, fork again, close stdin/stdout/stderr and exec, while the grandparent and parent each terminate.

No, an exec all by itself will not detach from the terminal.
 
  • Like
Reactions: mer
cy@ said:
Why would you say that? Why would exec (and an exec() call) detach a process from the terminal? No, to detach from the terminal a process must fork, the child sets itself as the session leader, fork again, close stdin/stdout/stderr and exec, while the grandparent and parent each terminate.

No, an exec all by itself will not detach from the terminal.
Click to expand...
Startx executes xinit which takes over the display and then runs .xinitrc on the still running CLI stdout. When .xinitrc ends, the entire X-session terminates.
You can circumvent this manually, start Xorg with command X and then executre programs from another terminal with DISPLAY set to the X output screen.
What happens different with exec in front of it? (I can't try quick, have everything autostart...)
It may be my bias but I don't use the exec command anywhere. I remember needing it for arithmetic in sh. Don't know if that's still normal.
 
MG said:
Startx executes xinit which takes over the display and then runs .xinitrc on the still running CLI stdout. When .xinitrc ends, the entire X-session terminates.
You can circumvent this manually, start Xorg with command X and then executre programs from another terminal with DISPLAY set to the X output screen.
What happens different with exec in front of it? (I can't try quick, have everything autostart...)
Click to expand...
It doesn't matter how one starts X, one can display to the Xserver by setting DISPLAY, assuming the X server authorizes the app to.

A process detaches from the terminal, i.e. console, is independent of whatever an app does to display to the X server running on the terminal.

When X takes over a console, i.e. ttyv9, it is owned by X until it terminates. XDM does the same. See my ttys(5) below.

Code: 
console none                            unknown off secure
#
ttyv0   "/usr/libexec/getty Pc"         xterm   on  secure
# Virtual terminals
ttyv1   "/usr/libexec/getty Pc"         xterm   on  secure
ttyv2   "/usr/libexec/getty Pc"         xterm   on  secure
ttyv3   "/usr/libexec/getty Pc"         xterm   on  secure
ttyv4   "/usr/libexec/getty Pc"         xterm   on  secure
ttyv5   "/usr/libexec/getty Pc"         xterm   on  secure
ttyv6   "/usr/libexec/getty Pc"         xterm   on  secure
ttyv7   "/usr/libexec/getty Pc"         xterm   on  secure
# ttyv8 "/usr/local/bin/xdm -nodaemon"  xterm   off secure
ttyv8   "/usr/local/bin/xdm -nodaemon"  xterm   on  secure
# dtlogin does not support PAM: ttyv8   "/usr/local/dt/bin/dtlogin -nodaemon -udpPort 177"      xterm   on  secure

Notice ttyv8. Unlike ttyv0 - ttyv7, which run getty for text mode operations, ttyv8 starts xdm. When xdm terminates, should I turn it "off" in column four and kill xdm, ttyv8 becomes non-functioning.
 
drhowarddrfine said:
FreeBSD has always focused on stability, security and throughput. Being good for servers makes for good slogans and mottos.

Because FreeBSD does not make choices for you. It's a feature not a fault. Install the desktop you want, not the one chosen for you.
Click to expand...
Totally agreed. Hence I said the FreeBSD put the power on user hands and let the user does what best suit for em.
 
You must log in or register to reply here.
Back
Top