5 ms·

The anxious parties are mostly the BSDs and maybe Ubuntu. Other using systemd is not a problem for anybody. The problems start once the higher-level stuff (X.o

by qznc 13y ago

The anxious parties are mostly the BSDs and maybe Ubuntu. Other using systemd is not a problem for anybody. The problems start once the higher-level stuff (X.org,Wayland,Gnome,KDE,gdm,etc) requires systemd. The question is whether the anxious parties have enough devpower to maintain portability layers and especially the BSDs may not. However, by Adams Law of Slow-Moving Disasters [0] these problems will be resolved in time. [0] http://www.dilbert.com/blog/entry/fact_checking_adams_law_of_slowmoving_disasters/ http://www.dilbert.com/blog/entry/fact_checking_adams_law_of...

nitrogen 13y ago
One of my concerns with systemd is that kernel interfaces for input and display devices will begin to assume its presence, negatively affecting my ability to use /dev/input/event* or /dev/fb* in embedded systems.
gonzo 13y ago
Why are the BSDs anxious about systemd?
- zokier 13y ago
  Because systemd doesn't run on BSD, and probably never will.
  - anonyfuss 13y ago
    footnote: because the maintainer (Lennart Poettering) is religiously anti-portability. This is a shame, because it makes for brittle software, even when targeting the same platform where APIs do shift and improve over time. To quote: > In fact, the way I see things the Linux API has been taking the role of the POSIX API and Linux is the focal point of all Free Software development. Due to that I can only recommend developers to try to hack with only Linux in mind and experience the freedom and the opportunities this offers you. So, get yourself a copy of The Linux Programming Interface, ignore everything it says about POSIX compatibility and hack away your amazing Linux software. It's quite relieving! I find this to be extremely cringe-worthy; I can only hope that a Linux monoculture isn't the future of open source development.
    - mseepgood 13y ago
      > This is a shame, because it makes for brittle software The opposite is true: Abundant use of #ifdefs makes for unmaintainable and brittle software.
      - anonyfuss 13y ago
        > The opposite is true: Abundant use of #ifdefs makes for unmaintainable and brittle software. False dichotomy; simply don't make abundant use of #ifdefs. Most large, portable projects don't use #ifdefs across the codebase. They abstract the core concepts out into interfaces that can be implemented atop different APIs, and then maintain distinct implementations where necessary. The advantage is that this also insulates you from changes to the underlying system APIs, creates testable code, and provides clean well-defined points of interaction between subsystems.
        mseepgood 13y ago
        > They abstract the core concepts out into interfaces that can be implemented atop different APIs This is exactly what systemd's D-Bus API is for.
        anonyfuss 13y ago
        D-bus isn't a software architecture and doesn't somehow magically make systemd more maintainable.
        bkor 13y ago
        Another layer of abstraction just results in more complicated code, more bugs, more difficulty testing the different code paths. Might be fine for a lot of projects, but this is just something to boot up your system.
        anonyfuss 13y ago
        > Another layer of abstraction just results in more complicated code, more bugs, more difficulty testing the different code paths. No. A proper approach to abstraction: - Reduces complexity by reducing interdependency between subsystems. - Facilitates testing by reducing interdependency between subsystems, and reduces bugs by facilitating testing. - Allows for iterating components of the code base independently, and more easily adapting to changes to underlying components and subsystems, whether in the software themselves, or part of the system(s) the software relies on. > Might be fine for a lot of projects, but this is just something to boot up your system. Actually, this isn't just something to boot up your system (and if it was, it would be even easier to keep portable). Instead, systemd a kitchen-sink-replace-everything-daemon that introduces massive cross-system/cross-module dependencies.
- noselasd 13y ago
  Because, as the parent said, as higher level projects, starts requiring systemd, the BSDs will either have to port over systemd and replace their init system, or keep around patches to go around systemd requirments for every application that needs it. Neither is desirable and would take non-trivial effort.
- jeltz 13y ago
  Because (as qznc stated) they are worried that various applications will start to rely on systemd features so that BSD either will have to maintain a compatibility layer or be stuck with old software.
bitwize 13y ago
Nobody cares about the old, portable, loosely coupled Unix Way of developing software. That's just not how modern apps are written anymore.
- anonyfuss 13y ago
  That's the way Mac OS X is written. They certainly haven't bundled the entire universe into a single master "system daemon" project. A few, off the top of my head: configd: A configuration store that handles storing (and monitoring changes to) configuration. It supports arbitrary plugins, such that other dependent systems can inject their own implementation code if necessary. It depends on kernel notification APIs and network notification APIs that are implemented at a different level. launchd: Starting/stopping/restarting services, on-demand and on a schedule, per-user and system-wide. diskarbitrationd: Handles mounting/unmounting of file systems, and notifies clients of changes to mounted file systems. opendirectoryd: Handles namespacing of local and remote user/data directories. This includes LDAP, local user accounts, etc. mDNSResponder: Used to be just the mdns daemon, now handles all name resolution and local caching. All of these things have been iterated on independently over time, are loosely coupled with each other, and do not create tight bindings between Mac OS X and open source software, nor do they require huge non-portable changes to open-source software. The precursor to opendirectoryd was netinfo, which also used to handle name resolution and caching. Later releases of Mac OS X moved name resolution into directory services, and then eventually into mDNSResponder. launchd replaced system starter (similar to initd/rc), cron, and a number of other services, but maintained 'perfect' backwards compatibility with the standard configuration file formats (eg, crontab(5)). These are just a few of the (independently maintained, internally) projects/daemons that Mac OS X layers together to produce the desktop. You don't need a huge monolthic project to tackle all these problem domains, as evidenced by the fact that Mac OS X works. You also benefit from laying these projects cleanly, as it allows them to tackle what they're good at, provide a stable interface, or even be swapped out entirely later.
  - bitwize 13y ago
    That's the way Mac OS X is written. They certainly haven't bundled the entire universe into a single master "system daemon" project. Actually, launchd replaces init, inetd, crond, atd, and watchdogd. I mean where do you think systemd got the idea from? :)

by qznc 13y ago

nitrogen 13y ago

One of my concerns with systemd is that kernel interfaces for input and display devices will begin to assume its presence, negatively affecting my ability to use /dev/input/event* or /dev/fb* in embedded systems.

gonzo 13y ago

Why are the BSDs anxious about systemd?

zokier 13y ago
Because systemd doesn't run on BSD, and probably never will.
- anonyfuss 13y ago
  footnote: because the maintainer (Lennart Poettering) is religiously anti-portability. This is a shame, because it makes for brittle software, even when targeting the same platform where APIs do shift and improve over time. To quote: > In fact, the way I see things the Linux API has been taking the role of the POSIX API and Linux is the focal point of all Free Software development. Due to that I can only recommend developers to try to hack with only Linux in mind and experience the freedom and the opportunities this offers you. So, get yourself a copy of The Linux Programming Interface, ignore everything it says about POSIX compatibility and hack away your amazing Linux software. It's quite relieving! I find this to be extremely cringe-worthy; I can only hope that a Linux monoculture isn't the future of open source development.
  - mseepgood 13y ago
    > This is a shame, because it makes for brittle software The opposite is true: Abundant use of #ifdefs makes for unmaintainable and brittle software.
    - anonyfuss 13y ago
      > The opposite is true: Abundant use of #ifdefs makes for unmaintainable and brittle software. False dichotomy; simply don't make abundant use of #ifdefs. Most large, portable projects don't use #ifdefs across the codebase. They abstract the core concepts out into interfaces that can be implemented atop different APIs, and then maintain distinct implementations where necessary. The advantage is that this also insulates you from changes to the underlying system APIs, creates testable code, and provides clean well-defined points of interaction between subsystems.
      - mseepgood 13y ago
        > They abstract the core concepts out into interfaces that can be implemented atop different APIs This is exactly what systemd's D-Bus API is for.
        anonyfuss 13y ago
        D-bus isn't a software architecture and doesn't somehow magically make systemd more maintainable.
      - bkor 13y ago
        Another layer of abstraction just results in more complicated code, more bugs, more difficulty testing the different code paths. Might be fine for a lot of projects, but this is just something to boot up your system.
        anonyfuss 13y ago
        > Another layer of abstraction just results in more complicated code, more bugs, more difficulty testing the different code paths. No. A proper approach to abstraction: - Reduces complexity by reducing interdependency between subsystems. - Facilitates testing by reducing interdependency between subsystems, and reduces bugs by facilitating testing. - Allows for iterating components of the code base independently, and more easily adapting to changes to underlying components and subsystems, whether in the software themselves, or part of the system(s) the software relies on. > Might be fine for a lot of projects, but this is just something to boot up your system. Actually, this isn't just something to boot up your system (and if it was, it would be even easier to keep portable). Instead, systemd a kitchen-sink-replace-everything-daemon that introduces massive cross-system/cross-module dependencies.
noselasd 13y ago
Because, as the parent said, as higher level projects, starts requiring systemd, the BSDs will either have to port over systemd and replace their init system, or keep around patches to go around systemd requirments for every application that needs it. Neither is desirable and would take non-trivial effort.
jeltz 13y ago
Because (as qznc stated) they are worried that various applications will start to rely on systemd features so that BSD either will have to maintain a compatibility layer or be stuck with old software.

bitwize 13y ago

Nobody cares about the old, portable, loosely coupled Unix Way of developing software. That's just not how modern apps are written anymore.

anonyfuss 13y ago
That's the way Mac OS X is written. They certainly haven't bundled the entire universe into a single master "system daemon" project. A few, off the top of my head: configd: A configuration store that handles storing (and monitoring changes to) configuration. It supports arbitrary plugins, such that other dependent systems can inject their own implementation code if necessary. It depends on kernel notification APIs and network notification APIs that are implemented at a different level. launchd: Starting/stopping/restarting services, on-demand and on a schedule, per-user and system-wide. diskarbitrationd: Handles mounting/unmounting of file systems, and notifies clients of changes to mounted file systems. opendirectoryd: Handles namespacing of local and remote user/data directories. This includes LDAP, local user accounts, etc. mDNSResponder: Used to be just the mdns daemon, now handles all name resolution and local caching. All of these things have been iterated on independently over time, are loosely coupled with each other, and do not create tight bindings between Mac OS X and open source software, nor do they require huge non-portable changes to open-source software. The precursor to opendirectoryd was netinfo, which also used to handle name resolution and caching. Later releases of Mac OS X moved name resolution into directory services, and then eventually into mDNSResponder. launchd replaced system starter (similar to initd/rc), cron, and a number of other services, but maintained 'perfect' backwards compatibility with the standard configuration file formats (eg, crontab(5)). These are just a few of the (independently maintained, internally) projects/daemons that Mac OS X layers together to produce the desktop. You don't need a huge monolthic project to tackle all these problem domains, as evidenced by the fact that Mac OS X works. You also benefit from laying these projects cleanly, as it allows them to tackle what they're good at, provide a stable interface, or even be swapped out entirely later.
- bitwize 13y ago
  That's the way Mac OS X is written. They certainly haven't bundled the entire universe into a single master "system daemon" project. Actually, launchd replaces init, inetd, crond, atd, and watchdogd. I mean where do you think systemd got the idea from? :)