Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Debian developer prompted to revisit FreeBSD after 20 years

changelog.complete.org

Post reply on HN
Print view View original

11–20 of 113 posts

Re: Debian developer prompted to revisit FreeBSD after 20 years

#11

Post by throwabob214 »

SpartanJ wrote: post #8
vezzy-fnord wrote: post #2

Apparently 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…

> 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...

Re: Debian developer prompted to revisit FreeBSD after 20 years

#12

Post by eleitl »

He seems to think in his comparison Debian comes on top.

However, the points which he thinks are where Debian is stronger illustrate precisely where Linux has lost its way. Laptop support is lacking -- assuming you care about laptops, and care about suspend working out of the box. Guess what, suspend didn't work out of the box under Debian, either.

Storage, he's forgetting that zfs is both a filesystem, and a volume manager.

Support of alien file systems, really? Irrelevant for servers, for everything else mount it via NFS.

Virtualization -- between jails and Virtual Box (on desktops) what is the use case for a different product here?

Nothing like Dropbox -- that's not a bug, it's a feature.

Desktop environments need configuration -- why I am migrating from Linux, you think? If I already have to use alternative window managers and desktops on Linux, where is the big difference?

Package managers, now that is a good point. XML config, that too. Nigh everything else is missing the point.

Re: Debian developer prompted to revisit FreeBSD after 20 years

#13

Post by throwabob214 »

vezzy-fnord wrote: post #9
Alupis wrote: post #7

The 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. IMH…

> 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.

It's going to happen soon. :-)

Re: Debian developer prompted to revisit FreeBSD after 20 years

#14

Post by lutoma »

eleitl wrote: post #12

He seems to think in his comparison Debian comes on top. However, the points which he thinks are where Debian is stronger illustrate precisely where Linux has lost its way. Laptop support is lacking -- assuming you care about laptops, and care about suspend working out of the box. Guess what, suspend didn't work out of the box under Debian, either. Storage, he's forgetting that zfs is both a filesystem, and a volume…

> Nothing like Dropbox -- that's not a bug, it's a feature.

What a horribly arrogant and conceited thing to say.

Re: Debian developer prompted to revisit FreeBSD after 20 years

#15

Post by [deleted] »

SpartanJ wrote: post #8
vezzy-fnord wrote: post #2

Apparently 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…

[deleted]

Re: Debian developer prompted to revisit FreeBSD after 20 years

#16

Post by throwabob214 »

vezzy-fnord wrote: post #10
SpartanJ wrote: post #8

Earlier quoted context omitted.

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.

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.

Re: Debian developer prompted to revisit FreeBSD after 20 years

#17

Post by tobik »

SpartanJ wrote: post #8
vezzy-fnord wrote: post #2

Apparently 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…

kern.maxfiles=782036 on FreeBSD 10.1 here and I have not changed the default at all. So it seems it is not set to 10000 by default anymore.

Edit: It seems to be set dynamically depending on available memory at boot. See http://fxr.watson.org/fxr/source/kern/subr_param.c#L266

Re: Debian developer prompted to revisit FreeBSD after 20 years

#18

Post by SpartanJ »

throwabob214 wrote: post #11
SpartanJ wrote: post #8

Earlier quoted context omitted.

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…

> 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 w…

> 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!

Re: Debian developer prompted to revisit FreeBSD after 20 years

#19

Post by SpartanJ »

tobik wrote: post #17
SpartanJ wrote: post #8

Earlier quoted context omitted.

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…

kern.maxfiles=782036 on FreeBSD 10.1 here and I have not changed the default at all. So it seems it is not set to 10000 by default anymore. Edit: It seems to be set dynamically depending on available memory at boot. See http://fxr.watson.org/fxr/source/kern/subr_param.c#L266

Well... that's great! :)

May be it was PC-BSD, i don't have it installed right now, so i can't say it with certainty. But that number looks just enough.

Re: Debian developer prompted to revisit FreeBSD after 20 years

#20

Post by vezzy-fnord »

lutoma wrote: post #14
eleitl wrote: post #12

He seems to think in his comparison Debian comes on top. However, the points which he thinks are where Debian is stronger illustrate precisely where Linux has lost its way. Laptop support is lacking -- assuming you care about laptops, and care about suspend working out of the box. Guess what, suspend didn't work out of the box under Debian, either. Storage, he's forgetting that zfs is both a filesystem, and a volume…

> Nothing like Dropbox -- that's not a bug, it's a feature. What a horribly arrogant and conceited thing to say.

It's also wrong. FreeBSD supports the best there is: Tarsnap.
Post reply on HN