> Right now, there's only a single package repository for each major FreeBSD release. The ABI doesn't normally change within major releases, so packages built on FreeBSD 10.0 will work on FreeBSD 10.1 (and vice verse).
And it's worth pointing out that the per-branch repositories are all built from the same sources — ports is not branched. The only reason to have separate release-branched binary repositories is for ABI bumps between stable releases.
Practically the limits are INT_MAX, the size of the process file descriptor table in-kernel. (And possibly a system limit on vnodes? Just guessing.) 2 billion fds makes for a lot of memory used for open files.
> FreeBSD has been in the early stages of working on a launchd port for 10 years now.
There were several half-serious individual efforts, but I don't think the community / foundation were pursuing it seriously until quite recently. Kip Macy has been working hard to get it in as an init replacement recently.
> It seems like progress with openlaunchd is going well, but there are certain things related to Mach IPC that need to be ported to the upstream FreeBSD kernel to get it working.
The mach stuff has been ported (recently), again by Kip Macy.
> I do recall some old version of launchd entitled launchd_xml was ported to pfSense, but it's one that puts the XML parser into PID1, so it's not desirable.
Right. I think the current plan is that the parsing is done in another process and then IPC'd to launchd via Mach. Or the plist stuff could be replaced with a 'libucl' parser that is safer in init? I'm fuzzy on these particular detail, sorry.
> IMHO, I wouldn't count on any major init changes in FreeBSD any time soon. It's been protracted enough already, and Jordan Hubbard giving a pep talk doesn't mean all that much. I could very well be mistaken.
>> FreeBSD has been in the early stages of working on a launchd port for 10 years now.
> There were several half-serious individual efforts, but I don't think the community / foundation were pursuing it seriously until quite recently. Kip Macy has been working hard to get it in as an init replacement recently.
This is because iXsystems (Jordan Hubbard) hired Kip to implement it for FreeNAS (and, presumably PC-BSD), not because the FreeBSD community thinks it needs a new init system.
Jordan also has plans to bring other large pieces from Apple to FreeBSD.
> This is because iXsystems (Jordan Hubbard) hired Kip to implement it for FreeNAS (and, presumably PC-BSD),
I believe EMC Isilon has also sponsored the work.
> not because the FreeBSD community thinks it needs a new init system.
Right. Kip is working on it because someone hired him too. But practically, this is how large-scale efforts get done. Some FreeBSD-using corporation hires / builds out a larger project in a way that is acceptable to the community and it is incorporated into base.
I do think the community has come to more or less that consensus at this point, though. The camp that is fine with /etc/rc hasn't started raising loud complaints about the idea incorporating a backwards-compatible launchd to replace rc.
> pretty much limited by the number of open file descriptors the OS allows to handle, if i don't remember wrong this number in FreeBSD is below 10000 by default
And on Linux inotify is bound by /proc/sys/fs/inotify/max_user_watches. Six of one, half dozen the other. FreeBSD file descriptor limit is arbitrary and can be raised to INT_MAX (2 billion). That should be plenty.
> i must say that the kqueue implementation was by far the worst to work at.
I agree that the kqueue API is a pain to work with. I haven't tried to do a recursive file monitoring (dropbox-alike) application with it.
It seems easy to implement inotify as a thin wrapper around kqueue. Maybe something to do for the FreeBSD linuxulator layer...
> And on Linux inotify is bound by /proc/sys/fs/inotify/max_user_watches. Six of one, half dozen the other. FreeBSD file descriptor limit is arbitrary and can be raised to INT_MAX (2 billion). That should be plenty.
Yes, on Linux you're limited to max_user_watches, and you can edit that value, just like you say with kqueue... but you need root access, so for end user applications this is not really a solution.
With inotify i use one watch per-folder, with kqueue you need to do it by file ( of course you can watch the folder changes, but you need to keep a copy of the file states in that folder, and then re-stat that files to find out what file was changed, not even close to an ideal solution ). So for example in my use case with inotify i can watch 65536 folders, and with kqueue less than 10000 files ( that could be a single folder! ).
Edit:
It seems that FreeBSD default a much bigger number for FDs ( https://news.ycombinator.com/item?id=9063893 ), so that should suffice a lot of use cases, that's good news for me!
> With inotify i use one watch per-folder, with kqueue you need to do it by file ( of course you can watch the folder changes, but you need to keep a copy of the file states in that folder, and then re-stat that files to find out what file was changed, not even close to an ideal solution ). So for example in my use case with inotify i can watch 65536 folders, and with kqueue less than 10000 files ( that could be a single folder! ).
Ah, I looked at inotify API briefly and did not notice that directory watches return file changes. That does make it easier to use than kevent vnode watches. Mea culpa.
And it's worth pointing out that the per-branch repositories are all built from the same sources — ports is not branched. The only reason to have separate release-branched binary repositories is for ABI bumps between stable releases.