3 ms·

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 h

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? :)
- anonyfuss 13y ago
  > Actually, launchd replaces init, inetd, crond, atd, and watchdogd. That's not a "system daemon". Let's break it down: - init: start/stop services - inet: start/stop services - cron: start jobs on a schedule - atd: start jobs on a schedule - watchdogd: restart services Notice the commonality? launchd launches services, possibly on a schedule. > I mean where do you think systemd got the idea from? :) systemd is monolithic and system-invasive in ways that launchd never could be, or that anyone wants it to be. Just take a look at the systemd feature list[1]: Quota handling, swap handling, encrypted disk handling, kernel module loading, graphical UI, syslog replacement, console/keyboard configuration, X11 integration, fsck handling, serial console handling, and more! Systemd is a crazy kitchen sink of a project. It's no wonder that it's non-portable, and I can't imagine trying to evolve the components of a system that came to rely on it. The minute you want to change how an OS subsystem works (eg, such as the automounter), you'll have to dig into the non-portable/non-abstracted systemd code. [1] http://0pointer.de/blog/projects/why.html http://0pointer.de/blog/projects/why.html
  - bitwize 13y ago
    Yes, but... five second boot time! Notice the commonality? launchd launches services, possibly on a schedule. And so does systemd. The other stuff is handled by separate daemons that are part of the overall systemd project. See? Separate processes! That means it's not tightly coupled at all! Personally, I feel that systemd is a shitfest -- so bad I switched back to slackware from Arch, being more than willing to sacrifice bleeding-edge distro releases and dependency management just to avoid it -- and that the unix way is how things should be developed. It's been a while since I've really been on top of Mac OS X internals, but if what you say is true they're doing a much better job of remaining modular and loosely coupled than Lennart has been. But the CADT hivemind has declared the traditional Unix model obsolete. They tend to do a lot of throwing out babies with the bathwater, then rationalize it by saying obviously they were children no one wanted, and aren't we overpopulated enough as it is. I don't think Lennart is particularly innovative in this regard; he learned the game from the GNOME team. When the rationale for your black hole in my /usr/lib is called "Let's Make Unix Not Suck", you know you're a special breed of arrogant.

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? :)

anonyfuss 13y ago
> Actually, launchd replaces init, inetd, crond, atd, and watchdogd. That's not a "system daemon". Let's break it down: - init: start/stop services - inet: start/stop services - cron: start jobs on a schedule - atd: start jobs on a schedule - watchdogd: restart services Notice the commonality? launchd launches services, possibly on a schedule. > I mean where do you think systemd got the idea from? :) systemd is monolithic and system-invasive in ways that launchd never could be, or that anyone wants it to be. Just take a look at the systemd feature list[1]: Quota handling, swap handling, encrypted disk handling, kernel module loading, graphical UI, syslog replacement, console/keyboard configuration, X11 integration, fsck handling, serial console handling, and more! Systemd is a crazy kitchen sink of a project. It's no wonder that it's non-portable, and I can't imagine trying to evolve the components of a system that came to rely on it. The minute you want to change how an OS subsystem works (eg, such as the automounter), you'll have to dig into the non-portable/non-abstracted systemd code. [1] http://0pointer.de/blog/projects/why.html http://0pointer.de/blog/projects/why.html
- bitwize 13y ago
  Yes, but... five second boot time! Notice the commonality? launchd launches services, possibly on a schedule. And so does systemd. The other stuff is handled by separate daemons that are part of the overall systemd project. See? Separate processes! That means it's not tightly coupled at all! Personally, I feel that systemd is a shitfest -- so bad I switched back to slackware from Arch, being more than willing to sacrifice bleeding-edge distro releases and dependency management just to avoid it -- and that the unix way is how things should be developed. It's been a while since I've really been on top of Mac OS X internals, but if what you say is true they're doing a much better job of remaining modular and loosely coupled than Lennart has been. But the CADT hivemind has declared the traditional Unix model obsolete. They tend to do a lot of throwing out babies with the bathwater, then rationalize it by saying obviously they were children no one wanted, and aren't we overpopulated enough as it is. I don't think Lennart is particularly innovative in this regard; he learned the game from the GNOME team. When the rationale for your black hole in my /usr/lib is called "Let's Make Unix Not Suck", you know you're a special breed of arrogant.