FreeBSD: Sway Compositor Can Run While KDE Plasma On Wayland Is Still A Work-In-Progress

[oiaohm]

You just really highlighted a major flaw in Redhats systemd in that it's Linux only, being kernel based, if Linux is no longer the most popular Unix then all that work is for naught. Well actually it isn't.. MacOS is so.. Second most popular desktop Unix. (or third if you could Android.. hmm)

Android uses cgroups and did a horrible hack to the problem of untraceable processes by running each program as it own individual user this is before cgroups was developed to useful.

Something to be aware the problem that cgroups addresses there is nothing in the posix standard that addresses this problem. Yes under Mac OS you have the problem that a program will not restart because a fragment of it has got away so people reboot their machine to fix.

Remember freebsd implemented jails and Solaris implemented zones before cgroups existed in the Linux kernel both were prior attempts to deal with the same problem cgroups/systemd does. SMF in Solaris intergrated zones into the into the init process. The reality what Redhat doing with systemd is not a new idea.

Really Linux being a popular Unix or not is not important. Being functional is more important. Process leak problem that results in programs not behaving correctly does have to be address and there is nothing in the posix standard to fix it. Yes this leads to OS unique solutions when posix standard does not cover the problem. Remember to claim to be Unix you have to only pass what the posix standard asks for and pay a fee not in fact be stable or usable.

Also systemd is not in fact Linux only. Systemd will work on Hurd kernel because it also implements cgroups. Now the bsd kernel could decide to implement cgroup like interface.

[angrypie]

You just really highlighted a major flaw in Redhats systemd in that it's Linux only, being kernel based, if Linux is no longer the most popular Unix then all that work is for naught.

There were efforts to port systemd's interface to FreeBSD (systemBSD?) but those apparently went nowhere as I haven't heard from them in a while.

Linux has more stuff because more people develop in it and for it, don't see how downscaling systemd to a smaller/more Unix-y kernel would be a problem, or how these smaller kernels couldn't implement Linux-y stuff that suits them (when NVIDIA asked for missing resources in the FreeBSD kernel they promptly filled the gap).

It doesn't help that BSD users and developers openly despise Linux while raving for proprietary walled-garden trash like macOS. Imagine where FreeBSD would be now if 10% of the people who spend all day bashing "Linsux" in a forum wrote a single line of code.

[k1e0x]

Something everyone overlooks. KDE and Gnome on Freebsd is going to be harder. The issue here is gnome and kde are moving over to using systemd user mode as the desktop session management instead of the old scripts.

https://systemd.io/DESKTOP_ENVIRONMENTS/

Yes this is still work in progress. Over time both KDE and Gnome developers have started they want to expand resource control features used.

The result of this change is the old script based start ups of KDE and Gnome are going to get less testing over time compared to the systemd path if the marketshares of Linux and BSD stay roughly where it is. Yes this is also going to make it harder for distributions of Linux that don't use systemd to have kde and gnome as well.

How we do graphical session management is a problem that has need solving. Its been really stupid that every WM/DE has been doing unique crud for this stuff.

You just really highlighted a major flaw in Redhats systemd in that it's Linux only, being kernel based, if Linux is no longer the most popular Unix then all that work is for naught. Well actually it isn't.. MacOS is so.. Second most popular desktop Unix. (or third if you could Android.. hmm)

It's fine tho..

[oiaohm]

I am also fairly convinced that no IPC daemon should be used. Instead the built in IPC in X11 should be utilized and I am sure some Wayland compositors will get similar once the project matures.

Dbus appears for IPC because X11 IPC is totallly broken. Those doing XACE to attempt make X11 secure also found that IPC in X11 protocol is broken. X11 developed as remote desktop in a time security was not important means X11 ipc not in fact correctly linked to the right system process.

Wayland protocol is a IPC. But its intentionally restricted IPC as this reduced the security processing that needs to be done on Wayland requests. Graphical items you don't want too much overhead. Anyone who has ever enabled Xace on X11 with selinux can tell you that its a good way to kill 40% of your desktop performance due to having to process security on everything due to how defective and over reaching X11 protocol IPC is. Remember at one point in history X11 IPC was used for a print server and other stupid things while being totally insecure.

Sorry to say X11 server IPC is bad. The split between wayland IPC and dbus IPC is good. Items needing security approval that dbus this will be a slower code path. Items for graphical display and input that need faster IPC but not security approval where security can be taken from the process that what the Wayland IPC covers. There is some overlap this leads to some arguments. But over all this is a good split.

The hard reality here on the desktop you really do need more than 1 IPC for everything to work right.

I think many of the DE projects make this stuff look *much* harder than it really is. Other than an IPC mechanism that needs to be launched. How complex do you think desktop startup scripts need to be?

start_ipc_daemon &
start_wm &
start_desktop_root &
start_panel

That is overly simple and this is the problem. In this case when application is full screen covering the start panel and start desktop root how you make sure that application is getting all the cpu resources it can. Like redrawing clock on a hidden panel does consume CPU time.

Problem here scripts were not designed to resource manage. Systemd service and scope files were designed to resource manage.

Lets say we had a version of bash that was modified that your script above would result in each of those parts automatically getting correctly wrapped in cgroups so they could be latter on correctly resource managed this would be a different matter.

Until recently most people have not been considering the fact that Mac OS, Windows, Android all give higher priority cpu access and so on active window. This requires resource control.

Desktop startup scripts in their historic form like it or not is lacking key functionality that will be need going forwards. Of course the resource control problem gets worse for a DE where you have to support XDG Autostart applications and other things like that as well.

Of course another reason why move to cgroups around applications. Linux has poor bindings between applications. So application starting applications in the right pattern can see child processes come disconnected from the parent so you perform a kill on the parent process and not everything that application started gets killed. This results in fun things X application crashes now it will not restart because a fragment of that application is still running hidden in your process table.

Resource control and proper process tracking means at least under Linux you need something more than historic shell script gives. Cgroup usage on Linux is more of a must so things can be handled correctly. If the solution for starting you desktop does not have that you are in trouble.

Good question with your script why should you log out because the start_panel crashes. Would this not be better to restart. Start seeing where systemd user comes in. At the start you have something starting that is a session manager this can allow more parts to crash and be restarted.

We have to move past the age of old school shell script.

[kpedersen]

How we do graphical session management is a problem that has need solving. Its been really stupid that every WM/DE has been doing unique crud for this stuff.

I think many of the DE projects make this stuff look *much* harder than it really is. Other than an IPC mechanism that needs to be launched. How complex do you think desktop startup scripts need to be?

start_ipc_daemon &
start_wm &
start_desktop_root &
start_panel

I am also fairly convinced that no IPC daemon should be used. Instead the built in IPC in X11 should be utilized and I am sure some Wayland compositors will get similar once the project matures.

[oiaohm]

Something everyone overlooks. KDE and Gnome on Freebsd is going to be harder. The issue here is gnome and kde are moving over to using systemd user mode as the desktop session management instead of the old scripts.

https://systemd.io/DESKTOP_ENVIRONMENTS/

Yes this is still work in progress. Over time both KDE and Gnome developers have started they want to expand resource control features used.

The result of this change is the old script based start ups of KDE and Gnome are going to get less testing over time compared to the systemd path if the marketshares of Linux and BSD stay roughly where it is. Yes this is also going to make it harder for distributions of Linux that don't use systemd to have kde and gnome as well.

How we do graphical session management is a problem that has need solving. Its been really stupid that every WM/DE has been doing unique crud for this stuff.

[reba]

Nice, you found one thing KDE does right. Hope it doesn't crash in the process.

Well, no, it did not crash. Actually, for what I do with KDE (multiple virtual desktops, several browsers, editors, VMs, Dolphins, dozens of cycles of suspend/resume, etc.), it never has crashed so far, so I'm a confident user.

As I have not much experience with the current Gnome I can't say much about it and I probably used it wrong for the screenshot. It was just meant as a UI-difference-shot and the latter comparison with the smaller screen sizes was just an "attachment" to it as I was a bit baffled by the Gnome "application picker" thingy drawing so small icons instead of, e.g. reducing the number of icons per row. If I reduce the resolution even more it manages to screw up the animations and hide applications above and below, making them un-callable if you do not know the name as you cannot see them anymore. But then again I'm not in the correct workflow for Gnome as I don't use it.

[angrypie]

Same comparison with (unusual) smaller screen sizes...

Nice, you found one thing KDE does right. Hope it doesn't crash in the process.

[reba]

If I remember correctly windows API allows for virtual desktops since w2k.

Personally I think it's not the most important feature

I've been using "The Imp Virtual Window Manager" (ImpVWM) for a 2x2 virtual desktop environment (hot corners with delay function, move windows in overview, etc., it's quite powerful) in ye olden days (read: 1995!) on Win9x and to my utter surprise it kind-of-works still with Windows 7:



Mirror: https://archive.org/details/IMPWM212_ZIP

"Thank you, George"

[skeevy420]

good grief... why do people wet themselves over trivia?

You've never peed yourself in shame because you didn't know some odd trivia?