KDE Plasma Login Manager Won’t Support Systemd-Free Linux or BSD Systems

Soon ... don't believe it. Wayland is not stable enough to drop X11.
And, I'm not sure that it ever will be at the rate it's going. I can't get it to stop moving all my windows from one monitor to the other because they don't think that it's their responsibility to have a way of dealing with that. I was somewhat enthusiastic about Wayland well over a decade ago, but I have to wonder what sort of a development process starts out because a project is too complicated to maintain and then goes on to take quite a few more years to develop than the original overly complicated project did. I'm going to laugh my backside off if Phoenix manages a functioning rewrite on this faster than Wayland finishes up.
The given reason was that no one (well, two persons) really understood X, it was hard to develuop for, had to cater for a use mode that was no longer valid (i.e. fat server, thin clients).
As for being designed for fps games, not really, as by default wayland was always vsync on (no option to disable), it took them nearly 10 years to figure out that maybe games may not want vsync on. Then there is the reasoning that wayland is not a server but instead a (collection of) protocol(s). That didn't work out as expected also. Security, for reasons, was also a provided reason (i.e. why it took 13 years to be able to take a screenshot of the screen and why screen sharing is a pain).

In any case Wikipedia has the "stated" reasons: https://en.wikipedia.org/wiki/Wayland_(protocol)#History
It is, and I have yet to get an adequate explanation as to why it was necessary to break so much of the ABI in the process. I don't know that there are many people that would argue that a thorough rewrite of Xorg with things that are truly obsolete being dropped would be a bad thing, but it's hard for me to understand the justification when it doesn't seem to do anything that X couldn't do if they cared to take the time to implement it.
 
And, I'm not sure that it ever will be at the rate it's going. I can't get it to stop moving all my windows from one monitor to the other because they don't think that it's their responsibility to have a way of dealing with that.
It is, and I have yet to get an adequate explanation as to why it was necessary to break so much of the ABI in the process. I don't know that there are many people that would argue that a thorough rewrite of Xorg with things that are truly obsolete being dropped would be a bad thing, but it's hard for me to understand the justification when it doesn't seem to do anything that X couldn't do if they cared to take the time to implement it.

That is the monitor lottery I spoke of earlier as I call it where they desktop opens the program on any damn monitor it chooses to do so on regardless of where you had it located. I eventually found a .kwin script that the author wrote to fix that problem. It works on both the KDE and LXQt I moved to after dumping the former.


The Wayland was never envisioned as fixing X it was meant as a method to kill it off cementing Redhat's control over the Linux desktop in the way the systemd garbage they pit out is meant to do. The maintainers of X deliberately left it to die on the vine by not doing any work on it despite people still submitting patches to fix problems,they did this for years. Now they have sprang back into action after being shamed into doing by the Xlibre fork who have proved those patches and work on it were viable and could be used. So they updated a few libraries a couple of days ago and are going to have a new release by the end of the year supposedly.

 
So there may be, probably, a chance on an attempt to have a try on testing the possibilities of maybe a resurrection of the old XOrg for the time being? Great. I'll buy that for a fillér.
 
The fillér was 1/100 of a forint, and is out of circulation for some time now.
Just checking, the forint is at 0.0026€, which would make my first price offer for that promise come in at 0.000026€. That's how much I'd wager on that statement being true for some years to come.
 
If it was, GNOME didn't get the memo until at least mid 2025 🤣 (high CPU/GPU load would make the cursor go floaty/disconnected; article, and even then it doesn't sound like it solves the issue of somehow making the cursor dependent on guess-timers vs whatever X11 and Windows have been doing fine for years :p)

1000Hz was seemingly fine GNOME 48 or 49 though, but I have questions for whoever praised that prior (especially before GNOME 42)
Ad Wall ; Don't (Can't) Read.
As far as I know, there were no session managers / login (display) managers on ancient X11R6.

At some point, I've noticed that something pulled in XDM, which I've never configured (I'm logging in with base CUI prompt, then, startx). Maybe DEs (starting from CDE? not sure) introduced and pulled into by default with xf86?

When I've noticed consolekit, seatd and so on, they were required by DEs or WMs.
If Wayland is not for gaming, no reason to remove the layer from under compositor layer.

Are there any reason that compositor is the bottom layer, under session manager? I cannot imagine other than decreasing quite small amount of delays. And this kind of things were often comes for gaming.

Yes, just out of curiosity that there are other reasons or not. No offending to anyone here is intended.
 

and pave the way for future releases in a Wayland-first world.

That article's meta discription (og:description, twitter:description) makes a nice attempt at viral "affirmation marketing" but its nonsense in two ways.

1) Wayland is struggling to take hold in the Linux world, let alone the wider *nix world
2) Microsoft Windows's DWM compositor is "first" and will remain first for our lifetime

Weirdly I don't see the quoted text in the article itself... I guess they had nothing to expand upon or back it up past the click-bait. The rest of the article was good though.
 
I am a nosystemD linux developer and unix enthusiast... we shall resist...
Today is a login manager tommorow will be more than that...
They are not just dependencies they are keyparts so microsoft will take linux 100% in their hands and it is a shame freebsd uses linuxolator based on systemD distros instead of Void or Antix for example or Alpine which is a more sensible approach anyhways.
 
That article's meta discription (og:description, twitter:description) makes a nice attempt at viral "affirmation marketing" but its nonsense in two ways.

1) Wayland is struggling to take hold in the Linux world, let alone the wider *nix world
2) Microsoft Windows's DWM compositor is "first" and will remain first for our lifetime

Weirdly I don't see the quoted text in the article itself... I guess they had nothing to expand upon or back it up past the click-bait. The rest of the article was good though.

Yes that is the way with the Wayland crowd all style over substance the total BS at all times being put forward to try and con the uninformed into believing they have something worth while. Because of number one "security" and number two they are right on everything as they know what they do and definitely what is best for you and your computer, the typical Gnome troll method of operation.
 
This article is suspicious. The header image mentions Zig, but that is nowhere in the rest of the article. Seems like a bad AI summary of this?

Who knows there is so much trash out there it is possible, the summary is by this sites software I do believe so if they use garbage AI to so it then that is here it came from. All I know is the Xorg people have got off their asses and are doing something for the first time in years due to IMHO being shamed into it by the Xlibre fork being released. As otherwise they were content to let it bitrot until they killed it off on purpose by their neglect.
 
All I know is the Xorg people have got off their asses and are doing something for the first time in years due to IMHO being shamed into it by the Xlibre fork being released.
Hard to tell because they stopped doing IRC logs in 2024. The previous directors meetings here show very little action. Almost nothing outside of XDC planning and re-elections.

More leadership is demonstrated in an average Xlibre bug ticket ;)
 
More leadership is demonstrated in an average Xlibre bug ticket


Indeed it is why I have formed the opinion I have about the Xorg maintainers, they have went out of their way to do nothing to enable them to kill it off. This latest effort by them to save face doing new releases now that someone has shown it is possible to move forward with the code is simply pathetic. And to top it off they are going to rebase it so they eliminate that work done by Xlibre denigrating it as somehow not up to their high standards of doing jack all with it for ages. Those people are something else.
 
I am a nosystemD linux developer and unix enthusiast... we shall resist...
Today is a login manager tommorow will be more than that...
They are not just dependencies they are keyparts so microsoft will take linux 100% in their hands and it is a shame freebsd uses linuxolator based on systemD distros instead of Void or Antix for example or Alpine which is a more sensible approach anyhways.
I wonder how much longer the current Linuxulater is going to make sense now that we've got podman and OCI containers that do mostly the same things. Plus there are Linux options for jails these days. The process of setting up a container that's got the Linux stuff in it isn't really that much harder than setting up Linux software using the Linuxulator. I haven't got Firefox to run in a podman container, but I was able to get Eclipse running in there. And, Alpine Linux definitely runs in podman containers.

It amazes me how invested people are in the benefits of systemd without bothering to consider just how much it breaks or requires to be coded around in order for it to do things that an init replacement shouldn't be doing in the first place.
 
They say not cutting freebsd support, but it’s only a matter time before other components have hard dependencies. Using systemd is not required to make a modern login manager. It’s just a preference. Clearly SDDM is proof of that.

Maybe they don’t want to provide support for distributions to use other methods. That I think would be more accurate. Using the “more modern” argument is just a way to convince the masses into thinking anything that does not use the Linux preferred stack is not modern, this way the masses will repeat the rhetoric for them. It’s a clever twisting of words to manipulate forced obsolescence.
 
I wonder how much longer the current Linuxulater is going to make sense now that we've got podman and OCI containers that do mostly the same things. Plus there are Linux options for jails these days. The process of setting up a container that's got the Linux stuff in it isn't really that much harder than setting up Linux software using the Linuxulator. I haven't got Firefox to run in a podman container, but I was able to get Eclipse running in there. And, Alpine Linux definitely runs in podman containers.

It amazes me how invested people are in the benefits of systemd without bothering to consider just how much it breaks or requires to be coded around in order for it to do things that an init replacement shouldn't be doing in the first place.
Well, as podman execution of Linux containers requires Linuxlator, I don't think there's a risk of it going away. Unless FreeBSD want's to go the way of docker in non linux, i.e. has a full blown linux vm just for it.
As is the current solution is really nice (well except the part where you are required to use root to use it).
 
It amazes me how invested people are in the benefits of systemd without bothering to consider just how much it breaks or requires to be coded around in order for it to do things that an init replacement shouldn't be doing in the first place.

People don't care about other's breakage.
Systemd is one of the easier inits I've worked with when it comes to turning the software I wrote into a service. And it is one of the hardest inits to debug.

The issue is largely noone is debugging the run cycle of servers any more. They boot the networking, storage and the container/virtualization layer. Then all the services are split between instances, partitioned, and in turn you have dozens of systemds running a few services each.

On the other hand writing as service "unit" for a piece of software that spits log on stdout/stderr is 5-6 lines.

Systemd succeed (yes it did, because large Linux masses adopted it) because it lifts off the burden of writing service scripts from developer/maintainer/porter.

Do not forget that, back in the early 90s, Microsoft broke Ctrl+C, assigning it to "clipboard copy" operation in Windows 3.x. But it couldn't be done for DOS Prompt, because in DOS it serves the same function as in Unix, the one true original thing (TM). For the next 20 years, after dropping win32-based Windows that had DOS vm86 functionality, after having NT as mainline for a decade, Microsoft did not have a nominal copy/paste operation as they defined it in their own bloody terminal.
 
People don't care about other's breakage.
Systemd is one of the easier inits I've worked with when it comes to turning the software I wrote into a service. And it is one of the hardest inits to debug.

The issue is largely noone is debugging the run cycle of servers any more. They boot the networking, storage and the container/virtualization layer. Then all the services are split between instances, partitioned, and in turn you have dozens of systemds running a few services each.

On the other hand writing as service "unit" for a piece of software that spits log on stdout/stderr is 5-6 lines.

Systemd succeed (yes it did, because large Linux masses adopted it) because it lifts off the burden of writing service scripts from developer/maintainer/porter.

Do not forget that, back in the early 90s, Microsoft broke Ctrl+C, assigning it to "clipboard copy" operation in Windows 3.x. But it couldn't be done for DOS Prompt, because in DOS it serves the same function as in Unix, the one true original thing (TM). For the next 20 years, after dropping win32-based Windows that had DOS vm86 functionality, after having NT as mainline for a decade, Microsoft did not have a nominal copy/paste operation as they defined it in their own bloody terminal.
Clearly not, the amount of gaslighting that I've had a subset of Linux users engaging in trying to convince me that systemd isn't impacting me personally, even though the development time that it takes to fix the integration that Linux software depending on something that's both Linux only and breaks compatibility doesn't have a knock on effect on other software or that it's a skill issue whenever I come back to my computer and see that wayland has swapped all my windows.
Well, as podman execution of Linux containers requires Linuxlator, I don't think there's a risk of it going away. Unless FreeBSD want's to go the way of docker in non linux, i.e. has a full blown linux vm just for it.
As is the current solution is really nice (well except the part where you are required to use root to use it).
Don't get me wrong, I don't expect it to be pulled anytime soon, but it is a tad redundant these days.
 
Clearly not, the amount of gaslighting that I've had a subset of Linux users engaging in trying to convince me that systemd isn't impacting me personally, even though the development time that it takes to fix the integration that Linux software depending on something that's both Linux only and breaks compatibility doesn't have a knock on effect on other software or that it's a skill issue whenever I come back to my computer and see that wayland has swapped all my windows.

Wayland is still broken even on happy paths. $dayjob machine Rocky Linux 9, wayland, Plasma, one update months ago, broke the taskbar, the tray windows and the start menu are now shown at the middle of the taskbar. The launcher is not shown top middle but dead middle. This makes my affairs quite shitty because I use focus-follows-mouse, and the popup areas are not rendered beside the click point but far away.

Why I use(d) wayland on there, I like the Plasma Irixum theme very much but can't use it on X11 because it doesn't work correctly with increased screen DPI - the top window decoration is not drawn correctly, bottom border line is offset up and runs straight through the window name. So while wayland worked as good as X11 I used it because of this one small point, but when it stopped, I just reverted to Plasma-X11.

Lol. didnt 80286 had protected memory (small joke)

It did but it was bad, a flop. Famously Bill Gates scrutinized the CPU.

286 didn't support kicking back from protected to real mode. Supposedly that was an intentional, security feature.

And they haven't provided any mechanism to reach >1MB address space from real mode. If this sounds like a disaster, yes it is.

Fortunately there was a way to switch in and out. And that meant XMS specification could be designed and implemented. A driver that switches between real and protected modes to deliver segment of >1MB protected map to <1MB real mode addressable.

In turn developers of intense applications had a choice to make - kick into protected mode the way Intel envisioned it, and reboot on exit, or use real mode and access extra RAM through DOS XMS services. They used the latter, because with option 1 the users would be pissed.

What used the protected mode are new OSes, Windows, Xenix for 286, etc. But that was a very small piece of PC market then. Very very small.

Intel did pay attention and 386 brought improvements almost exclusively in this backward compatibility area - now you could switch modes freely, and protected mode had a vm86 and traps stuff, so real mode code could be executed in protected mode. This was a tremendeous achievement, because now you could have a runtime library that allows programs to access 4 GB RAM, while the programs can still perform direct hardware I/O. This is why the games exploded in 386 age.

Anyhow 286 without its protected mode is just a 186, and since the protected mode was avoided due to its supposedly intentionally dumb design, the whole thing is a flop. Yeah PC/AT was fast, but it also had 4x the cost of PC/XT.

(/offtopic)
 
Systemd is one of the easier inits I've worked with when it comes to turning the software I wrote into a service.
It was the most complex for me :p

I had two parts for a daily updater at 4AM:
Code:
[Service]
User=wwwrun
Group=www
Type=oneshot
WorkingDirectory=/srv/www/social
Environment="COMPOSER_CACHE_DIR=/dev/null"
ExecStart='/usr/bin/git' -C '/srv/www/social' reset --hard 'origin/develop'
ExecStart='/usr/bin/git' -C '/srv/www/social' pull origin 'develop' --rebase
ExecStart='/usr/bin/git' -C '/srv/www/social/addon' reset --hard 'origin/develop'
ExecStart='/usr/bin/git' -C '/srv/www/social/addon' pull origin 'develop' --rebase
ExecStart='/usr/bin/composer' --working-dir='/srv/www/social' --no-cache install --no-dev
ExecStart='/usr/bin/php' '/srv/www/social/bin/console.php' dbstructure update --force
ExecStart='/usr/bin/php' '/srv/www/social/bin/console.php' dbstructure drop --execute
ExecStartPost='/usr/bin/php' '/srv/www/social/bin/console.php' postupdate
ExecStartPost='/usr/bin/sync'

Code:
[Unit]
Description=Friendica Git Updater
After=network-online.target
Wants=network-online.target

[Timer]
OnCalendar=*-*-* 04:00:00
Persistent=true

[Install]
WantedBy=timers.target

FreeBSD's easier: I put the stuff in a .sh script I can run/edit flexibly, and one line in a cron.d:
Code:
#!/bin/sh

cd '/tmp'
'/usr/bin/su' -m 'www' -c "'/usr/local/bin/git' -C '/usr/local/www/social' reset --hard 'origin/develop'"
'/usr/bin/su' -m 'www' -c "'/usr/local/bin/git' -C '/usr/local/www/social' pull 'origin' 'develop' --rebase"
'/usr/bin/su' -m 'www' -c "'/usr/local/bin/git' -C '/usr/local/www/social/addon' reset --hard 'origin/develop'"
'/usr/bin/su' -m 'www' -c "'/usr/local/bin/git' -C '/usr/local/www/social/addon' pull 'origin' 'develop' --rebase"
'/usr/bin/su' -m 'www' -c "'/usr/local/bin/php' -c '/usr/local/etc/php-fpm.d/social.conf' '/usr/local/bin/composer.phar' --working-dir='/usr/local/www/social' --no-cache install --no-dev"
cd '/usr/local/www/social'
'/usr/bin/su' -m 'www' -c "'/usr/local/bin/php' -c '/usr/local/etc/php-fpm.d/social.conf' '/usr/local/www/social/bin/console.php' dbstructure update --force" > '/dev/null'
'/usr/bin/su' -m 'www' -c "'/usr/local/bin/php' -c '/usr/local/etc/php-fpm.d/social.conf' '/usr/local/www/social/bin/console.php' dbstructure drop --execute" > '/dev/null'
'/usr/bin/su' -m 'www' -c "'/usr/local/bin/php' -c '/usr/local/etc/php-fpm.d/social.conf' '/usr/local/www/social/bin/console.php' postupdate" > '/dev/null'

Code:
0 4 * * * root '/home/espionage724/.local/scripts/www/social/updater.sh'

Windows I put stuff in a script like FreeBSD, but scheduling it is easy!
Code:
SCHTASKS /Create /SC "DAILY" /TN "Social Update" /TR "%SystemDrive%\www\scripts\social\Update.bat" /ST "04:00" /F

Debugging that systemd script on Fedora with SELinux was particularly fun :p
 
If I recall correctly, what i80286 made programmers most dissappointed was the limitation in segment size, 64kiB, not 16MiB.

If the definition of the segment was actually a "page" in current term, having MMU that handles multiple segments in its "Segment" Lookup Table defining (here, not defined the term was, though) code block, data block, BSS block and stack block, with an equivalent of vm86, things could be differ.

Yes, it means almost i80386SX without 32bit support.
 
Back
Top