Ask HN: Can we talk about FreeBSD vs. Linux?
Since the recent surge of interest in FreeBSD I've been curious to find out more about it. I did some Googling but couldn't find any quality articles discussing FreeBSD from the common Linux-er's perspective.
I did find this: https://www.over-yonder.net/~fullermd/rants/bsd4linux/01. It doesn't have a date, but he mentions using GCC 3.2.2, which came out in 2003, so I'd say the info is pretty out of date.
Can we share some links and knowledge?
PS: I'm sure I speak for everyone when I say I'm not remotely interested in arguing over which system is "better" - I just want to know about differences in design and unbiased identification of strengths and weaknesses.
219 comments
[ 6.3 ms ] story [ 261 ms ] threadAnyway, I like the first comments idea about a wiki. That would be helpful.
Do you manage thousands/hundreds/a handful of machines?
Or is your interest entirely academic and structural?
I agree that most of the obvious Google searches return superficial comparisons of the installation process or explanations of the packaging and upgrade processes.
I used FreeBSD out of curiosity. So far, I'm using my VPS to run services (mail, vpn, etc.) and found FreeBSD to be stable, easy to admin and fairly secure. Another interesting thing are the tools. BSD tools seem to be easier to configure: e.g. PF syntax > IPTABLES syntax, or OpenSMTPD (OpenBSD's smtp server) vs virtually-everything-else.
For reference see discussions here:
Ruby ML Discussion: https://www.ruby-forum.com/topic/5673725
See the gist for results: https://gist.github.com/atmosx/14efea27eb2c1e38af09
There's no such thing as an unbiased identification of strengths and weaknesses, especially when it comes to monoliths like operating systems.
You say you're not interested in arguing about which system is better -- and I believe you -- but you're also asking for argument about which system is better, in list form. Heck, even your title has a versus in it.
That said, I join you in looking for a concise source of information about FreeBSD's design and usage in the wild contrasted with Linux.
(I don't want to start a flamewar, just add more stuff for a good discussion)
1) userland and kernel owned by the same group. this lends consistency to the experience, that is absent in linux, where it's clear that it's an amalgamation of many different tools.
2) (largely) one way of doing things
3) package management system (pkg-ng) that is a cross between gentoo portage and debian apt-get
4) extremely good documentation for an open source project (https://www.freebsd.org/doc/handbook/)
5) configuration is very simple (mostly driven from rc.conf)
6) excellent full-disk encryption support (geli)
driver support always lags a bit behind linux, on the other hand the drivers that do exist i'm confident are stable. i make sure to buy hardware which i know is supported.
So true. In my day job, I am a Windows admin, and I continue to be surprised that FreeBSD (the other BSD systems, too) comes with such good documentation while Microsoft is not ashamed to charge its customers thousands of bucks for software that comes without a ing manual...
The userlands are pretty similar, I think, they both support the GNU tools, as is attested to by the existence of Debian/kFreeBSD.
I don't know what the OP's motivation is, but I'm an enterprise server admin, with lots of Debian experience, but no real FreeBSD knowledge at all. I've been looking at Debian/kFreeBSD off and on for a while as a way to get at ZFS, and possibly better NFS performance. I was actually planning on deploying some experimental Debian/kFreeBSD systems when Jessie releases, but it now looks like that might not be such a good plan: http://lwn.net/Articles/614142/
The Gnu tools are of course portable, so you can install them from ports - you will need them for compiling software that assumes Gnu options for example.
Debian/kFreeBSD is a weird idea for me, you will have no support either form the FreeBSD community or the Debian community. I would go straight for FreeBSD proper, it is very well documented.
https://wiki.debian.org/Debian_GNU/kFreeBSD_why
1. If you like the Debian package system (or its package set) more than FreeBSD ports (just a matter of preference).
2. If you like GNU userland more than BSDish one (again, just a matter of preference).
3. If you don't have anything against GPL or other copylefted free software licenses, you'll appreciate that useful kernel modules like ext2fs driver, the upcoming reiserfs and xfs, or the upcoming ethernet driver for Xbox are (or will be) compiled in on the default kernel.
4. If you're concerned about running a 100% free system, our commitment to the Debian Free Software Guidelines (DFSG) guarantees that Debian GNU/kFreeBSD doesn't contain any non-free software. In fact, we have removed some non-free binary-only drivers that are contained in the upstream FreeBSD tree (see 903_disable_non-free_drivers.diff in kernel sources for a list).
Of which 1, 2 are just "you prefer it", 3 you can compile those drivers into FreeBSD if you want them. 4 is reasonable, but overall the reasons to use it over the better supported FreeBSD are weak.
http://smile.amazon.com/Design-Implementation-FreeBSD-Operat...
McKusick and his partner Eric Allman (sendmail & syslog) are the kind of older open source developers who're famous to Unix people and more Unix-inclined Linux people, but aren't as well known now as Stallman or de Raadt, say. Even now there's a high chance than any human being using the net has had their email, IM, or web traffic pass through software written by either of them.
I've never used a BSD or even looked into it... given what I read there, it seems like it'd be a lot nicer in at least one sense, since Debian releases die off and release-upgrade can be either perfect or very painful.
On the other hand, I do love how small and unassuming a basic Linux installation is, and -- as the author repeatedly and correctly stresses -- I'm used to doing things the way I currently do them. That's not good or bad, it's just momentum.
I do hope I'll get the chance to work with a BSD at some point, but much like my attempts to really get into Clojure... well, unlike the Stones, most of us do not have time on our side.
There is no "basic linux installation". Every distro is its own thing. Size seems like a really odd thing to bring up since every mainstream linux distro's "basic" installation is larger than the full OS of any of the four BSDs.
I meant small in terms of packages. The kernel, a shell, and not much else unless you specify it. Obviously you will specify something else, but the point was that I'm used to specifying exactly what else I want, so I have that habit to break/relearn.
The point you ignored or missed is that as a Linux user with no BSD exposure there's a basic difference in philosophy that creates several kinds of tradeoffs that I find compelling and interesting. I'm not "bringing up" anything in terms of absolute pros and cons, I'm highlighting what I consider noteworthy differences in terms of learning more about things I have not used.
[1] http://blog.dustinkirkland.com/2014/08/re-introducing-jeos-j...
The point was that what you get without selecting or installing anything else via a package manager is still apparently far less than what you get with a "base install" from a BSD (at least according to the article) and that that starting point is what I'm used to.
NetBSD takes bootstrapping most seriously - you can cross build it on any system with a vaguely functional C compiler, and it will bootstrap completely.
That will happen when you don't read it. Allow me to repeat it for you: 'There is no "basic linux installation"'. Linux is a kernel. There is no "basic linux installation". I do not know how it could possible be stated any clearer. Each individual distro is its own OS, which may or may not have a installation labelled "basic". Most of those are larger than any BSDs full OS. This is very simple.
>And, frankly, your statement about the "full OS" is meaningless
No it is not. You are awfully hostile for someone who just wants to learn. BSD operating systems are operating systems. The full OS means the full OS. Plain and simple. The lack of distinction between the OS and third party packages is unique to linux distros, where the OS itself consists almost entirely of third party packages in the first place. In BSD systems as in most systems, the operating system is everything included in the operating system, and third party software is third party software.
>it includes every possible package
This is one of the fundamental differences, which is why it seems to odd that you claim to be talking about the differences but you don't even know them.
>I meant small in terms of packages. The kernel, a shell, and not much else unless you specify it.
There is no mainstream linux distro where that is the case. Only specialized micro distros intended for embedded use and based on busybox provide anything like that. Debian, ubuntu, fedora, etc all have a few hundred MB more stuff in their minimal installation.
>but the point was that I'm used to specifying exactly what else I want
It is unreasonable to expect me to understand that was your point when you said something completely different. Nonetheless, you do not get that unless you are doing a custom LFS.
>The point you ignored or missed is that as a Linux user with no BSD exposure there's a basic difference in philosophy
No, that's the point you missed and instead talked about being minimal.
>I'm not "bringing up" anything in terms of absolute pros and cons
Saying "I love thing that is my own misunderstanding" implies that the other option lacks that thing. That's what pros and cons are all about.
I don't think that's entirely true. The Debian install I do by default, with no tasksel tasks selected, is very minimal. I haven't checked recently how large it is (and one of the reasons I am considering moving away is that I suspect the minimal required system has been growing with the adoption of things like systemd), but I remember a few years ago noting that it was a fair bit smaller than a clean OpenBSD install. That's not including X and compilers IIRC.
Also, as I understand it, Arch Linux is becoming quite popular and it is also pretty spartan by default.
(Not that I think this really matters for most cases (embedded excepted); I would like to be able to uninstall tcsh, though.)
This seems to be in the nature of the task. Freebsd-update is also often perfect, but if it goes wrong it can be very painful as well.
On the other hand, you do have a rollback feature, but then you're back to a probably working, outdated system.
AWS and GCE have support, but it seems the kernel is provided by a FreeBSD maintainer rather than AWS or GCE. How stable is FreeBSD on AWS or GCE ?. And are there any companies using FreeBSD on AWS / GCE ?.
https://www.cloudsigma.com/landing/freebsd-cloud-hosting/
https://www.rootbsd.net/
Given that fact and the fact that Tarsnap runs on AWS I think it's safe to assume it's pretty stable.
http://ovh.com/ has dedicated servers available with FreeBSD.
http://azure.microsoft.com/blog/2014/05/22/running-freebsd-i...
http://www.panix.com/v-colo/plans.html
Very. You're more likely to run into problems running FreeBSD on physical hardware, in fact, because (a) a wider range of hardware means more potentially weird drivers, and (b) Amazon does a better job of weeding out flaky hardware than Joe's Dedicated Server Shop.
Very affordable pricing, and these plans support FreeBSD: http://nqhost.com/freebsd-vps.html http://nqhost.com/unmetered-xen-vds.html http://nqhost.com/nq-vps.html
FreeBSD pros:
Very stable
Excellent network support
Friendly, knowledgeable devs and tightly knit community
Runs most GNU/Linux apps via ports or jails, sometimes better than on Linux
Easy to learn given prior 'nix experience
FreeBSD cons:
Difficult to learn if you're new to the 'nix world
Smaller pool of compatible hardware[1]
The above has been my personal experience and obviously won't be the same for everyone. Also, I'm most comfortable with Slackware Linux, which is very BSD-like compared to other Linuxes, so that probably influences my point of view. Generally speaking, I like FreeBSD but I don't run it as a production machine (yet) since I'm happy with Slackware. Should that ever change (and there's only one reason it would, and that doesn't need to be rehashed here) I'd be able to switch to FreeBSD relatively easily.
Something else you might want to explore, as an easy introduction to FreeBSD, is PC-BSD. It takes FreeBSD and makes it much more user friendly, with a focus on being a GUI based desktop OS (though they do offer an alternate server installation as well).
[1] While the official list of compatible hardware is extensive, I've found in practice that certain COTS hardware simply doesn't work well with FreeBSD. I've even had professional workstations like a Lenovo ThinkCentre refuse to boot the installation media, throwing a kernel panic instead. I've also had poor luck with cheap motherboards. Generally, my best experiences with installing and running FreeBSD have been on Dell and HP workstations, and on quality motherboards from companies like Gigabyte and ECS.
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.
[1] https://www.freebsd.org/doc/en/articles/linux-users/
- kqueue is a very powerful event loop similar to epoll [1]
- the FreeBSD ports collection is very simple to use as far as compiling from source goes. I only really prefer Debian's apt-get and Gentoo's emerge
- the FreeBSD Handbook is a very well-maintained text [2]. I freely admit OpenBSD has the best man pages ever written, but the Handbook is good too. Not bleeding-edge talk like the gentoo-wiki or archwiki, just reliable information.
[1] https://www.freebsd.org/cgi/man.cgi?query=kqueue&sektion=2
[2] https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/
Is there really such a person that prefers bsdmake over GNU make?? I really don't mean this as a troll comment, but bsdmake has about 5% of the functionality of GNU make.
It's perfectly adequate if you just want to give it a list of files to compile, but it's a nightmare to do things like write a recursive directory scanner to auto-generate Qt .moc files, to scan PATH to find the location of Qt on Windows, to parse command-line arguments passed into make, etc. Sure, the GNU Lisp-like syntax is an absolute nightmare, but at least it's doable with a widely available build tool.
I would be seriously interested in hearing what someone likes more about bsdmake, other than simplicity (you can avoid using complex features in GNU make if you like.)
(netcat) http://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/src/usr....
(inetd) http://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/src/usr....
(ntpd) http://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/src/usr....
(httpd) http://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/src/usr....
One way where the problem with this is showing, is the filesystem notification API of kqueue. It is a ridiculously bad API. E.g., you can't properly watch a directory with it. Replacing it with something saner would require changes to kqueue. If it had been designed like epoll then it would only require adding a different API to create a filesystem notification file descriptor.
I have both FreeBSD servers and Ubuntu servers. Thing I like the most with FreeBSD is its further separation (compared with Ubuntu) of OS (kernel and world) from third-party software. In Ubuntu every package comes in multiple versions for different releases, in FreeBSD there's only one version.
There's no "because I want git 1.8 so I have to upgrade to Ubuntu 14.04", in FreeBSD you can install the latest version of git on all supported OS versions. (In my experience even a slightly outdated OS version can run latest third-party software quite smoothly)
Software in FreeBSD Ports (its system getting third-party software) catch up with upstream releases very quickly. You might think they have less testing than that is in Ubuntu/Debian, but I don't know if it's really the case. Though I rarely encounter bugs with these cutting-edge software in FreeBSD.
I speak mainly from the experience with Ubuntu, I'm not so familiar with other Linux distros.
Rolling release distros (Arch Linux, OpenSUSE Tumbleweed, and Gentoo. n.wikipedia.org/wiki/Rolling_release
I like BSD but I prefer Linux BOTH are good. BSD is just a different flavor of NIX.
Just put up a disclaimer.
I often hear stability issues with Tumbleweed, and even more complaints of software breaking after an upgrade (software upgrade, not OS upgrade) on ArchLinux. (I heard ArchLinux's philosophy is "fix it yourself")
So I guess you can get more stable bleeding edge software in FreeBSD than OpenSUSE Tumbleweed and ArchLinux. I don't know the case with Gentoo, I don't often hear things about it.
In fact, I actually dread Ubuntu updates far more ... I've had them break various and sundry things about my (previously-working) system. In my experience, at least, Ubuntu is far less stable than Arch. With that said, though, I haven't used Ubuntu since 12.04 and 10.04 before that, so I don't know how it fares anymore.
Isn't that because ports are used compiled from source? You can do the same on Ubuntu with apt-get build-dep && apt-get source -b, which will install the build dependencies, download the source and compile it.
Sometimes small size means things can change faster, eg NetBSD has had 64 bit time_t since 2012, while 32 bit Linux still has no roadmap to fix this (the BSDs are also have a different compatibility model). Other times it of course means that less is done and things take longer. You will often hear people say the BSDs are better designed, as perhaps prioritising limited resources leads to more design, or maybe there are just fewer people who need to solve a problem fast but not so well.
Including (some) userspace means that the tools are less bloated than the GNU ones which were designed pre Linux as portable tools, before the Gnu project had a kernel - remember GNU was the cathedral in the cathedral and the bazaar.
[1] https://github.com/freebsd/freebsd/commits/master
[2] https://github.com/torvalds/linux/commits/master
I really like how easy Debian on the desktop is: install it, apt-get install xfce, and I have a nice desktop. It's very easy to add Adobe Flash, Steam, Skype, etc.
The FreeBSD desktop isn't as nice. You can add things like Flash and Skype on FreeBSD, but you have to fight harder and often use the Linux emulator. We're missing nouveau, I've had some kernel panics with the nvidia binary drivers (caused by nvidia's own shoddy code, not FreeBSD's fault), there's a lot of missing and unstable features due to developers primarily targeting Linux these days (Thunar's file refresh is glitchy and often fails to update, Thunar volman only really works with udev/Linux, mousepad crashes when you open a file an even multiple of 4KiB due to a bug in their code and a quirk of Linux mmap, livbte-based terminals tend to crash sometimes when you open them due to a bug somewhere between libvte and FreeBSD's /bin/sh, file-roller explodes when you try and extract large archives, Firefox has freezing issues with loading gigantic images unless you set MOZ_DISABLE_IMAGE_OPTIMIZE=1 in your environment, on and on.)
And it's also not really configured well out of the box for the desktop. I have to make this org.freedesktop.consolekit.pkla file and add entries to it in order to get the restart and shutdown buttons in Xfce to work. I have to create a fontconfig/fonts.conf file and substitute Helvetica with Sans in order to get Firefox to anti-alias text on web pages. And so on.
You are also doing all the setup from scratch. You install xorg, you install your video drivers, you set up xorg.conf, you create .xinitrc, you install a display manager if you want one, etc. This is both good and bad. It's great if you love tweaking your system, it's bad if you just want to throw it on a box and run it.
Moving on ... I really, really appreciate Debian's branches. If you install Wheezy, you can get security updates for packages, but not get version bumps. With FreeBSD, you have to choose between "the packages made at release time", or "the absolute bleeding edge." These updates can and do break workflows, especially on the desktop (Firefox pushed Australis on me, ibus moved to this braindead, slow-as-molasses super+space IME changer, etc.) The actual package installs are about the same for binary (apt-get vs pkg), but I much prefer FreeBSD's ports for building software (which is great when you need to patch software bugs.)
But if you're patient and good at fixing problems, you can end up with a rock-solid desktop. And hey, maybe PC-BSD will save you all of the above steps, too. I kind of look at FreeBSD vs PC-BSD as I do Debian vs Ubuntu: I'd rather know how things work than have it all done for me.
In terms of features, I really like FreeBSD's ZFS, even though it does eat a lot of RAM. Snapshots, whole-disk encryption on root, encrypted swap, mirroring/striping/RAID even across different disks, easy resilvering, etc. I also really like pf a whole lot more than iptables, as I find the syntax a whole lot more readable and flexible, although I will lament that FreeBSD's pf ships with ALTQ (QoS) off by default. I prefer the base system being maintained by the FreeBSD team. I like the consistency, the minimalism, and the great documentation.
Whenever I spot a difference between FreeBSD and Linux, I almost always favor the former's design: /dev/random behavior, jails vs cgroups, SO_NOSIGPIPE socket opt instead of needing the MSG_NOSIGNAL flag, etc.
I like that FreeBSD avoids a lot of the 'licensing wars' BS of Linux. I have Firefox instead of Iceweasel, I have cdrtools instead of cdrkit (I continue to this day to have issues with burning on Linux), I have ZFS instead of btrfs, we had sound mixing in an OSS fork instead...
As a side note, I'd love to have something like "freebsd-update rollback" for most Linux distros. I've seen attempts at it, but the only one that worked well for me was openSUSE integration of btrfs snapshots and the package manager. That's kind of swatting a fly with the complete works of Knuth, but it did the job.
http://www.freebsd.org/doc/handbook/updating-upgrading-freeb...
I have my VPS (production) and a local HDD I use for testing (stage), configured exactly the same way. I'll update stage first, and if all looks good, then I'll update production.
https://forums.freebsd.org/threads/howto-freebsd-zfs-madness...
https://github.com/vermaden/beadm/
http://wiki.pcbsd.org/index.php/Multiple_Boot_Environments
I would like to try FreeBSD again. Does anyone know if this works now?
edit: clarified the reason I ask is because I want to know.
With zsh you even get tab completion of ports, packages, and other command specific arguments.
However, in the FreeBSD ports tree, I guarantee you there is a bash package you can install, and then you can just switch your shell to be bash instead of sh.
I didn't see tab completion when I was running the installer and I gave up.
Thank you for answering my question.
The default root shell on FreeBSD is csh (tcsh) [1] and has been that way for at least 21 years (at least if I read the revision history [2] correctly, my own memories only go back about some 15 years).
As per Wikipedia article, tcsh natively supports tab completion since about 1983 [3] (which I can confirm always worked without an issue as far as my memories go, so again, give or take 15 years).
Permanently switching any user shell to tcsh (if it happens to be sh) is pretty much a single `chsh` command away, so as far as strictly tab completion goes, manual installation of bash is not required at all.
The required steps (step) to setup tcsh for tab completion can be found i.e. in this 2004 FAQ [4]:
Tip#7: List possible completions
I often see Bash users complain that Tcsh does not give a list of completions with the tab key. This is not true. Not only can Tcsh list complentions, but it can do it in color. Just add this to your ~/.tcshrc
set autolist set color set colorcat
[1] https://www.freebsd.org/doc/en/articles/linux-users/shells.h...
[2] https://svnweb.freebsd.org/base/head/etc/master.passwd
[3] https://en.wikipedia.org/wiki/Tcsh
[4] http://www.tcsh.org/TipsAndTricks
Also want to add that csh comes stock with historical auto completion which I very much enjoy.
Typing "tail " and pushing the up arrow will auto complete with the last command you typed starting with "tail ".
/bin/sh in 10.x has tab completion.
It's funny how little things like this affect where you go with systems. On the uni systems, emacs was set up to reformat your code by default (as you typed it in). This drove me bananas, and I didn't realise it was configurable. So I went off and found another editor, and I'm still using it.
I think the biggest worry is that if you need to do something like boot into single user mode for an emergency recovery, and /usr or /usr/local (with root's shell in it) is on a different or unmountable partition then you will not be able to do anything.
This is a really bad place to be.
Personally I run Ubuntu on my work desktop so I can focus on work and not managing the OS. I run a private irc server on a busted old desktop running Arch Linux for the opposite reason :)
These Just Worked for me. My only real annoyance with Xfce is that it's unresponsive to mouse clicks for the first few seconds after starting.
> I really, really appreciate Debian's branches. If you install Wheezy, you can get security updates for packages, but not get version bumps. With FreeBSD, you have to choose between "the packages made at release time", or "the absolute bleeding edge."
There are quarterly port branches now to give people more of a choice: https://lists.freebsd.org/pipermail/freebsd-ports-announce/2...
> encrypted swap
Be nice to see this on by default these days, but if you're not already using it: swapoff -a && $EDITOR /etc/fstab && plop ".eli" at the end of the swap device name && swapon -a. Done.
> I also really like pf a whole lot more than iptables
I just wish it were more actively maintained and kept at least vaguely in-sync with upstream. Makes me reluctant to switch from ipfw.
Under a regular user account? I even added my user to wheel and operator, and no go. I've helped a few people on forums.freebsd.org set up this pkla file, too.
> There are quarterly port branches now to give people more of a choice
The quarterly branches are definitely a step in the right direction, but still not really what I want. I want patches for Heartbleed and Shellshock, but without any software version number bumps. I know their team is much smaller so it's just not feasible, but it's definitely something that would be greatly appreciated.
> I just wish it were more actively maintained and kept at least vaguely in-sync with upstream.
Definitely. Is OpenBSD's MP-safe yet? I believe that's partly related to why FreeBSD's has ALTQ disabled (but it's hard to find good information on why that choice was made.)
Yep. Only special factors I can think of are VirtualBox guest additions and passphraseless sudo - though I don't recall any similar problems when I last had it on my laptop which had neither.
Also starting from console and not a display manager, because they're vile things that are almost as bad as splash/boot screens.
> I know their team is much smaller so it's just not feasible, but it's definitely something that would be greatly appreciated.
Very much so - the biggest thing I miss from the Debian world is unattended-upgrades. Maybe with some more commercial support..
> Is OpenBSD's MP-safe yet? I believe that's partly related to why FreeBSD's has ALTQ disabled
It's still under a big giant lock as far as I'm aware. They're also removing ALTQ in favour of a simpler framework: http://undeadly.org/cgi?action=article&sid=20140419151959
As much as I would love to have the newest OpenBSD pf config syntax available in FreeBSD I do appreciate them not breaking my firewall config as part of an OS update.
Why aren't modern filesystems based on a content-addressable-store where the content is 100% separated from the organization of the filesystem itself? It seems to me like it would make more sense to have only one copy of a file ever saved and when modifications are made you get a new pointer to the changed file. Obviously it wouldn't make sense to do full copy on modifications for files over a certain size, but in this situation the filesystem could offer an abstraction over a patch and pointer to the original file until the system is idling and a full copy could be made.
The reason I ask about this is because it would make updating anything and rolling things back trivial since it would simply be a pointer change in the file hierarchy hash map from the new file to the old file and back again. Furthermore, such a system would give you dedupe for free and files could be marked for deletion only once the last pointer to the file in the CAS has been deleted.
Camlistore and TahoeLAFS are both designed this way. But they are more of a content store than a file system.
In fact, BTRFS is implemented this way. The content and the metadata can be separately treated with mirrors vs raid. You can balance just the metadata or both data and metadata. When you convert an ext2/3/4 file system to BTRFS, it just sets up it's own metadata pointing to the same blocks that the ext used. You get a free snapshot of your data pre-conversion and it's all COW from then on. I believe the B-Tree of BTRFS is the metadata and the content never changes on disk until no more pointers exist. If you decide to go back, it just restores the superblock and the old data is still in the same spot. You would only regain that space after you delete the snapshot and the last pointers to the data are gone.
Btrfs is not content-addressable, although everything else you say about it is correct.
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.
The above video is an explanation of a bunch of the barriers to implementing block pointer rewrites. The conclusion is that it would make the code a lot more complicated and break a lot of the layering, and probably make addition of other new features a lot harder. Even a standalone offline rewriting tool wouldn't necessarily be accepted into the OpenZFS codebase because of the maintenance burden. Their advice is that if you think you need that feature to solve a particular problem, you should be looking for a workaround to solve that problem without requiring the huge block pointer rewrite project (which nobody's working on), even if the workarounds have a significant and permanent performance impact.
When you take into account how long the feature's been in demand and been on the roadmaps under "eventually", it's clearly not going to happen anytime soon and won't happen without a major change to how ZFS development is being done. It's not definitely impossible, but it's perpetually several years away from happening. With btrfs already having it's equivalent to that feature and stealing an ever-growing slice of the users who need that feature, it's probably never going to happen for ZFS.
http://open-zfs.org/w/images/7/71/Fast_File_Cloning-Pavel_Za...
It's also worth noting that ZFS has been available as a root file system long before FreeBSD added ZFS to RELEASE. I remember running OpenSolaris (and some of it's forks, eg Nexenta) with ZFS root about 6 years ago. Possibly longer actually.
The issue with ZFS as root was more of a problem with the boot menu than the OS. OpenSolaris used GRUB where as FreeBSD obviously doesn't, so FreeBSD needs to either port their ZFS drivers to their bootloader, or employ a hacky method of having a UFS boot volume that then points to a ZFS root partition (which, sadly, is how FreeBSD currently works).
Interestingly, since GRUB is GPL, it meant that technically there were GPL ZFS drivers even before Btrfs started life (never mind the various Linux ports of CDDL-licenced ZFS drivers that have appeared since). Albeit those GPL ZFS drivers were read only
A ZFS-aware loader hit CURRENT in late 2008, and a dedicated zfsloader for use from (gpt)zfsboot hit the stable branches in late 2009.
https://www.freebsd.org/releases/7.3R/announce.html
Anyhow, thank you for the correction :)
But I don't think you'd have this problem. Just like we have an inode telling every block of a file, a filesystem like that would need a similar structure telling every hash of the file. When you delete a block, you look at this structure, the same way you look at an inode.
The only thing missing is that you'll need a counter at the blocks. And this counter will create some synchronization problems that may turn out more important than saving disk space.
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.
ZFS has deduplication as an optional feature, which is implemented as a content-addressable store of filesystem blocks. In contrast to e.g. git the content-addressable aspect is an implementation detail that is not exposed to users.
http://blogs.sun.com/bonwick/entry/zfs_dedup
I know that. But CoW does cover a few points raised by the previous poster.
> ZFS has deduplication as an optional feature, which is implemented as a content-addressable store of filesystem blocks. In contrast to e.g. git the content-addressable aspect is an implementation detail that is not exposed to users.
I know what dedup is and how ZFS utilises it (I've been running ZFS for about 8 years now - I'm quite familiar with it).
If you read my post again, you'll see I was discussing two separate points: 1) that CoW file systems do provide the pointer-like methods the former commenter raised. And 2) deduping isn't free.
What you're arguing with me is semantics and if you read the former post again, you'll understand why I chose the language I chose.
> the filesystem could offer an abstraction over a patch and pointer to the original file
I've implemented a delta-based patching system before: the idea is that, given two binary buffers (ostensibly files), encode the differences between them. I have no idea how Xdelta (VCDIFF-based) and bsdiff manage to do this at reasonable speeds (their code is too much for me to understand), but the best I could manage for this was O(n^2). It's a very complicated and difficult thing to do efficiently. But indeed it can result in massive file space savings. You could cheat a bit by intercepting fwrite commands, but that won't catch insertions or deletions. Nor programs that overwrite files instead of updating them in-place (eg most of them.) As you can guess, to really make something like this efficient would require program authors to rethink how they write to files, which is unlikely to ever gain traction.
What I'd really like to see, but know that we'll never get thanks to xkcd.com/927, is a metadata system for files that is portable. Instead of relying on file extensions or unreliable magic byte header detection, you'd have the MIME type included in this metadata. Along with the displayed file name that can have any characters in them (sans maybe the path separator), the file attributes (read/write/exec/user/group/owner/hidden), creation+modification+access times, etc. And then when you'd send a file through your e-mail client or FTP it up to some web server, it'd copy over the metadata along with it. So when you moved your file from extfs over to NTFS, and then copied that over to ZFS, you wouldn't lose all of that metadata.
But good luck getting all file system authors and browser vendors to agree to a common format to transparently wrap files with.
It's not as seamless as one might wish; you do have to use zip. do the transfer and then unzip on the target, and of course remember to use -V in the first place.
FTP implementations also exist in the VMS world for transferring the file metadata, but I haven't used these myself so can't comment on their usability in practice.
The downside to ZIP is that the information is cast away once you decompress it. If your file system doesn't maintain that metadata (eg Windows and file permissions), then it's just gone.
You also can't really just keep your files in ZIP because operating systems don't really natively integrate transparent ZIP support into files, and you probably don't want the file compressed in most cases (your app may want to read it often, and not want to pay the cost of decompressing the whole thing.)
But that is very close to what I am seeking, yes.
"I just apt-get install xfce and I'm done" isn't learning how anything works.
If you want a ready-made desktop, use PC-BSD. If you want to learn to install a desktop from scratch, use vanilla FreeBSD. However, don't claim you want to know how it works, then whine when you have to gasp actually configure it to work.
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.
For those who haven't experienced this: it's really painful. Your entire desktop becomes completely unresponsive for 5-10 full seconds while a picture very slowly loads.
I'm sure most people here don't even know it's the only OS in the world allowing you run Xorg as an unprivileged user.
Just like Linux taught me to appreciate FreeBSD, FreeBSD taught me to appreciate OpenBSD. OpenBSD -- the world's simplest and most secure Unix-like OS. Creator of the world's most used SSH implementation OpenSSH, the world's most elegant firewall PF, the world's most elegant mail server OpenSMTPD, and the OpenSSL rewrite LibreSSL. OpenBSD -- the cleanest kernel, the cleanest userland and the cleanest configuration syntax.
FreeBSD -- growing overly complex [1], lagging on security [2], packing itself with unnecessary, experimental technologies, and representing itself with a satanic mascot and a shiny, dildo-looking logo.
--
[1] http://lists.freebsd.org/pipermail/freebsd-hackers/2012-Janu...
[2] http://itwire.com/business-it-news/open-source/62641-crypto-...
Maybe the first, but these articles claim Fedora can do it too, although currently you need to edit a config file, and it only works if you invoke startx(1), not when logging in from gdm.
http://hansdegoede.livejournal.com/14446.html http://hansdegoede.livejournal.com/14268.html
"X is now rootless with the help of systemd-logind, this also means that it must be launched from the same virtual terminal as was used to log in, redirecting stderr also breaks rootless login. […]"
https://www.archlinux.org/news/xorg-server-116-is-now-availa...
This is obviously not a feature of archlinux itself, but an upstream x.org feature.
Attempting to talk about "Linux", as if some single operating system - lack of pluralism between commenters to handle the differences notwithstanding - is a problem with this thread.
Now, some of the about:config options that were proposed as alternate workarounds definitely caused very weird rendering glitches, but this one seems mostly side-effect free.
https://freedesktop.org/patch/23215/
Comparing a full system like FreeBSD to a kernel like Linux doesn't really get us anywhere. You can't really talk about the desktop experience comparisons when Linux can't even boot without a userland. If you tried to do it in an abstract sense, you'd be guaranteed to get responses of, "yes but Mouse Rat Linux supports ZFS and is also run by an elected core team!"; since there's pretty much a Linux distro for everything imaginable.
I'm curious if anyone who knows more than me would disagree, though (maybe for some purposes?).
You now get the regular repository (binary packages updated once per week), or the 'Quarterly Branch' (a known-good snapshot of the packages, with security updates)
Or you can build your self from ports (or build your own packages using poudriere), which is up-to-the-minute bleeding edge.
Curious then as to your choice of licensing your Higan/BSnes emulators under GPLv3.
The reason in higan's case, is because of the culture of the emulation community. There's a long, dark history of closed source emulators (even now with SuperGNES, no$sns and SNESGT), and I feel that emulation is a bit different from ordinary software: here, we are working under the threat of time. We realistically only have another 10-20 years to improve SNES emulation before finding a working system and persons interested in reverse engineering it are impractical.
I think it's very shallow and narcissistic to take the research of others, and not contribute back your own findings. I view this as more of an academic / historical preservation project than a regular desktop application. To end users, it's just for playing games, and not tied to any other system components, so I feel less bad about it.
To give a real world example, I encountered a bug in SuperFX (GSU1) emulation, and found that FuSuYa had a tracer-based fork of Snes9X: he basically added in a few fprintf() statements, and then refused to release the source to his changes. That would have been fine, but he botched something and introduced a very serious bug, one that I was also experiencing in my emulator. If I were able to diff his source to the official Snes9X source, I would have found and been able to fix that bug in a few minutes. Instead, it took me about two weeks to track it down.
Once I feel that SNES emulation has reached its limits in terms of research, I'll likely release the emulator under an ISC license as well.
Now I'm sure you can view this as me being hypocritical, and maybe it is, but that's my answer: I feel there's something more important than licensing at stake here.
However, what many of the people I've discussed this have an issue with are:
* Becoming the default init in stable even though it's fairly new (and untested)
* Strong break from how common tasks are done (e.g. logging)
* Applications are very tied together and cannot easily be replaced or left out.
* NIH syndrome (e.g. their DNS resolver that just had a major caching issue)
Apart from your own list of things wrong with it, it is also monolithic, which goes directly against the Unix Philosophy,[1] which when concisely expressed is:
Systemd is an application that more properly belongs on Microsoft Windows and MacOS, because of their own tendency towards centralization and control. But I'm not surprised that many popular Linux distros have chosen to adopt systemd, as they suffer from a bad case of Windows and Apple envy.[1] - https://en.wikipedia.org/wiki/Unix_philosophy
The "systemd concept", from what I understand (and is by no means specific to systemd), is to have a smarter init system for starting processes in order and better process management. Additionally, all the IPC "stuff" that's been happening and being touted reminds me a lot of microkernels where you could write small, simple services that do a single thing over a common, programmatic interface. Systemd however feels much too integrated and makes no effort to make it easy to swap components.
I'm also sort-of shocked that almost all the major distros just switched within a year or two of each other. Especially distros like RH and Debian (yes I know systemd is deved at RH) who bill themselves as "stable."
So there is nothing wrong with wanting a better init system and a common IPC platform, but that doesn't mean systemd is the best we can do.
>goes directly against the Unix Philosophy
"Those days are dead and gone and the eulogy was delivered by Perl." -- Rob Pike
Further, rc.d really isn't anywhere near as bad as SysVinit. See an example of an rc.d script here: https://www.freebsd.org/doc/en/articles/rc-scripting/rcng-ho... (and even with how tiny it is, most of those lines aren't necessary for your average script, either.)
> an intentional and strong lack of portability He doesn't want the added complexity to support OSs which are over a decade behind. Should Microsoft still support Windows XP? Seems like some of the BSDs are already planning on forking it anyways, which is precisely what he wanted.
> pushing software into production servers before it is stable and mature It's been on production servers over at Red Hat for about three years now, and thus quite mature.
> the backroom politics involved in this displacing other competing technologies I haven't seen any proof of this yet, but feel free to link some beyond him showing why systemd is better. Is he actively poaching OpenRC developers or something? Shit, even the upstart creator admitted systemd was designed better.
> the move to corruptible binary log files It's just KEY=value. When a log file is corrupt, it's just the particular portion of the entry which is affected, you can still read the others. Or, just have it forward to the syslog of your choice.
> the assimilation and/or replacement of countless other services that already have more mature and stable implementations While being maintained under the "systemd" umbrella, only journald is required by systemd. Feel free to ignore the rest if you don't approve.
> The PID1 requirement This is _absolutely necessary_ for any init system. The very definition of "init" implies it.
> coupling itself tighter with the kernel There have been zero changes which will _only_ effect systemd.
> the aggressive and hostile attitudes of the lead developers Mr. P is actually incredibly kind and helpful, you shouldn't only look at the few cases where the peanut gallery pipes up. See: Linux, Theo De Raadt...
> the complete lack of choice being provided from nearly all major distros It's always been like this, you just haven't noticed. How many other init systems did they have scripts for before? That's right, none.
> Debian dismissing their heritage as a rock-solid, stable, conservative distro Refer to me mentioning that systemd has been battle tested already, and has the full backing and support from a commercial entity on top of that.
> Further, rc.d really isn't anywhere near as bad as SysVinit You chose one of the simplest examples possible with Mumble, and it's still needlessly complex. RC still uses a scripting language as a necessity instead of declarative syntax, needs a process watchdog, unique device names, socket activation, etc. Compare it to systemd:
[Unit] Description=Mumble Daemon After=network.target
[Service] ExecStart=/usr/sbin/murmurd -fg -ini /etc/murmur.ini
[Install] WantedBy=multi-user.target
I am not especially worried though, as it was just a presentation from [one guy][2] who is not a current member of the [core team][3] or [the FreeBSD foundation][4] and is probably not wholly representative of the entire FreeBSD project.
[1]: http://www.slideshare.net/iXsystems/jordan-hubbard-free-bsd-...
[2]: http://en.wikipedia.org/wiki/Jordan_Hubbard
[3]: http://en.wikipedia.org/wiki/FreeBSD_Core_Team#List_of_membe...
[4]: http://en.wikipedia.org/wiki/FreeBSD_Foundation
GNU/Linux: Desktop
Disclaimer: the following is all very opinionated and 8.1 is the last version of FreeBSD I actively used. Actually, it's still running without any problems on a colocated machine, but it's a bit a "don't touch it" situation, because upgrading even a single piece of software would probably cause a cataclysm of struggle. So I don't touch it (except for the occasional move of something to an Ubuntu vps), but it works like a charm. I've tried version 10 in a virtual machine because it had a new installer, but it was not the best experience ever (FreeBSD's x.0 versions have always been better to skip, the x.1s were fine though). FreeBSD really needed a new installer and they did some great work, but it did not yet feel very solid. On the other hand, I've had to restart the Ubuntu installer often enough as well and I have a love/hate relationship with both of them.
Okay, let's hit it.
FreeBSD: it's clean, it's minimal. It's very good for learning *NIX stuff because you will have to do a lot of configuration yourself. What they do is very well done and I'd say it's hard to break it. Jails are very cool (OS level virtualization), but like everything else in the FreeBSD world, it's quite some work to maintain. If it runs, it runs and will keep on running basically forever. If you want to upgrade stuff, brace, brace. The ports tree was amazing back in the day, but has been overtaken by stuff like apt-get. Installation of bash used to be like this: cd /usr/ports/shells/bash && make install clean. And then, depending on your hardware and de ports dependencies, minutes or hours of waiting on the compilation. You can upgrade your base to any version without having to fear. You fetch a specific version, compile all the things (again, that is a lot of waiting), run mergemaster to fix up your configurations, reboot and you're back. FreeBSD isn't very cutting edge on the level of hardware support, but it comes with OpenBSD packet filter which is the best firewall ever, it's very powerful yet easy to setup. Also, the zfs support is awesome. That file system is truly amazing, very flexible and serious about data integrity. It's cool until it breaks though, 'cause you'll be diving deep in obscure Solaris documentation and just praying to get your data back. But, I had zfs on an external USB drive and you just shouldn't do that. With built-in drives you'll probably be very safe with zfs. To sum it up: if you're patient, care about technology and have a lot of time, FreeBSD is truly a marvellous operating system that will never let you down. It's solid stuff and it's serious, but it is an investment.
Ubuntu: as someone who started with FreeBSD, Linux always felt a bit messy to me. We, the FreeBSD users at the time, used to make fun of Linux guys saying they have scripts for everything. And in some way I still think that's true. ;) The scripts in init.d very often have 'issues'. Ubuntu does a lot of stuff for you automatically. Installation of software couldn't be much easier and many times there's not much to configure. A 'disadvantage' is that you don't have to spend a lot of time figuring out how the software does and what all it's options are, it just works. The way configuration files are organised is pretty neat, with almost everything in it's own dir in /etc/ and foo.d dirs for adding extra options in small config files. (This is very contrary to FreeBSD, where you have one big /etc/rc.conf to configure the stuff that starts when booting and where you can define extra parameters for the software. There's /etc/ for configuring the base system and /usr/local/etc/ for placing files for software that's not in base.) When you're used to pf, iptables i...
It makes the experience in this regard not much different from any apt-get based linux distribution. The old way of having to compile everything makes your system very configurable, but it gets brittle on systems where you have to make big upgrades.
The problem with binary packages on freebsd was that they are frozen at release. So when you use the package manager to install everything you need... then a large package has a security hole (or it already has a hole.. since the packages might be months out of date), and the only way to patch it is by using the ports.
THe only thing packages on freebsd are good for is getting up and running. You'll save a bit of time if you install the packages.. but you have to use ports to upgrade and maintain those packages.
I used it from 3.4-8.. nice to see that they addressed my problem with the new package manager.
The new pkg uses the up-to-date repository by default. It has fixed all this mess, and turned binary packages from something very clunky that nobody really used to something fairly solid that can be used in production. The only reason I use ports nowadays is when I need to set custom build options on a package.
You mean like Netflix And Whatsap do?
If you wanted to create Ubuntu today, would you use GNU/Linux or FreeBSD as base?
FreeBSD has the aim to create a solid Unix environment. IMO FreeBSD is awesome as a server, and okay-ish for the desktop. PC-BSD makes it easier, but still: you need to know what you're doing, but if you do, it's pretty solid.
Even on a single disk ZFS can notify the user what files have been damaged and should be restored from backup.
That is the most important thing for me, I want to make sure that my data is safe.
There is no file system that can protect against corruption if a bit is flipped in memory while reading from/writing to disk, at least with ZFS it can warn me and re-read the data from disk and give the upper layers a valid file.
Even without ECC RAM ZFS's end-to-end checksumming can help save your data and give you piece of mind that it is not silently being corrupted once it's on disk.
Snapshots can also be promoted to fully-fledged filesystems using cloning, which is very handy for spawning off fully-featured jail environments and for setting up boot environments for a host.
Filesystem replication. My primary backups involve using `zfs send` to maintain remote copies of my snapshots on another machine with minimal cost in bandwidth and disk IO.
Filesystem compression. My root pool is just 0.63x the size it would have been thanks to lz4, basically for free.
As X-Isence says, end-to-end data protection. Every bit of data and metadata are checksummed so any errors are detected, and if possible automatically repaired. Crucial metadata is duplicated even on single-disk configurations.
Copy-on-write semantics make for more robustness in face of problems - active data is never overwritten in-place. This also makes for much safer parity RAID than traditional approaches.