14 ms·

Debian developer prompted to revisit FreeBSD after 20 years

198 points by liotier 12y ago

vezzy-fnord 12y ago
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.
- ziahamza 12y ago
  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.
  - leimy2k 12y ago
    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 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.
  - derpsss 12y ago
    https://github.com/libuv/libuv/blob/v1.x/src/unix/kqueue.c#L299 https://github.com/libuv/libuv/blob/v1.x/src/unix/kqueue.c#L...
  - durin42 12y ago
    I'm almost 100% certain FSEvents uses kqueue internally. You can definitely use kqueue for the same things you'd need inotify for on Linux.
- duskwuff 12y ago
  kqueue replaces select/poll/epoll/etc as well. It really is your one-stop event handling call.
- SpartanJ 12y ago
  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 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 ).
  - vezzy-fnord 12y ago
    By default, yes. The kern.maxfiles sysctl value can go to the upwards of hundreds of thousands, if I recall correctly.
    - throwabob214 12y ago
      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.
  - throwabob214 12y ago
    > 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...
Alupis 12y ago
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 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...
- vezzy-fnord 12y ago
  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.
  - throwabob214 12y ago
    > 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. :-)
eleitl 12y ago
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.
- lutoma 12y ago
  > Nothing like Dropbox -- that's not a bug, it's a feature. What a horribly arrogant and conceited thing to say.
  - vezzy-fnord 12y ago
    It's also wrong. FreeBSD supports the best there is: Tarsnap.
    - swills 12y ago
      There's also the syncthing port and owncloud sync support via mirall.
    - blfr 12y ago
      That's a backup solution which you can also run on Linux without an issue. Dropbox is more for collaboration. It's often the only tool in its class used by smaller publishers or marketing companies. They don't have an ftp or webdav server. And it sure beats emailing files around.
    - smcgivern 12y ago
floatboth 12y ago
"There are some other issues, too: FreeBSD ports make no distinction between development and runtime files like Debian’s packages do. So, just by virtue of wanting to run a graphical desktop, you get all of the static libraries, include files, build scripts, etc for XOrg installed." That's definitely a feature, not a bug! I hate how Linux distributions require you to install a thousand "-dev" or "-devel" packages. All headers should always be present on a Unix system! Also, you don't need HAL/PolicyKit/dbus on FreeBSD. xorg-server recently switched the default configuration option from HAL to devd. And you can compile things like Firefox WITHOUT="DBUS" :-)
- exacube 12y ago
  But not everyone that uses Linux compile X libs or Firefox themselves (a very tiny fraction do). Why does it make sense to have include headers and source?
  - smutticus 12y ago
    Disk space is cheap. If it really is a problem for you then work around it. But for most of us installing dev files makes sense if we ever need to compile something against those .h files.
    - cwyers 12y ago
      Even if it is, bandwidth isn't particularly cheap.
      - gaadd33 12y ago
        I think with compression most headers are probably tiny compared to even the ads on a large widely read news site.
    - buster 12y ago
      Disk space may be cheap but limited. It just makes no sense whatsoever to just put a lot of files on my disk i will NEVER care about. NEVER. And if i need them, i will install them. Usually i only want a freaking binary to run.
_paulc 12y ago
I think that a lot of this depends on whether you want to run a desktop or server - a lot of comparisons focus on how Linux/FreeBSD compare as a user workstation. To be honest I wouldn't recommend anyone use FreeBSD as a desktop/laptop OS but if you want a 'production' server there is a lot to be said for simplicity and avoiding too many 'clever' features.
mavhc 12y ago
Package management was my main problem, all I wanted to do was keep my home server up to date, but it became a nightmare. Moved to debian/kfreebsd (where a lot of stuff just didn't work) and then debian/linux when ZOL became stable.
penland 12y ago
That's a good overall article - I've been switching back and forth between FreeBSD and Debian for several years now, and I never spend more than a couple of month without using one of them. The one thing that surprised me was his take on FreeBSD's package management system, pkg. PKG is relatively new, having been released in late summer 2012. Prior to that, FreeBSD relied on the ports collection, which was (is) a vast tree of Makefile's allowing you to create custom builds of virtually any software imaginable. While pkg is still raw on the edges, I VASTLY prefer it to Debian's hodgepodge of package management tools that all do 90% of the other, though none of them do it cleanly and none of them have straightforward interfaces. Am I using dpkg here? What about aptitude? Or should I just roll w/ apt-get? All of these tools combine the ease of use of git with the flexibility of a Maven build. If you know how to use to descend deep into the depths of git or Maven, this isn't an issue ( and for the author, it certainly is not ). Yet there are numerous simple tasks ( like say, searching for a package remotely when you aren't sure the exact name ) which still require hitting up google and settling in for a Click-Your-Way-To-Adventure session. PKG, in contrast, is both simplistic and flexible ( it reminds me of a industrial grade version of Brew in some sense ). It's a tool that I find myself integrating into my workflow beyond simple installs / updates, particularly it's seamless integration with jails. Configuration of remote repositories is vastly simplified as well. PKG is not perfect by an means - it definitely has worts that need to be taken care of. I'm also sure that PKG probably feels a tad inadequte to some hard core sys admins - pkg has the look and feel of a tool designed by a programmer looking to handle normal cases than a tool designed to provide a sys admin with an atom bomb if necessary. Yet the system is still relatively new and as the bugs continue to get ironed out it's a reminder to me of why I love FreeBSD in a lot of ways - the abstraction point is flawless and it gets out of my way.
- Volundr 12y ago
  For at least as long as I've been using it (7+), FreeBSD has always had binary and source packages. Ports are still very much existent and supported (and needed if you want anything custom). All pkg replaces is the old way of getting/managing binary packages (pkg_add, pkg_delete, pkg_info, etc).
  - 12y ago
dorfsmay 12y ago
I saw some @HNstatus tweet about ZFS issue that shows that it runs on FreeBSD. Are they running the storage layer on FreeBSD only, or everything?
cplease 12y ago
Those who switch operating systems out of ideological disillusionment are liable to end up as disillusioned again as those who switch religions out of religious disillusionment. You may think the new one is more pure, but it's really just more novel to you. The old timers have been around for their own iterations of in-fighting and may be happy to see fresh blood but probably won't be happy to see rehashing of hardened partisan battles. Linux hasn't lost its way, it has evolved over the past 20+ years as UNIX has evolved over the past 40+ years. So have the BSDs--all of them.
hobarrera 12y ago
It's a shame FreeBSD was the chosen BSD to do this comparison. It always seemed to me that FreeBSD felt almost-like-linux. It also seems to me that most of the issues mentioned would be non-issues for OpenBSD (though it does not support ZFS, which the op wants).
xenophonf 12y ago
but there is no way with FreeBSD, like there is with Debian, to say “never even show me packages that aren’t DFSG-free.” I would be very surprised to discover non-free software in FreeBSD's binary package repository. However, if this is a concern, one needs to set LICENSES_REJECTED in /etc/make.conf, at which point FreeBSD Ports will not build anything with a license that matches. If a company's concerned about the licenses of the binary packages provided by FreeBSD, it could simply set up its own internal binary package repository using poudriere, and use poudriere to filter out software with the unwanted licenses. See /usr/ports/Mk/bsd.licenses.mk (https://raw.githubusercontent.com/freebsd/freebsd-ports/master/Mk/bsd.licenses.mk https://raw.githubusercontent.com/freebsd/freebsd-ports/mast...) for the gory details.
- emaste 12y ago
  A lot of non-Free software also disallows redistribution, so it's not permissible to put it in the binary repository. It's possible that free but not Free (e.g., zero-cost binary-only software) software could be included in the repository. pkg metadata does include license information -- see https://github.com/freebsd/pkg/issues/20 https://github.com/freebsd/pkg/issues/20, but I am not sure of plans to provide user-facing control over acceptable licenses at the moment. It's a good idea though and I'll see if we can make it happen.
smegel 12y ago
> and solid memory management What does he mean by this?
- feld 12y ago
  You'll often find FreeBSD using less memory to run the same software stack. I also tend to see more intelligent use of swap. I can't comment on the comparison of the filesystem cache performance.
jorgecastillo 12y ago
If you happen to try FreeBSD don't let that be your only impression of BSD based systems. Try OpenBSD too, if your hardware is supported and all the software you use is available you won't be disappointed. OpenBSD more or less just works provided the previous conditions are true.
r3ddaem0n 12y ago
"GEOM, however, supports only RAID0, RAID1, and RAID3. It does not support RAID5 or RAID6 in software RAID configurations!" Looks like the author is still learning FreeBSD and hasn't read all relevant docs yet. 'man 8 gvinum' clearly says that raid5 _is_ supported: "To create a raid5 array on disks /dev/ada1 /dev/ada2 and /dev/ada3, with stripesize 493k you can use the raid5 command: gvinum raid5 -s 493k /dev/ada1 /dev/ada2 /dev/ada3" I'd take this article with a big grain of salt.
- teddyh 12y ago
  RAID5 is obsolete. In RAID5, if a disk breaks in an array and is replaced, the system has to read all of the remaining disks to rebuild the array. If a single byte is unreadable on any of those remaining disks, your array can’t be rebuilt and you have lost your data. With today’s disk sizes, the chance of this happening is larger than is acceptable. The interim solution is RAID6, which will work for some years to come.
  - Scramblejams 12y ago
    Not true with mdadm. Yes, your unreadable single byte will translate into a corrupted file somewhere, but I've recovered plenty of mdadm RAID5 and RAID6 arrays that had lost one or both extra drives and suffered from UREs on the remaining disks. Love good software RAID!
    - teddyh 12y ago
      I agree about software RAID – I use it exclusively myself. Also, nice to know that an array can be recovered, even though it would seem to be a reasonable thing to assume, it is good to know that it is possible. But my point was that: 1. You still have some lost data. 2. An RAID5 array which breaks in this way must be manually rebuilt, possibly from a rescue boot media. Your server will no longer even boot up by itself.
deleted 12y ago
[deleted]
gtrubetskoy 12y ago
I too started out on FreeBSD. Another feature that I don't think you mentioned, and don't know whether it's supported with ZFS was union mounts, where you can mount one filesystem atop another (as many times as you'd like) and thereby get yourself a COW filesystem. I think there was a method to run FreeBSD from a CD-ROM using this?
cthalupa 12y ago
The article seems kind of odd on some of its logic: >Its storage subsystem also has some surprising misses. Its rough version of LVM, LUKS, and md-raid is called GEOM. GEOM, however, supports only RAID0, RAID1, and RAID3. It does not support RAID5 or RAID6 in software RAID configurations! Well, actually, it does support raid5, but also... With ZFS being a truly first class citizen, why not just use raid-z or zfs encryption instead of raid5 or luks? >ZFS also does not support some common operations, like adding a single disk to an existing RAID5 group (which is possible with md-raid and many other implementations.) This is a ZFS limitation on all platforms. No block pointer rewrite for ZFS, so no expanding of existing vdevs by adding disks, but you can still add more vdevs to increase the total pool size. You generally want specific numbers of disks based on raidz level for performance reasons anyway. (In general) RAID isn't really a "consumer" thing, outside of maybe a basic home NAS type environment. If you're doing this for a server environment where RAID sees the majority of it's use, I don't think it's too onerous to have to add more vdevs instead of a single disk. > Apparently this is because FreeBSD has nothing like Linux’s inotify. Nothing like? kqueue/kevent. It's not 'exactly' like inotify, but it's definitely something like it. (It's also something like epoll, and others... kqueue is fairly big and replaces multiple linux equivalents) I find it odd that the network stack isn't mentioned either. It's still significantly more performant than the linux network stack, and FreeBSD is pulling away even farther in this arena. Things like https://wiki.freebsd.org/NetworkRSS https://wiki.freebsd.org/NetworkRSS , netmap being a first class citizen, etc (Netflix blogs on why they chose FreeBSD for their CDN devices are fascinating) are all pretty damn sweet. Kind of nitpicky, I guess, especially since the author isn't claiming to be intimately familiar with the state of every part of modern FreeBSD
davidgerard 12y ago
Yeah. I was an ardent FreeBSD fan for years - it pleased me in all the ways Linux didn't - but then I tried Ubuntu 5.04, discovered Synaptic and went "HOLY CRAP THIS IS SO OBVIOUSLY THE RIGHT WAY TO DO THIS."

198 points by liotier 12y ago

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.

ziahamza 12y ago
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.
- leimy2k 12y ago
  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 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.
- derpsss 12y ago
  https://github.com/libuv/libuv/blob/v1.x/src/unix/kqueue.c#L299 https://github.com/libuv/libuv/blob/v1.x/src/unix/kqueue.c#L...
- durin42 12y ago
  I'm almost 100% certain FSEvents uses kqueue internally. You can definitely use kqueue for the same things you'd need inotify for on Linux.
duskwuff 12y ago
kqueue replaces select/poll/epoll/etc as well. It really is your one-stop event handling call.
SpartanJ 12y ago
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 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 ).
- vezzy-fnord 12y ago
  By default, yes. The kern.maxfiles sysctl value can go to the upwards of hundreds of thousands, if I recall correctly.
  - throwabob214 12y ago
    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.
- throwabob214 12y ago
  > 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...

Alupis 12y ago

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

vezzy-fnord 12y ago
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.
- throwabob214 12y ago
  > 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. :-)

eleitl 12y ago

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.

lutoma 12y ago
> Nothing like Dropbox -- that's not a bug, it's a feature. What a horribly arrogant and conceited thing to say.
- vezzy-fnord 12y ago
  It's also wrong. FreeBSD supports the best there is: Tarsnap.
  - swills 12y ago
    There's also the syncthing port and owncloud sync support via mirall.
  - blfr 12y ago
    That's a backup solution which you can also run on Linux without an issue. Dropbox is more for collaboration. It's often the only tool in its class used by smaller publishers or marketing companies. They don't have an ftp or webdav server. And it sure beats emailing files around.
  - smcgivern 12y ago

floatboth 12y ago

"There are some other issues, too: FreeBSD ports make no distinction between development and runtime files like Debian’s packages do. So, just by virtue of wanting to run a graphical desktop, you get all of the static libraries, include files, build scripts, etc for XOrg installed." That's definitely a feature, not a bug! I hate how Linux distributions require you to install a thousand "-dev" or "-devel" packages. All headers should always be present on a Unix system! Also, you don't need HAL/PolicyKit/dbus on FreeBSD. xorg-server recently switched the default configuration option from HAL to devd. And you can compile things like Firefox WITHOUT="DBUS" :-)

exacube 12y ago
But not everyone that uses Linux compile X libs or Firefox themselves (a very tiny fraction do). Why does it make sense to have include headers and source?
- smutticus 12y ago
  Disk space is cheap. If it really is a problem for you then work around it. But for most of us installing dev files makes sense if we ever need to compile something against those .h files.
  - cwyers 12y ago
    Even if it is, bandwidth isn't particularly cheap.
    - gaadd33 12y ago
      I think with compression most headers are probably tiny compared to even the ads on a large widely read news site.
  - buster 12y ago
    Disk space may be cheap but limited. It just makes no sense whatsoever to just put a lot of files on my disk i will NEVER care about. NEVER. And if i need them, i will install them. Usually i only want a freaking binary to run.

_paulc 12y ago

I think that a lot of this depends on whether you want to run a desktop or server - a lot of comparisons focus on how Linux/FreeBSD compare as a user workstation. To be honest I wouldn't recommend anyone use FreeBSD as a desktop/laptop OS but if you want a 'production' server there is a lot to be said for simplicity and avoiding too many 'clever' features.

mavhc 12y ago

Package management was my main problem, all I wanted to do was keep my home server up to date, but it became a nightmare. Moved to debian/kfreebsd (where a lot of stuff just didn't work) and then debian/linux when ZOL became stable.

penland 12y ago

That's a good overall article - I've been switching back and forth between FreeBSD and Debian for several years now, and I never spend more than a couple of month without using one of them. The one thing that surprised me was his take on FreeBSD's package management system, pkg. PKG is relatively new, having been released in late summer 2012. Prior to that, FreeBSD relied on the ports collection, which was (is) a vast tree of Makefile's allowing you to create custom builds of virtually any software imaginable. While pkg is still raw on the edges, I VASTLY prefer it to Debian's hodgepodge of package management tools that all do 90% of the other, though none of them do it cleanly and none of them have straightforward interfaces. Am I using dpkg here? What about aptitude? Or should I just roll w/ apt-get? All of these tools combine the ease of use of git with the flexibility of a Maven build. If you know how to use to descend deep into the depths of git or Maven, this isn't an issue ( and for the author, it certainly is not ). Yet there are numerous simple tasks ( like say, searching for a package remotely when you aren't sure the exact name ) which still require hitting up google and settling in for a Click-Your-Way-To-Adventure session. PKG, in contrast, is both simplistic and flexible ( it reminds me of a industrial grade version of Brew in some sense ). It's a tool that I find myself integrating into my workflow beyond simple installs / updates, particularly it's seamless integration with jails. Configuration of remote repositories is vastly simplified as well. PKG is not perfect by an means - it definitely has worts that need to be taken care of. I'm also sure that PKG probably feels a tad inadequte to some hard core sys admins - pkg has the look and feel of a tool designed by a programmer looking to handle normal cases than a tool designed to provide a sys admin with an atom bomb if necessary. Yet the system is still relatively new and as the bugs continue to get ironed out it's a reminder to me of why I love FreeBSD in a lot of ways - the abstraction point is flawless and it gets out of my way.

Volundr 12y ago
For at least as long as I've been using it (7+), FreeBSD has always had binary and source packages. Ports are still very much existent and supported (and needed if you want anything custom). All pkg replaces is the old way of getting/managing binary packages (pkg_add, pkg_delete, pkg_info, etc).
- 12y ago

dorfsmay 12y ago

I saw some @HNstatus tweet about ZFS issue that shows that it runs on FreeBSD. Are they running the storage layer on FreeBSD only, or everything?

cplease 12y ago

Those who switch operating systems out of ideological disillusionment are liable to end up as disillusioned again as those who switch religions out of religious disillusionment. You may think the new one is more pure, but it's really just more novel to you. The old timers have been around for their own iterations of in-fighting and may be happy to see fresh blood but probably won't be happy to see rehashing of hardened partisan battles. Linux hasn't lost its way, it has evolved over the past 20+ years as UNIX has evolved over the past 40+ years. So have the BSDs--all of them.

hobarrera 12y ago

It's a shame FreeBSD was the chosen BSD to do this comparison. It always seemed to me that FreeBSD felt almost-like-linux. It also seems to me that most of the issues mentioned would be non-issues for OpenBSD (though it does not support ZFS, which the op wants).

xenophonf 12y ago

but there is no way with FreeBSD, like there is with Debian, to say “never even show me packages that aren’t DFSG-free.” I would be very surprised to discover non-free software in FreeBSD's binary package repository. However, if this is a concern, one needs to set LICENSES_REJECTED in /etc/make.conf, at which point FreeBSD Ports will not build anything with a license that matches. If a company's concerned about the licenses of the binary packages provided by FreeBSD, it could simply set up its own internal binary package repository using poudriere, and use poudriere to filter out software with the unwanted licenses. See /usr/ports/Mk/bsd.licenses.mk (https://raw.githubusercontent.com/freebsd/freebsd-ports/master/Mk/bsd.licenses.mk https://raw.githubusercontent.com/freebsd/freebsd-ports/mast...) for the gory details.

emaste 12y ago
A lot of non-Free software also disallows redistribution, so it's not permissible to put it in the binary repository. It's possible that free but not Free (e.g., zero-cost binary-only software) software could be included in the repository. pkg metadata does include license information -- see https://github.com/freebsd/pkg/issues/20 https://github.com/freebsd/pkg/issues/20, but I am not sure of plans to provide user-facing control over acceptable licenses at the moment. It's a good idea though and I'll see if we can make it happen.

smegel 12y ago

> and solid memory management What does he mean by this?

feld 12y ago
You'll often find FreeBSD using less memory to run the same software stack. I also tend to see more intelligent use of swap. I can't comment on the comparison of the filesystem cache performance.

jorgecastillo 12y ago

If you happen to try FreeBSD don't let that be your only impression of BSD based systems. Try OpenBSD too, if your hardware is supported and all the software you use is available you won't be disappointed. OpenBSD more or less just works provided the previous conditions are true.

r3ddaem0n 12y ago

"GEOM, however, supports only RAID0, RAID1, and RAID3. It does not support RAID5 or RAID6 in software RAID configurations!" Looks like the author is still learning FreeBSD and hasn't read all relevant docs yet. 'man 8 gvinum' clearly says that raid5 _is_ supported: "To create a raid5 array on disks /dev/ada1 /dev/ada2 and /dev/ada3, with stripesize 493k you can use the raid5 command: gvinum raid5 -s 493k /dev/ada1 /dev/ada2 /dev/ada3" I'd take this article with a big grain of salt.

teddyh 12y ago
RAID5 is obsolete. In RAID5, if a disk breaks in an array and is replaced, the system has to read all of the remaining disks to rebuild the array. If a single byte is unreadable on any of those remaining disks, your array can’t be rebuilt and you have lost your data. With today’s disk sizes, the chance of this happening is larger than is acceptable. The interim solution is RAID6, which will work for some years to come.
- Scramblejams 12y ago
  Not true with mdadm. Yes, your unreadable single byte will translate into a corrupted file somewhere, but I've recovered plenty of mdadm RAID5 and RAID6 arrays that had lost one or both extra drives and suffered from UREs on the remaining disks. Love good software RAID!
  - teddyh 12y ago
    I agree about software RAID – I use it exclusively myself. Also, nice to know that an array can be recovered, even though it would seem to be a reasonable thing to assume, it is good to know that it is possible. But my point was that: 1. You still have some lost data. 2. An RAID5 array which breaks in this way must be manually rebuilt, possibly from a rescue boot media. Your server will no longer even boot up by itself.

deleted 12y ago

[deleted]

gtrubetskoy 12y ago

I too started out on FreeBSD. Another feature that I don't think you mentioned, and don't know whether it's supported with ZFS was union mounts, where you can mount one filesystem atop another (as many times as you'd like) and thereby get yourself a COW filesystem. I think there was a method to run FreeBSD from a CD-ROM using this?

cthalupa 12y ago

The article seems kind of odd on some of its logic: >Its storage subsystem also has some surprising misses. Its rough version of LVM, LUKS, and md-raid is called GEOM. GEOM, however, supports only RAID0, RAID1, and RAID3. It does not support RAID5 or RAID6 in software RAID configurations! Well, actually, it does support raid5, but also... With ZFS being a truly first class citizen, why not just use raid-z or zfs encryption instead of raid5 or luks? >ZFS also does not support some common operations, like adding a single disk to an existing RAID5 group (which is possible with md-raid and many other implementations.) This is a ZFS limitation on all platforms. No block pointer rewrite for ZFS, so no expanding of existing vdevs by adding disks, but you can still add more vdevs to increase the total pool size. You generally want specific numbers of disks based on raidz level for performance reasons anyway. (In general) RAID isn't really a "consumer" thing, outside of maybe a basic home NAS type environment. If you're doing this for a server environment where RAID sees the majority of it's use, I don't think it's too onerous to have to add more vdevs instead of a single disk. > Apparently this is because FreeBSD has nothing like Linux’s inotify. Nothing like? kqueue/kevent. It's not 'exactly' like inotify, but it's definitely something like it. (It's also something like epoll, and others... kqueue is fairly big and replaces multiple linux equivalents) I find it odd that the network stack isn't mentioned either. It's still significantly more performant than the linux network stack, and FreeBSD is pulling away even farther in this arena. Things like https://wiki.freebsd.org/NetworkRSS https://wiki.freebsd.org/NetworkRSS , netmap being a first class citizen, etc (Netflix blogs on why they chose FreeBSD for their CDN devices are fascinating) are all pretty damn sweet. Kind of nitpicky, I guess, especially since the author isn't claiming to be intimately familiar with the state of every part of modern FreeBSD

davidgerard 12y ago

Yeah. I was an ardent FreeBSD fan for years - it pleased me in all the ways Linux didn't - but then I tried Ubuntu 5.04, discovered Synaptic and went "HOLY CRAP THIS IS SO OBVIOUSLY THE RIGHT WAY TO DO THIS."