In Tiger, Apple introduced a new system startup program called launchd. The launchd daemon takes over many tasks from cron, xinetd, mach_init, and init, which are UNIX programs that traditionally have handled system initialization and prepared the system for the user. These venerable programs are widely used by system adminstrators, open source developers, managers of web services, even consumers who want to use cron to manage iCal scheduling, and they can still be called with launchd.
This is typical Apple. Look, we’ve got a ridiculous system here. Let’s sort it out and simplify it.
The question is, will it work? Will existing apps migrate to this new way of doing things (as far as I am ware it is only available in Tiger). Will developers use it for new apps? Will Apple eventually faze out the other systems in order to force developers to this?
I seem to remember Apple saying at some point that this is open source, and that it was their way of giving a bit back to the open source community. They also said that they hoped other people would back-port it to other systems. Does anyone know if anyone’s planning on doing so?
Don’t count on it – at least for linux. It is under APSL – license recognized as ‘free’ by FSF and others but not license fascists like Debian foundation. So at best we will see it used in one or two distributions and five ‘free’ but incomplete replacements fighting for others. Maybe even one of them with all uber-leet depencencies like dbus, hal (what for? no idea, but come on, it sooo coool and makes slashdot crowd all warm and fuzzy inside) will be put on freedesktop.org and heralded as ‘standard’ despite near zero usage.
And of course years will pass until most distro makers will even think about abandoning sucky sysvinit.
Stop the nonsense and half-truth please, are you an astro-turfer or what ?
The FSF recognized APSL as a free software license, but explicitely say :
– it is not a true copyleft
– it is incompatible with the GPL
So it CAN’T be used effectively in a GNU system and they DISCOURAGE anyone to use it in a new project. So no problem for BSD systems. So you’re well worth the Godwin point you gained when calling Debian foundation license fascists.
We will hopefully not see this used in any GNU system, it would be suicide. And there are already alternative to sysvinit that are much more powerful and simple (I use simpleinit-msb).
The combination of simpleinit-msb, fcron (much more powerful and simple than cron) and xinetd are far more simple and powerful than launchd, and they are GPL compatible, which launchd is not.
I say the reviewer must have some guts putting head to head config files from launchd and xinetd. I’ll take the xinetd one any day thanks. Don’t even get started on a cron line : the huge error prone launchd config file equivalent to cron is less than 40 characters in a fcron line (&nice(1) %daily 15 3 /usr/sbin/periodic).
All the advantages cited in the article are already present in the apps I cited above, and even more. So it’s OK for launchd to replace anything in non-GNU systems, but nowhere else.
Oh, another guy with ‘no gpl compatible == evil’ hardwired into brain. It is free license – you can hack the source, fork it, whatever. So what if it is not GPL compatible? Are you going to link your application with launchd or what?
Senseless comment about how it cannot be used effectively in GPL system only show you complete lack of understanding how licenses work.
Oh, another guy with ‘no gpl compatible == evil’ hardwired into brain.
Actually, you are the one with a hatred for the GPL. I never said once that not GPL compatible == evil, I never even said anything about any system being evil. I only made the distinction between GNU systems and others. YOU are the one trying to put words I didn’t say in my mouth.
It is free license – you can hack the source, fork it, whatever.
This I acknowledged …
So what if it is not GPL compatible? Are you going to link your application with launchd or what?
It’s meant to replace GPL compatible, perfectly working, and well tested programs, that is my problem.
If you can’t understand the stupidity of replacing such solutions with one not GPL compatible, more complicated to configure and not as well tested, well, too bad.
Senseless comment about how it cannot be used effectively in GPL system only show you complete lack of understanding how licenses work.
It has far more sense that you think. The problem is not apparent right now fortunately, because glibc and PAM (which fcron uses for example) are LGPL. But as soon as we try to communicate with dbus, udev, and fcron for example, we have practical problems with launchd, and none with fcron or xinetd.
I don’t talk about init because init should be as lightweight as possible (launchd is not), and not link more than libc.
I am the one with hatred toward GPL? Man, you must have troubles with reading. I simply have knowledge about licensing that goes beyond your simplistic GPL==teh r0x0r view.
Your “distinction” between GPL system and others obviously makes no sense – for example Mozilla and Apache licenses are incompatible with GPL. Yet nobody has problems with including Apache or Mozilla in GPL system. Please, try to do something with your ignorance before commenting further.
Your example with dbus is as idiotic as rest of them – from dbus faq, question 3: “The short answer is yes, you can use it [dbus] in proprietary applications.” . See? Your application does not need to be even free. I’m not even going to comment on supposed ‘problems’ with using udev, if you had any idea what is it and how other parts of system interact with it, you would not have written all this garbage.
Fcron? Dude, launchd is fcron replacement.
If you don’t like launchd linking to other libraries, link it statically and stop whining.
I simply have knowledge about licensing that goes beyond your simplistic GPL==teh r0x0r view.
Good. Though I don’t understand the part about my view of the GPL as the best for me as being simplistic.
It’s just a choice, entirely legitimate I made for myself. I do not impose it on others.
Your “distinction” between GPL system and others obviously makes no sense – for example Mozilla and Apache licenses are incompatible with GPL.
I’m bound to repeat myself indefinitely with you : Apache and Mozilla are not core OS components like init is or cron can be, which launchd wants to replace. So I doubt it’s as obvious as you make it …
Yet nobody has problems with including Apache or Mozilla in GPL system.
I don’t either. They are not core OS compponents anyway. You could have cited Xinetd which has a licence incompatible with the GPL.
Your example with dbus is as idiotic as rest of them – from dbus faq, question 3: “The short answer is yes, you can use it [dbus] in proprietary applications.” . See? Your application does not need to be even free.
My bad, but where you think I was idiotic, I rather think that I was uninformed. You just added more weight to my concerns. So now I know you can use DBUS with launchd … making DBUS licensed under the AFL. Looks like a mess, but viable.
I’m not even going to comment on supposed ‘problems’ with using udev, if you had any idea what is it and how other parts of system interact with it, you would not have written all this garbage.
So sth is false in your logic, as I do well know what udev is. What I was talking about is the combination of dbus, hal and udev. You do now that to be efficient, the three (part of Project Utopia) must have some dialog, right ?
Fcron? Dude, launchd is fcron replacement.
No it’s not. Not as long as it does not support PAM.
If you don’t like launchd linking to other libraries, link it statically and stop whining.
I have no problem with all these licensing terms, no problems other than the one I stated already.
My problem right now is not about licensing (I said there is no problem today), but rather with the inferior functionality of launchd compared to what I use right now. So I have no incentive to use it, and the licensing does not help on a GNU system, though I understand the need for such a license and applaud Apple efforts.
a SoC (Summer of Code) for FreeBSD is doing a port.
See
http://wikitest.freebsd.org/moin.cgi/launchd
And i think that’s a good except perhaps for cron but time will say if it’s good.
Like it or not this is the way startup systems are evolving. I have not had a chance yet to look at launchd in detail, but it looks like a cross between the AIX System Resource Controller and Solaris Service Manager. In fact it looks a lot cleaner than the AIX src which has to mess with ODM, inittab and rc scripts on bootup.
Apple is playing with the big boys and I think they can show them a thing or two. Seems like dependancies could be simpler/better though.
Another good article launchd in depth : http://www.afp548.com/article.php?story=20050620071558293
I believe one of Google’s Summer of Code projects for either FreeBSD or NetBSD (I forget which) was to get it to use Apple’s launchd. I’m not sure what the outcome of that is, however.
IIRC, the FreeBSD project is interested in launchd too (they will probably use the one currently being developed for NetBSD).
I am totally wrong!
As it was pointed out, it is developed for FreeBSD.
(I was thinking about Zeroconf, in fact; another thing used in MacOS X that is developed for NetBSD as part of SoC).
Silly me.
Look at listings 2 and 3 in the article: the xinetd config file (a list of assignments, immediately intelligible); and its launchd counterpart (an XML file, 3 times longer, full of tags). To quickly see what is happening, the XML must be studied carefully, or run through XSLT, CSS or (most likely) viewed with a specialised GUI tool. Don’t bother with `grep disable /etc/xinetd.d/*`.
The real problem with launchd in my opinion is that it is not the UNIX way of doing things. Launchd seems to be a whole bunch of services rolled up into one program. This is at odds with the UNIX philosophy where a program should do one thing and have the ability to interface with other programs, usually via text. With launchd when one aspect is modified it will affect everything else. When there is a bug in launchd it could affect numerous services instead of just one. These all-in-one type programs create more complexity and reduce security.
Nonsense. Just because the subsystem evolved to have many similar daemons that launch things, doesn’t mean it’s the best way. When it comes down to it, cron, inetd, etc have more in common than not and combining them reduces complexity and saves memory. It’s not an all-in-one, it’s a daemon that launches other programs based on system events. Why do you need a daemon for each kind of event?
When it comes down to it, cron, inetd, etc have more in common than not and combining them reduces complexity and saves memory. It’s not an all-in-one, it’s a daemon that launches other programs based on system events. Why do you need a daemon for each kind of event?
I wouldn’t want my cron program to be the same as my init program. What if the “cron” portion of launchd gets exploited? Now your init is also vulnerable. What happens when you decide to overhaul the “init” part of the code? Now bugs are not only introduced into your init application but also your cron application. Launchd is too all-encompassing for my likes. Exactly why does something that launches startup scripts have to be same as something that executes scheduled commands? How does this save memory when init only has to run once. Now the larger launchd program has to run all the time to schedule cron jobs and other things.
You sure they’re not licence communists?
I mean, let’s get real. “freedom” is a joke to either type of ideologue………(except the freedom to have an overbearing government) Do it my way or I kill you.
Just…… figured I’d bring it up. 🙂
Actually, I like having 9 million daemons.
gotta have one for each letter on my keyboard you know!
http://arstechnica.com/reviews/os/macosx-10.4.ars/5
http://arstechnica.com/journals/apple.ars/2005/7/5/623
I like it i would to see it added to FreeBSD
Mr. R. Tyler Ballance is already working on it as part of SoC, it will be likely ready for FreeBSD 6.1, see http://wikitest.freebsd.org/moin.cgi/SummerOfCode2005 for more.
HTH, Daniel
Religious license issues aside, it seems to me Apple is working to improve on the system. If one launch service works exceptionally well [and the fact that it works well is an unadulterable prerequisity] I can’t see why it would be not more elegant than having a lot of services running, some of which can be launched in three separate ways.
No doubt there have been reasons to do this and they are going to perform their function well, but if it can be streamlined into a better working service, I don’t see how that can be a good idea.
Besides, there is an added layer of security by allowing non-root to launch apps that do not get their grubby little hands on root systems. How is adding more security less secure [always assuming that the functionality is competently and properly implemented]?
Apple is doing what is should be doing. It makes a whole lot of fun stuff but it is also a systems builder and it is constantly working on building a better system.
I can think of ways to reason why this is just another load of hooiee on the part of Apple, but that line of thinking is so old, SO old.
The better approach is to examine what they are offering, tell them where they went wrong [if they went wrong] and appreciate a systems builder whose trying to build a better system.
A launcher that controls how jobs are launched, unloads jobs that don’t need to be running and reloads them as required and allows starting jobs without “@ requires you to restart your system” is a smart extension of the functionality. And if it is then offered through Open Source licensing [Hey minefield, I’m going to jump around to see if something explodes, ok?] so that other systems can use it to improve on their functionality, I would be curious to hear an argument why this is evil and bad.
If you start a flame war, do include references to my ancestral heritage and the inherent lack of intelligence therein to prove why I’m wrong. Those are always fun to read. Thanks.
If one launch service works exceptionally well I can’t see why it would be not more elegant than having a lot of services running, some of which can be launched in three separate ways.
That’s because the premise that the 3 launch services do the same thing is false : they don’t.
Init is the only one that is mandatory on a Linux system. It has mechanisms to launch services and restart them automatically if they crash. It is the only one with this functionality, which is necessary to apps that take VTs.
Cron is the only one that can schedule jobs (with at in fact), and xinetd is the only one that can launch services on demand. Cron and xinetd are not mandatory, and even worse, can need ressources that are NOT available when init starts. This is typically the case with my setup, where /usr is not even available when init starts.
No doubt there have been reasons to do this and they are going to perform their function well, but if it can be streamlined into a better working service, I don’t see how that can be a good idea.
So the question becomes : can it be streamlined ? In my case it can’t.
Besides, there is an added layer of security by allowing non-root to launch apps that do not get their grubby little hands on root systems. How is adding more security less secure ?
Where is the added security ? I don’t understand, because init has to be launched as root, which means any replacement should have to be launched as root too.
Apple is doing what is should be doing. It makes a whole lot of fun stuff but it is also a systems builder and it is constantly working on building a better system.
I agree with that.
The better approach is to examine what they are offering, tell them where they went wrong [if they went wrong] and appreciate a systems builder whose trying to build a better system.
The problem is they are not wrong. It’s just that their new program does not integrate well with GNU systems, which already have better alternatives.
A launcher that controls how jobs are launched, unloads jobs that don’t need to be running and reloads them as required and allows starting jobs without “@ requires you to restart your system” is a smart extension of the functionality.
It is not an extension, all of these functionalities are already available, in softwares compatible with the GPL. This has its importance when using a GNU system. It has none on a BSD system, that’s why I said that it poses no problem on non-GNU systems, except the fact that often, better alternatives already exist.
And if it is then offered through Open Source licensing so that other systems can use it to improve on their functionality, I would be curious to hear an argument why this is evil and bad.
It is not evil nor bad, the guy who responded thought it was, but I never said such thing. It is just inconvenient in a GNU system (how many times will I have to repeat this). It does not improve anything either. I mean, it is no better than the simpleinit-msb I use now, which have even more functionalities and is simpler (unless you think XML is simpler than a shell script).
Ookaze
It is just inconvenient in a GNU system
How?
As has been pointed out before, you’re not linking anything to launchd and so the GPL clause regarding that simply doesn’t come into the equation.
And must I remind you that plenty of non-“GPL-compatible” but free software already is part of your average Linux distribution, including Debian?
This just sounds like a case of not-invented-here syndrom.
Sigh. I already answered that.
It is not really a problem now, because most of the program this aims to replace link to LGPL libs (like PAM). But it can be in the future when, for example, the cron process links to dbus (most likely possibility).
I have non GPL compatible softwares on my system as well, but they have no GPL equivalent, and most of all, they are not very important base infrastructure of the system like a replacement of init is.
Like I said already, the tools I use are more powerful than launchd. If it can’t plug with PAM, it can not replace my fcron. If it can’t link to tcp_wrapper, it can not replace my xinetd. Only thing it could replace is my simpleinit-msb, and even that is already more powerful and simpler to configure than launchd. So there’s no case of NIH in my case at least.
A similar tool being Free Software would not have any more meaning to me. Just because it’s from Apple does not mean it is better than the tools already existing.
But for Apple, sure it’s better. Perhaps even for BSD, especially if they do not intend to use DBUS.
Ookaze