On Sun, 2014-11-09 at 22:38 +0100, Simon Richter wrote: > 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. I even think it's best on a server (that means, if it was used as it could be)...
With sysvinit it was basically not possible to make any guarantees, e.g. like start XYZ only when firewall rules were successfully loaded, at least not in a systematic fashion. Or things like: When iptables rules are reloaded, stop fail2ban before, restart it afterwards. Unforunately, even if systemd would support such nice things, nothing of this is deployed to the masses,... which is also why I wrote, that it sometimes feels as if we'd only try to map sysvinit into systemd. > 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. Well I guess that goes back into the init-system discussion ^^ That being said, I personally would welcome, if it was policy that it's not allowed to require a specific init-system (unless specifically related software). > 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. ... which, especially in the complex cases, often lead to just more problems... I mean it's of course nice to be able to edit the init-scripts, add debug output, or adapt something to one's own very personal need. But often this also just means that either one isn't doing things right in the first place OR that the init script wasn't generically configurable enough. > 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. Which is why I'm definitely in favour of init-system diversity. > 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. Well I for the matter always hated autotools... (perhaps one should lobby Linus for CMake? ;) )... I think: an init-system shouldn't be programming,... one could always see that this basic idea is somehow broken, when programs (shell scripts) need to go to /etc,... and when people realised that this causes only troubles, they've started trying to make them generic enough to handle all cases and configurable via /etc/default/* > The systemd architecture is, in my opinion, similar to automake. Well, in a way, surely... but then one need to question: Should an init system be a universal programming language or should it be a systematised framework to boot the system, start software and perhaps manage all this after boot. And *I* don't think it should be a universal programming language. In most cases where I've ever needed to manipulate init-scripts and doing "advanced" things, like not only starting one apache http but several, running as different user and that like (which is IIRC nowadays even supported by the init script, at least partially), one could also simply say, that the original init script was simply not powerful enough and should have been implemented better in the first place, to avoid any need to manipulate it. And speaking of things like autotools,... I'd also say that the world has mostly just benefit from systematising build procedures. > 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. Uhm, I absolutely agree with that,... but I don' think it's a problem of systemd per se - it's rather a problem of how it's used/configured. Unfortunately the general direction seems to be to assume a single user PC or even tablet,... which is why we have default settings like: mount a USB stick if plugged in, or what I recently found in virt-manager/libvirt/spice,... forward any usb stick plugged in automatically to guest VMs. But these problems aren't inherent to systemd or polkit,... it's rather bad default decisions being made by people who have only their won usage scenario in mind. This is one of the main reasons why I got more and more of a gnome and utopia-stuff critic. I also think it's potentially dangerous when systemd upstrem tries to "revolutionise" more and more things, which go far beyond any init system or process manager (like the recent adventure of how software should be installed o.O) But even then, systemd seems to be better (actually especially in the server case - well at least if it was used correctly) than sysvinit. Anyway... let's not start this discussion again ^^ Cheers, Chris.
smime.p7s
Description: S/MIME cryptographic signature
