I’ll admit it. I have a soft spot for FreeBSD. FreeBSD was the first Unix I ran, and it was somewhere around 20 years ago that I did so, before I switched to Debian. Even then, I still used some of the FreeBSD Handbook to learn Linux, because Debian didn’t have the great Reference that it does now.
Anyhow, some comments in my recent posts (“Has modern Linux lost its way?” and Reactions to that, and the value of simplicity), plus a latent desire to see how ZFS fares in FreeBSD, caused me to try it out. I installed it both in VirtualBox under Debian, and in an old 64-bit Thinkpad sitting in my basement that previously ran Debian.
The results? A mixture of amazing and disappointing. I will say that I am quite glad that both exist; there is plenty of innovation happening everywhere and neat features exist everywhere, too. But I can also come right out and say that the statement that FreeBSD doesn’t have issues like Linux does is false and misleading. In many cases, it’s running the exact same stack. In others, it’s better, but there are also others where it’s worse. Perhaps this article might dispell a bit of the FUD surrounding jessie, while also showing off some of the nice things FreeBSD does. My conclusion: Both jessie and FreeBSD 10.1 are awesome Free operating systems, but both have their warts. This article is more about FreeBSD than Debian, but it will discuss a few of Debian’s warts as well.
The experience
My initial reaction to FreeBSD was: wow, this feels so familiar. It reminds me of a commercial Unix, or maybe of Linux from a few years ago. A minimal, well-documented base system, everything pretty much in logical places in the filesystem, and solid memory management. I felt right at home. It was almost reassuring, even.
Putting together a FreeBSD box is a lot of package installing and config file editing. The FreeBSD Handbook, describing how to install X, talks about editing this or that file for this or that feature. I like being able to learn directly how things fit together by doing this.
But then you start remembering the reasons you didn’t like Linux a few years ago, or the commercial Unixes: maybe it’s that programs like apache are still not as well supported, or maybe it’s that the default vi has this tendency to corrupt the terminal periodically, or perhaps it’s that root’s default shell is csh. Or perhaps it’s that I have to do a lot of package installing and config file editing. It is not quite the learning experience it once was, either; now there are things like “paste this XML file into some obscure polkit location to make your mouse work” or something.
Overall, there are some areas where FreeBSD kills it in a way no other OS does. It is unquestionably awesome in several areas. But there are a whole bunch of areas where it’s about 80% as good as Linux, a number of areas (even polkit, dbus, and hal) where it’s using the exact same stack Linux is (so all these comments about FreeBSD being so differently put together strike me as hollow), and frankly some areas that need a lot of work and make it hard to manage systems in a secure and stable way.
The amazing
Let’s get this out there: I’ve used ZFS too much to use any OS that doesn’t support it or something like it. Right now, I’m not aware of anything like ZFS that is generally stable and doesn’t cost a fortune, so pretty much: if your Unix doesn’t do ZFS, I’m not interested. (btrfs isn’t there yet, but will be awesome when it is.) That’s why I picked FreeBSD for this, rather than NetBSD or OpenBSD.
ZFS on FreeBSD is simply awesome. They have integreated it extremely well. The installer supports root on zfs, even encrypted root on zfs (though neither is a default). top on a FreeBSD system shows a line of ZFS ARC (cache) stats right alongside everything else. The ZFS defaults for maximum cache size, readahead, etc. auto-tune themselves at boot (unless overridden) based on the amount of RAM in a system and the system type. Seriously, these folks have thought of everything and it just reeks of solid. I haven’t seen ZFS this well integrated outside the Solaris-type OSs.
I have been using ZFSOnLinux for some time now, but it is just not as mature as ZFS on FreeBSD. ZoL, for instance, still has some memory tuning issues, and is not really suggested for 32-bit machines. FreeBSD just nails it. ZFS on FreeBSD even supports TRIM, which is not available in ZoL and I think fairly unique even among OpenZFS platforms. It also supports delegated administration of the filesystem, both to users and to jails on the system, seemingly very similar to Solaris zones.
FreeBSD also supports beadm, which is like a similar tool on Solaris. This lets you basically use ZFS snapshots to make lightweight “boot environments”, so you can select which to boot into. This is useful, say, before doing upgrades.
Then there are jails. Linux has tried so hard to get this right, and fallen on its face so many times, a person just wants to take pity sometimes. We’ve had linux-vserver, openvz, lxc, and still none of them match what FreeBSD jails have done for a long time. Linux’s current jail-du-jour is LXC, though it is extremely difficult to configure in a secure way. Even its author comments that “you won’t hear any of the LXC maintainers tell you that LXC is secure” and that it pretty much requires AppArmor profiles to achieve reasonable security. These are still rather in flux, as I found out last time I tried LXC a few months ago. My confidence in LXC being as secure as, say, KVM or FreeBSD is simply very low.
FreeBSD’s jails are simple and well-documented where LXC is complex and hard to figure out. Its security is fairly transparent and easy to control and they just work well. I do think LXC is moving in the right direction and might even get there in a couple years, but I am quite skeptical that even Docker is getting the security completely right.
The simply different
People have been throwing around the word “distribution” with respect to FreeBSD, PC-BSD, etc. in recent years. There is an analogy there, but it’s not perfect. In the Linux ecosystem, there is a kernel project, a libc project, a coreutils project, a udev project, a systemd/sysvinit/whatever project, etc. You get the idea. In FreeBSD, there is a “base system” project. This one project covers the kernel and the base userland. Some of what they use in the base system is code pulled in from elsewhere but maintained in their tree (ssh), some is completely homegrown (kernel), etc. But in the end, they have a nicely-integrated base system that always gets upgraded in sync.
In the Linux world, the distribution makers are responsible for integrating the bits from everywhere into a coherent whole.
FreeBSD is something of a toolkit to build up your system. Gentoo might be an analogy in the Linux side. On the other end of the spectrum, Ubuntu is a “just install it and it works, tweak later” sort of setup. Debian straddles the middle ground, offering both approaches in many cases.
There are pros and cons to each approach. Generally, I don’t think either one is better. They are just different.
The not-quite-there
I said that there are a lot of things in FreeBSD that are about 80% of where Linux is. Let me touch on them here.
Its laptop support leaves something to be desired. I installed it on a few-years-old Thinkpad — basically the best possible platform for working suspend in a Free OS. It has worked perfectly out of the box in Debian for years. In FreeBSD, suspend only works if it’s in text mode. If X is running, the video gets corrupted and the system hangs. I have not tried to debug it further, but would also note that suspend on closed lid is not automatic in FreeBSD; the somewhat obscure instuctions tell you what policykit pkla file to edit to make suspend work in XFCE. (Incidentally, it also says what policykit file to edit to make the shutdown/restart options work).
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! Linux’s md-raid, by comparison, supports RAID0, RAID1, RAID4, RAID5, RAID6, etc. There seems to be a highly experimental RAID5 patchset floating around for many years, but it is certainly not integrated into the latest release kernel. The current documentation makes no mention of RAID5, although it seems that a dated logical volume manager supported it. In any case, RAID5 does not seem to be well-supported in software like it is in Linux.
ZFS does have its raidz1 level, which is roughly the same as RAID5. However, that requires full use of ZFS. 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.
FreeBSD’s filesystem support is rather a miss. They once had support for Linux ext* filesystems using the actual Linux code, but ripped it out because it was in GPL and rewrote it so it had a BSD license. The resulting driver really only works with ext2 filesystems, as it doesn’t work with ext3/ext4 in many situations. Frankly I don’t see why they bothered; they now have something that is BSD-licensed but only works with a filesystem so old nobody uses it anymore. There are only two FreeBSD filesystems that are really useable: UFS2 and ZFS.
Virtualization under FreeBSD is also not all that present. Although it does support the VirtualBox Open Source Edition, this is not really a full-featured or fast enough virtualization environment for a server. Its other option is bhyve, which looks to be something of a Xen clone. bhyve, however, does not support Windows guests, and requires some hoops to even boot Linux guest installers. It will be several years at least before it reaches feature-parity with where KVM is today, I suspect.
One can run FreeBSD as a guest under a number of different virtualization systems, but their instructions for making the mouse work best under VirtualBox did not work. There may have been some X.Org reshuffle in FreeBSD that wasn’t taken into account.
The installer can be nice and fast in some situations, but one wonders a little bit about QA. I had it lock up on my twice. Turns out this is a known bug reported 2 months ago with no activity, in which the installer attempts to use a package manger that it hasn’t set up yet to install optional docs. I guess the devs aren’t installing the docs in testing.
There is nothing like Dropbox for FreeBSD. Apparently this is because FreeBSD has nothing like Linux’s inotify. The Linux Dropbox does not work in FreeBSD’s Linux mode. There are sketchy reports of people getting an OwnCloud client to work, but in something more akin to rsync rather than instant-sync mode, if they get it working at all. Some run Dropbox under wine, apparently.
The desktop environments tend to need a lot more configuration work to get them going than on Linux. There’s a lot of editing of polkit, hal, dbus, etc. config files mentioned in various places. So, not only does FreeBSD use a lot of the same components that cause confusion in Linux, it doesn’t really configure them for you as much out of the box.
FreeBSD doesn’t support as many platforms as Linux. FreeBSD has only two platforms that are fully supported: i386 and amd64. But you’ll see people refer to a list of other platforms that are “supported”, but they don’t have security support, official releases, or even built packages. They includ arm, ia64, powerpc, and sparc64.
The bad: package management
Roughly 20 years ago, this was one of the things that pulled me to Debian. Perhaps I am spolied from running the distribution that has been the gold standard for package management for so long, but I find FreeBSD’s package management — even “pkg-ng” in 10.1-RELEASE — to be lacking in a number of important ways.
To start with, FreeBSD actually has two different package management systems: one for the base system, and one for what they call the ports/packages collection (“ports” being the way to install from source, and “packages” being the way to install from binaries, but both related to the same tree.) For the base system, there is freebsd-update which can install patches and major upgrades. It also has a “cron” option to automate this. Sadly, it has no way of automatically indicating to a calling script whether a reboot is necessary.
freebsd-update really manages less than a dozen packages though. The rest are managed by pkg. And pkg, it turns out, has a number of issues.
The biggest: it can take a week to get security updates. The FreeBSD handbook explains pkg audit -F which will look at your installed packages (but NOT the ones in the base system) and alert you to packages that need to be updates, similar to a stripped-down version of Debian’s debsecan. I discovered this myself, when pkg audit -F showed a vulnerability in xorg, but pkg upgrade showed my system was up-to-date. It is not documented in the Handbook, but people on the mailing list explained it to me. There are workarounds, but they can be laborious.
If that’s not bad enough, FreeBSD has no way to automatically install security patches for things in the packages collection. Debian has several (unattended-upgrades, cron-apt, etc.) There is “pkg upgrade”, but it upgrades everything on the system, which may be quite a bit more than you want to be upgraded. So: if you want to run Apache with PHP, and want it to just always apply security patches, FreeBSD packages are not up to the job like Debian’s are.
The pkg tool doesn’t have very good error-handling. In fact, its error handling seems to be nonexistent at times. I noticed that some packages had failures during install time, but pkg ignored them and marked the package as correctly installed. I only noticed there was a problem because I happened to glance at the screen at the right moment during messages about hundreds of packages. In Debian, by contrast, if there are any failures, at the end of the run, you get a nice report of which packages failed, and an exit status to use in scripts.
It also has another issue that Debian resolved about a decade ago: package scripts displaying messages that are important for the administrator, but showing so many of them that they scroll off the screen and are never seen. I submitted a bug report for this one also.
Some of these things just make me question the design of pkg. If I can’t trust it to accurately report if the installation succeeded, or show me the important info I need to see, then to what extent can I trust it?
Then there is the question of testing of the ports/packages. It seems that, automated tests aside, basically everyone is running off the “master” branch of the ports/packages. That’s like running Debian unstable on your servers. I am distinctly uncomfortable with this notion, though it seems FreeBSD people report it mostly works well.
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.
For a package as concerned about licensing as FreeBSD, the packages collection does not have separate sections like Debian’s main, contrib, and non-free. It’s all in one big pot: BSD-license, GPL-license, proprietary without source license. There is /usr/local/share/licenses where you can look up a license for each package, but there is no way with FreeBSD, like there is with Debian, to say “never even show me packages that aren’t DFSG-free.” This is useful, for instance, when running in a company to make sure you never install packages that are for personal use only or something.
The bad: ABI stability
I’m used to being able to run binaries I compiled years ago on a modern system. This is generally possible in Linux, assuming you have the correct shared libraries available. In FreeBSD, this is explicitly NOT possible. After every major version upgrade, you must reinstall or recompile every binary on your system.
This is not necessarily a showstopper for me, but it is a hassle for a lot of people.
Update 2015-02-17: Some people in the comments are pointing out compat packages in the ports that may help with this situation. My comment was based on advice in the FreeBSD Handbook stating “After a major version upgrade, all installed packages and ports need to be upgraded”. I have not directly tried this, so if the Handbook is overstating the need, then this point may be in error.
Conclusions
As I said above, I found little validation to the comments that the Debian ecosystem is noticeably worse than the FreeBSD one. Debian has its warts too — particularly with keeping software up-to-date. You can see that the two projects are designed around a different passion: FreeBSD’s around the base system, and Debian’s around an integrated whole system. It would be wrong to say that either of those is always better. FreeBSD’s approach clearly produces some leading features, especially jails and ZFS integration. Yet Debian’s approach also produces some leading features in the way of package management and security maintainability beyond the small base.
My criticism of excessive complexity in the polkit/cgmanager/dbus area still stands. But to those people commenting that FreeBSD hasn’t “lost its way” like Linux has, I would point out that FreeBSD mostly uses these same components also, and FreeBSD has excessive complexity in its ports/package system and system management tools. I think it’s a draw. You pick the best for your use case. If you’re looking for a platform to run a single custom app then perhaps all of the Debian package management benefits don’t apply to you (you may not even need FreeBSD’s packages, or just a few). The FreeBSD ZFS support or jails may well appeal. If you’re looking to run a desktop environment, or a server with some application that needs a ton of PHP, Python, Perl, or C libraries, then Debian’s package management and security handling may well be attractive.
I am disappointed that Debian GNU/kFreeBSD will not be a release architecture in jessie. That project had the promise to provide a best of both worlds for those that want jails or tight ZFS integration.
Well FreeBSD changing their X to require hal was commented with laughter on the sides of the real BSDs. We always felt FreeBSD was “something like a Linux”.
But then, the BSDs don’t have that much modern features like FreeBSD has, like zfs.
On the other hand, you get more classic, more simple systems with OpenBSD, NetBSD and MirBSD. The latter also got rid of csh ;-)
It looks like FreeBSD backtracked on HAL being required for X all the time, but it is still required for some use cases. (USB devices being presented to VirtualBox guests, for instance)
There is no need to reinstall binaries after a major version upgrade. You can keep your old binaries and install the compat port/package.
That’s not what the FreeBSD Handbook says:
https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/updating-upgrading-freebsdupdate.html
“After a major version upgrade, all installed packages and ports need to be upgraded” Questions on freebsd-questions produced similar comments.
That is more or less is a documentation bug, where it is taking the easy way out even though it leaves the reader with lots of extra work. That in turn is indicative of a larger problem with the FreeBSD core team, and it isn’t the only symptom of that problem (various aspects of pkgng and changing ports over to it, aspects of ports management, the repeated communication failures surrounding the introduction of unbound, how zfs can get you into a right bind should an update botch that the documentation is eerily quiet about, and a few others spring to mind), but I digress. This particular problem however is mostly a failure to explain how, even that, the backward compatability works.
And that’s a pity, because the mechanism itself is quite interesting. You see, there’s this kernel module that provides a shim for a previous major version’s ABI and translates it to the current ABI. Add the original previous libc and friends, and you can run binaries for previous major versions for the same architecture, the binaries won’t know the difference.
In fact, the same trick is used to support linux binaries; the “linuxulator” works exactly this way. Since the syscalls are emulated it only works up to a point, some of the more exotic linux-only syscalls aren’t available (yet, possibly) and so not everything works, but quite a lot of it does work nicely.
There’s more, like how such older packages complicate upgrades and dependency management and how this very new pkgng tool relates to those. But the bottom line is that FreeBSD does have optional but functional backward ABI compatability all the way back to FreeBSD 4, even if it neglects to tell you about it.
Maybe you should give Debian kFreeBSD a try? It won’t be an official Jessie target, but there are still people putting a lot of work into it to have it as a working (unofficial) release.
Already on my list, yes ;-)
If you have a FreeBSD system already running, you can also just debootstrap Debian kFreeBSD into a jail and fire it up (debootstrap and dpkg are directly installable with pkg). My main Debian system these days is in a jail running ssh on a FreeBSD server.
I agree with much you’ve said in these three blog posts, and I’m all the more determined to continue working on Debian GNU/kFreeBSD. (I’ve sadly not given as much time to it in recent weeks). There’ll still be some kind of jessie release but can’t say exactly when that’ll be ready.
I do see it as a bridge between Debian and FreeBSD projects, bringing the former’s packaging and policy, security support and free software ideology to the latter’s excellent core system. It should be useful as a chroot or jail on top of regular FreeBSD, and of course as a standalone system installed with Debian’s own installer.
We haven’t really tackled yet the desktop and laptop usability issues you’ve described, so we’re probably doing worse than GNU/Linux jessie and FreeBSD in that regard. But my own taste would be to solve these in the most intuitive way for someone with UNIX/Linux experience to automatically understand (just use sudo? shell scripts? plain-text configuration) rather than the streamlined but radical approaches of systemd, policykit and other mechanisms that usually must be learned afresh.
I feel compelled to work on this, as to me, Debian GNU/Linux jessie will be something of a downgrade to a less-understandable (therefore less free and open) system that makes me uncomfortable and unhappy. Yet Debian has some advantages over FreeBSD that are difficult to let go of. So unless something better comes, I’ll feel obligated to switch more systems to Debian GNU/kFreeBSD, as GNU/Linux squeeze and wheezy become obsolete.
Thank you for this very detailed research, avoiding the usual trolls, and specifying good use cases ( ex why do I need licenses information in the entreprise field)
I would advocate against using GNU k/FreeBSD
II tried to use it to build a NAS in 2012, and it failed on many aspects ( see http://unix.stackexchange.com/a/48598 with links to bug reports)
I ended up with ZFS on Linux. I don’t think the situation has changed that much.
Well, stop thinking, start tinkering. 2012 is three years, or one Debian release, ago.
That was an interesting write-up in 2012, I wish I’d seen it at the time. Some of those issues are fixed in the meantime, but some still wait for someone to fix them. Coincidentally I’ve been running GNU/kFreeBSD on my NAS since 2012, and more recently on the desktop, and other core developers do too (cf. other comment about Linux devs using Apple Macs!).
Not everyone has a great experience right away: it may be that awkward hardware or a combination of minor bugs can become a roadblock to a newcomer. I’d like others’ out-of-box experience to be in line with how smoothly I’ve now got it to work on my own systems, so we should consider overriding some packages and default configuration for an unofficial jessie release.
Official Debian stable doesn’t usually allow to fix bugs unless they’re ‘serious’, but in an unofficial release I’d like to be more open to fixing minor nits, based on the simplicity of the change/patch or a proof of its correctness (e.g. a supplied regression test), instead of only on the severity of the bug. It’s the combination of small bugs – already known and maybe fixed in sid – that add up to users having a frustrating experience, and I’m sad to see that happening.
Regarding documentation, many good ideas came up in these blog posts and comments. It seems it would be helpful to have a ‘high-level’ overview of which parts come from Debian GNU or from FreeBSD, the main differences in syntax for users familiar with those other systems, and perhaps a walk-through of the whole boot process up to a graphical desktop running.
FreeBSD does have ABI compatibility. The thing that is incompatible between major versions are the libraries in the base system (openssl, etc)
For these, there is a package, for example, to run binaries from 9.x on a 10.x system, install: compat-9x
The statement regarding ABI stability is not quite true, there is no need to reinstall or recompile all your packages after a major upgrade.
Regarding Dropbox, FreeBSD has kqueue that can be used instead of inotify, for file system notifications.
My understanding is that kqueue cannot be used to track tens of thousands of files or directories?
On the contrary kqueue events can track /all/ filesystem events, essentially drinking from the hose. With inotify on linux: there is no way to establish race-free recursive inotify watches of directories or renames; and one quickly runs out of file descriptors and watch instances limits. Kqueue/Kevent is more like a firehose – and one subscribes what events to receive, is generic and superseed a few linux APIs combined.
kqueue/kevent is an effective combination of inotify and epoll and surely can do the same thing. Moreover, there is a devel/libinotify port that wraps kqueue API into inotify_ one.
The thing with FreeBSD is, being able to install everything according to one’s wish. So that even X Windows do not come preinstalled. That also makes it possible to work on very old PC’s with 128MB RAM. I haven’t used FreeBSD on a commercial environment. To me it’s basically a learning platform on which I can try different software, see how it works, etc.
This is true, but is not unique to FreeBSD. Both Debian and FreeBSD list 64MB RAM required on their i386 platforms. FreeBSD requires 1.5GB disk and Debian “requires” 1GB disk. These numbers are virtually identical. Debian can make do with less disk space as things expand because it separates out development files into optional packages.
Debian also says ” The actual minimum memory requirements are a lot less than the numbers listed in this table. Depending on the architecture, it is possible to install Debian with as little as 20MB (for s390) to 60MB (for amd64). The same goes for the disk space requirements, especially if you pick and choose which applications to install; see Section D.2, “Disk Space Needed for Tasks” for additional information on disk space requirements. ” A minimal Debian amd64 installation takes up less than 500MB, and it would be even smaller on i386.
Sources: https://www.freebsd.org/doc/handbook/bsdinstall-hardware.html and https://www.debian.org/releases/stable/i386/ch03s04.html.en
Isn’t that also true for Debian? It’s quite easy to install it without Xorg. And the minimum hardware requirements for Wheezy on amd64 https://www.debian.org/releases/stable/amd64/ch03s04.html.en seem pretty low to me.
Last time I used FreeBSD was about 3 years ago; it was version 7.4. These days I’m trying to compile OpenJDK 7 on Ubuntu using icedtea; a demanding task on the scale of my experience. And during this task the most challenging parts were about the Xorg. At one stage as I was trying to compile&install “cairo” I have messed up the built-in Xorg and it was no longer booting into Desktop ; I have fixed it but it still has problems on “nautilus” Ubuntu’s file management.
I mean when I undertake such a challenging act as compiling OpenJDK, me not knowing all the parts of the OS causes arbitrary troubles.
On FreeBSD I was feeling like a part of the OS, because it was forcing me to take care of everything. FreeBSD is simply more tidy than Linux, or at least I feel like that. I’m considering installing a FreeBSD soon again, just to try and see compiling OpenJDK on it.
Is it harder than:
apt-get build-dep openjdk-7-jdk
apt-get -b source openjdk-7-jdk
? It seems like this ought to do it.
Both yes and no.Surely there must be ways of installing a version of OpenJDK on Linux like apt-get but the reason I build it manually is because eventually I want to build it on a PowerPC Mac and there’s no pre-compiled package of OpenJDK 7 on PPC Mac, I have to build it from scratch.
So here Linux serves as a learning platform to me :)
I don’t know about Ubuntu, but on Debian OpenJDK is built for powerpc: https://packages.debian.org/search?keywords=openjdk-7-jre
I also don’t know much about Ubuntu, but there are files like http://ports.ubuntu.com/ubuntu-ports/pool/main/o/openjdk-7/openjdk-7-jdk_7u75-2.5.4-2_powerpc.deb in their repository, so you can probably use apt-get to install binary packages of OpenJDK 7 on powerpc there (btw: the commands John Goerzen posted don’t install binary packages but build OpenJDK from source!). Or did you want to build OpenJDK on a PPC Mac running OSX?
Oh yes, I meant the PPC Mac OSX of course. Currently the biggest version of OpenJDK for PPC Mac OSX is 6 and the only way to get the JDK 7 it seems is to compile OpenJDK from scratch.
Using FreeBSD almost exclusively from 4.0. FreeBSD-HEAD for about 2 years now (10 and 11 respectively) on a business HP laptop. In 20 minutes from booting the install media you have, without touching but rc.conf and .xinitrc, a full production system. From developing environment and office to multimedia. Everything installed via pkg, except a handful of programs installed from ports for which the binaries were compiled with different options than required by my personal preferences.
It just works always reliable where GNU/Linux had failed me over and over again.
Regards.
That sounds more like my experience with Debian :-)
It’s perfectly possible to have what you describe on FreeBSD, of course, but it depends on how much you demand of your system.
Even if acpiconf -s 3 works while you’re in X, your desktop environment won’t be able to use it unless you edit some .pkla files. So it won’t automatically go to sleep when you close the lid. Ditto for restart or shutdown. These things work out of the box on Debian. That’s just an example.
How about getting notified when your packages are out of date? update-notifier is installed by default in Debian. Or automatically installing security patches? Can’t be done except for the base system in FreeBSD, as far as I can tell.
FreeBSD is primarily geared towards the server and network environment, hence it’s strengths are ZFS and it’s tremendous network stack. FreeBSD high performance and scalability are far greater than Linux. There’s a reason why companies such as NetFlix and Juniper Networks chose FreeBSD and not Linux. Linux fails poorly when it comes to high computing and scalability.
Comparing Linux and FreeBSD on the desktop/laptop is somewhat pointless. FreeBSD community is not necessarily concerned with the client level of the computing world, and puts it’s energy towards high-computing environments. So, you can use FreeBSD as a desktop, but you’ll have to do some work and may even have to give up some conveniences. Most BSDs are for the server primarily for that matter.
“Apparently this is because FreeBSD has nothing like Linux’s inotify.”
FreeBSD has kqueue, and has for awhile. I don’t know why Dropbox isn’t available on FBSD.
https://en.wikipedia.org/wiki/Kqueue
http://www.unix.com/man-page/FreeBSD/2/kevent/
So, why not try Windows for once? Why does it always have to be Unix this, Linux that?
Trololololol
We should try OpenVMS too, right?
Longtime BSD user from 4.1 (and v7 on pdp11) I can say this article nails it. I still run a large bevy of freebsd hosts but I also run Debian and raspbian and my experience is pretty much this Linux users. I prefer the BSD systems for my research in networking but the lack of fq_codel is telling. Even Van Jacobsen now routinely releases code for Linux first. How things change
Might want to check out PC-BSD. From http://www.unixmen.com/dru-lavigne-talks-freebsd-interview/:
“If I’m approaching FreeBSD as a desktop user, I’m using the version of FreeBSD that is pre-configured as a desktop: PC-BSD. It’s still FreeBSD, but why spend several hours installing and configuring desktop apps when PC-BSD does this for me, while still allowing me to customize the desktop during and after installation? As a desktop user, PC-BSD provides a choice of window managers, graphical front-ends to common administrative and customization tasks, as well as some cool applications like the AppCafe® for managing software, an Update Manager for managing security advisories and upgrades, Warden® for managing jails, and Life Preserver for automating backups.
In my experience, FreeBSD is a user-friendly server and PC-BSD is a user-friendly desktop.”
There are some things about PC-BSD that really scare me — from the Wikipedia article on how its package manager works, it seems like the PC-BSD approach is to “give people that crap they’re used to, because then it’ll be familiar.” Monolithic clickwrap installers – ugh. That is just a gut reaction from Wikipedia, though, so I’m open to be shown to be wrong.
That is terribly old information you are spouting off…
PC-BSD has been using the exact same pkg system as FreeBSD since 10.0 was released – the old PBI container system was required as an alternate to all the issues with the old pkg_* tools on FreeBSD, but with pkg(ng) on FreeBSD now in use everywhere the PBI system has just become an additional information wrapper (for things like screenshots, plugins, icons, similar applications, etc – things that you would need for a “modern” interface for casual users).
As a happy FreeBSD user:
Raid5 is worse than useless: http://www.zdnet.com/article/why-raid-5-stops-working-in-2009/ . Under linux md I have lost data to this problem (yes, raid is not supposed to be a substitute for backups, but I was a student at the time and couldn’t afford better). Raidz1 solves the problem correctly.
ext2 is plenty good enough for e.g. USB sticks, or /boot on a dual-boot system so you can edit grub.conf from Linux or FreeBSD. It’s not useless.
If you want a smoother install process, PC-BSD is the way to go.
Polkit/hal/dbus are annoying linuxisms that are sadly forced on FreeBSD by upstream (one of the big reasons I’m worried about systemd). Note that nothing in the base system requires them, only ports. Again, FreeBSD’s primary audience seems to be for solid server systems; PC-BSD is where you’ll find more support for a mainstream X-based GUI and such desktop-oriented things. But I must say I don’t share your experience; in many years I’ve only ever had to edit one hal file, and it was the same one I had to change on linux before linux switched to yet another different approach (fun fact: I still don’t know how to configure linux to use a dvorak layout at the X login screen).
The pkg tool is a rewrite that was new in the current version; the package-management tools in 9 are rock solid. That shouldn’t be an excuse to break things and it’s possible the new thing has been released before it’s ready, but medium-term I’m very confident the FreeBSD folks will produce something very solid.
ABI stability is better than linux, IME. As per your follow-up, you need the packages for it.
Not supporting RAID5 also means that you don’t support RAID6, by the way.
RAID6 is a grossly inefficient way to achieve the same level of safety as raidz1.
@Imm : You are very, very much mistaken.
You seem to be confused about ZFS raid levels.
raidz1 is the equivalent of raid5
raidz2 is the equivalent of raid6
While ZFS offers self-healing through checksums, there is no universe, known or unknown, in which raidz1 provides the same level of safety as raid6.
raid5 allows you to lose the one drive
raidz1 allows you to lose the one drive
raid6 allows you to lose 2 whole drives
raidz2 allows you to lose 2 whole drives
I should know, I designed the RAID arrays for the ZFS pools we run in production.
@OP :
That is a pretty good article and I enjoyed reading it.
I’m afraid your view is somewhat skewed towards the user end of the scope here, what with desktop environments and laptops.
Keep in mind that FreeBSD is much more oriented towards server environments, in which it’s rock solid.
Regarding package management, as a FreeBSD user since 4.2, I am delighted with the ports system.
Debian has always had this way of forcing me to install rubbish dependencies from pre-built packages.
No, I do not want openssl with that apache install thank you very much, and no, I have no need for TLS support in cURL.
The ports system in FreeBSD allows one to tailor options to their needs, resulting in lower exposure to threats and vulnerabilities.
Lastly and regarding file systems.
I acknowledge your points and indeed UFS2 is growing old.
However, I should point out that :
– it is possible to read Linux file systems from FreeBSD
– it is NOT possible to read FreeBSD file systems from Linux
See what I’m getting at ? ;)
There is Dropbox on FreeBSD, using the Dropbox API, on Github (it’s basically a collection of shell scripts). The only thing missing is a GUI, but do you really need it?
I tried to find what you’re talking about, but the only ones I could find were ones that did not do the immediate real-time sync that Dropbox is famous for.
I solved it with a cronjob. Indeed, this one feature is missing.
As a side note on stability of FreeBSD in summer of 2012 which was the last time I installed FreeBSD for i386, I had installed FreeBSD 9.0 but later I had to switch back to version 7.4 because 9.0 caused neverending harddisk read/write cycles. 7.4 was working perfectly.
WRT “Its other option is bhyve, which looks to be something of a Xen clone” I thought you might be interested to know that there has been a lot of work going on recently to allow FreeBSD to run as a Xen domain 0 (control domain) using the new “PVH” mode of operation. I believe running as a guest domain has been supported for a while now as either old-style PV or HVM.
A lot of people don’t realise it but Xen is largely OS agnostic, even for the control stack and Xen has a long history of supporting *BSD, mostly via NetBSD (since the 2.x days). These days most of the active work is on FreeBSD AFAICT.
Talkin about ABI stability – is worth to mention that NetBSD provides binary compatibility down to version 0.9, see http://netbsd.gw.com/cgi-bin/man-cgi?options+4+NetBSD-current in section “Compatibility Options”.
Its laptop support leaves something to be desired. I installed it on a few-years-old Thinkpad — basically the best possible platform for working suspend in a Free OS.
Right. Typing this on an old Thinkpad X30 with broken s2ram (has been broken, like, forever) and no sound, running the currently frozen testing. Laptop support – in general – is really no fun, stuff works, then breaks, then might work again someday. Of course, this laptop is so old that hardly anyone uses it anymore…
Suspend works fine with my laptops.
Filesystems: could be better, yes, but situation is not that good in linuxland either: even primary fs as ext4 are subject to corruption those days.
Base & Ports: one of the strenghs, it allows to separate what define the OS and what defines 3rd party value. This separation allows interesting concepts build upon FreeBSD such as PC-BSD PBI, instead of “yet another debian spin”.
Btw, pkg/ports have a much cleaner organization that follow upstream project design, in opposition of the splitting done especially in debian packages. And don’t get me started on -dev(el) packages…
Hackability of ports is also something fantastic, you can configure your system as wanted, and even very easily inject your own patchs as needed, which really help to submit patches and version update.
One last note: there is quarterly release security branches for packages, but I tend to think it is delusion those days to hope catch every fix in security branch: so many projects don’t bother and fix them in feature releases…
There is a lot here that’s incorrect. Linux filesystems are rock-solid and have been for years. ext4 is solid. I have administered both small laptops and large server farms and never an issue. It just works. This is a typical experience.
Whether forcing the user to install dev files they don’t need is a feature or a bug is, I guess, an opinion. To me it’s a bug, because it’s trivial to get the -dev packages when you want them in Debian anyhow.
But you didn’t really address my issues: pkg(8) not having proper error handling, security updates taking up to a week to be built, no way to easily script applying security patches. These are my real concerns. Taking too much disk space is annoying, but making my life difficult on a daily basis by not automating security is showstopper.
You mention a lack of virtualization (and FreeBSD not supporting Xen Dom0 is…dumb), but doesn’t FreeBSD support running as a qemu-kvm hypervisor, nowadays?
The Handbook doesn’t mention it. I don’t know?
” FreeBSD not supporting Xen Dom0 is…dumb”: It’s coming, see http://wiki.xen.org/wiki/FreeBSD_Dom0 and https://wiki.freebsd.org/FreeBSD/XenNG
FreeBSD is a really good OS.
It is difficult to compare it to a Linux because both its method of development / architecture, and more importantly, it’s expected method of use by users… is different.
At the end of the day, neither is polished, yet you can still use essentially all the same GUI’s and tools day in and day out on both OS.
How you get there is up to you.
disclaimer: i started linux, then used fbsd, then linux, and have now permanently settled on fbsd.
Having extfs support in FreeBSD is not that important, because this filesystem is only used by Linux anyway. The only reliable “driver” available for accessing it is the Linux kernel itself. That’s the definition of a proprietary file system. ;-)
In a desktop environment, reliable NTFS and FAT support is much more important, and FreeBSD worked fine with FUSE last time I checked. OSX doesn’t have any extfs support at all and nobody cares. Even as a UNIX die-hard I consider having stuff like USB drives formatted with ext4 a stupid idea.
In a network/storage/server environment, you usually set up a Linux node which exports its extfs filesystems via NFS and you can access it from FreeBSD, done. That’s what I did for migrating my ext volumes after migrating my desktops and servers away from Linux (Linux is really past its prime now, although it served me for good 20 years)
“Apparently this is because FreeBSD has nothing like Linux’s inotify”
Really? What about kqueue? libnotify?
I used to be a diehard BSD user but switched over to Linux over a decade ago and over the years Ive gotten used to the niceties in Linux that are missing or incomplete in most BSDes. My main point of friction is that the command-line tools have not gotten any of the nice tweaks and updates that Linux tools have. Maybe Im spoiled but having to write a long command-line to do something that is one command in Linux reminds of UNIX from over 20 years ago.
Well we can agree to disagree there.
It has taken *years* for the “-d” flag for `du’ to be implemented on Debian.
–max-depth is so much practical to write I guess.
YMMV
First I am stunned, how much content there is in the Debian-ecosystem, you can spend time on reading, maybe also responding to , if you feel you are determned to do so. It’s positive in my opinion, it does not cost too much time, because it is optional. If you want the software and the binaries only, you are fine, too.
I tried out FreeBSD. It is doing fine as a headles server, then you can even bootstrap GNU/kFreeBSD on it inside a jail or something, if you need Debian-specific things on it, say an apt-cacher or the like.
Of course you could learn a lot of things, when adding an X-server to it and building your own Desktop-system, FreeBSD-tutorials usually work. But it’s probably not worth the effort for productive use, because your FreeBSD-system can also easily be turned into PC-BSD, by adding the according repository to it. It has a different package-management-system then and comes reasonably preconfigured for desktop-use.
b-hyve virtualization also works for headless systems only as far as I know, no X-virtualisation supported.
Regarging the lack of dropbox support: syncthing seems to have freebsd support, so it might be worth a try.
Предлагаем полностью рабочее ПО/We offer a ready solution for ЛИРА-САПР 2016 ВСЕ МОДУЛИ (CRACK – Dongle emulator/Custom license/Patch). Полная поддержка наших решений. Тестирование перед оплатой/Full support for our solutions. Testing before payment. Контакты/Contacts: nodongle24 /@/ gmail.com (remove spaces and /)
Hasp Srm Dongle Emulator, Minilock Hid Dongle Emulator, Sentinel Shk Dongle Emulator, Megalock Korea Dongle Emulator, Wibu Codemeter Dongle Emulator, Sentinel Shk Dongle Emulator, Sentinel Superpro Dongle Emulator, Tinyhid Dongle Emulator, download, Dinkey 1s Dongle Emulator, Sentinel Scribe Dongle Emulator, Rockey 4nd Dongle Emulator, кряк, Sentinel Eve3 Dongle Emulator, NetROCKEY 4 Dongle Emulator.
Do you basic app installs so you can spread in the app trust in chart? Then we can commandeer you. We do provide app installs for only 0.04$ per install. We do fix up with provision app installs seeking both Android and IOS apps. All our installs are from honest users.
best nclex review app ipad
To bad I came across this post a year after. I still want to make my 2c though.
The first reply I saw was Mirabilo’s, and I stopped right there. I understand what he says, and probably his (is Mirabilo a he or she? Can’t really know based just on the name, sorry) reasons also.
However, being classic just for the sake of being classic doesn’t really help solving modern situations. Many times, one must experiment with different approaches. Take a wing design, for example. Would us stick to the classic double wings design of early 20th century, would we be able to cruise at supersonic speeds today?
There should really be no place for “we don’t do that like this because it is not how we do it” simple justifications. Instead, we all should go “well… we don’t do that like this because that would require us to rebuild a series of things, and we don’t really want to do that”. That is a more sincere justification, and I believe it helps us all mitigate the battle between good and evil that always surround any and every POV discussion.
Congratulations, John, for the really very mature and solid article.
“To bad” should read “Too bad”. Sorry for that. Keyboard typo.
No dropbox?? Try unison.
@Robert Unison is that really cool OCaml file sync project, isn’t it?
I like Unison. I wonder if there are any attempts to “2018” it with some kind of IPFS or other distributed storage integration.
Re: FreeBSD RAID5/6 support — one can use ZFS raidz1 as just a volume manager by exporting a “ZVOL” for use by another filesystem. Maybe not ideal, but you don’t have to commit to ZFS for the filesystem.
Afaik bhyve is conceptually KVM for FreeBSD. though no common code.
where as Xen has a similar structure to VMware.
See also:
https://en.wikipedia.org/wiki/Bhyve
https://wiki.freebsd.org/bhyve
http://www.bhyve.org/
I believe it came out of NetApp, and given how much BSD is floating around in Juniper and other appliances – I wouldnt doubt that its used in production widely (though discretely) in specific circumstances
BSD isn’t meant for desktop use. I don’t care if you want to spend your entire 14 hours a day configuring your printer or graphics card for that reason because you have no life and end up having it APPEAR to be one. Even Linux sucks for a desktop but is better than BSD, it is more mature. BSD shines as a server OS, plain and simple. It has features Linux doesn’t have or has but are much better run on the BSD OS, which appeals to major entities like yahoo, banks, WhatsApp and others. I don’t know them all but off the top of my head, they are ZFS, jails, networking stack, Neither are better or more secure than each other, it depends on your use case. Gustavo is right, just because its classic doesn’t mean its the right way. Just like classic cars look nice but absolutely suck as a vehicle in the modern era..I wouldn’t waste my time discussing differences between BSD and Linux unless I was making some serious money from it.
@jgoerzen @eludom #debian has been dropping architectures, actually NetBSD is the one that focuses on running everywhere.
Debian
I write this in the context of my decision to ditch Raspberry Pi OS and move everything I possibly can, including my Raspberry Pi devices,…