On Sat, Apr 8, 2017 at 4:15 PM, <to...@tuxteam.de> wrote: > [...] > What systemd brings (mainly[1]) to the table is the decoupling of > different "parts" of init: just imagine you have one service (let's > say a web server) which depends on some other thing (say a file > system being present via ummm... NFS, but it could be a RAID or a > memory stick, you get the idea). With a SysV init you can't express > that: you would have to script it explicitly. With systemd you > can express that the web server is only to be started once that > file system appears.
Well, sure you could express such relationships in the sysv scripts, and people did. But sysv scripts used the shell as the declaration language, and the shell is very flexible, and everyone seems to have done their own thing in expressing such relationships. That made it hard to get an overall analysis. What could have been done here was to build a simple database of relationships and a daemon to maintain the database. Sysv could start that daemon early, and other inits could simply register through that daemon as they came on-line. But there were several different approaches to that, and territory wars, and it wasn't ready for prime-time on the schedule of Fedora's management team. > [...] > [1] Yeah: a "declarative" configuration, which may be considered > as a plus (less obscure side effects) or as a minus (stronger > separation between "priests" and "mortals"). There is no plus to a restricted declaration syntax except the walls between the controlling service and the controlled services. In other words, the minus of separation is the plus of separation. And, of course, all the relationship database daemons used their own subset of the shell's syntax for the declaration syntax. Systemd uses a completely separate declaration syntax to strengthen the walls. Noting that the walls are an illusion will invite flames, but that's true of all the walls in software systems. They can all be got around. If we couldn't get around the walls, no work could be done. The issue is not the walls, it is whether processes can maintain reasonable behavior in getting around the walls and still get their jobs done, without too much policing and hand-holding from whatever daemon/service is in charge of the wall. And it was not that it could not be achieved in sysv, it was only that it had not been uniformly achieved to meet Fedora management's timetables. This was and is the core of the arguments, I believe, but, if I expand that thought too much I think it will still cause flames. (And I don't understand why. Politics is an essential part of management, and no one reasonable claims that open source means no management at all. We ultimately will have to deal with the political issues, whether we think we want to or not.) (No, wait, I guess I do understand why. We do not have a uniform language of politics. We can't say words like "democratic" or "committee" and be sure that the person we are talking to understands them they way we intend them. I should have been more careful about that then, and I will try to be more careful now, if we can do this conversation this time.) -- Joel Rees I'm imagining I'm a novelist: http://joel-rees-economics.blogspot.com/2017/01/soc500-00-00-toc.html More of my delusions: http://reiisi.blogspot.jp/p/novels-i-am-writing.html
