On Sun, Jun 18, 2017 at 05:16:34AM -0700, Bruce Perens wrote: > On Sun, Jun 18, 2017 at 3:19 AM, Joachim Fahrner <[email protected]> wrote: > > > > systemd is not not only an init system, it is expanding to a whole eco > > system around the linux kernel, creating apis for everything you can think > > of. > > > Systemd started with the desire to communicate the desktop hardware state > to user-mode applications and to make up for the lack of login sessions in > the Unix API. There is no reason not to have APIs for everything you can > think of, as long as they don't depend on systemd. The bad decisions were > to tie these things into init system, to thus require a single software > package for all of these APIs, and to subsume a great many system tasks > into one software project. > > Although Unix provided these services (to the extent that they existed at > all) using small programs, Unix was monolithic in that the kernel and the > system utilities were all developed by ATT or later U.C. Berkeley, with > some tweaks by your hardware manufacturer. You got the system utilities on > your installation tape, and most hardware only had one choice of > installation tape. > > It was only with the creation of the Free BSDs and the Linux distributions > that you got package choice of system utilities. The original Debian had > the entire base system produced by Ian Murdock as a single package. Before > I split up production of the base system into separate packagers, nobody > knew that you *could *produce the base system that way, and that it would > work. > > The solution for this is to restore what I did with Debian: balkanize the > system utilities, so that the APIs are provided by separate utilities > developed by separate projects. The APIs originally provided by systemd > need not change in doing this, although they need not be the only APIs for > those services. Provide package choice. > > Provide the expected messages regarding the hardware state and user > sessions through libsystemd0. Just don't have them come from systemd. Don't > just answer all calls with "systemd is not here", provide the actual > services where they do something useful. Provide a means for any system > utility to originate those messages.
Have the API interfaces for systemd stablized? If not, you will end up with a maintenance headache or another incompatible API set as systemd continues to mutate. Which may be a good thing if the new API set is stable. If stability is the goal instead of compatibility, I propose that the new API be the existing traditional one wherever that is feasible and soething new where it is not. -- hendrik _______________________________________________ Dng mailing list [email protected] https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
