Debian developer prompted to revisit FreeBSD after 20 years
changelog.complete.org
Debian developer prompted to revisit FreeBSD after 20 years
1–10 of 113 posts
Re: Debian developer prompted to revisit FreeBSD after 20 years
#2Apparently this is because FreeBSD has nothing like Linux’s inotify.
It has kqueue, which is a generic event mechanism that can take the place of inotify, signalfd, eventfd, timerfd and others on Linux systems. It has a bit of a learning curve, but it's actually neat.
Concerning platform support, that has always been NetBSD's shining ground.
Re: Debian developer prompted to revisit FreeBSD after 20 years
#3Apparently this is because FreeBSD has nothing like Linux’s inotify. It has kqueue, which is a generic event mechanism that can take the place of inotify, signalfd, eventfd, timerfd and others on Linux systems. It has a bit of a learning curve, but it's actually neat. Concerning platform support, that has always been NetBSD's shining ground.
I dont think kqueue fulfils the need of listening on file system events. Mac OSX has FS Events, to fill the need of inotify. Kqueue is more of a replacement for Epoll and works consistently across all file descriptors, not necessary for listening events on file paths.
Re: Debian developer prompted to revisit FreeBSD after 20 years
#4Apparently this is because FreeBSD has nothing like Linux’s inotify. It has kqueue, which is a generic event mechanism that can take the place of inotify, signalfd, eventfd, timerfd and others on Linux systems. It has a bit of a learning curve, but it's actually neat. Concerning platform support, that has always been NetBSD's shining ground.
I dont think kqueue fulfils the need of listening on file system events. Mac OSX has FS Events, to fill the need of inotify. Kqueue is more of a replacement for Epoll and works consistently across all file descriptors, not necessary for listening events on file paths.
Please google the kqueue man page. There's many filters for kqueues. Specifically look at the VNODE filter.
Here's the link: https://www.freebsd.org/cgi/man.cgi?query=kqueue&sektion=2
You want to watch a directory? Open it and register it with the VNODE filter. You can watch a file for delete, rename, extend, write etc. OpenBSD can even watch TRUNCATE events.
You can use a kqueue filter for userspace events between threads, timers, signals, process states, asynchronous io, writability, and readability of fds.
It's quite generic and fairly evenly supported across BSD derivatives including Mac OS X.
Re: Debian developer prompted to revisit FreeBSD after 20 years
#5Apparently this is because FreeBSD has nothing like Linux’s inotify. It has kqueue, which is a generic event mechanism that can take the place of inotify, signalfd, eventfd, timerfd and others on Linux systems. It has a bit of a learning curve, but it's actually neat. Concerning platform support, that has always been NetBSD's shining ground.
I dont think kqueue fulfils the need of listening on file system events. Mac OSX has FS Events, to fill the need of inotify. Kqueue is more of a replacement for Epoll and works consistently across all file descriptors, not necessary for listening events on file paths.
Re: Debian developer prompted to revisit FreeBSD after 20 years
#6Apparently this is because FreeBSD has nothing like Linux’s inotify. It has kqueue, which is a generic event mechanism that can take the place of inotify, signalfd, eventfd, timerfd and others on Linux systems. It has a bit of a learning curve, but it's actually neat. Concerning platform support, that has always been NetBSD's shining ground.
kqueue replaces select/poll/epoll/etc as well. It really is your one-stop event handling call.
Re: Debian developer prompted to revisit FreeBSD after 20 years
#7The article makes some good points, and I'm glad it didn't just rail on one single part/component since linux distrobutions have so much variety. ZFS is really a killer FS, and unfortunately Linux just doesn't have a native answer just yet (although BtrFS does have some promising parts).
There's a lot of people either threatening to switch or are switching to one of the BSD's as a result of being dissatisfied with the systemd debate outcome -- apparently not realizing FreeBSD (and others) are in the early stages of working on their own systemd/launchd-like init system. Everyone seems to realize the need for a more modern init system...
Re: Debian developer prompted to revisit FreeBSD after 20 years
#8Apparently this is because FreeBSD has nothing like Linux’s inotify. It has kqueue, which is a generic event mechanism that can take the place of inotify, signalfd, eventfd, timerfd and others on Linux systems. It has a bit of a learning curve, but it's actually neat. Concerning platform support, that has always been NetBSD's shining ground.
This is true but not entirely accurate. The use case that he's mentioning, an application like Dropbox, that relies on a good file system watcher wouldn't be totally feasible with kqueue, since you're 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, so it's limited for that use case. And that's also why OS X have FSEvents, because kqueue falls short for some use cases.
I've worked on a multi-platform file system watcher ( https://bitbucket.org/SpartanJ/efsw ), and i must say that the kqueue implementation was by far the worst to work at. On the other side inotify is super simple and just works ( but sadly it's not recursive like FSEvents and IO Completion Ports ).
Re: Debian developer prompted to revisit FreeBSD after 20 years
#9The article makes some good points, and I'm glad it didn't just rail on one single part/component since linux distrobutions have so much variety. ZFS is really a killer FS, and unfortunately Linux just doesn't have a native answer just yet (although BtrFS does have some promising parts). There's a lot of people either threatening to switch or are switching to one of the BSD's as a result of being dissatisfied with th…
FreeBSD has been in the early stages of working on a launchd port for 10 years now. 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. 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.
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.
The differences in scope between launchd and systemd are pretty big, too.
Re: Debian developer prompted to revisit FreeBSD after 20 years
#10Apparently this is because FreeBSD has nothing like Linux’s inotify. It has kqueue, which is a generic event mechanism that can take the place of inotify, signalfd, eventfd, timerfd and others on Linux systems. It has a bit of a learning curve, but it's actually neat. Concerning platform support, that has always been NetBSD's shining ground.
This is true but not entirely accurate. The use case that he's mentioning, an application like Dropbox, that relies on a good file system watcher wouldn't be totally feasible with kqueue, since you're 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, so it's limited for that use case. And that's also why OS X…
By default, yes. The kern.maxfiles sysctl value can go to the upwards of hundreds of thousands, if I recall correctly.