- 37comments
- 288comments
- 80comments
- 97comments
- 177comments
- 23comments
- 34comments
- 318comments
- 467comments
- 123comments
- 19comments
- 290comments
- 384comments
- 3comments
- 33comments
- 109comments
- 26comments
- 17comments
- 568comments
- 12comments
- 17comments
- 15comments
- 41comments
- 20comments
- 121comments
- 9comments
- 39comments
- 3comments
- —discuss
- 2comments
They don't have to use it exactly as OSX uses it
It's not doing all of that stuff in pid 1
Even on OSX it's not all done in PID 1; the post isn't quite right about that. I believe plist parsing is done by launchctl, not in launchd itself.
FBSD: I was just dealing with circular dependency hell (or misunderstanding of docs/conventions) in some rc.d scripts.
Maybe someone here knows how to do this properly (or better):
^--- REQUIRE: ... NETWORKING always seems to cause a circular dependency (as per running: rcorder /etc/rc.d/* /usr/local/etc/rc.d/*)
Help appreciated, not required, just showing a real-life example.
did you open a bug? this should be fixed in the port, not on your local machine.
Mmm. Unix like OS with controversy newly swirling about init replacement. Déjà vu.
I hope the experience is less filled with tedious "mah Unix philosophy" for the BSD community than it was for the Linux community, but I wouldn't hold my breath.
The linked article is fortunately not really in that genre. It's criticizing the specific proposal in a reasonable amount of detail, not just vaguely criticizing the abstract idea of launchd for being allegedly "not unix enough". The main thrust of the criticism is that wholesale porting over the OSX services layer to FreeBSD produces a poor fit, because a lot of the OSX design is designed for a different purpose: as developer-facing tools used to configure/ship a desktop/laptop OS, not sysadmin-facing tools used on servers. Also, it's all tied up with Mach in a way that is fine if you're running Mach (as OSX is), but drags in a lot of baggage for FreeBSD.
Then again, Launchd seems to know its limits...
Doesn't the design philosophy of a complex piece of software matter? Doesn't consistency of philosophy provide power by enabling separate pieces to integrate smoothly?
There's a legitimate discussion about tradeoffs to be had, sure. But at least since Fred Brooks it's been quite clear that conceptual integrity is valuable. And the concepts behind Unix have been shown to be consistent and powerful; Plan 9 demonstrated that there's still unexploited potential there.
The Unix philosophy argument may be wrong in a particular case, but it shouldn't be derisively dismissed.
Well, Jordan Hubbard outlines some quite good things about what's going on and why in the video: http://www.nextbsd.org/jordan-hubbard-visits-bafug/
Certainly, this is not without controversy. However, it seems like Hubbard has pissed off far fewer people than Lennart did, so his ideas are likely to get a much more receptive response and actual technical discussion beyond "Lennart wrote it so I hate it.". In addition, Hubbard and co are likely to have learned from the systemd fiasco, and other *BSD systems have written some other solutions in this space. These ideas are falling on relatively fertile ground.
However, the FreeBSD leadership will occasionally make a decision and tell people to get stuffed if they don't agree. I would cite the GEOM changeover, in particular. People forget the vitriol that accompanied it now that it has been well integrated.
I know I shouldn't feed the trolls... But
https://www.freebsd.org/cgi/man.cgi?query=init&apropos=0&sek...
Not sure what you're trying to say. Launchd may not be a 100% function for function equivalent for init(8), but it does replace it, along with the rc subsystem.
"launchd(8) replaces: init, rc, the init.d and rc.d scripts" (source: https://wiki.freebsd.org/launchd)
You are right. I was drawing on quite old knowledge regarding the OS-X boot process in thinking launchd worked in collaboration with init(8) and friends. Apparently, it has been this way for some time[1].
I have been aware of launchd replacing rc.d since its introduction. What I did not realize is that it supplanted init as PID 1. Knowing that this is the case, I am less likely to support its adoption FWIW.
1 - http://aplawrence.com/Words2005/2005_05_15.html