Am Donnerstag, 25. September 2014, 12:09:20 schrieb martin f krafft: > also sprach lee <lee@yun.yagibdah.de> [2014-09-25 01:45 +0200]: > > Just one day they might wake up and find out that it was a very > > bad idea to depend on systemd, and then it'll be difficult to do > > without. > > That day was yesterday. I'll let Paul Venezia echo almost all of my > thoughts verbatim: > > > http://www.infoworld.com/article/2608864/data-center/choose-your-side-on-th > e-linux-divide.html I bet I may have read this already, will check at a later time maybe. > But dependency creep is unfortunately nothing new ever since we > declared next year the Year of Linux of the Desktop and forgot that > the Universal Operating System should also cater to non-desktops. Oh, while I for sure see some cases of dependency creep with systemd, especially with desktop environment depending on logind with systemd upstream supplies – what business has a desktop environment to depend on an init system? –, I also see another tendency: The KDE project has spent *years* of development to reduce dependency creep. For Plasma and Plasma Workspaces 5 developers split up all KDE components in a way that many of them can be used *without* installing the rest of KDE. Many of them are now simple Qt libraries[1]. They have established clear dependency rules. So… I think its possible to reduce dependency creep and there is a good case for it. And here this example of mine is *exactly* about a desktop environment (and more). Also KDE (as in SC 4.14.1) still runs without PulseAudio for example. Again, I really believe there is always more than one side to something… Actually I even think ConsoleKit may still be supported by KDE. But as long as no one steps up and makes a logind outside of systemd… I bet some will do. At least as long as BSD wants to have desktop environments too. [1] http://inqlude.org/ Ciao, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7
Attachment:
signature.asc
Description: This is a digitally signed message part.