On 02/10/2014 02:50 PM, Igor Živković wrote: > On 2014-02-10 13:04, Fernando de Oliveira wrote: >> I thought it would be worth sharing what I have just read. Perhaps not >> everybody knows about it yet. >> >> 1. Debian votes for systemd >> >> https://lists.debian.org/debian-ctte/2014/02/msg00338.html > > > I just came across an interesting blog article today: > > "Debian's discussion of whether to adopt systemd or not basically > devolved into a false dichotomy between systemd and upstart. > > None of the things systemd "does right" are at all revolutionary. > They've been done many times before. DJB's daemontools, runit, and > Supervisor, among others, have solved the "legacy init is broken" > problem over and over again (though each with some of their own flaws). > Their failure to displace legacy sysvinit in major distributions had > nothing to do with whether they solved the problem, and everything to do > with marketing. Said differently, there's nothing great and > revolutionary about systemd. Its popularity is purely the result of an > aggressive, dictatorial marketing strategy including elements such as: >
Isn't the marketing the most important thing today? :P How would you expect someone to use/buy/know about something without good marketing strategy? > * Engulfing other "essential" system components like udev and making > them difficult or impossible to use without systemd. I rather think that udev isn't a big problem here. We have extracted udev from systemd tree and there's also eudev fork. The actual problem is logind, which can't be run without systemd since version 205+ due to change in cgroups handling, and that's rather a kernel requirement, not really enforced by systemd. The bigger problem than that is that there's no good replacement for logind at the moment. ConsoleKit is dead, insecure and doesn't have everything that people require nowadays. > * Setting up for API lock-in (having the DBus interfaces provided by > systemd become a necessary API that user-level programs depend on). Using D-Bus API's instead of C/C++ API's makes the code more portable. Several different projects can export same D-Bus API's and you can use them without the need to port over. Rare case, but it's possible (see notification daemon or policykit agent interfaces - same interfaces exported by several different packages). systemd also provides C API's so it's just systemd that really requires D-Bus now and will require kdbus later. > * Dictating policy rather than being scoped such that the user, > administrator, or systems integrator (distribution) has to provide glue. > This eliminates bikesheds and thereby fast-tracks adoption at the > expense of flexibility and diversity." > You can override anything you don't like, really. Even the shipped unit files can be overriden by user ones if they don't suit the user and it's rather documented. It's a recent feature though. > More at http://ewontfix.com/14/ > -- Note: My last name is not Krejzi. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
