On Sun, 18 Jun 2017 08:41:15 -0400 Hendrik Boom <hend...@topoi.pooq.com> wrote:
> On Sun, Jun 18, 2017 at 05:16:34AM -0700, Bruce Perens wrote: > > On Sun, Jun 18, 2017 at 3:19 AM, Joachim Fahrner <j...@fahrner.name> > > 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. Which, I believe, would either preclude inclusion of Gnome3 or make inclusion of Gnome3 a constantly ugly problem. SteveT Steve Litt June 2017 featured book: The Key to Everyday Excellence http://www.troubleshooters.com/key _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng