> Am 13.10.2019 um 10:21 schrieb Oliver Schad <oliver.schad_at_automatic-server.com>:
>
> Hi Casper,
>
> thank you for the effort putting things together. I was asking myself
> some questions. What is the target group? What is the exact purpose of
> that document?
>
> For systemd I have a more practical approach to discuss:
>
> 1) how many config statements are there?
What's the measurement to do?
CFG_EVERTHING_RIGHT_QUICKLY=1
would be one (but insane) config statement.
More isn't better and less neither. It should be as much as required.
And requirements depends on goal.
I think, this is a poor KPI.
> 2) how many cases exist, which you have to work around (practical
> setups, where a config statement is missing or do the wrong thing)
Both (englisch and german) Wikipedia articles reference enormous list
of issues wrt. systemd in general. Big problems - not individual ones.
Collecting individual ones is maybe a stackoverflow grep away, but how
about the dark ones - those who has questions without knowing that
systemd eat the low-level infrastructure and wonder - eg. where the
dhcpcd went to ...
> 3) how many bugs/feature requests are opened over time and how long does
> it take to solve them?
This is probably a wrong question. More features is likely not the
analyzation to do :D
> 4) how big is the memory footprint and for which systems this is too
> much?
Compared to what?
One can easily build some embedded images using e.g. OE or Yocto or
E2. But having one system with systemd (and all it's belongings) and
another (simple) one is comparing plums with melons.
Systems with a touchscreen and Qt5 interface and attached NFC readers
etc. might have a similar memory footprint with all services with and
without systemd.
The better question is: can you tune?
> 5) how many lines of code?
Also: what do you compare? I don't repeat from above.
Maybe flexibility in choice of tool is a reasonable KPI, or portability,
location of configuration (per service, over all), atomicity of configuration
changes, easiness of customization (even rocket science is no rocket
science anymore, but you need a particular skill level - where is it?),
how active is the community, easiness of debugging in error situations
and so on.
Also,
http://www.mewburn.net/luke/papers/rc.d.pdf could be worth reading ;)
But yes, you need some metrics. You also need to define scenarios first,
eg. datacenter BI algorithm machine vs. traffic light controller.
There is a big range ...
> So you would have metrics - especially if you compare them to other
> solutions. If you want to have more food, make more metrics (call graph
> complexity or whatever). But there are simple metrics, which shows the
> result(!) of the design. Talking about the design itself is really a
> personal opinion otherwise and very lengthy and needs a lot of
> knowledge to follow.
>
> For the philosophy itself there are some parts missing in my opinion:
> what does that really mean what you're talking about in practical
> solution?
>
> Is there a practical approach anywhere, interface definition,
> architecture? You describe a few patterns ok - but they are really
> common. I don't get really, which people would help this document.
>
> Maybe that thing is missing: if somebody would like to build a modern
> UNIX: what are practical steps to achieve it?
>
> Which tools, which interfaces (kernel, userland) are needed?
Cheers
--
Jens Rehsack - rehsack_at_gmail.com
Received on Mon Oct 14 2019 - 06:35:40 UTC