-----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----- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/545fdece.4050...@debian.org