On 01/09/2015 10:04, Tobias Hunger wrote:
Now that is a really depressing outlook.
What can I say: the state of affairs with the systemd madness *is* depressing.
I am way more positive than about your chances than that. X11 used to be impossible to replace because of drivers and we are pretty close to getting Wayland anyway.
Eh, if you like systemd, it probably makes sense that you like Wayland; but I don't. Wayland is yet another integrated, all-encompassing, monolithic (despite otherwise claims) attempt at solving a problem, with the exact same design issues as systemd. Granted, the X problem is much more acute than the init problem, and much harder; and it's probably impossible, given our technical knowledge, to find a solution that accommodates both my desire for security and modularity and a modern graphics system's need for performance and support for stuff like 3D. But still, I don't think Wayland is the right answer, and I'm not exactly impatient to see it released.
Heck, windows was the future for ages
No, Windows was never the future. Windows was the present, because it was all people had. Unfortunately, when it was released, Windows was already 20 years behind the academic state of the art in operating systems; so, a more accurate statement would be that Windows was the past. :P Windows was the future from a "market shares" point of view, and you are reasoning in market shares terms - this is also exactly what systemd is doing. And the reason why Linux eventually took over is that it was designed right in the first place. In the same fashion, we are getting things right first no matter what is happening in the marketplace, and we will eventually take over.
I do not see that happening anywhere at this time. So far it is mostly claiming everything used to be fine before systemd. It was not.
What you are saying is that the "anti-systemd" camp is lacking communication effort. You're right. I can't talk for other people, but as far as I'm concerned, I've been totally taken by surprise by systemd's success. I've always found it so technically inept that I simply could not see it spreading, so I just ignored it. Boy, was I wrong: so many resources - time, money, energy - have been poured into communicating about systemd that it has become the most talked-about init system ever. If a quarter of the resources spent in promoting systemd had been spent on hiring experienced Unix programmers and designing a better init system, we would all be in paradise right now. And propaganda works: when you smother people with information about a product, they tend to forget that this product is not the only thing that exists. What is important to realize is that the "alternatives to systemd" community is not a company: it is mostly made of people who only have an interest in the technical side of things (i.e. who like to get things right before making big announcements) and it does not have the resources of a company (i.e. getting things right takes time, and communicating also takes more time). So it's obvious why you're not hearing much about alternatives yet. But the loudest voice is not necessarily the wisest; actually, it very rarely is.
I do not see why you would need the same socket for all daemons
It is possible to open as many sockets as there are daemons, but this is only desirable if you're using the daemontools model, i.e. one supervisor per daemon. And if you're using that model, opening a socket to listen to daemon notifications is entirely unnecessary and a waste of resources, so why would you do that? s6, for instance, has a simpler notification model that does not need a socket. Using the NOTIFY_SOCKET mechanism would require a deep rework of the supervisor code for a net loss in simplicity and maintainability. So, in practice, NOTIFY_SOCKET only benefits monolithic designs.
SD_notify is so much simpler to do than double forking, so most developers will pick that on their own. Do something even simpler and they will use that instead.
I've already done it. Writing a newline to stdout is much simpler than using sd_notify(). You haven't heard of it because I'm not in the "communication" phase yet. I want to get s6-rc ready first: deeds before words.
They do whatever makes their lives easier, just like any other open source project out there.
No, that's not the right way to look at it. Despite the licensing terms, systemd *does not* have an "open source" approach; it has a proprietary, company-driven approach, with the exact same political and technical stunts as proprietary software to make people use it, to make sure it grabs the market and holds it captive. As I said, systemd does not play fair: it pretends to play the open source game where projects are judged and adopted or ignored on mostly technical merits - but it's heavily skewing the rules and behaving in the open source world like a bully in a schoolyard.
Which concrete problems did you, Jude and whoever solve recently?
Jude is solving the needless integration of a hotplug manager into the init system. I am solving parallel, dependency-based, supervision-based service management.
What is your (meant collectively here) proposal to manage cgroups consistently? That is the one core feature of systemd that make other software depend on systemd-PID1 - directly or indirectly via other services.
Have you read the article about CoreOS and Docker that was linked in a previous post to this list? This is exactly why "managing cgroups consistently", iow "having a centralized registry of cgroups", is a bad idea.
Please blog as much as you can so that developers can find out about what you are doing. Posting here won't get your message across I think.
Your wish for more communication has been duly registered. I believe you are genuine; however, other posters on this list are reacting badly to you, because you are giving advice in the form of "just do that" and basically telling us how to do our job. In most cases, we are already "just doing that", the devil being, as always, in the details; and you can't see what the details are or why "just doing that" is difficult because you are not as involved. Unless you can make precise, constructive feature requests, or - even better - actively going to help, please don't give that kind of advice: it comes across as cavalier and dismissive, or in the worst case, antagonistic. -- Laurent _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng