Positions forming in the Debian init system discussion
Positions forming in the Debian init system discussion
Posted Jan 16, 2014 7:44 UTC (Thu) by oldtomas (guest, #72579)In reply to: Positions forming in the Debian init system discussion by oldtomas
Parent article: Positions forming in the Debian init system discussion
> [raven667] some people would prefer an apology or contrition and are skeptical of confidence.
> [anselm] Lennart Poettering does not appear to suffer fools gladly
> [jezuch] "confidence in one's work" [...] characterizing this as "objectionable" is laughable
> [anselm] if you can't attack the work, attack the author
And so on and so forth. In a nutshell "if you don't share our opinion, you're an idiot, because We Are Right (TM)"
Thanks for making my point even more clearly that I could ever have made it.
Posted Jan 16, 2014 8:33 UTC (Thu)
by smurf (subscriber, #17840)
[Link] (6 responses)
One can only respond calmly to the latter sort of 'argument' a finite number of times before losing one's patience. That is not the problem, that's basic human nature.
The grandstanding of some upstart proponents on a "The systemd repository is taking over Linux! Run away!" platform is the problem. (I know you don't see it that way. But I do.)
Posted Jan 16, 2014 16:18 UTC (Thu)
by oldtomas (guest, #72579)
[Link] (5 responses)
That (for me, at least) there are several criteria beyond technical on which to decide which software I use and associate with. That while systemd has a couple of nifty ideas -- (x)inetd could rip off some of that socket association thing; yes, the PID file stuff was clumsy in SysV init from the very beginning (remember: BSDinit had it already right then). CGroups, DBus -- meh, for me (the CGroup thing becoming negative with the last developments in the kernel front). The mixing of lots of policy into a bunch of binary: negative.
But: as long as the community around systemd behaves the way it does, I won't touch it with a ten foot pole. That's the deal breaker for me.
Posted Jan 16, 2014 17:08 UTC (Thu)
by cortana (subscriber, #24596)
[Link] (3 responses)
yes, the PID file stuff was clumsy in SysV init from the very beginning (remember: BSDinit had it already right then)
The process described in FreeBSD's init(8) sounds almost identical to Linux's sysvinit scheme (/etc/ttys : /etc/inittab and /etc/rc.d : /etc/rc?.d). Is this what you mean, or are you talking about something else?
Posted Jan 16, 2014 17:42 UTC (Thu)
by oldtomas (guest, #72579)
[Link] (2 responses)
Yes and no. I was talking about this (cf. your reference):
> The init utility can also be used to keep arbitrary daemons running,
Of course, one could use inittab for daemons under Linux too, but the point is that it was customary in the mid-90's to shepherd system daemons this way, thus potentially controlling their run status and their stdin/stdout/stderr and reacting to their termination via signals.
This would have been a nice evolution path towards something interesting (and those are the things systemd gets right, IMHO)
Posted Jan 16, 2014 18:24 UTC (Thu)
by anselm (subscriber, #2796)
[Link] (1 responses)
The most obvious problems with this are that starting daemons via /etc/inittab doesn't give you service ordering even in the clumsy way SysV init does (so no making sure Apache only starts when syslogd and MySQL are already running), and that there is no provision on the part of init for actually dealing usefully with a daemon's stdin/stdout/stderr, which Unix-style daemons customarily close when they start, anyway (and that convention is older than the mid-90s). There's a reason why SysV init works like it does.
This of course completely disregards the fact that systemd does many other useful things even when it is simply starting service processes based on a »runlevel-like« target (leaving aside obvious nifty things like socket activation). All of this would have to be retrofitted into the SysV init infrastructure and would only make that more convoluted and non-standard.
Posted Jan 17, 2014 10:34 UTC (Fri)
by oldtomas (guest, #72579)
[Link]
Yep. That's why I talked about the mid-90ies (no, I wasn't trying to show off what an old fart I am ;-) and hand-waved about evolution path. I do know that when I first saw this SysV bunch-of-scripts I thought "oh, my! what happened to respawn?" (there were other thoughts about those brutal shell epics in HP/UX, but I disgress).
Anyway, this has taken us astray from the original intention of my post, and that was that beyond "technical excellence", which is, of itself not a well-defined thing anyway, there are other factors *for me* on which to judge whether I want to use/take part in some software. And systemd and its "environment" fail on those other accounts so much (I repeat: *for me*, probably not for you) that I refuse to even have a deeper look at it.
Posted Jan 16, 2014 19:44 UTC (Thu)
by smurf (subscriber, #17840)
[Link]
Sorry, but I don't see a problem here. All I see are people who know what they're doing, whose software _works_, and has a ton of features certain other software does not have. In my book, that gives them some leniency in the "how much arrogance willl I put up with" department -- of which I don't see all that much in the first place.
I _have_ worked with people (and/or their software) who were so sure of themselves that there was absolutely no way to convince them to change a single bit in their source code.
The authors of systemd are not members of that set.
IMHO.
Posted Jan 16, 2014 8:35 UTC (Thu)
by Cyberax (✭ supporter ✭, #52523)
[Link]
I was initially against systemd, but then I actually tried to use it... It is really a brilliant piece of software.
Positions forming in the Debian init system discussion
Positions forming in the Debian init system discussion
Positions forming in the Debian init system discussion
Positions forming in the Debian init system discussion
> automatically restarting them if they die. In this case, the first field
> in the ttys(5) file must not reference the path to a configured device
> node and will be passed to the daemon as the final argument on its com-
> mand line. This is similar to the facility offered in the AT&T System V
> UNIX /etc/inittab.
Positions forming in the Debian init system discussion
Of course, one could use inittab for daemons under Linux too, but the point is that it was customary in the mid-90's to shepherd system daemons this way, thus potentially controlling their run status and their stdin/stdout/stderr and reacting to their termination via signals.
Positions forming in the Debian init system discussion
Positions forming in the Debian init system discussion
Positions forming in the Debian init system discussion