Wayland's Weston Gets Systemd Notification Support

[schmidtbag]

Wow, so much blinding hate.

This isn't systemd lock-in, it's simply a patch to tell systemd when Weston can accept client connections. As Tom Gunderson mentions in the followup though the approach they're using shouldn't be necessary because systemd can queue up socket connections before the server is available - there's no need to notify.

I also agree. Besides, I don't think systemd is that bad. Using it can be a little vague at times but it isn't bad, and 1 more feature for wayland makes it that much closer to being usable in everyday situations.

[Vim_User]

that is because they don't use systemd and have never seen a linux system with SSD botting to kdm/gdm in 1 sec or save a ton of ram making your services activate ondemand so they only use resources when needed.

Actually I have seen that. But there is more to an init system than "OMG so fast!!!!!1111111"
We will see how that all works out when RHEL 7 comes out and a huge number of RHEL/CentOS admins are confronted with it, you know, on servers, not on "OMG so fast" desktop systems.

sometimes i think lennard goes out at night to bang trolls moms <-- that would explain the blind hate

Than he would be a necrophiliac. Do you have anything substantial to say or is insulting all you can do?

[finalzone]

Actually I have seen that. But there is more to an init system than "OMG so fast!!!!!1111111"
We will see how that all works out when RHEL 7 comes out and a huge number of RHEL/CentOS admins are confronted with it, you know, on servers, not on "OMG so fast" desktop systems.

Those admins have plenty times to try a Fedora 18+ Livemedia to get familiar with systemd.
Afterall, Fedora is the upstream of RHEL/CentOS.

[dee.]

How hard is it to figure out that Wayland is a standard? This isn't even about Wayland, it's about Weston, which is a REFERENCE IMPLEMENTATION of a Wayland compositor, no one is forcing any other Wayland compositor to implement any kind of systemd dependency or compliance or support or whatever. You're entirely free to make your own Wayland compositor and name it "systemdsucksmyballsWM" if you like.

[Vim_User]

Those admins have plenty times to try a Fedora 18+ Livemedia to get familiar with systemd.
Afterall, Fedora is the upstream of RHEL/CentOS.

And there is plenty of documentation about it. But that is not what I am talking about. With RHEL 7 we will see the first massive deployment of systemd in professional server environments, where stability and reliability is magnitudes more important than boot times, and we have yet to see how that works out.

[Ericg]

Actually I have seen that. But there is more to an init system than "OMG so fast!!!!!1111111"
We will see how that all works out when RHEL 7 comes out and a huge number of RHEL/CentOS admins are confronted with it, you know, on servers, not on "OMG so fast" desktop systems.

Than he would be a necrophiliac. Do you have anything substantial to say or is insulting all you can do?

If you think systemd is just about "OMG SO FAST!!!!!!" Then you are definitely VERY out of the loop on it. The speed is a by-product of doing things right, not its goal. Systemd is about reliable starting, stopping, restarting and tracking services. Its about resource management (both in the forms of quotas, but also through on-demand starting of services to make sure a service is only using up RAM and CPU time when its actually being used). Its about using cgroups to prevent orphaned and zombie processes. Its about reliable logging of information FROM those services to make sure if you do get breached the attacker cant modify the logfiles to cover up what he did.

USE systemd. READ about the wiki pages, READ the mailing lists, don't just go off what Michael or even I say, and DEFINITELY not what other people in these forums say.

[RahulSundaram]

And there is plenty of documentation about it. But that is not what I am talking about. With RHEL 7 we will see the first massive deployment of systemd in professional server environments, where stability and reliability is magnitudes more important than boot times, and we have yet to see how that works out.

You seem to be assuming that systemd is about*just* boot speed but that is a common myth. Much of the functionality in systemd has nothing to do with boot speed at all and enterprises care about it as well for starting clusters of vm machines quickly for instance. There are several features including tighter control over resources using cgroups and containers, additional security, dynamic virtual machine detection and so on, are highly relevant for enterprise customers.

[Vim_User]

You seem to be assuming that systemd is about*just* boot speed but that is a common myth.

Actually no, I am not assuming that. I have read many of Lennart's blog posts and know that there is more two it. I just answered to comments like:[quote]that is because they don't use systemd and have never seen a linux system with SSD botting to kdm/gdm in 1 sec[/code]It seems for some people to reduce to that. Or comments like:

save a ton of ram making your services activate ondemand so they only use resources when needed.

That also shows the desktop centric view of those people, since that usually is not an issue on servers, where a service is started on boot time and then runs forever.

That is why I have said we have to wait and see if systemd works as promised on the huge number of RHEL/CentOS machines out there, once it is deployed on those.
To be honest, I am not convinced of systemd and will keep my BSD-style scripts, if possible, or maybe switch to OpenRC some time in the future, when it is more mature and has the features that are planned now. But that doesn't mean that I am hostile to systemd, I just don't want to use it, which seems to become harder in the future and also seems to be impossible to grasp by some of its users (and sadly it seems by some of its developers also).
We will see how it works out.

[RahulSundaram]

That also shows the desktop centric view of those people, since that usually is not an issue on servers, where a service is started on boot time and then runs forever.

Not really. It really depends on the type of servers. Cloud servers or clusters deal with dynamically started services all the time. Servers also have the requirement of automatically restarting services. Now they use ad-hoc hacks but systemd would make this much simpler.

You can continue to use init scripts with systemd but unit files are certainly much less error prone and standardized.

[Vim_User]

You can continue to use init scripts with systemd but unit files are certainly much less error prone and standardized.

Unless I hit a bug in systemd itself, where I first have to learn C to get it working as it should or hope that it is fixed upstream in a timely manner, while any system administrator should be able to fix a shell script or at least implement a workaround.