Re: Please more fish (was: so long and thanks for all the fish)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
On 09.11.2014 04:57, Christoph Anton Mitterer wrote:
> In the end it's quite easy: sysvinit has many deficiencies ans
> missing feature, systemd is superior in all places.
- From your perspective.
I can completely understand why we (and that includes me) want systemd
as a default: it gives the best possible integration of desktop
components possible.
However, there are use cases where systemd does not work because of
software design choices that, again, are in the best interest of its
users.
This is a common pattern in software development. When designing a
complex system, you have two extremes:
1. A system that covers all use cases by building a minimal framework
and letting users fill in the rest via a scripting language.
2. An elaborate system that simplifies use for the majority of cases,
uses a descriptive language for configuration, and falls flat for any
case that is out of scope.
Neither approach is inherently "better" than the other, but they can
be better suited for particular applications, and the choice which to
use is up to the user.
The vast majority of software in the world can be compiled by invoking
a compiler on all source files, and passing the compiler output to a
linker. With that knowledge, we can create a simple build system that
needs nothing but the name of the project, whether it is a program or
a library and a list of dependencies.
- From the point of view of an application developer, this is the best
thing since sliced bread. Comparing
- -----------------------------------------------------------------------
SOURCES = foo.c bar.c
OBJECTS = $(SOURCES:.c=.o)
DEPENDS = $(SOURCES:.c=.d)
PREFIX = /usr/local
foo: $(OBJECTS)
$(CC) -o $@ $^
%.o: %.c
$(CC) -MD -MF $*.d -c $<
%.d:
touch $@
clean:
$(RM) foo *.o *.d
install: foo
$(INSTALL) -d $(DESTDIR)$(PREFIX)/bin
$(INSTALL) foo $(DESTDIR)$(PREFIX)/bin/
- -include $(DEPENDS)
- -----------------------------------------------------------------------
with the much shorter
- -----------------------------------------------------------------------
bin_PROGRAMS = foo
foo_SOURCES = foo.c bar.c
- -----------------------------------------------------------------------
I think it is immediately clear which one is preferable. However, I
doubt you'd get far trying to move the Linux kernel to automake, as it
has additional requirements that cannot be represented in this way,
and extending automake to handle these is a herculean task.
> The only thing *I* regret is that it's not really used to it's
> full potential - i.e. in some places it rather seem we just try to
> rebuild sysvinit in systemd, restricting ourselfs.
The systemd architecture is, in my opinion, similar to automake.
There is a descriptive language with lots of keywords, which allows
you to do a lot of cool stuff easily, and at the same time, it is
possible to leave the framework behind for missing functionality, with
the same results for complexity and potential for error.
The blog post[1] by joeyh about his alarm clock illustrates this,
however you can already see that the framework is at its limits here,
as it is necessary to run the job with root permissions so it can use
an external tool to call back into the framework and inhibit lid
switch handling while the job is running.
At this point, I have to start asking questions:
1. What does "inhibit" mean? Will it ignore the events or just delay
processing?
2. Is this behavior guaranteed, or is that an implementation detail?
3. Does this have security implications, like a lid switch event not
being delivered to the screensaver?
4. Does this mean that other jobs will not start if they depend on the
lid switch being open, when the lid was opened while the alarm clock
was playing?
5. Is there a mechanism to be exempted from inhibit states?
6. If the events are queued, will similar events be coalesced, and
will obsolete events be dropped?
7. Why "inhibit handling the lid switch"? Wouldn't it be better to
have a mechanism to effect what we really want to do, stopping the
system from going to sleep, rather than assuming that the reason the
system would want to go back to sleep is the closed lid switch?
The alarm clock example already escalated into a round of Cambridge
Standard Five Cards Mao, with the condition of a rule being fulfilled
leading to a temporary change of the rules. Managing this at a system
level is a pure nightmare, especially when third party packages and
local policies come into the mix as well.
Restricting ourselves to a conservative default policy without any
assumptions thus sounds sensible to me. One such assumption is whether
we're running on a server, desktop or laptop system, which basically
limits us to starting programs on conditions because we cannot really
define a one-size-fits-all power policy.
Simon
[1]
https://joeyh.name/blog/entry/a_programmable_alarm_clock_using_systemd/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iJwEAQECAAYFAlRf3sYACgkQ0sfeulffv7t0ZAP/fCEy2UR/lsxjY3WcGa4ubVgr
+ktHDikXCKQU/IFEM9MMWfQjKrCpr0XRmBvQlhz/6lXuATUC/qbwMOVrDQMrA3uR
XC1PH7jMKUuXI52zQIbgHLndM3BgLWuJ4uFxapLKxd3071rQYCBahmZLIfEVzkhB
AebI5J2hwKdeaz92zaA=
=agec
-----END PGP SIGNATURE-----
Reply to: