Ask HN: Can we talk about FreeBSD vs. Linux?

These discussions usually amount to flame wars but I will offer some real world usage perspective. I use to work for a fortune-5 company that standardized on Linux. We compiled our own Linux kernel and we used the SUSE distribution from Novell. The main driver behind this was two fold. (1) Novell indemnifies us from a legal perspective and (2) they support us on IBM hardware. Any problem from drivers, to user space apps (CUPS, Syslog, etc...) they support us. These are pretty much required by large companies.

I'm still in the automotive field but now I work on embedded stuff. I'm one of the software developers behind CUE (Cadillac User Experience) and Linux is the go-to defacto standard pretty much because all the BSP (Board Support Packages) run Linux. For example, Freescale iMX processors and their demo kits are all Linux based and so brining up drivers for iMX ethernet, SPI, GPIO, I2S and I2C have some sort of vendor support.

The large fortune-5 companines indirectly support Linux by entering multi millon dollar support contracts with companies like Novell and RedHat. To give an example: We once had an issue with CUPS where the root cause was a software bug. Novell, under the support agreement, fixed the issue and then submitted the patch back to the open source community.

So from my perspective, I can see how Linux seems to have more traction than openBSD. Linux seems to have a larger following in the automotive sector but I'm not sure if Linux's success is because of these factors I'm pointing too or if these factors are because a lot of people just know of or about Linux more so than openBSD.

There also seem to be more company backed open source projects that support Linux before openBSD. Example is Yocto which advertises itself as an open source Linux build system. And recently Freescale has been moving their LTIB BSP tools to Yocto.

I would be interested in hearing how others industries are using Linux outside automotive.

Zfs, to take one example, does do approximately what you want - the file system (or rather, the underlying block storage) has a tree structure, and changes to files are propagated via copy-on-write rewrites up the tree, so that earlier snapshots still get to see the original file.

This does make rolling things back trivial.

It doesn't give you dedupe for free, though. Think about what would have to happen: every modification would mean rehashing the modified block (not a problem, that should happen anyway to verify integrity). Let's say we dedupe at the block level rather than the file level to avoid the need for more expensive hashing operations, and to increase the likelihood of actually sharing stuff. Now, to determine whether we can deallocate the new block, we need to look up the hash. So we need an index of every block on the file system by hash. That necessarily involves either a big chunk of memory or a bunch of random I/O. Both are at a premium for a filesystem - the former for cache, the latter for throughput.

If you just want file dedupe, it's a smaller problem, but is less likely to create gains - most people don't store many copies of the same file, unless they're in the third party file storage business. So it isn't really suited to a general file system. If this is something you want, you could periodically go through your file system, hash all files with only one link count in the inode, and hard link them using the hash as a file name, into an set of directories fanning out by hash prefix. There may be some wrinkles with permissions; I believe btrfs has a different kind of copy with copy-on-write semantics that might be useful here.

> Runs most GNU/Linux apps via ports or jails, sometimes better than on Linux

Jails is containers like Solaris Zone, or LXC and OpenVZ on Linux. So it doesn't have any relation to FreeBSD ports.

FreeBSD does have binary repositories though (pkgng), so perhaps that's what you meant?

Another interesting point worth noting is that FreeBSD also has "Linux compatibility" modes for supporting Linux ABIs and virtual file systems (eg /proc). Though these are often outdated and generally it's better to run something native to FreeBSD instead.

That's called copy-on-write (CoW) and is supported by a few modern filesystems (including ZFS). In fact ZFS does do some very basic deduping in the way you suggest (ie you copy a file instead of move it, and ZFS will just issue a pointer).

However full deduplication could never be free simply because of the overhead of keeping a table of all the duplicated data and scanning new content for duplications.

> Your post is self-contradicting. You tell people not to use PC-BSD if they "want to know how stuff works". You then complain that to get a desktop working on plain old FreeBSD... you have to actually configure it... and know how it works.

Actually ... you're absolutely right. Sorry about that.

I guess a better way of putting it is that Debian is the upstream, and FreeBSD is the upstream, and that's what I was comparing. I'd personally feel a bit uneasy using PC-BSD, like I do with Ubuntu. But that's my hang up. It is a trade-off though. Things like the consolekit.pkla file I'd rather have done for me (there's only one way it should ever be done), things like font rendering I'm happy to know how to do myself now (in case I want to tweak things.)

But yes, for anyone looking to try FreeBSD on the desktop, definitely look into PC-BSD, as it may solve a lot of the complexities I discussed.