Re: [arch-general] SystemD poll
On Thu, Aug 16, 2012 at 01:05:27PM -0500, David C. Rankin wrote:
In all of the discussion about systemd, all anyone should care about is:
(1) Does systemd provide *needed* additional capabilities that are not currently available;
(2) What are they?
(3) What are the disadvantages of the switch?
(4) Do the advantages significantly outweigh the disadvantages, taking into consideration the time, talent and energy required to implement the change (for both the developers and end-users)?
If it is justified -- do it. If it is just being pushed because it is somebody pet project, then seriously consider impacting all end-users before foisting the change on them.
My personal experiences with systemd: My interest was piqued when it was first mentioned in the lists so I read all the blogs, man pages and other wide ranging discussions about it on the Internet. Utterly confused I decided to tentatively try it on one of my boxes. Since then the software in the Arch Repositories has slowly matured and I personally do not find, as a user, much difference from the original Arch init scripts. Pros: Faster boot times Cleaner boot screens, -quiet option enabled Cons: udev is now tightly integrated with systemd. Systemd is not KISS. IMHO systemd is unnecessarily complex in trying to do too many separate tasks. One of the big reasons I embraced GNU/Linux over 18 yrs ago is because of its KISS principle. At that time I was disolusioned with both MS Windows and IBM OS/2. GNU/Linux's policy then was KISS and one program for each needed task compared to IBM and MS policies of monolythic operating systems. Since that time I have watched GNU/Linux slowly degenerate from simplicity to complexity and IMHO systemd is just another step along this road of progress. IMHO the cost of Linux embracing complexity is a loss of freedom. We must all decide personally if we are willing to pay this price or we remain true to the principles of GNU/Linux and abandon this type of software. At this time we as Arch users do not have to make this decision but we will shortly. Please no flame wars Regards John
On Sat, 18 Aug 2012 20:11:58 +1000 John Briggs <johneb47@optusnet.com.au> wrote: <snipped wisdom> As I have said in a previous post, I arrived in linux a little later than you, but for much the same reasons. On "KISS" / "The Arch Way" / "Unix philosophy" etc, it seems to me that here as in my own field (law), maxims make good servants but poor masters. Ultimately, every decision has to be evaluated as good or bad in its own right. In most cases the answer will be in terms of the quality of the software engineering and I am more than happy to accept the judgment of people much better qualified than I am to make it. On the other hand, at the highest level, engineering decisions in all fields, sadly and inevitably, have a "political" dimension. Is the supplier of this solution trustworthy over the long term? Where does this leave us if x happens? What are the implications of this choice for future choices? Engineers are not necessarily any better qualified than the rest of us to get those calls right. Geoff
On Sat, Aug 18, 2012 at 12:03:55PM +0100, Geoff wrote:
As I have said in a previous post, I arrived in linux a little later than you, but for much the same reasons. On "KISS" / "The Arch Way" / "Unix philosophy" etc, it seems to me that here as in my own field (law), maxims make good servants but poor masters.
This is a sound observation. We should all avoid evoking slogans for their own sake. But in software, we have the luxury of some of our cliches having a more cogent, annotative meaning.
Ultimately, every decision has to be evaluated as good or bad in its own right.
Indeed. This is the discussion afoot. How tightly coupled can we afford to make any piece of software? When one cde base manages mounting filesystems, daemon startup, service dependencies, and the like, how does this affect the software ecosystem as a whole? What technologies become easier or harder to adopt and why? systemd strikes me, based on my experience, as too centralized to give the flexibility that *nix has been famous for. I may be totally off my rocker on this one. That's what I have come to believe as I have been forced to deal with it and te plethora of other startup systems that we use at work. Dev here is right that init scripts are worse (as is upstart, IMHO), but the praise leveled on systemd by its proponents (even the casual ones) is disproportionate to the gains from using it.
On 2012/8/18 John Briggs <johneb47@optusnet.com.au> wrote:
IMHO systemd is unnecessarily complex in trying to do too many separate tasks.
I don't understand why you are saying that. The systemd project may be larger than a small utility, but it is composed of: * multiple, small utilities that do well knwon and well defined tasks (we package that in systemd-tools), * a core daemon (systemd) which is hardly larger than bash wrt lines of code * udev These things are separate and each one of them does not look complex to me. What complexity do you think it has ? Rémy.
On Sat, Aug 18, 2012 at 01:52:59PM +0200, R??my Oudompheng wrote:
I don't understand why you are saying that.
I can't speak for him but I can tell you why I say it. Parsing a config file is _always_ unnecessary complexity. It is where some of the biggest bugs lurk. It hurts the functional paradigm, hurts the idempotence, harms the testability of the system, harms the automatability of the setup and packaging, and is just plain not worth it. Secondly, the cgroups feature is more harm than good. It only nurtures slopy design on daemon developers' parts. Just my opinion based on my work in the Unix software indutry.
I think a poll is a good idea. Remember it's not about whether or not you're allowed to use initscripts/systemd, it's about what will become the default. Sure, in the end it's the devs who get the final call, they're putting in the work after all, but a poll can show whether the community agrees with the devs decision. Looking at the poll (and discussions) now, it seems that people are generally in agreement with the developers and so I say we go ahead with it. Yes, there are also technical reasons/strong arguments for systemd, but that's beside the point. As Denis said: "the man with the will and skills to help makes the rules", whether it's a good or a bad decision it's up to them. You're not entitled to anything but an opinion. And I'd like to remind those that feel strongly against systemd that you can still run initscripts and make a package for it, submit patches etc. You just have to be careful on a clean install that you tick-off systemd and tick-on initscripts. R. Deckers
I agree with you. Using systemd to be the default or not is a very disputable issue. Many people like me do not like it, but some people think that it is the trend and so accept it. A poll is the best way to solve this problem. 2012/8/19 Roel Deckers <r.deckers.93@gmail.com>
I think a poll is a good idea. Remember it's not about whether or not you're allowed to use initscripts/systemd, it's about what will become the default. Sure, in the end it's the devs who get the final call, they're putting in the work after all, but a poll can show whether the community agrees with the devs decision. Looking at the poll (and discussions) now, it seems that people are generally in agreement with the developers and so I say we go ahead with it. Yes, there are also technical reasons/strong arguments for systemd, but that's beside the point. As Denis said: "the man with the will and skills to help makes the rules", whether it's a good or a bad decision it's up to them. You're not entitled to anything but an opinion.
And I'd like to remind those that feel strongly against systemd that you can still run initscripts and make a package for it, submit patches etc. You just have to be careful on a clean install that you tick-off systemd and tick-on initscripts.
R. Deckers
A poll is the best way to solve this problem.
A poll would be better done by the mailing list but I can't see anyone counting and verifying (even then newly seen addresses can't be verified) and many people don't really care as long as they're system works the way they want which is why Windows ran everything as Administrator for so long but Also why they stopped using Administrator eventually ;-). A dev poll might be interesting. As some devs have said they may be leaned towards systemd as it's less work for the devs but as long as that's beared in mind and it's used purely as a decision making tool then that's all good. -- _______________________________________________________________________ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) _______________________________________________________________________
Quoted from [1]: "The hardest thing about voting is determining when to do it. In general, taking a vote should be very rare—a last resort for when all other options have failed. Don't think of voting as a great way to resolve debates. It isn't. It ends discussion, and thereby ends creative thinking about the problem. As long as discussion continues, there is the possibility that someone will come up with a new solution everyone likes." Considering that the topic is so so trivial as to the default settings, it is stupid to have a vote on it. On the other side, ArchLinux installation is so much customizable that except for people who are just copy-pasting instructions from net without thinking, almost everyone else can use initscripts. And I believe, the first population will not bother anyway about their init system. Not because the former population is not skilled enough, anyone installing ArchLinux is skilled enough. But because, the fact that they are satisfied with default options show that they are not specifically worried about special needs. The fact that a rescue/installation CD should always boot makes it relevant that it should be widely supported. Systemd will be widely supported (for better or for worse), and the corresponding effort to install initscripts is very very small and developers time is valuable. I think the debate of default is useless. -- Cheers and Regards Jayesh Badwaik stop html mail | always bottom-post www.asciiribbon.org | www.netmeister.org/news/learn2quote.html [1] http://producingoss.com/en/consensus-democracy.html#when-to-vote
On Sunday 19 Aug 2012 19:11:12 you wrote:
I think the debate of default is useless.
I meant the voting not debate. That was typo. -- Cheers and Regards Jayesh Badwaik stop html mail | always bottom-post www.asciiribbon.org | www.netmeister.org/news/learn2quote.html
On Sunday 19 Aug 2012 13:23:12 Roel Deckers wrote:
I think a poll is a good idea. Remember it's not about whether or not you're allowed to use initscripts/systemd, it's about what will become the default. Sure, in the end it's the devs who get the final call, they're putting in the work after all, but a poll can show whether the community agrees with the devs decision. Looking at the poll (and discussions) now, it seems that people are generally in agreement with the developers and so I say we go ahead with it. Yes, there are also technical reasons/strong arguments for systemd, but that's beside the point. As Denis said: "the man with the will and skills to help makes the rules", whether it's a good or a bad decision it's up to them. You're not entitled to anything but an opinion.
And I'd like to remind those that feel strongly against systemd that you can still run initscripts and make a package for it, submit patches etc. You just have to be careful on a clean install that you tick-off systemd and tick-on initscripts.
R. Deckers
I think it is important that even if there is a poll, it should be treated as a poll, not a vote. And I completely agree with you. The fact that Ionut has already stated his intention to go along with systemd makes the poll redundant though, unless the developers do an about turn on systemd issue. So, while the poll would have been a good idea in some other circumstances. In this, I am not so sure. -- Cheers and Regards Jayesh Badwaik stop html mail | always bottom-post www.asciiribbon.org | www.netmeister.org/news/learn2quote.html
On Sun, Aug 19, 2012 at 01:23:12PM +0200, Roel Deckers wrote:
Remember it's not about whether or not you're allowed to use initscripts/systemd, it's about what will become the default.
No, maintaining both boot methods, even if upstream weren't abandoning init scripts (which they are going to) would be a terrible waste of time.
Yes, there are also technical reasons/strong arguments for systemd, but that's beside the point.
I disagree. The technical reasons are the entire point to do or not do anything.
And I'd like to remind those that feel strongly against systemd that you can still run initscripts and make a package for it, submit patches etc.
An init system isn't one of those things that just drops-in, tho'. A package for an MTA (for example) will have to know how to start itself up. You're left with the following options: 1. Rework the MTA to startup with your own method 2. Have the package maintainer somehow allow both such as... 3. Post to the AUR (or whatever) another version of the same package that uses the alternate startup system. The work snowballs from there. For every package that needs to care about how it starts up, you have to change that, too. Yes it still remains a possibility but people aren't going to do that work. Upstream has explicitly stated that the effort isn't worth _their_ time. Why would it be worth ours?
A package for an MTA (for example) will have to know how to start itself up. You're left with the following options: 1. Rework the MTA to startup with your own method 2. Have the package maintainer somehow allow both such as... 3. Post to the AUR (or whatever) another version of the same package that uses the alternate startup system.
That's why a declarative service config files help. An alternative init system could just read the "systemd" ini files and do whatever it thinks it can do better. -- дамјан
On Sun, Aug 19, 2012 at 05:28:16PM +0200, Damjan wrote:
A package for an MTA (for example) will have to know how to start itself up. You're left with the following options: 1. Rework the MTA to startup with your own method 2. Have the package maintainer somehow allow both such as... 3. Post to the AUR (or whatever) another version of the same package that uses the alternate startup system.
That's why a declarative service config files help. An alternative init system could just read the "systemd" ini files and do whatever it thinks it can do better.
I'm confused as to how this solves the problem. Sounds like you've just introduced parsing into the mix ---- another unnecessary complication.
A package for an MTA (for example) will have to know how to start itself up. You're left with the following options: 1. Rework the MTA to startup with your own method 2. Have the package maintainer somehow allow both such as... 3. Post to the AUR (or whatever) another version of the same package that uses the alternate startup system.
That's why a declarative service config files help. An alternative init system could just read the "systemd" ini files and do whatever it thinks it can do better.
I'm confused as to how this solves the problem. Sounds like you've just introduced parsing into the mix ---- another unnecessary complication.
I don't understand why you think parsing is a hard thing. INI files have been around for millennia (in internet years) and both parsers and writers for them are well established in many languages. Also, bash scripts are also parsed, for better or worse. The benefit of declarative config files is that you can extract information from them by *just* parsing and not by parsing AND running them as is the case for random init scripts. Also, even making a small error in a Turing complete bash script is much more dangerous than in a declarative file, in which you'd just ignore that line. -- дамјан
On Sun, Aug 19, 2012 at 07:14:29PM +0200, Damjan wrote:
I don't understand why you think parsing is a hard thing. INI files have been around for millennia (in internet years) and both parsers and writers for them are well established in many languages.
The question is not whether it is hard but whether it's a good idea. Things are much more likely to go wrong in parsing than many other parts of a program. When you introduce parsing, or the need to parse, you are necessarily introducing the potential for bugs. You can be a mathematically immaculate programmer and never write bugs and this doesn't change the fact that the room for human error is greater in parsing code or in the data being parsed than in other places. You are correct in assuming that well-covered territory is less buggy than new ground. I assume this is why you mention that parsing's been done for so long. This is important when we consider the following:
Also, bash scripts are also parsed, for better or worse.
This is infinity percent true. Now consider that: 1) Using shell does not introduce a new parsing code-base but instead, uses a code-base that is actively and rigorously used in a multitude of other ways such that bugs are more vigorously identified and corrected. 2) Razor-thin shell scripts (such as those used in daemontools style run scripts) have an order of magnitude less matetiral to parse than their systemd equivalents. Thus, the room for errors in the input data is far, far less; while the versatility of such "run scripts" are far greater -- all with a smaller code base than if you were consuming a config file yourself. Even if you are using a popular config-file-reading library to consume your configuration data, that is still more code and, necessarily, more potential forg bugs than if you did not consume config files at all. Thus, my advocacy for daemontools over systemd.
The benefit of declarative config files is that you can extract information from them by *just* parsing and not by parsing AND running them as is the case for random init scripts.
You are correct and articulate this truth well. It does not invalidate my position; that systemd is unnecessarily complex, that it has greater room for errors than some alternatives (please understand that I am not advocating sysv inits cripts in the least), and that the only reason to adopt systemd is because upstream is making it mandatory. If technical benefit were the only consideration and Arch were developed in a vacuum, daemontools would certainly be a superior choice. Because Arch is part of a greater Linux ecosystem and does not carry the burden of all its development by itself, systemd is probably superior for Arch at this time. This truth has convinced me that devs are making the right call in spite of the fact that most advocacy of systemd is based on some fallacious assumptions.
Also, even making a small error in a Turing complete bash script is much more dangerous than in a declarative file, in which you'd just ignore that line.
By what means do you know to ignore a line? What kinds of errors are we talking about? I'm having a hard time understanding this assertion.
2012/8/19 Anthony ''Ishpeck'' Tedjamulia <archlinux@ishpeck.net>
On Sun, Aug 19, 2012 at 01:23:12PM +0200, Roel Deckers wrote:
Remember it's not about whether or not you're allowed to use initscripts/systemd, it's about what will become the default.
No, maintaining both boot methods, even if upstream weren't abandoning init scripts (which they are going to) would be a terrible waste of time.
I agree at all. I'm trying systemd in these days, I like how the system is managed and my distro is "a bit" more standard.
On Aug 19, 2012 10:35 AM, "Alessio 'Blaster' Biancalana" < dottorblaster@archlinux.us> wrote:
2012/8/19 Anthony ''Ishpeck'' Tedjamulia <archlinux@ishpeck.net>
No, maintaining both boot methods, even if upstream weren't abandoning init scripts (which they are going to) would be a terrible waste of time.
I agree at all.
This reads funny :-)
I'm trying systemd in these days, I like how the system is managed and my distro is "a bit" more standard.
... and upstream has stated that while its not worthwhile to actually share code, they are supportive (and encouraging) common interfaces/formats/protocols for startup tasks (such as DBUS interfaces and whatnot for setting hostname, etc) so implementations on other platforms -- eg. the BSDs -- could support applications designed for systemd. IMO its very refreshing to finally see these deficiencies being tackled. -- C Anthony
Remember it's not about whether or not you're allowed to use initscripts/systemd, it's about what will become the default.
No, maintaining both boot methods, even if upstream weren't abandoning init scripts (which they are going to) would be a terrible waste of time.
What upstream are you actually talking about here considering the vast majority of Users unix-like systems are still planning on using /sbin/init and absolutely, immediately and intuitively controllable shell with comments.
... and upstream has stated that while its not worthwhile to actually share code, they are supportive (and encouraging) common interfaces/formats/protocols for startup tasks (such as DBUS interfaces and whatnot for setting hostname, etc) so implementations on other platforms -- eg. the BSDs -- could support applications designed for systemd.
What's the benefit of using dbus over reading a file. Seems convoluted to me and I am gad that I can't see OpenBSD using dbus for such a simple task especially considering the criticism that dbus is already far too overused. In fact I can't ever see dbus making into the audited base. -- _______________________________________________________________________ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) _______________________________________________________________________
2012/8/19 C Anthony Risinger <anthony@xtfx.me>
IMO its very refreshing to finally see these deficiencies being tackled.
Linux landscape had been thirsty for years about these decisions. I like very much the Arch approach to this matter and, as I said, I like systemd as my init system.
On Sat, Aug 18, 2012 at 08:11:58PM +1000, John Briggs wrote:
IMHO the cost of Linux embracing complexity is a loss of freedom. We must all decide personally if we are willing to pay this price or we remain true to the principles of GNU/Linux and abandon this type of software. At this time we as Arch users do not have to make this decision but we will shortly.
Well said. Arch devs are making he right decision to follow upstream. But LInux as a whole is going to suffer from this trend. Tying stuff tightly to the startup system will undoubtedly harm the high disposability principle spoken of in ESR's Art Of Unix Programming. When software loses this kind of orthogonality, rot sets in and it becomes harder to move to new technologes without breaking everything else. Yes, I imagine it is easier for folks in Red Hat to control things thru' a central authority of their own desgn. I feel the same way about my own systems. I do believe that there are real engineering consequences that we will suffer (not just in Arch but in other Linux distros as well) as a result of this highly coupled, overzealous aproach to startup and daemon management. It is true that linux is more unified and possibly more accessible to other corporate users and developers as a result of this. But at what technical cost?
participants (11)
-
Alessio 'Blaster' Biancalana
-
Anthony ''Ishpeck'' Tedjamulia
-
C Anthony Risinger
-
Damjan
-
Geoff
-
Jayesh Badwaik
-
John Briggs
-
Kelvin
-
Kevin Chadwick
-
Roel Deckers
-
Rémy Oudompheng