Systemd is strictly better than what came before it, while Wayland still has missing functionality and breaks a lot of use cases.
i am willing to bet that there are systemd haters out there that love wayland and would make the exact reverse claim.
Wayland's weakest point is a11y and automation tools, which XWayland doesn't work for.
> sure it's not the same, but unlike systemd vs sysv-init, you can't run two windowing systems side by side with equal privileges unless maybe you have two monitors and graphic cards. one has to be the one that controls the screen. and the other must necessarily run as a client inside it. wayland-on-X may have been possible, but it would have limited waylands capabilities and development.
You can do both, actually; XWayland can run an X server in a window, and many Wayland compositors will run in a window on top of an X11 server. It's not seamless, of course, but it does work.
It's not "gaslighting" it's just name-calling and argument through insinuation about other people's characters, rather than substance. It's not even ad hominem, because you assume people are arguing in bad faith because of the positions they've taken, not because you know a thing about them.
Whereas with Wayland the effort to transition is significant and most compositors still have limitations X doesn't (and yes, I realise some of those means X is more vulnerable) - especially for people with non-standard setups. Like me.
I use my own wm. I could start with ~40-50 lines of code and expand to add functionality. That made it viable. I was productively using my own wm within a few days, including to develop my wm.
With Wayland, even if I start with an existing compositor, the barrier is far larger, and everything changes. I'm not going to do that. Instead I'll stick with X. The day an app I actually depend on stops supporting X, I'll just wrap those apps in a Wayland compositor running under X.
And so I won't be writing blog posts about how much I hate Wayland, and hence the quotes around "hater" above. But maybe I will one day write some about how to avoid running Wayland system-wide.
If Wayland gave me something I cared about, I'd take the pain and switch. It doesn't. Systemd did, so even if I hadn't liked it better than SysVinit, I'd still have just accepted the switch.
If I one day give up Xorg, my expectation is that it'll be a passive-aggressive move to a custom franken-server that is enough-of-X to run modern X apps coupled to enough-of-Wayland to run the few non-X-apps I might care about directly (I suspect the first/only ones that will matter to me that might eventually drop X will be browsers), just because I'd get some of the more ardent Wayland proponents worked up.
the idea here is to make it easy for x-based wms to keep working like they always have!
> [wayback] is intended to eventually replace the classic X.Org server, thus reducing maintenance burden of X11 applications, but a lot of work needs to be done first.
It also has the benefit that if it gets enough traction, then you can displace the backend off of Wayland and go directly to hardware.
Killing Wayland would just be a bonus...
An X server selectively deprecating older functionality can be lean. There are lots of the protocol you can just ignore, and what's left is fairly easy to implement. Time consuming, but easy.
Is that actually true?
The big problem is that Xlib uses a lot of the dusty corners and the people using X11 apps expect those dusty corners to work. And Xlib is very, very, very badly architected in many places and you still have to do something sane or the apps won't work.
If you get Xcb right, you at least pick up Qt and that gets you probably 80+% of the modern apps.
It really depends on your personal needs, so your mileage may wary, but having run xtruss on most of the X11 programs I use: It's true for me at least.
The key thing is that most modern clients (and Xlib vs. Xcb doesn't matter much in this respect) use exceedingly few features of the protocol.
E.g. you'll find very few modern clients that actually uses the X protocol to draw lines with any complex options. You'll also find very few attempts at using exotic visuals, because most X servers won't support them anyway.
To take a more extreme example: You could probably get away with just ripping out most or all server-side font-rendering support. Most modern X apps use Xrender, and render the glyphs client side and creat a glyph set via Xrender or just render the whole buffer client side.
Removing those will break apps, including some that some people care about (like xterm), but API surface is similar enough that it'd be reatively easy to fix the few apps people care about, or just providing an optional shim for Xlib as a temporary measure.
For own my own use, if I were to write an X server to meet my needs, I'd just not support it - I've checked with xtruss and none of the apps I care about rely on server-side fonts at all, and none of them use any drawing primitives but the most basic line drawing and rectangles either, and all of them are capable of handling an X server that refuses anything but truecolor visuals.
I could rip out large parts of the drawing code from Xorg and all the apps I run would still work just fine...
For other people, of course, this would be a different matter, and that's fine. But I think moving a bunch of that code to an Xlib-compatible library to handle client side as a means to carry over legacy apps would be an option as a means to let people evolve leaner X servers and move shift the hassle of managing legacy code to those who care about the legacy apps.
I mean, no one puts a gun against your head to use Wayland, X will be on life support for decades and will likely work without any issue.
But with this stance, no evolution could ever happen and every change would be automatically "bad". Sure, changes have a downside of course, but that shouldn't deter us in every case.
X can evolve both by extensions and by "pseudo extensions" that effectively tell the server it's okay to make breaking changes to the protocol. There are also plenty of changes you could just make and accept the breakage because the clients it's break are limited.
I don't mind breaking changes if they actually bring me benefits I care about, but to me Wayland is all downside and no upsides that matter to me.
Wayland has a few years to go yet and I'm sure it will be worth the wait. For me, it seems to work OK already.
Nope. No simple way to run a single simple script on boot, which lived in /etc/rc.local for decades. Create a unit instead. It's not much but systemd is full of little annoyances like this one.
> [] offering useful additional capabilities without taking away the old.
Once they introduce capabilities, the old quickly becomes irrelevant due to sheer mass of systemd crowd.
After they have introduced timers, it suddenly became clear that cron, which served us perfectly well for decades is now cubersome and seriously lacking. The same can be said about syslog/journald drama. Now they decided they want sudo replaced. Up next: something else that you cannot even think of, is already on their radar.
Have you tried?
At least on Debian and Ubuntu, if /etc/rc.local exists and is executable, systemd-rc-local-generator will auto-generate an rc-local.service unit that will run rc.local.
If the unit isn't visible for you, create an /etc/rc.local file. chmod +x it. Then run "sudo systemctl enable rc-local.service". Then try "systemctl status rc-local.service".
If your distro has the relevant generator, you'll see something with a line saying "Drop-In: [some path]". If so, "systemctl start rc-local" should run your /etc/rc.local, and/or it will run after reboot.
In other words, you can easily have /etc/rc.local running on boot.
On Debian and Ubuntu, you can do ls /usr/lib/systemd/system/rc* to see the compatibility options for SysV init that are available to you.
If your distro doesn't ship with an rc.local drop-in and generator, then put this in /etc/systemd/system/rc-local.service:
```
[Unit]
Description=/etc/rc.local compatibility
ConditionFileIsExecutable=/etc/rc.local
After=network.target
[Service]
Type=forking
ExecStart=/etc/rc.local start
TimeoutSec=0
RemainAfterExit=yes
GuessMainPID=no
StandardOutput=journal+console
StandardError=journal+console
Then run "systemctl enable rc-local.service". Now, as long as /etc/rc.local is executable, it will be run on startup after your network has come up (you can change the "After" if you want to trigger it based on another condition instead)
> clear that cron, which served us perfectly well for decades is now cubersome and seriously lacking.
Cron is severely limited compared to systemd timers, but nothing stops you from also running a cron. I have anacron running on my systemd setup because I agree it serves a lot of needs perfectly well. It coexists just fine and lets me use a cron for the simple stuff, and systemd timers for things that requires conditions cron can't handle, such as e.g. advanced preconditions.
Then:
> Then run [...] Then try [...]
I believe that last time I tried, systemd had different semantics (no mask/unmask, etc), but memory might fail me here.
Thing is, I don't want to do any of those things. It is not looking healthy to me that a simple unix instance needs dancing around to execute /etc/rc.local. The only solution that looks sane to me is "if /etc/rc.local is present and executable - run it". Yeah, I can understand the security implications of that.
> but nothing stops you from also running a cron
For now. Apple already deprecated and banned cron from running on macOS instances in favor of their absolutely batshit insane launchd (which was the inspiration for systemd, hence the inherited brain damage).
Before long Ubuntu will ship with no cron installed and then just a bit later it won't even be available in packages. Not even as a rust rewrite.
Only if you're running a distro that lacks basic defaults from Systemd. Are you a distro like that? Have you tried just creating /etc/rc.local and seen if it gets executed?
It's not systemd's fault if your distro ships with a broken systemd install.
> "if /etc/rc.local is present and executable - run it". Yeah, I can understand the security implications of that.
That is indeed what happens if you're on a distro with a non-broken systemd install.
> Before long Ubuntu will ship with no cron installed and then just a bit later it won't even be available in packages. Not even as a rust rewrite.
Then don't use Ubuntu. Still not systemd's fault.
Technically yes. Realistically systemd fosters insane decisions like ssh socket activation or killing of cron by providing features. Useless, unnecessary, unwanted, unrequested features that solves no real problems.
Wait until they start from scratch by rewriting everything in Rust. This absolutely will happen one day.