Linked by Thom Holwerda on Fri 30th Apr 2010 18:41 UTC, submitted by diegocg
Linux Via LWN: "Lennart Poettering has put up a lengthy post describing the 'systemd' project, which is creating a new init system. The whole thing is an interesting discussion of how system initialization should work. Upstart maintainer Scott James Remnant has posted a response to the announcement."
Thread beginning with comment 421853
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[2]: launchd
by foobaz on Fri 30th Apr 2010 20:39 UTC in reply to "RE: launchd"
foobaz
Member since:
2009-12-05

The article points out a few shortcomings in launchd, but admits it does most of what he wants just fine. His only concrete objections are (1) not all existing daemons would be compatible with launchd, and (2) launchd is not flexible enough to do everything he can conceive.

I believe it would be wiser to use a working, release-quality codebase than to write something from scratch. If more backwards compatibility is needed, it would be much simpler to add this functionality to launchd - there is nothing in its architecture to prevent this. And to answer his second objection, sure, launchd is not perfect, but it's much, much better than init/cron/inetd/xinetd/whatever.

Plus, if Linux adopted launchd, daemons could be written to be compatible with both Linux and OS X, and developers from both communities could contribute to the further development of launchd. Both OSs would benefit from sharing an open standard.

Reply Parent Score: 3

RE[3]: launchd
by Rahul on Fri 30th Apr 2010 20:46 in reply to "RE[2]: launchd"
Rahul Member since:
2005-07-06

Well talk in cheap and the blog does talks about the advantage of being platform specific. If you want to talk to the author and get to know more details, the blog post is open for comments :-)

Reply Parent Score: 1

RE[3]: launchd
by Zifre on Fri 30th Apr 2010 21:12 in reply to "RE[2]: launchd"
Zifre Member since:
2009-10-04

His only concrete objections are (1) not all existing daemons would be compatible with launchd, and (2) launchd is not flexible enough to do everything he can conceive.

He also says that launchd is a bit Mac specific.

I believe it would be wiser to use a working, release-quality codebase than to write something from scratch. If more backwards compatibility is needed, it would be much simpler to add this functionality to launchd - there is nothing in its architecture to prevent this.

If systemd had not been written yet, maybe it would have been easier to adapt launchd. However, systemd already works reasonably well, and it might take less work to complete systemd than to adapt launchd to Linux.

Plus, if Linux adopted launchd, daemons could be written to be compatible with both Linux and OS X, and developers from both communities could contribute to the further development of launchd. Both OSs would benefit from sharing an open standard.

I agree. However, the daemon requirements for systemd and launchd are very similar, and it should take little or no work to make daemons work on both systems.

Reply Parent Score: 2

RE[3]: launchd
by vivainio on Fri 30th Apr 2010 22:18 in reply to "RE[2]: launchd"
vivainio Member since:
2008-12-26


I believe it would be wiser to use a working, release-quality codebase than to write something from scratch. If more backwards compatibility is needed, it would be much simpler to add this functionality to launchd - there is nothing in its architecture to prevent this. And to answer his second objection, sure, launchd is not perfect, but it's much, much better than init/cron/inetd/xinetd/whatever.


To modify launchd, they would either have to fork it or co-operate with Apple. It may be that Linux-specific modifications are not something they want in Apple codebase.

Reply Parent Score: 3

RE[4]: launchd
by darknexus on Sat 1st May 2010 06:08 in reply to "RE[3]: launchd"
darknexus Member since:
2008-07-15

Yes, launchd at the moment is heavily dependent on OS X frameworks. Even though it's the core system process, it still makes heavy use of OS X APIs and libraries, and porting it to Linux would be quite the task.

Reply Parent Score: 2