| |||||||||||||
Remarks about the benchmarkRemarks about the benchmarkPosted Nov 28, 2012 14:54 UTC (Wed) by HelloWorld (guest, #56129)In reply to: Remarks about the benchmark by oldtomas Parent article: Langasek: Upstart in Debian
> IMHO what hurts systemd adoption most is this very attitude.
I don't think an opinion is a bad thing to have, but you're right in that some people don't seem to like that.
Now, given systemd's technical benefits (use of cgroups for service babysitting, much easier configuration, virtually no need for service dependency configuration, many different activation schemes instead of just static runlevels), could you please name a reason to use another init implementation for Debian GNU/Linux? Because otherwise I'll be inclined to think that my opinion is actually correct.
(Log in to post comments)
Remarks about the benchmark Posted Nov 28, 2012 22:11 UTC (Wed) by oldtomas (guest, #72579) [Link]
> I don't think an opinion is a bad thing to have, but you're right in that > some people don't seem to like that.
Opinions are fine. Dicussing them is fine too. What "some people" dislike is to be forced into one (instead of, for example, being convinced).
> Now, given systemd's technical benefits (use of cgroups for service
Because others might not share your opinion?
I won't go into the details of the discussion, they have been hashed out ad nauseam in other places.
I do appreciate Debian GNU/Linux because it goes to great lengths to enable multiple possibilities. As long as there are people willing to maintain other init systems, there should be other init systems. Your opinion is... your opinion, and is no better or worse than other people's opinion.
Trying to establish your opinion as The Truth (TM) isn't very helpful in a discussion. methinks.
Remarks about the benchmark Posted Nov 28, 2012 23:45 UTC (Wed) by HelloWorld (guest, #56129) [Link]
> Because others might not share your opinion?
As long as they can't make a valid point as to why, they'll have a hard time to convince me.
It's really easy for users like man_ls to request choice, because they don't have to do the actual work to make that possible. And they invariably fail to see that there is a (complexity) cost involved, and that ultimately they are the ones to pay it.
Remarks about the benchmark Posted Nov 29, 2012 0:38 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
if you define "not having a valid point" to be "not agreeing that when I say it's better, it's better" you will never meet anyone with a valid point.
There are a lot of people who don't like systemd, and they have expressed why. I believe that many have made valid points, you dismiss them all as being invalid.
and you wonder why people don't warm to systemd??? telling them that their concerns are all invalid and they just need to 'man up and get with the times' is not the way to change their mind.
Remarks about the benchmark Posted Nov 29, 2012 15:14 UTC (Thu) by HelloWorld (guest, #56129) [Link] if you define "not having a valid point" to be "not agreeing that when I say it's better, it's better"...I don't. There are a lot of people who don't like systemd, and they have expressed why. I believe that many have made valid points, I guess this is where you and I are different. I've seen one thing that comes close to what I'd consider a valid argument in favour of sysvinit: init must never crash, and since sysvinit is smaller than systemd, there's a smaller chance for it to crash. There are two problems with that. The first is that it's an entirely theoretical argument and lacks empirical evidence: systemd doesn't crash all the time, in fact I've never seen it crash. It is possible to make programs of that size (and much bigger ones, like the Linux kernel) reliable. The second is that it entirely ignores all the other ways in which systemd is more robust and secure than sysvinit: less need for service dependency configuration, service supervision with cgroups, predictable environments for service execution, fewer messy distro-specific shell scripts, syscall filtering, capability limitation, network isolation, SELinux support, on and on it goes. So, if you think you or anyone else has a compelling argument to make against systemd, tell me, I'm listening. But I haven't heard one so far, and my opinion about what a sensible thing for the Debian GNU/Linux developers to spend time on would be reflects that.
Remarks about the benchmark Posted Dec 2, 2012 16:20 UTC (Sun) by oldtomas (guest, #72579) [Link]
> > if you define "not having a valid point" to be "not agreeing that when I say it's better, it's better"...
> > I don't.
Sigh. Quoting you upthread:
> "Debian should pick a single init system, and it's obviously systemd given
You seem to be quite absolute about your standpoint. That's the one all should share.
You are of the strong opinion that systemd is (technically) superior. That's OK, but it's *your* opinion, not mine (besides, I value other, non-technical aspects too). Thus, it's fine Debian comes with the option of systemd (for you) and with other options (for me).
At least whenever there are enough folks willing to do maintenance. Right?
Remarks about the benchmark Posted Dec 2, 2012 18:36 UTC (Sun) by HelloWorld (guest, #56129) [Link]
Why do you want me to repeat myself?? Once more: I'm entirely prepared to change my opinion on the matter, you just need to give me a good reason why anybody would prefer sysvinit or upstart to systemd.
Until you do, I'll maintain my position: supporting init implementations other than systemd on GNU/Linux is harmful due to the increase in complexity, need for testing and waste of developer time.
Remarks about the benchmark Posted Dec 2, 2012 23:03 UTC (Sun) by dlang (✭ supporter ✭, #313) [Link]
many people have listed problems, you don't consider any of them 'real' and just dismiss them, so you aren't worth arguing with.
Remarks about the benchmark Posted Dec 2, 2012 23:36 UTC (Sun) by HelloWorld (guest, #56129) [Link]
> many people have listed problems, you don't consider any of them 'real' and just dismiss them, so you aren't worth arguing with.
I've been presenting arguments in favour of systemd again and again in this thread; you didn't refute any of them. I've been asking you and oldtomas over and over again to name technical arguments in favour of other init systems; you didn't name one.
And now YOU are accusing ME of ignoring other people's arguments? Sorry, you're ridiculous.
Remarks about the benchmark Posted Dec 17, 2012 16:43 UTC (Mon) by wookey (subscriber, #5501) [Link]
You really don't get it do you?
Read what tuomas wrote again and see if you can understand why your forthright advocacy is not helping.
It no longer an entirely technical question.
In principle I don't care at all what my init system is, but currently, after reading many of these threads and comparing what the upstart people say in comparison to what the systemd people say, and especially the way some of them say it, it's looking as if upstart is the preferable init system for me. Compare your posts with vorlon's in this particular thread, for example (approx bout 6 of this particular fight).
Did you see that? it wasn't a technical argument. You will dismiss it along with all the previous ones. You still won't have got me on your side.
Remarks about the benchmark Posted Dec 17, 2012 17:28 UTC (Mon) by raven667 (subscriber, #5198) [Link]
> ... comparison to what the systemd people say, and especially the way some of them say it, it's looking as if upstart is the preferable init system for me
I would just like to point out that regardless of what HelloWorld or oldthomas or you or I say it doesn't change the design and implementation of Upstart and systemd so there are real technical arguments and you can safely ignore partisans and fan-bois on either end.
For my part the systemd design of dependancy resolution for process startup, the process monitoring and watchdog that gets rid of the need for daemontools, the reliable process shutdown and ability to have multiple instances of a particular daemon without having to do brain surgery, the simple config file format with includes and clear overrides that allows one to repeatably set up the process runtime environment, the built-in support for all the Linux container and security and resource management features and on and on and on are reasons why I think systemd is the better tool.
It's kind of similar to the arguments around SVN and git replacing CVS, there are real technical reasons why so many distros who didn't find enough value to make the jump to Upstart are jumping to systemd.
Remarks about the benchmark Posted Dec 17, 2012 18:03 UTC (Mon) by wookey (subscriber, #5501) [Link]
Right, but ultimately either of these init systems will clearly work fine for undemanding users, so I'm (currently) inclined to give my (rather limited) support to the inclusive one not the one with all the irritating w*ankers in tow. Ultimately I'm happy that changing my mind is a simple apt-get away anyway, as I'm a Debian user, and I appreciate that people have made the effort to give me that choice. I think that's important.
And relating to your analogy, I'm one of the people that much prefers SVN over git, so am clearly a hopeless luddite anyway. :-)
Remarks about the benchmark Posted Dec 4, 2012 14:06 UTC (Tue) by nix (subscriber, #2304) [Link]
You missed a bit: it's not just that sysvinit is small, it's also that it's almost maintenance-dead. Thus, it is highly unlikely that it contains significant unknown crash bugs. systemd is relatively new and rapidly changing, so its probability of containing unknown crash bugs is much higher.
I treat init like filesystems, and don't use inits that are still changing a lot or only a few years old for anything important. systemd still falls into both categories. In time, it will emerge from them and become mature (i.e. closer to dead :) ) and thus safe to use for real work in the view of paranoid maniacs like me.
Stable software Posted Dec 4, 2012 20:53 UTC (Tue) by man_ls (subscriber, #15091) [Link] Not just for paranoid maniacs. "Stable" has two meanings: "robust" and "unchanging", and both are highly correlated: software that changes tends to be brittle. When clients say that they want software to be "stable" while it is changing I tend to think to myself "Well, don't change it then".
Stable software Posted Dec 5, 2012 0:33 UTC (Wed) by nix (subscriber, #2304) [Link]
Oh yes. We want it stable! Give us $new_feature yesterday!
Stable software Posted Dec 5, 2012 1:03 UTC (Wed) by HelloWorld (guest, #56129) [Link]
> Not just for paranoid maniacs. "Stable" has two meanings: "robust" and "unchanging", and both are highly correlated: software that changes tends to be brittle.
I don't buy that. There are dozens of projects that prove that it's perfectly possible to develop new features while not introducing regressions all the time, such as Apache httpd, Postfix, PostgreSQL and many others.
Robustness is primarily a result of good design, developer competence, care and good development practices, not of age and lack of changes. Sendmail has had much more time to mature than Postfix, yet the latter has had far fewer vulnerabilities. And BIND 8 was so broken that they decided to throw it away and start over, resulting in the much more robust BIND 9.
Stable software Posted Dec 5, 2012 10:21 UTC (Wed) by man_ls (subscriber, #15091) [Link] I agree; I should have specified "software that changes too fast". In my opinion, stability is a result of developing at the right speed and using good practices.Is there a way to quantify the right speed? Allow me to link my own post about reversible software development. Rushed developments are highly irreversible and always result in instabilities.
|
|||||||||||||