On 07/08/2015 00:09, Rainer Weikusat wrote:
Since this is maybe/ likely a bit harsh
Not harsh, just unwilling to accept that I'm actually your ally and not your enemy. I'm not trying to replace Unix, because Unix is not broken - at least, not as far as system startup is concerned. There *are* broken things in Unix, but that's a whole other enchilada that I won't have time to address in the next 2 or 3 lifetimes. I'm trying to replace *systemd*, with something that embraces Unix much, much more. sysvinit or sysvrc init scripts don't define Unix. Trying to do better than them is not replacing Unix, it's trying to do things right. Now is the time to do things right, because if we don't, systemd is going to take over, for good. I don't want that, and since you're here, I don't think you want that, either.
If you're convinced that "rip and replace" is the only viable option then I won't claim that you're wrong because I really don't know. However, until I hit a technical obstacle, I won't be convinced that the existing system can't be fixed (I acknowledge almost all defects you mentioned) and this is based on being familiar (as in 'I wrote the code') with both approaches.
Fine. I'm okay with the burden of proof. Let's take a simple example and see how deep we have to dig to make it work. You have 3 longrun services, A, B and C. A and C can take a long time to start and be ready, because they access some network server that can be slow, or even fail. But they don't depend on anything else than this network server. B depends on A. It does not contact the network server, but it consumes non-negligible resources on the local machine at startup time. Your objective is to reach the state where A, B and C are all up and ready as quickly and reliably as possible. How do you proceed ? Serially ? "A start && B start ; C start" Not good: you add A's and C's latencies. Parallely ? "A start & B start & C start" Not good: B can be scheduled to start before A, and will crash. Using a supervision system to make sure all the services will eventually be up ? "s6-svc -u /service/A ; s6-svc -u /service/B ; s6-svc -u /service/C" Better, but still not optimal: if B crashes because A is not up yet, it will be restarted, and it's annoying because it's hogging important resources every time it attempts to start. You need a dependency manager. "rc A+B+C" Much better. Except there's no such thing yet. The closest we have is OpenRC, and for now it's serial: you'll eat the added latencies for A and C just like in the naive serial approach. Ouch. ISTR there are plans to make OpenRC go parallel at some point. Let's assume it is parallel already. What do you do if A crashes because the network server is down ? You also need a supervision system, coupled with the dependency manager. The OpenRC folks have realized this, and you can use a flag to have your service auto-restarted. There's also some early support for s6 integration, which I won't deny is flattering, but I still don't think the design is right: for instance, there are early daemons you can't supervise. OK, now, how do you detect that A is ready and that you can start B ? Well, you need readiness notification, assuming A supports it. You need it because you don't want B to crash and restart. And now your rc system must implement some support for it. And I haven't even mentioned logging yet. If you've written init systems, you must have reached that point. I'm interested in knowing how you solved those issues. Now, if you try to implement process supervision, dependency management, readiness notification and state tracking in pure init scripts, well, gl&hf. That's what sysvrc, with tools like start-stop-daemon or other horrors, has been trying to do for 10 years, without knowing exactly what it was that it was trying to do. The result isn't pretty. Then systemd came and said "hey look! I can do just that, and more, and you don't have to bother anymore with those horrible sysvrc scripts!" And what did admins say? YES, PLEASE. And they gobbled up the crap because it was coated with the sweet, sweet features. (And, yes, with an unhealthy dose of propaganda and bullshit, but if you dig through the bullshit, you can find a few things of value.) I'm saying the same causes will have the same results, and more tweaking of the init scripts isn't going to accomplish anything without some serious redesign. It's the easy path; I'm all for the easy path when it can be taken, but in this case, it's not the right one. The right path is to provide the sweet, sweet, *needed* features - but to do it the Unix way.
A social reason, eg, $someone pays my bills ($someone =~ /hat/) and that's what I did and you will have to eat it aka 'resistance is futile ...' won't do.
You are fighting windmills. This is the Lennart way, it's not mine and I don't think it is anyone's here. Even if I wanted to, which I don't and never will, I don't have the power to ram anything down people's throats. -- Laurent _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng