
Introducing the launch_daemon - Tomte
https://www.haiku-os.org/blog/axeld/2015-07-17_introducing_launch_daemon
======
vezzy-fnord
Good to see this. Article was killed because of a new/penalized submitter last
time.

I'm actually not a big fan of the launchd architecture, though Haiku's
spiritual equivalent still sounds nice. It's good to see different ways of
solving this problem, even if launch_daemon doesn't bring much in the way of
novelty. The config syntax beats XML plists.

~~~
yalogin
Out of curiosity, what are your complaints about the launchd architecture?

~~~
thaumaturgy
Here are my peeves. None of them are really things that make me actively hate
launchd, they're just things that I think could be done better.

1\. Too many different launchd file locations. See for instance
[http://stackoverflow.com/questions/18502705/how-to-know-a-
sp...](http://stackoverflow.com/questions/18502705/how-to-know-a-specifix-
launchd-plist-file-location) \-- this can make it difficult to troubleshoot a
startup issue or get a handle on what is and isn't being started and when.

2\. .plist files are a binary format, ostensibly to save space, which seems a
little bit ridiculous on an operating system like recent versions of MacOS X.
So you have to use a separate set of tools just to interact with them. This
also means that it's harder to fix corruption of .plist files or troubleshoot
strange values they may have; in a plain text format, you'd just open it up in
vi or emacs or whatever, and if you know what you're doing, you could find and
fix anything that doesn't make sense.

3\. The XML format in general isn't a very nice way to handle configuration
files. Unless you've got syntax highlighting, it's hard to read.

4\. Complex declarative configuration files aren't my favorite thing
regardless, because it's hard to know what your options are and what the right
values for those options are. With simple configuration systems where there is
are several sets of values, and each set of values has the same half-dozen or
so options, it's not so bad. But, in cases where you can have hundreds of
different options, and not all of them documented well, an optimal
configuration can turn in to a bit of black magic.

I guess maybe #4 doesn't really apply directly to .plists, since they're not
intended to be edited by the user, they're intended to just be for application
developers. But I'm not sure that's a point in their favor either.

