Ask HN: Can we talk about FreeBSD vs. Linux? - <AUTHOR> 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. <comment><USER3> Like others have said, being unbiased is difficult, but I'll try. First, Linux v FreeBSD is really tough, so I will instead approach this from Debian v FreeBSD.

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 of ALSA, and just in general I favor the BSD/MIT/ISC licenses to the GPL.

I very much like that FreeBSD is much more conservative about major changes, and open to choice, so we don't get things _like_ systemd, Pulseaudio, etc pushed on us before they are ready for production. I used to love this about Debian as well, but they've really lost their way as of late in pushing systemd on everyone before it was ready. I greatly value stability over whiz- bang bleeding edge features. I like that FreeBSD is run by a democratically elected core team instead of by a benevolent dictator (I don't have to read what crazy thing Linus or Theo said today in the news.) I like that FreeBSD isn't balkanized into hundreds of different distros. I _love_ not having people telling me to say "GNU/FreeBSD" whenever I mention FreeBSD. I like that third-parties like Redhat don't exert so much control over upstream.

I like the community of FreeBSD more, as it feels that most of the members are more technically oriented. Distros like Ubuntu have brought in a lot of users with little to no experience nor interest in learning the unix way of doing things. I'm not saying this is a bad thing, or that I think less of eg Ubuntu users, just that I prefer the company of sysadmins and developers over gamers and web surfers. I dislike that I can't really discuss the OS with anyone in real life, because it's too niche.

<comment><USER4> What stopped me from using FreeBSD a year ago was lack of automatic tab completion on the shell.

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.

<comment><USER5> The default shell in freebsd is probably still sh, which does not have tab completion. The Linuxes long ago moved to bash, which does.

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.

<comment><USER6> Few minor corrections as several posts in this thread suggest outright installing bash just to achieve tab completion in FreeBSD.

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...](https://www.freebsd.org/doc/en/articles/linux- users/shells.html)

[2] [https://svnweb.freebsd.org/base/head/etc/master.passwd](https://svnweb.freebsd.org/base/head/etc/master.passwd)

[3] [https://en.wikipedia.org/wiki/Tcsh](https://en.wikipedia.org/wiki/Tcsh)

[4] [http://www.tcsh.org/TipsAndTricks](http://www.tcsh.org/TipsAndTricks)

<comment><USER7> +1 I'm confused as to why so many people are saying that FreeBSD doesn't autocomplete when it always has.

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

</comment></comment></comment></comment></comment><comment><USER8> Long time reader, first time poster.

I've run FreeBSD on laptops, desktops and servers since 2.2.7. Laptops are not its strong suit. It works great for me as a desktop, but I've been tinkering with X desktop configurations for a long time, and don't mind doing some work to have a desktop that functions precisely the way I want it to. Also, it is not my only desktop. (/usr/ports/sysutils/synergy FTW!)

Servers and network appliances are where FreeBSD really shines. The ports tree can be updated independent from the base OS and the base OS can be updated independent of ports. No upgrading to a new OS just to get a security fix for your web server.

ZFS is brilliant. ~7 years of FreeBSD/ZFS and no issues.

PF makes every other firewall I've run (including every commercial option) look silly. PF is like the Python of firewalls: optimized for readability. Add in CARP and PFsync for easy fault tolerance.

The project is managed by a democratically elected core group. Like a real democracy, sometimes this means change happens slowly. But the deliberate approach to change is part of what makes FreeBSD great. It's stable, predictable, and reliable. It functions as a well-engineered, well-documented whole.

FreeBSD's biggest fault is how little attention it draws to itself. It is quietly brilliant. It just works. It doesn't try to do everything. It's just good, reliable infrastructure.

<comment><USER9> _No upgrading to a new OS just to get a security fix for your web server_

In thoery, yes. But in practice, not really. The port maintainers build/test the ports against whatever the current version of FBSD is.. and if you're system is more than a version or two out of date (and you have an up to date ports tree), you'll find broken ports throughout it.

<comment><USER8> Sure, sometimes. Can't say it's been an issue for me. I'm sure it's more or less frequent depending on which ports you favor and how far you drift from release. (And it goes without saying: open source, send patches, etc.)

To be fair, I've found fewer excuses to not stay current on the OS since freebsd-update. cvsup and building your own source worked fine, but it was a little tedious.

pkg has done the same for the ports tree. If you just need the tool on the box now, pkg install bash. If you care about how the tool is configured, cd /usr/ports/mail/postfix; make config-recursive && make install clean. It all just works, works well, and works well together.

There have been some threads on HN lately about the frustration of changing the UI for the sake of changing the UI. FreeBSD rarely surprises me. When it does, the documentation usually sets me straight. (Or a few minutes browsing <[https://docs.freebsd.org/mail/>.](https://docs.freebsd.org/mail/>.))

I lived through a lot of This vs. That flame wars and I've learned to roll with whatever the choice is. At the end of the day, they're all just tools I use to do my job; I use whatever tools are in vogue. But as a professional user of tools, FreeBSD is a very well designed tool and I wish I got to use it more. It makes my job easy.

</comment></comment></comment><comment><USER10> FreeBSD user since 2.0.5 (1995) - Linux since 0.95

I have always found that FreeBSD has had a much cleaner and more orthogonal feel as a system than any of the Linux distros and was always much more familiar for UNIX 'old hands'. If you come from the school where UNIX systems shouldn't have displays or the frippery associated with PCs and should be interacted with from a terminal you will probably be comfortable with FreeBSD. It shines as a rock-stable server O/S and in most cases trying to use it as a desktop is going to be fairly frustrating - the easiest way round this is not to bother and buy a MacBook Pro.

My view is that in the late 90s early 2000s adoption was impacted fairly significantly by two rather flaky major releases (3.0 & 5.0) where major bits of the system (SMP/Giant lock) were upgraded and took a long time to stabilise. These felt like a step back from the previous rock solid releases (2.2.8 & 4.11). Realistically the next really good release was the 8.0 series but since then the pace of development has really taken off and the 9.0 and 10.0 series are outstanding.

My view is that it is a great choice as a server O/S - with the significant commercial backing as an embedded O/S looks to have a strong future. I know that there will continue to be an interest in getting the desktop bits working but to be honest I think that this is a lost cause and should be dropped (though I acknowledge that the PC-BSD team doesn't agree)

One other point is that there is probably a chunk of the Linux userbase who probably shouldn't try FreeBSD as it really isn't aimed at them.

</comment><comment><USER11> Facebook Seeks Devs To Make Linux Network Stack As Good As FreeBSD's: [http://bsd-beta.slashdot.org/story/14/08/06/1731218/facebook...](http://bsd- beta.slashdot.org/story/14/08/06/1731218/facebook-seeks-devs-to-make-linux- network-stack-as-good-as-freebsds)

(I don't want to start a flamewar, just add more stuff for a good discussion)

<comment> ezequiel-garzon Thanks for the link! The comments there are very interesting, and therefore relevant to this thread. It is of course also interesting the way Facebook worded that open position.

</comment></comment><comment><USER12> My personal (limited) experience with FreeBSD vs my (extensive) experience with GNU/Linux:

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.

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

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

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

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

<comment><USER12> You're right of course, I meant to write "packages" and I honestly don't know why I wrote "jails" instead. Call it Saturday morning brain fuzz, I guess.

</comment></comment></comment><comment><USER14> This book came out a few months ago, may be a good springboard if you're interested in learning how FreeBSD works under the hood. From what I understand, the first edition of this book is highly regarded.

[http://smile.amazon.com/Design-Implementation-FreeBSD- Operat...](http://smile.amazon.com/Design-Implementation-FreeBSD-Operating- Edition/dp/0321968972)

<comment><USER15> That's an incredible book if you want to understand the core of the various BSD kernels (obviously it's best for FreeBSD). It's the latest descendant of "The Design and Implementation of the 4.3BSD UNIX Operating System" which he wrote in 1989, a series of books that are justly famous. McKusick has been involved with the BSDs since he was Bill Joy's officemate and I'm pretty sure wrote the first fsck and most of the first usable filesystem for BSD. The filesystems section of the 4.4BSD version of the book was a fascinating read. He's also the guy responsible for the little red BSD daemon.

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.

</comment></comment><comment><USER16> BSD is often just a little bit different. Hard to be unbiased. Some people prefer GNU make, some like bsdmake.

\- 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](https://www.freebsd.org/cgi/man.cgi?query=kqueue&sektion=2)

[2] [https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/](https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/)

<comment><USER3> > Some people prefer GNU make, some like bsdmake.

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

<comment><USER17> I absolutely love the bsd.*.mk system. It's not just that the tool is simple, but that the average makefile is very short and simple. Here, a few examples:

(netcat) [http://cvsweb.openbsd.org/cgi- bin/cvsweb/~checkout~/src/usr....](http://cvsweb.openbsd.org/cgi- bin/cvsweb/~checkout~/src/usr.bin/nc/Makefile?rev=1.6)

(inetd) [http://cvsweb.openbsd.org/cgi- bin/cvsweb/~checkout~/src/usr....](http://cvsweb.openbsd.org/cgi- bin/cvsweb/~checkout~/src/usr.sbin/inetd/Makefile?rev=1.4)

(ntpd) [http://cvsweb.openbsd.org/cgi- bin/cvsweb/~checkout~/src/usr....](http://cvsweb.openbsd.org/cgi- bin/cvsweb/~checkout~/src/usr.sbin/ntpd/Makefile?rev=1.12)

(httpd) [http://cvsweb.openbsd.org/cgi- bin/cvsweb/~checkout~/src/usr....](http://cvsweb.openbsd.org/cgi- bin/cvsweb/~checkout~/src/usr.sbin/httpd/Makefile?rev=1.26)

<comment><USER3> Thanks! Those do look nice. But I think I could do the same as you with GNU make and rule pattern matching (I use a Makefile library for compiler detection and some useful functions, but stop short of including automatic rule generation, in case I want to customize things.)

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

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

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

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

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

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

<comment><USER19> For what its worth, when I test drove an XTS I was incredibly impressed with CUE. Though if I had my druthers, I'd prefer a good old fashioned knob and button interface for the radio.

</comment></comment><comment><USER20> I have few experience with Linux distros other than Ubuntu, so I'm only comparing FreeBSD with Ubuntu. Linux distros are so diverse I don't think you can just compare all of them with FreeBSD anyway.

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.

<comment><USER21> Wait what? You are stating an Ubuntu thing about versions that are non- specific to Linux and to a Distro.

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.

<comment><USER20> Yeah, I know rolling release distros, though I haven't used any of them. Though I should have mentioned it.

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.

<comment><USER22> I've used Arch for years now---on the same install. The only thing that has been unstable about my system is the function of my USB A/D converter (microphone). Other than that, there has never been an upgrade where something broke. Now, sure, it is wise to check the Arch homepage before you upgrade, just in case some action needs to be taken: that's something that you don't really have to do with, e.g., Debian. But if you do that, as I've done, you probably will never have major problems upgrading.

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.

</comment></comment></comment></comment><comment><USER23> The culture is different. The most noticeable thing is of course simply size. FreeBSD is by far the largest of the BSDs, but it is a much smaller community than Linux. That means that it is easier to get involved, easier to follow what is going on - eg look at the commit log[1] - you can follow it pretty well, vs the Linux commits where each is a large merge of a nested set of commits[2].

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](https://github.com/freebsd/freebsd/commits/master)

[2] [https://github.com/torvalds/linux/commits/master](https://github.com/torvalds/linux/commits/master)

</comment><comment><USER24> i use it mainly as a soho nas. the things i like about it are

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/](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.

<comment><USER25> > 4) extremely good documentation for an open source project > ([https://www.freebsd.org/doc/handbook/](https://www.freebsd.org/doc/handbook/))

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

</comment></comment><comment><USER26> I think this would be a useful conversation.

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/](http://lwn.net/Articles/614142/)

<comment><USER23> You can install GNU tools, but the base system is not very GNU, eg now has clang not gcc, BSD Make not Gnu make and so on.

The Gnu tools are of course portable, so you can install them from ports - <USER2> 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.

<comment><USER27> Debian does have some support for GNU/kFreeBSD. It was an official port of the last stable release. There are also good reasons to want to use it:

[https://wiki.debian.org/Debian_GNU/kFreeBSD_why](https://wiki.debian.org/Debian_GNU/kFreeBSD_why)

<comment><USER23> The reasons listed to use it over FreeBSD are:

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.

</comment></comment></comment></comment><comment><USER28> Freebsd has this Quickstart Guide for Linux Users[1] which is somewhat helpful.

[1] [https://www.freebsd.org/doc/en/articles/linux- users/](https://www.freebsd.org/doc/en/articles/linux-users/)

</comment><comment><USER29> In my experience it all comes down to performance and tunability. Our personal preferences are just that, personal.

Linux has vsyscalls which makes it performant for the typical LAMP stack. If you profile a PHP Zend framework "hello world" app it makes 20k+ calls to gettimeofday(), which is very slow on FreeBSD in comparison. Throw a couple hundred requests/s and you saturate the CPU for no good reason.

FreeBSD needs business support in order to maintain funding, and be a relevant competitor to Linux. If a developer were to pick a popular application stack like node and identify significant performance gains it would make waves.

</comment><comment><USER30> I wanted to know about hosting solutions if I want to use FreeBSD. Linode, Digital Ocean don't support it.

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

<comment><USER31> [https://vultr.com/](https://vultr.com/) is what I use. No complains.

<comment><USER3> You do have to fax them a copy of your driver's license and credit card in order for them to open up outbound SMTP, though.

<comment><USER31> I had no had a need for outbound SMTP, but I read on the FAQ there is a form to fill out. Did not know a driver's license was needed--they have my credit card already--seems a bit extreme.

</comment></comment></comment></comment><comment><USER32> I'd really like to hear from someone about the network stack. I often see jabs at Linux's networking features in regards to FreeBSD, but Linux has a crazy comprehensive stack. Many network appliances are based on Linux kernels and I've personally worked on Linux routers. I also recall doing brief investigation into FreeBSD's networking features and came away with the impression that Linux is out ahead; is this not the case?

How does the storage stack compare? I really love ZFS and have used ZoL quite extensively in the past for a VPS/baremetal backup system and of course FreeBSD has rock solid ZFS support. But Linux has bomber RAID, LVM, dm(which lets you write you're own targets and do all kinds of awesome mapping) etc.

And then of course there are "containers". I'm aware of jails and they are much tested but I saw the other day that they don't have cgroup type features to allow controlling RAM and CPU usage? Namespaces? Is it the case that Linux containers are overtaking jails on the features front?

I really like the idea of FreeBSD and I have bought "The Design and Implementation of the FreeBSD Operating System"(which I ought to start reading) but I'll admit to not knowing a whole lot about it. Most of the topics that come up in comparison discussions seem a bit more superficial than what I'm interested in.

</comment><comment><USER33> For those of us that are more interested in FreeBSD due to the whole Systemd 'controversy', look at the other HN link about the 'FreeBSD: the next 10 years' presentation. They clearly state that FreeBSD is in the same position and it seems that they are not hostile towards the concept of Systemd. Personally I hope that FreeBSD will choose a solution that does not involve QR codes (not mandatory).

<comment><USER3> Opponents of systemd aren't opposed to smarter dependency tracking at boot time. We're opposed to vendor lock-in (making desktop environments and regular GUI applications dependent upon it), an intentional and strong lack of portability (especially important given the former), pushing software into production servers before it is stable and mature, the backroom politics involved in this displacing other competing technologies (OpenRC, upstart, etc), the move to corruptible binary log files, the assimilation and/or replacement of countless other services that already have more mature and stable implementations (consoled, hostnamed, journald, localed, logind, networkd, resolved, shutdownd, timedated, timesyncd, udev, etc), the PID 1 requirement, coupling itself tighter with the kernel (cgroups changes just for it, kdbus, etc), the aggressive and hostile attitudes of the lead developers (Poettering and Sievers in particular), the complete lack of choice being provided from nearly all major distros, Debian dismissing their heritage as a rock-solid, stable, conservative distro, on and on.

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...](https://www.freebsd.org/doc/en/articles/rc- scripting/rcng-hookup.html) (and even with how tiny it is, most of those lines aren't necessary for your average script, either.)

</comment></comment><comment><USER34> It might help to know your main interest: bare metal server in a coloco? Virtualised servers? embedded? desktops?

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.

<comment><USER35> For virtual servers, I've found Ruby API calls to be excruciatingly slow on FreeBSD VM compared to Linux. I'm using TransIP as a VPS provider and although expensive I'm happy with them.

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](https://www.ruby-forum.com/topic/5673725)

See the gist for results: [https://gist.github.com/atmosx/14efea27eb2c1e38af09](https://gist.github.com/atmosx/14efea27eb2c1e38af09)

</comment></comment><comment><USER36> They are both free *nix, so they are very similar. BSD prefers the simpler versions of many of the common command line tools where the Linuxes prefer the GNU tools which tend to have more features. There will also be other small tech differences that will come into play in special cases, like ZFS being nice for fileservers.

Other than the basic tech there are 2 important differences. First is the that there is one FreeBSD but there are hundreds of distributions of Linux. And among them you'll find much larger differences than between FreeBSD and the popular Linux dists.

The other big difference is simply derived from the fact that Linux is more popular. It will tend to have better drivers, have more bugs worked out of the software, etc., just like any other free software out there. FreeBSDs conservative nature towards its core software more than mitigates this, but for all the peripheral software it will matter.

</comment><comment><USER37> I have introduced FreeBSD at a number of companies, and I'm a big fan of it, but also like Debian and Ubuntu a lot. Here are some things I like about FreeBSD:

* Since it's all developed in a smaller community, and FreeBSD hackers/users tend to be pretty opinionated about many things, most subsystems have a consistent feel and are very unsurprising. This makes that you can often guess and be right. It also means you don't get to have some hyped trends. (I have the same feeling about the Go language and community by the way.)

* This might be subjective but I feel that many administration tasks are very transparent, orthogonal and simple. Many system configuration, like enabling of services, network configuration, can be changed by a simple setting in a /etc/rc.conf shellvariables file with defaults in /etc/defaults/rc.conf. Stuff ends up in understandable text config files. Comments and options tend to be simple and don't require --lots-of-long-options --which-i-cant-ever-remember which GNU utils seem to really love :(

* The base system is being developed in a conservative way. We never reinstall servers for a major upgrade, we just upgrade running systems forever. We have some boxes that come from FreeBSD 6.0 (2005) and were gradually bumped up without reinstalling. There is little switching around of subsystems, so you don't often have to learn replacements (like ipfwadm/ipchains/iptables). The OS is just a vehicle to me, please don't complicate my life needlessly!

* The storage options are pretty nice. ZFS is now a common buzzword so I won't go into it, also Linux is now getting a good replacement in btrfs. But I also like FreeBSD's GEOM, which has a lot of 'building blocks' that you can stack on eachother. For instance, you can use gmirror to create a RAID1 mirror, then use geli to create an encrypted volume on top of that.

* The ports/packages collection is a rolling release and generally has very new versions of apps from OpenJDK to Node to PHP etc. In my mind, it's best to keep your app stack continuously fresh, compared with lagging and doing large upgrades every few years. That way you get security updates from the app authors constantly, instead of from maintainers who backport it. I actually prefer this, since upgrading apps creates tangible value for our developers and customers, but it's a tradeoff. If you want to be hands-off, set-and-forget, no-budget-for-maintenance, then you might be better off with an Ubuntu LTS or RHEL strategy of locking apps into old versions with backported fixes. But damn, I cringe whenever I see a box with PHP 5.3...

* If you compile ports yourself, the port maintainers often create configurable options so you can build stuff with your own preferences. This is very useful for instance if you need ffmpeg with some specific codecs. It can be a real drag on Linux to get it just right. Creating your own binary package repository with your favorite custom options is super easy.

* We distribute that stuff like crazy (e.g. on appliances), and it's nice to be able to do that without having too much fear about the GPL(v3).

That said, there's some positive points about Linux (mostly Ubuntu/Debian here):

* Desktop support is undoubtedly better on Linux right now. FreeBSD desktops seem a bit like Linux desktops were in the '00s: manual twiddling, lots of tweaking, having to really watch what video and wireless hardware you get. PC-BSD should be better in this regard, but I haven't tried BSD on the desktop for years now. But I'm tempted to give it another try.

* I think AppArmor is a really cool way to constrain applications without going the whole container way, for which FreeBSD doesn't have an equivalent right now.

* While I'm skeptical about systemd's overreaching goals, I do agree that it is time to centralize service and event management. It's not a critical issue to me however, I'm not too bothered by the old inits for instance. So hopefully FreeBSD doesn't have to have a big controversy and pick the 'good parts'.

* Obviously Linux has a lot of momentum right now, so using it might be less of a long term risk in terms of support, hiring, etc.

</comment><comment><USER38> [https://www.freebsd.org/doc/en_US.ISO8859-1/articles/linux-c...](https://www.freebsd.org/doc/en_US.ISO8859-1/articles/linux- comparison/article.html)

[http://www.onlamp.com/pub/a/bsd/2004/11/11/FreeBSD_Basics.ht...](http://www.onlamp.com/pub/a/bsd/2004/11/11/FreeBSD_Basics.html)

[http://www.onlamp.com/pub/a/bsd/2005/01/13/FreeBSD_Basics.ht...](http://www.onlamp.com/pub/a/bsd/2005/01/13/FreeBSD_Basics.html)

[http://www.pl.freebsd.org/doc/en/articles/explaining- bsd/art...](http://www.pl.freebsd.org/doc/en/articles/explaining- bsd/article.html)

[https://www.youtube.com/watch?v=y1puNK0xuhw](https://www.youtube.com/watch?v=y1puNK0xuhw)

[http://www.freebsdnews.net/](http://www.freebsdnews.net/)

[http://www.bsdnow.tv/](http://www.bsdnow.tv/)

[https://www.pfsense.org/getting- started/#overview](https://www.pfsense.org/getting-started/#overview)

[http://bsdtalk.blogspot.in/](http://bsdtalk.blogspot.in/)

[http://www.openbsd.org/security.html](http://www.openbsd.org/security.html)

[https://www.linkedin.com/pulse/article/20141028100615-571779...](https://www.linkedin.com/pulse/article/20141028100615-57177969-the- beauty-of-de-dup-in-dragonflybsd-hammer-file-system)

[http://www.embeddedarm.com/software/arm-netbsd- toaster.php](http://www.embeddedarm.com/software/arm-netbsd-toaster.php)

</comment><comment><USER38> [https://www.freebsd.org/doc/en_US.ISO8859-1/articles/linux-c...](https://www.freebsd.org/doc/en_US.ISO8859-1/articles/linux- comparison/article.html)

[http://www.onlamp.com/pub/a/bsd/2004/11/11/FreeBSD_Basics.ht...](http://www.onlamp.com/pub/a/bsd/2004/11/11/FreeBSD_Basics.html)

[http://www.onlamp.com/pub/a/bsd/2005/01/13/FreeBSD_Basics.ht...](http://www.onlamp.com/pub/a/bsd/2005/01/13/FreeBSD_Basics.html)

[http://www.pl.freebsd.org/doc/en/articles/explaining- bsd/art...](http://www.pl.freebsd.org/doc/en/articles/explaining- bsd/article.html)

[https://www.youtube.com/watch?v=y1puNK0xuhw](https://www.youtube.com/watch?v=y1puNK0xuhw)

[http://www.freebsdnews.net/](http://www.freebsdnews.net/)

[http://www.bsdnow.tv/](http://www.bsdnow.tv/)

[https://www.pfsense.org/getting- started/#overview](https://www.pfsense.org/getting-started/#overview)

[http://bsdtalk.blogspot.in/](http://bsdtalk.blogspot.in/)

[http://www.openbsd.org/security.html](http://www.openbsd.org/security.html)

[https://www.linkedin.com/pulse/article/20141028100615-571779...](https://www.linkedin.com/pulse/article/20141028100615-57177969-the- beauty-of-de-dup-in-dragonflybsd-hammer-file-system)

[http://www.embeddedarm.com/software/arm-netbsd- toaster.php](http://www.embeddedarm.com/software/arm-netbsd-toaster.php)

</comment><comment><USER39> Start watching [http://www.bsdnow.tv](http://www.bsdnow.tv) , great show focusing on the *BSD's.

</comment><comment><USER40> A lot of HN posts related to BSD release announcements end up with the inevitable "Can somebody explain the advantages of using xxxBSD?" comments. Might be worth looking at the comments section for some of those past submissions.

</comment><comment><USER41> It's going to be hard to find an unbiased identification of the strengths and weaknesses of both. These kinds of things tend to bring out the definition of bias.

Anyway, I like the first comments idea about a wiki. That would be helpful.

</comment><comment><USER42> I started using FreeBSD (version 4.8 at the time) in 2003 and I began a switch to Ubuntu in around 2011.

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 is just shit (but ufw helps a lot). It's such a struggle to configure.

So why did I switch from FreeBSD to Ubuntu? Reason number one is because the place where I started working had done that. I really loved FreeBSD and I didn't really had that feeling towards Linux, but using Linux in day to day life is just a lot easier. It's more common, most people use Linux so you don't have to do 'BSD specific stuff'. Also, I loved doing all the configuration stuff years back, but I know how it's done now and I mostly just want my stuff to work without spending hours on configuration and maintenance. You can do that with one FreeBSD server without any problem, but when you have to manage around 50 servers, it becomes quite a thing. Installing a new kernel on an Ubuntu server or upgrading software is super easy and you don't have to wait for hours because you don't have to compile all the stuff.

To conclude, I'd say: just give FreeBSD a try, it's never a bad idea to have a look at what others do. I just wouldn't advise rolling it out to lots of servers, unless you have a very specific reason to do so.

<comment><USER43> It's worth pointing out that since FreeBSD 10, there is a new binary package manager, "pkg", which works pretty well and makes package management much less painful.

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.

<comment><USER9> Freebsd already had binary packages.. they (finally) developed a new binary package manager, which is great, but it doesn't change much.

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.

<comment><USER44> I don't think you are correct here - pkg upgrade most certainly pulls down updated versions of packages, complete with security patches. In fact, the default freebsd daily job will send you an email listing which packages have security vulnerabilities, so you can go update them.

<comment><USER9> You are right.. I'm wrong.

I used it from 3.4-8.. nice to see that they addressed my problem with the new package manager.

</comment></comment></comment></comment></comment><comment><USER45> Maybe start a wiki page somewhere with what you know/want to know about Linux and then people can fill in the equivalent FreeBSD parts

</comment><comment><USER46> I arrived at this thread about 6 hours late and people have said most of what I would say; but I'll add that we would like to see more startups using FreeBSD (a preference which predates Koum's donation!) so if you've considered FreeBSD but found that it was lacking some functionality which your startup needed I'd love to hear from you.

</comment><comment><USER47> Docker has a ton of momentum right now, which should play into this comparison (as it doesn't run on FreeBSD).

<comment><USER48> I've been doing isolated, per-service environments that can be shipped around using jails on FreeBSD for a looooong time.

</comment></comment><comment><USER49> As a Debian user who started on Gentoo, I think the linked article was _very_ interesting in terms of at least getting an idea of what the differences in design are.

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.

<comment><USER50> >On the other hand, I do love how small and unassuming a basic Linux installation is

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.

<comment><USER49> So your contention is that there is no basic installation... followed by the assertion that the basic installation, which does not exist, is larger than that of any BSD. Sorry, I'm going to have a hard time taking this seriously. And, frankly, your statement about the "full OS" is meaningless, as unless you consider the "full OS" to be only the base system, it includes every possible package, which very obviously is NOT going to be smaller than anything you could consider a basic Linux installation.

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.

<comment><USER23> There is a huge amount more than a kernel and a shell in a Linux distro. There is of course a package manager, which is usually written in python. There are all the utils to configure hardware and file systems (mkfs, mount, raid, ip, etc). The minimal Ubuntu is 63MB compressed[1], although it is not strictly comparable with a BSD base, as the BSDs include compilers in the base system.

[1] [http://blog.dustinkirkland.com/2014/08/re-introducing- jeos-j...](http://blog.dustinkirkland.com/2014/08/re-introducing-jeos-just- enough-os-aka.html)

<comment><USER49> Yeah... poorly phrased. I understand that there's more than a kernel and a shell; I started with Gentoo and worked quite a bit with RedHat/CentOS/Fedora before moving to Ubuntu and then to Debian.

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.

<comment><USER23> Gentoo is probably the most similar, as it has enough to bootstrap the system in the base (stage3), which is not surprising as it was modelled on BSD ports to a large extent. Although the BSDs will also include a debugger too. Linuxes generally got pretty hard to bootstrap reliably though, nad had binary packages earlier, which was where things diverged in base systems.

NetBSD takes bootstrapping most seriously - you can cross build it on any system with a vaguely functional C compiler, and it will bootstrap completely.

</comment></comment></comment></comment></comment></comment><comment><USER51> FreeBSD: ZFS. Jails. Dtrace. Greatly easier to grok

GNU/Linux: Desktop

</comment><comment><USER52> I love the BSD ecosystem, but until FreeBSD is as easy to use and as maintained as Debian, I can't see myself switching over. Debian is just far to convenient, not because it is better, but because it probably has 100 fold the maintainers that FreeBSD does.

<comment><USER53> I'll take 10 skilled maintainers over 100 not-so-skilled ones any day. It's like that Swedish proverb, "the more chefs, the worse the soup". The better the OS, the less maintenance it needs. Just look at OpenBSD.

</comment></comment><comment><USER54> Voxer is a really interesting case, as they have run a similar production load on Linux, then switched to SmartOS (Solaris), and now switched to FreeBSD.

Their staff are technically savvy, and I don't know of anyone else who has tested the options in this way, in production. They have a popular mobile app which turns your phone into a walkie talkie and more, and have millions of users.

I saw them interviewed about their move to FreeBSD recently: [http://youtu.be/NGT3jpilYfE?t=15m](http://youtu.be/NGT3jpilYfE?t=15m)

I like FreeBSD, but I have yet to run the same stack on multiple operating systems in production. That's a LOT of work!

</comment><comment><USER55> Here [0] is a really extensive how-to for running FreeBSD as a desktop OS. It goes beyond the basics, including information about 3D graphics, printing, emulating Linux binaries, installing Flash, and running Wine. It's useful as a guide for someone starting out with FreeBSD, but it's also useful to skim over it in order to get a sense of the distance between the minimalist, base FreeBSD installation and a modern desktop environment.

[0]: [https://cooltrainer.org/a-freebsd-desktop- howto/](https://cooltrainer.org/a-freebsd-desktop-howto/)

</comment><comment><USER56> > I just want to know about differences in design and unbiased identification > of strengths and weaknesses.

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.

</comment><comment><USER57> We do quite a bit of Java development and particularly with regards to Java EE 7. In the past I've had bad experiences in terms of a stable Java environment on production servers on FreeBSD.

It appears that OpenJDK is the best option on FreeBSD right now - but is it something one can trust as much as Oracle's Java on Linux?

These are mission critical servers, so I would hesitate to take chances. To put it in perspective, even the latest Java 8 has a serious bug (on Linux) that we've recently reported to Oracle, so we'd like to be as risk averse as possible.

<comment><USER58> You can also install and use the Linux version of Oracle Java on FreeBSD. The FreeBSD Foundation and Oracle also started a project to build/distribute binary packages of OpenJDK for FreeBSD this year.

</comment></comment><comment><USER59> I run Linux on my desktop and servers, and I can't say much about FreeBSD, but if you want a taste, I recommend building a little NAS for yourself and installing FreeNAS. It's been fun to play around with jails and ports and learn some of the differences. I've found this to be a great way to get your feet wet without risking your productivity or server reliability. I'm surprised no one has mentioned this yet!

</comment><comment><USER60> _The_ thing that brought me to FreeBSD is the base system. A full installation is about 2.5 GB including source code (which is about 900 MB for the FreeBSD sources plus about another 800 MB for the Ports tree). Installation is extremely simple. Third-party software is cleanly separated from the base system. If you're coming from Linux, FreeBSD now has great binary package management tools in the form of pkgng, which is every bit as good and easy to use as APT or yum. I love the FreeBSD documentation. There are useful manual pages even for kernel internals and device drivers. I think that PF is vastly easier to understand and configure than iptables; the same goes for FreeBSD's IPsec implementation. Everything's laid out in a very logical, consistent manner, with lots of comments in config files and whatnot.

What's kept me on FreeBSD is the Ports tree (the third-party package build infrastructure). I love how easily I can build customized packages for my computers, especially now with pkgng and tools like poudriere (refer to this great tutorial at [http://www.bsdnow.tv/tutorials/poudriere](http://www.bsdnow.tv/tutorials/poudriere)). I can very easily set up my own custom package repository that either supplements or wholly replaces FreeBSD's. I've tried to do similar things with Linux, but it definitely isn't as easy. The ports tree committers are very responsive, and creating (and submitting!) one's own packages is both well documented and very easy.

I like how much of the system configuration is done in /etc/rc.conf. I like how the various system and ports tree build-time knobs are all in /etc/make.conf. I like how daily maintenance scripts/health checks both run by default and are all configured in /etc/periodic.conf. I like how understandable the base system is, kernel internals included. I'm no expert developer (and believe me, there's plenty of advanced Unix hacker wizardry in the FreeBSD sources), but things are accessible enough to even one such as me that I successfully modified the ciss driver this year to work around a weird bug in some old server gear I was experimenting with.

Don't get me wrong - I love me some Unix, but modern Linux distributions seem over-complicated in a lot of the ways I don't like about Solaris or AIX or Windows, even though there's a lot of nice stuff from the perspective of an end user. If you install Ubuntu or Fedora, a lot of stuff Just Works(tm), and that's great! I love Ubuntu and Fedora! But if anything breaks and I have to go digging, things get complicated so rapidly that it makes debugging more of an effort than it should be.

</comment><comment><USER61> What has kept me from using FreeBSD (or other bsds) in the past on my laptop was lack of nvidia optimus support. Last time I checked, there still wasn't a bumblebee port. Nevertheless, I have always wanted to try it for longer periods. Perhaps I should try to contribute if it's feasible.

</comment><comment><USER62> This is a brief (probably incomplete) summary of my understanding (many points also supported by the essays in your included link):

\---

Philosophy:

FreeBSD has the concept of a base system: a set of tools intended to work together harmoniously, maintained by a core group of people. You can easily find evidence of this by looking at the source code; the userspace tools sit right next to the kernel[0]. This is in contrast to _GNU_/Linux, where everything (including coreutils) is pulled in from various sources. Many Linux distributions emulate a base system by including utilities that transform the kernel into a complete standard system (e.g. Debian[1]).

[0]: [https://github.com/freebsd/freebsd/tree/master/usr.bin](https://github.com/freebsd/freebsd/tree/master/usr.bin)

[1]: [https://www.debian.org/doc/debian-policy/ch- binary.html#s3.7](https://www.debian.org/doc/debian-policy/ch- binary.html#s3.7)

\---

Leadership:

Linux has a benevolent dictator who decides project direction[0], while FreeBSD has a core group of contributers who decide the future of the project. However, I'm not sure that the Cathedral vs. Bazaar is a fair comparison to impose on these projects[1]. In any case, both projects seem to have been getting things done, and unfortunately (or maybe fortunately), I'm not too savvy on internal managerial disputes or issues.

[0]: [http://www.softpanorama.org/People/Torvalds/index.shtml](http://www.softpanorama.org/People/Torvalds/index.shtml)

[1]: [https://www.freebsd.org/advocacy/myths.html#closed- model](https://www.freebsd.org/advocacy/myths.html#closed-model)

\---

Package Management:

The closest Linux distribution to FreeBSD is most likely Gentoo Linux, as its Portage system is very heavily inspired by the FreeBSD Ports system, in which all "packages" are simply recipes to build from source. You can even run the Gentoo project on a BSD kernel[0], although this sickens most FreeBSD users for some reason. Most other Linux distributions default to installing binary packages, which is also possible, but not traditional in FreeBSD[1].

[0]: [http://en.wikipedia.org/wiki/Gentoo/Alt#Gentoo.2FFreeBSD](http://en.wikipedia.org/wiki/Gentoo/Alt#Gentoo.2FFreeBSD)

[1]: [https://www.freebsd.org/doc/handbook/pkgng- intro.html](https://www.freebsd.org/doc/handbook/pkgng-intro.html)

\---

Process Management:

Linux has recently added LXC, while FreeBSD has had Jails for a while now[0]. LXC is much better marketed than BSD Jails through Docker, but Absolute FreeBSD has an excellent section that describes how to do isolated deployments via Jails[1]. FreeBSD also has the Linuxulator[2] that emulates 32-bit Linux system calls via FreeBSD system calls, allowing users to seamlessly run Linux binaries on FreeBSD. The FreeBSD startup system, however, has stayed more or less the same for the past few decades, revolving around an rc.conf file and init scripts. Linux has seen many more efforts in this area, including systemd and initramfs.

[0]: [https://www.freebsd.org/doc/handbook/jails.html](https://www.freebsd.org/doc/handbook/jails.html)

[1]: [http://www.amazon.com/Absolute-FreeBSD-Complete-Guide- Editio...](http://www.amazon.com/Absolute-FreeBSD-Complete-Guide- Edition/dp/1593271514)

[2]: [https://www.freebsd.org/doc/handbook/linuxemu.html](https://www.freebsd.org/doc/handbook/linuxemu.html)

\---

Licensing:

BSD projects use a BSD license, which many businesses prefer over the GNU license used by Linux. However, this is a discussion that deserves more than a small summary.

\---

Misc:

Linux is most likely to support recent hardware because of extensive userbase and industry support. For example, NVidia's latest CUDA SDKs always have Linux bindings, but not BSD ones.

The BSDs have great reputations for killer implementations of TCP/IP.

The BSDs have been using the GEOM[0] disk management system for a long time, which is one of my personal favorites in terms of features. It allows you to treat character and block devices as pipes, so for example, adding encryption is simply "piping" a bare disk through an encryption layer, resulting in a new device. You can even "pipe" things across the network. Linux is somewhat caught up via device-mapper, so this is not a huge deal if you're trying to choose which one to use. Both are great operating systems. Just use whatever works.

[0] [https://www.freebsd.org/doc/handbook/geom.html](https://www.freebsd.org/doc/handbook/geom.html)

It's likely that you know things that I don't, so please feel free to correct me if I'm wrong.

<comment><USER63> Your "Philosophy" section describes the current situation, but with the growing adoption of systemd the GNU/Linux ecosystem will move more and more in the FreeBSD direction here so its coherent development approach will be less of a differentiator.

Re GEOM: does it have any features that Linux device-mapper lacks? Both look very similar to me in capabilities. For example, device-mapper has support for thin provisioning (thinp) and GEOM has gvirstor(8).

</comment></comment><comment><USER64> A side question somewhat related to the theme: What features of ZFS can't be achieved with ext4 on top of LVM? I see lots of people longing for full disk encryption, mirroring, snapshots or foreign hard disk consolidation, all of which seem doable with ext4+LVM.

<comment> X-Istence Full end to end checksumming. ZFS can find and correct errors on the fly, and can ensure data integrity.

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.

<comment><USER65> This is only guaranteed with ECC RAM, right?

<comment> X-Istence Without ECC RAM it is entirely possible that upon reading a file may be marked as damaged when it is not, and it is entirely possible ZFS may write a file that has a bit flipped to disk (this one is silent and unrecoverable). While there is a chance, it is unlikely. In my case my zpool's have always given me early warning when one of my hard drives was having issues, even before SMART or anything else started showing warnings. Due to having multiple backups (desktop machine backs up to 2 different networked machines, and it is checksummed end to end) I haven't found any silent data corruption while writing data on any of my zpool's even without ECC RAM.

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.

</comment></comment></comment></comment><comment><USER66> Because I have a FreeBSD box with this:

$ uptime 11:23PM up 835 days, 5:33, 1 user, load averages: 0.07, 0.02, 0.01

<comment><USER67> That is good, but I had linux and centos in my basement with about 700 days. Went down with a multi-day power failure.

Shucks,one of my favorite stories about COHERENT was the near 2-year uptime of the port to Z8000 running on a bunch of disconnected hardware sitting on a table in an office.

</comment></comment><comment><USER68> Why aren't we talking about OpenBSD vs. Linux? I mean, it's the only OS I trust anymore.

</comment><comment><USER53> There's the old "FreeBSD vs. Linux vs. Windows 2000" document which caused quite the stir:

[http://people.freebsd.org/~murray/bsd_flier.html](http://people.freebsd.org/~murray/bsd_flier.html)

<comment><USER69> That comparison is either dated or biased. Linux supports more hardware, supports many filesystems, and is definitely version-controlled. The GPL vs. BSD license discussion is political and has no place in a comparison like this, IMHO.

</comment></comment><comment><USER38> [http://www.embeddedarm.com/software/arm-netbsd- toaster.php](http://www.embeddedarm.com/software/arm-netbsd-toaster.php)

</comment><comment><USER70> I think an interesting question in this context is:

If you wanted to create Ubuntu today, would you use GNU/Linux or FreeBSD as base?

<comment><USER71> This is not the right question to ask. Ubuntu is aimed at making Linux available to the masses on the desktop.

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.

<comment><USER70> I started wondering about this when I heard Sony uses the FreeBSD kernel. If for a console, why not for the desktop?

<comment><USER72> developing drivers is expensive. it makes sense to take a kernel and develop a in-house drivers for a more or less fixed set of hardware. less so to test thousands of apps on thousands possible hw configurations for _very_ limited customer base. it's a ROI thing.

</comment></comment></comment></comment><comment><USER73> You will find that FreeBSD is way easier to configure manually, but you have to.

One of the biggest differences when compared to Linux distributions is that you have a base system which split from third party software. This is true for the other BSDs too. I think that's a huge point for people using one of the BSDs. The reason is that in practice it means you can have a stable and recent system. Where in Ubuntu on Debian one usually relies on third party repositories having a stable FreeBSD with the latest PostgreSQL for example is something you can decide on having. In fact that is so inherent that they have a lot of PostgreSQL versions in their ports tree which means you are not forced to use the old or the new version. However in a production environment it also means you want to use a tool like poudriere (extremely easy system to build packages and install them with the package manager on other systems. It's _really_ easy) so in case you have a library dependency you don't get stuck. In the PostgreSQL example that would be true for PostGIS. That's actually one of the primary reasons for me using FreeBSD in production. I don't have a day or more to make PostgreSQL version X working on a system and then making that setup work with PostGIS version Y. If you have such a problem you really should have a look at FreeBSD and poudriere.

And then there are tons of small things. Packages come as intended, unmodified. pf and ipfw are (in my opinion) way nicer than iptables. jails are a nice way to abstract your system using virtualization (even though there is LXC). Sane and secure defaults are another I really like. Sometimes you want to change them for performance reasons, but most of the time it means that you don't have to worry about stuff popping up.

Then a personal experience: Updates and upgrades are nice. They always work out for me. I don't think that this is a pure FreeBSD thing, but I have used many systems where I had to be really scared about upgrades. FreeBSD isn't one of those.

It has nice tons of nice features like HAST. That is file system replication. I am not talking about ZFS here, which is also a really fine thing. If you somehow work with files, especially when it comes to high availability you should take a look at FreeBSD for both ZFS and HAST.

My biggest con until recently was performance. Linux had especially when it comes to HD access and stuff like memory mapping (something all kinds of DBs need to be performant) a standing way ahead of the BSDs. I think as of now the order for such things (based on various PostgreSQL benchmarks) is: DragonFly BSD, Linuxm FreeBSD, with DragonFly being the fastest, but all of them being so close that it mostly depends on specifics of Hardware, data set, exact DB version, etc.

Another problem you run into is that the world is often very Linuxy and it's especially at the beginning really hard to grasp that FreeBSD is not Linux. It is a separate operating system, just like FreeBSD, DragonFly, NetBSD, OpenBSD and MacOSX are all different BSDs. They simply are, so you can not really expect things to work in the same way and making things closer to something like Linux means that they will lose their strengths and disadvantages.

If you are happy with Linux then there is no reason to use FreeBSD. Neither system is magically perfect.

I mostly enjoy FreeBSD for knowing what is going on and I think that has mostly to do with people having a similar way of thinking and should there be a problem I will easily get to the right track. However as a matter of fact I know lots of experts with something like RedHat or Debian who have the same experience with those systems.

What I really want to disagree with because people always mention it is that using FreeBSD is hard. If you ever installed and configured Slackware, Arch Linux or Debian from scratch then installing any BSD will most likely be easier. However it is different. It is not like knowing Linux and trying just a new distribution, even if it at some points looks like it. OpenBSD might have a scare install procedure, but in the end it is just doing the ordinary stuff without using ncurses, GTK or whatever. It has questions like "Do you intend to use X11?" and you enter y or n. At first boot you have a nice mail in your inbox, etc. That's about as hard as it gets there. Slackware and Arch Linux can be way harder to use (I use Arch Linux on the Desktop and have been using it since its beginnings).

What is really great about the BSDs is how much they care about good official documentations, be it on their web pages, manual pages, etc. A big mistakes people sometimes make is going the usual Linux way googling for the problem they wanna solve. On the BSDs the documentation on the website will usually tell you things so you understand them. They are at a really good shape and things are rarely outdated. People really consider good documentation part of their software. There is a total lack of attitudes in the way of "I will do documentation later" or "It will be outdated soon anyway, so why care?". Community wise there is an age difference. There have been surveys on that. BSD folks tend to be older, both when it comes to users and developers. That's just a side note, because you asked for differences. Also I seem to be an exception here, because my first contact with FreeBSD was when I was 16 or so. So that's really just stats.

Sometimes stuff really is Linux specific, but it's usually only the kind of things that only work on one Linux distribution. Basically every piece of software can be found in FreeBSD ports, but if you have something that is optimized for Ubuntu for example (so basically things you find on GitHub) you might run into troubles getting in run on FreeBSD. However, you will usually also have some issues trying to run that on RedHat or Slackware then.

The most common problem I run into when using something made for Linux is shebangs that look like '#!/usr/bin/python' instead of '#!/usr/bin/env python' (FreeBSD has third party software, so everything you install as a package in /usr/local/bin). However, since I am an Arch Linux user I also run into that problem, because Python 3 is the default.

One last thing: You will most likely learn to use sysctls. FreeBSD tend to be extremely conservative about certain settings. That is good from a security point of view and from preventing servers to get into a state where you can't even connect to them anymore, but sometimes that is a hindrance for your performance. Typical example are databases again, but then if you think about PostgreSQL then you probably know their default settings are also conservative and still work fine for most people.

Taking a look at FreeBSD is really worth it, even if you end up not using it. People in the BSD community often respond something like "If you are happy with Linux why would you want to switch?". That might be related to their age, having used many tools seeing how everything has benefits and weaknesses. However, you really have to keep in mind that it is not Linux. It really is a different operating system and some things will be weird first. It's like learning a new programming language, maybe even a new paradigm. People in the BSD community don't usually try to convince everyone and they want people to understand stuff, so you will maybe have a hard time if you ask for copy&paste resolution, like on Ubuntu forums or so. That might also mean that you will end up understand the system in a more in-depth way than other systems in a really short time.

Saying one of them is better doesn't make a lot of sense anyway even in single instances, because things change so rapidly (see the LXC example). FreeBSD might suit you needs, but so might Linux and in a year or so that might have completely changed.

</comment><comment><USER74> Why, FreeBSD is an advanced UNIX-like system _for servers_ , derived from original BSD sources I don't remember exactly when. My first experience was with FreeBSD 2.0

It confirms to recent _UNIX_ standards, such as various POSIXes (pthreads, rt extensions), UNIX98 (I guess), etc. and obviously don't have any Linuxisms, like udev, systemd (thank god!) fuse, you name it, which aren't that important _for a server_. So you could compile as a _port_ or install as a pre-compiled package almost everything you want _for a server_.

It runs on pair with Linux on network and application performance, in some cases even slightly better. Notably, nginx prior to version 1.0 has been developed on FreeBSD.

Nowadays here are a few obvious disadvantages.

1\. Driver support is fair - it runs on standard modern hardware, but cannot be compared to Linux with tens of thousands of contributors, it has very small core-team.

But it considered much less "marginal" than, say, OpenBSD (which is _very clever_ in its own way) or NetBSD.

2\. Vendors doesn't support it, so basically you wouldn't run, say, Oracle or DB2 on FreeBSD (while there is a possibility to install some Linux binaries with emulation). Notably, there is no that "certified, safe Oracle JDK" for FreeBSD, only "unofficial" OpenJDK port.

Not long ago it has a reasonable share of all Internet servers and the recent decline isn't due to any quality or reliability issues with FreeBSD, but because "too many Linuxes everywhere".

It has some clever technologies of its own, like netgraph, jails+union-fs (which is you could call "chroot-based containers before Docker") native ZFS support, etc.

Lots of sane people ran FreeBSD in production, Yahoo is the most notable example. Russians love FreeBSD too - many early ISPs and hosting services has been built on top of it. Lots of developers and contributors are from Russia.

So it is modern, reliable UNIX for servers. But not _that popular_ , of course.

<comment><USER63> > It confirms to recent UNIX standards, such as various POSIXes (pthreads, rt > extensions), UNIX98 (I guess), etc. and obviously don't have any Linuxisms, > like udev, systemd (thank god!) fuse

I don't believe any BSD has ever been certified for UNIX98 (or any version). [http://www.opengroup.org/openbrand/register/](http://www.opengroup.org/openbrand/register/)

And instead of Linux-isms you get BSD-isms like strlcpy(3) and devfs (which is the equivalent of udev).

[https://wiki.freebsd.org/WhatsNew/FreeBSD10](https://wiki.freebsd.org/WhatsNew/FreeBSD10) lists "FUSE support in the base system" as a new feature.

Also the "native ZFS support" is not a "technology of FreeBSD's own" but ported from OpenSolaris.

</comment></comment><comment><USER75> no, or your comments will be banned :/

</comment><comment><USER76> The worst part of FreeBSD is the license.

</comment><comment><USER77> If you can't decide yourself just stick with your current OS.</comment>


Finally, It Will Be Legal to Unlock Your Own Cellphone - <AUTHOR> http://www.slate.com/blogs/future_tense/2014/07/25/s_517_leahy_senate_bill_on_cellphone_unlocking_passes_congress.html

<comment><USER2> FYI: This has absolutely nothing to do with bootloaders.</comment>


Social ranking company Klout is shutting down - <AUTHOR> https://gizmodo.com/klouts-score-drops-to-zero-as-it-announces-plans-to-clo-1825930417 <comment><USER2> Really did not enjoy reading the news years ago when Klout got bought for 9 figures (iirc?). Rewarding shitty businesses in this way just incentivizes people towards the wrong things and sends terrible signals down the system.

</comment><comment><USER3> I wonder if it's possible for these """journalists""" to write an article that is not full of pathetic jokes and puns.</comment>


Did a Human or a Computer Write This? - <AUTHOR> http://www.nytimes.com/interactive/2015/03/08/opinion/sunday/algorithm-human-quiz.html

<comment><USER2> Previously discussed (a month ago): [https://news.ycombinator.com/item?id=9166967](https://news.ycombinator.com/item?id=9166967)

</comment><comment><USER3> Although impressive, this quiz's content seems cherry picked for situations where bots can do well.

On the one hand we have highly informational content such as the one about the earthquake, earnings report and sports game. Reporting on this kind of information can be done in a context free way. Sentences and paragraphs can be self contained and need not reference each other or greater contexts. I only missed the sports game in part because I'm not an American and was not familiar with the game involved. In hindsight the earnings reports stands out from the others since much broader connections are made then just reporting the raw information itself.

On the other hand we have poetry, which is often so hard to parse that nonsense and genius are hard to tell apart, especially for short excerpts like these. I missed the poetry app one because although it read like nonsense for me, as a non native speaker much of these Shakespearean poems do on first sight. I don't know exactly why but "True Love" and "Absurdistan" immidetly stuck me as fake and real respectivly. For example I thought it was weird to be that her nerves where strained as _two_ tight strings, and that someone would make her drink hot wine. Also the "True Love" excerpt seems very factual and deseperate where "Absurdistan" paints more of an atmosphere.

<comment><USER4> It could report on small events that are normally not covered to. Further it could customize articles based on readers interests. Have a favorite player? He is now highlighted in your articles.

It could also do vanity articles. Go back to your college days and write about your games, making you the highlight.

Worse it could be influenced to do personalized advertisements in the middle of the article.

</comment></comment><comment><USER5> Define "write." Is the output of printf("Should I compare %s to a summer's day", name) written by a human or a computer?

If it's defined to be "written by a human", then I bet that most (all?) of their examples are written by a human in a similar way.

If it's defined to be "written by a computer", then guessing if a human or a computer wrote any of their examples is like guessing the output of coin tossing.

<comment><USER6> Perhaps some notion of entropy would be useful here? Normal information theoretic definitions of entropy usually rely on "bits of entropy". I.e. if you are given information in the form, "Should I compare %s to a summer's day" then how many new bits of information are we actually getting? In this case, it is unbounded, because what we are calling `name` can be arbitrarily long.

But what about if we define entropy in terms of something like parts of speech? Then, the computer can only change one part of speech (the noun phrase to which we compare a summer's day) whilst maintaining the context of the sentence, so in terms of that metric, entropy is low.

With this parts of speech entropy metric in hand maybe we could declare the output of a computer to be "written by a computer" if the entropy in its sentences approaches that of a human writing about the same topic.

 _Disclaimer:_ I spent about as much time thinking about this as you did just reading it, so I don't expect this is in any way a fully formed or implementable idea, just food for thought.

<comment><USER5> You need to know how the sentences were constructed then. In their Turing- test-lookalike webpage you get to guess based on the final sentence, which is kinda pointless without the conversation part of the test which precludes canned responses/format strings.</comment></comment></comment>


Ask HN: What makes Ruby so great? - <AUTHOR>

Ok, I'm sick of reading articles where the writer says, "Ruby is awesome, you should use it." and ones that compare Ruby to C or some other language that isn't used for the same things.
Each language has it's pros and cons. It's unfair to compare apples and oranges. It's also unfair to to just say "it's awesome" and that you need to use it.
So what makes Ruby better than PHP? Python? Perl? All can be used for web programming (Which is what I'm talking about here). Which brings me to another point. Ruby on Rails, I had no idea that Rails was a framework at first. It's the same as using a framework for PHP (Symfony, Kohana, CakePHP, etc) or for Python or for Perl.
Please HN, why is Ruby so great? Ruby fans seem like Apple fans to me =\
Thank you. <comment><USER2> Spend a week learning it and see what you think. Play with the metaprogramming, runtime code creation, and dynamic method invocation, and see if it floats your boat.

(Try this article I wrote for DevX: <http://www.devx.com/RubySpecialReport/Article/34502>

I tried to give an example that would show off some of the nicer things in Ruby.)

After trying the language, if you don't like it, don't use it, and stop reading Ruby articles.

BTW, anything that claims "Blub is so awesome, you should use it," but doesn't explain why, isn't worth the time of day. Ignore them.

It's unfortunate that there are some people who gush over Ruby like it was their first high school crush, but so what? Try a variety of languages, find one or two that suit you, learn them well, and go make stuff.

Code talks, bullshit walks.

<comment><AUTHOR> Thanks, you are very straight forward. I was assuming I would get a lot of people flaming this because Ruby is like "their first high school crush", but was wrong.

Do you have another link to your article? I'd like to read it, but the site wants me to register. I'm not down with that.

Thanks James

<comment><USER2> Re my other comment: Also ran into the odd sign-in required, so I decided to just host the article myself:

[http://www.neurogami.com/articles/10_minutes_to_your_first_R...](http://www.neurogami.com/articles/10_minutes_to_your_first_Ruby_app/)

</comment></comment></comment><comment><USER3> I'm with you on the Ruby fans seem like Apple fans.

Based on your comment about web programming, you are talking about Ruby on Rails which is the web framework for the Ruby language.

I've just gone back to learning RoR after trying it a few years ago. I'm normally a PHP programmer, but have been playing with some RoR with MongoDB stuff.

My take on it coming from a regular LAMP is that RoR has lots of gems (packages) that are easy to install and use.

The code generators get you up and running really quickly, though I'm not actually a fan of most generators.

RoR applications have a rather specific structure. I think it is deeper than MVC, as there are naming conventions for functions, variables/collections, etc.

The structure is good because it is fairly easy to back-trace through somebody else's code to see what they've done.

What I'm finding really challenging is that there are so many small details that are hidden from the code.

For instance, in RoR, 'render' is like an include file, but you don't actually have to type the name of the file or where it exists. Based on the naming schemes and structure of RoR it gets the variable/collection and file name because everything has the same name.

What I haven't found is a place where it explains what RoR is doing, so you know that when you have an error, this is why.

I think we are just supposed to blindly follow the 'it just works' mantra, which has never really worked for me with Apple, and I'm barely holding it together with RoR.

As far as documentation goes, it is tough to beat PHP. The documentation is really good, and the language/framework doesn't do the work for you, so you build a page, put something into the db, get it out, put it on this page, call it from that page, etc. You build your own structure so you know where things are and how things work.

The tutorials I've seen keep going through the very same basic stuff of getting RoR to build crud operations for you, or how to change a view. But getting into the meat of RoR is proving to be much more difficult.

</comment><comment><USER4> From the perspective of someone who is looking for a first programming language or a language that is dead simple to use for basic tasks, I think Ruby is a great choice.

I think this is primarily because the syntax can be very intuitive, especially compared to something like perl. Ruby code is generally readable even to someone who doesn't know Ruby (there are some exceptions of course, as Ruby can be very terse in the right hands).

There are also a ridiculous number of gems that are easy to install and use. Need to do document classification? There's a gem for that (classifier). Need to access a database and want to do it through Ruby objects? There's a gem for that (sequel).

<comment><USER5> _Ruby code is generally readable even to someone who doesn't know Ruby...._

I hear this claim often about many languages. I'd like to see some sort of proof, as well as some explanation of why that should matter.

<comment><USER2> " ... as well as some explanation of why that should matter."

It doesn't.

I've heard the same thing, or some variation ("It's executable pseudo-code!"), and thought it a useful indicator of some intangible but important goodness, but it doesn't hold up.

Look at Haskell. (No, really, you won't go blind. ) Few people are going to claim it's generally readable to the uninitiated, but so what? So is French, for a lot of people. The thing is, if you think it would be useful, you learn it, and at that point the value of "readable to people who haven't learned it" goes to nil.

You could argue that some languages (maybe Haskell) maintain a level of inscrutability for a long time as you are learning; you continue to spend too much time decoding text when you could be zipping along with some reads-just- like-English language.

But that's a different issue. "Difficult to obtain proficiency" is not the same as "intelligible to outsiders", and concerns different value to the programmer. Plus, the cost of proficiency needs to be weighed against the return on effort. (Consider Vim or Emacs. Worth the effort to learn? An awful lot of people seem to think so.)

It may take longer to become proficient in (say) Haskell than in Ruby, but the long term payoff may be that you become far more efficient, with your code being far more concise.

There's a difference between BASIC and Brainfuck, and some language comparisons are just apples and oranges, but the value of being easy or readable to newbies or outsiders is largely tied to the value of being a newbie or an outsider. Once you are neither you really need your language to have other strengths.

(Which certainly Ruby has, and its those strengths people should use to sell it.)

</comment></comment></comment><comment><USER6> Rails.

Prior to Ruby on Rails, most people's exposure to web dev was PHP. Go from doing PHP by hand for the simplest CRUD based pages, to the magic of Rails that magically does half the work for the same page. That magic gained the language not just converts, but fans on the level of Apple fans.

There are other choices these days, but thats where the fandom originates from.

</comment><comment><USER7> Although Ruby is a very productive language, I think its more about the community. Its moving incredibly fast, and the people in the community are doing really awesome things right now. Resources for programmers are abundant.

</comment><comment><USER8> Ruby is toast, now that we have node.js you can do just about everything with JavaScript alone.</comment>