> >>     One of the unique attributes of the free software world
> >> historically has
> >>     been the modular nature of system components. There was
> >> opportunity for
> >>     anyone with an interest in doing so to write a replacement for a
> >>     component, and if the software they wrote was reliable and
> >> presented novel
> >>     features, it might become the preferred solution for that
> >> particular task.
> >>     The end result of this was that a wide variety of code from a large,
> >>     diverse group of free software developers saw use in many systems,
> >> giving
> >>     free software users a choice in what software they used. Because
> >> of this,
> >>     we have a number of excellent free software solutions to serve
> almost
> >>     every function - mailers of various sorts, loggers, web servers,
> >> process
> >>     monitors, domain name system software, with the list going on nearly
> >>     indefinitely, and this flexibility and suitability has made free
> >> software
> >>     the preferred platform for writing and running software services
> >> of all
> >>     types.

> >>     One of the issues with systemd is that, contrary to the Unix
> >> philosophy of
> >>    "do one thing and do it well", systemd seeks to do all things, and to
> >>     explicitly crowd out other software by offering tightly-integrated
> >> modules
> >>     that are heavily dependent upon one another. As operating systems
> >>     integrate systemd, the temptation exists to run more and more
> systemd
> >>     code, with each piece being difficult to replace individually given
> >>     systemd's lack of interest in portability or standards compliance.
> >> Systemd
> >>     seeks to define a new, defacto standard, controlled by the
> relatively
> >>     small and isolated group of systemd developers, rather than
> >> adhering to
> >>     portable, proven, multi-vendor POSIX standards, honed through
> >> decades of
> >>     experience running complex, critical, real-world computer systems.