Re: If Linux Is About Choice, Why Then ...
On Sat, Apr 8, 2017 at 4:15 PM, <tomas@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
Reply to: