Ask HN: Can we talk about FreeBSD vs. Linux?
220 comments
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.
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.
The Firefox issue is because gtk is brain damaged and sends the image to the x server, then reads it back, but it gets broken up into tiny chunks and causes a billion syscalls. You can fix it by recompiling x with larger socket buffers.
Thank you, I've been trying to figure out what the actual problem was for a while and was not having any luck.
For those who haven't experienced this: it's really painful. Your entire desktop becomes completely unresponsive for 5-10 full seconds while a picture very slowly loads.
For those who haven't experienced this: it's really painful. Your entire desktop becomes completely unresponsive for 5-10 full seconds while a picture very slowly loads.
FYI, this issue exists in PC-BSD too. I tend to use Chromium anyway and Firefox as a backup, so it doesn't bite me as much when I'm in that OS. But it's definitely a big one.
Well, you can work around it (with no known downsides) by adding:
export MOZ_DISABLE_IMAGE_OPTIMIZE=1
IIRC that would sometimes lead to weird glitches like images with repeating static patterns, though perhaps those bugs have been fixed as well.
Might have in the past, I have yet to see any rendering glitches from it.
Now, some of the about:config options that were proposed as alternate workarounds definitely caused very weird rendering glitches, but this one seems mostly side-effect free.
Now, some of the about:config options that were proposed as alternate workarounds definitely caused very weird rendering glitches, but this one seems mostly side-effect free.
You're right. I was thinking of gfx xrender.
Bug still exists, but only shows up in fewer cases now.
Surprisingly, PC-BSD doesn't generate a ~/.xinitrc file, I had to create one. I just put that line in mine, and restarted X. Seems to be working well, I loaded up a 4K image in Firefox with no stuttering, pausing, or other noticeable problems, and it definitely slowed the system to a crawl before making the change. Thanks!
This is why OpenBSD is the superior desktop operating system. Fixed months ago. :)
Indeed. This thread should really be titled OpenBSD vs. Linux.
I'm sure most people here don't even know it's the only OS in the world allowing you run Xorg as an unprivileged user.
Just like Linux taught me to appreciate FreeBSD, FreeBSD taught me to appreciate OpenBSD. OpenBSD -- the world's simplest and most secure Unix-like OS. Creator of the world's most used SSH implementation OpenSSH, the world's most elegant firewall PF, the world's most elegant mail server OpenSMTPD, and the OpenSSL rewrite LibreSSL. OpenBSD -- the cleanest kernel, the cleanest userland and the cleanest configuration syntax.
FreeBSD -- growing overly complex [1], lagging on security [2], packing itself with unnecessary, experimental technologies, and representing itself with a satanic mascot and a shiny, dildo-looking logo.
--
[1] http://lists.freebsd.org/pipermail/freebsd-hackers/2012-Janu...
[2] http://itwire.com/business-it-news/open-source/62641-crypto-...
I'm sure most people here don't even know it's the only OS in the world allowing you run Xorg as an unprivileged user.
Just like Linux taught me to appreciate FreeBSD, FreeBSD taught me to appreciate OpenBSD. OpenBSD -- the world's simplest and most secure Unix-like OS. Creator of the world's most used SSH implementation OpenSSH, the world's most elegant firewall PF, the world's most elegant mail server OpenSMTPD, and the OpenSSL rewrite LibreSSL. OpenBSD -- the cleanest kernel, the cleanest userland and the cleanest configuration syntax.
FreeBSD -- growing overly complex [1], lagging on security [2], packing itself with unnecessary, experimental technologies, and representing itself with a satanic mascot and a shiny, dildo-looking logo.
--
[1] http://lists.freebsd.org/pipermail/freebsd-hackers/2012-Janu...
[2] http://itwire.com/business-it-news/open-source/62641-crypto-...
Personally, I love FreeBSD's beastie.
Don't care much if it is "satanical" or whatnot.
Beastie was much better than the new logo that looks like a shiny bauble.
> I'm sure most people here don't even know it's the only OS in the world allowing you run Xorg as an unprivileged user.
Maybe the first, but these articles claim Fedora can do it too, although currently you need to edit a config file, and it only works if you invoke startx(1), not when logging in from gdm.
http://hansdegoede.livejournal.com/14446.html http://hansdegoede.livejournal.com/14268.html
Maybe the first, but these articles claim Fedora can do it too, although currently you need to edit a config file, and it only works if you invoke startx(1), not when logging in from gdm.
http://hansdegoede.livejournal.com/14446.html http://hansdegoede.livejournal.com/14268.html
I really don't want to be _that_ guy that brings up archlinux, but…
"X is now rootless with the help of systemd-logind, this also means that it must be launched from the same virtual terminal as was used to log in, redirecting stderr also breaks rootless login. […]"
https://www.archlinux.org/news/xorg-server-116-is-now-availa...
This is obviously not a feature of archlinux itself, but an upstream x.org feature.
"X is now rootless with the help of systemd-logind, this also means that it must be launched from the same virtual terminal as was used to log in, redirecting stderr also breaks rootless login. […]"
https://www.archlinux.org/news/xorg-server-116-is-now-availa...
This is obviously not a feature of archlinux itself, but an upstream x.org feature.
C'mon, this unimpressive feature is the default in Arch for a while now.
Attempting to talk about "Linux", as if some single operating system - lack of pluralism between commenters to handle the differences notwithstanding - is a problem with this thread.
Attempting to talk about "Linux", as if some single operating system - lack of pluralism between commenters to handle the differences notwithstanding - is a problem with this thread.
It's just too bad they don't support ZFS or any similar filesystem. Their reasoning makes a lot of sense, but there are a lot of useful features that would be nice to have.
[deleted]
Ah interesting, thanks for the pointer.
https://freedesktop.org/patch/23215/
https://freedesktop.org/patch/23215/
This is OT, but since you seem to know a fair bit about filesystem types and their trades and have an opinion on sane patching behavior, I have a question you might be able to answer:
Why aren't modern filesystems based on a content-addressable-store where the content is 100% separated from the organization of the filesystem itself? It seems to me like it would make more sense to have only one copy of a file ever saved and when modifications are made you get a new pointer to the changed file. Obviously it wouldn't make sense to do full copy on modifications for files over a certain size, but in this situation the filesystem could offer an abstraction over a patch and pointer to the original file until the system is idling and a full copy could be made.
The reason I ask about this is because it would make updating anything and rolling things back trivial since it would simply be a pointer change in the file hierarchy hash map from the new file to the old file and back again. Furthermore, such a system would give you dedupe for free and files could be marked for deletion only once the last pointer to the file in the CAS has been deleted.
Why aren't modern filesystems based on a content-addressable-store where the content is 100% separated from the organization of the filesystem itself? It seems to me like it would make more sense to have only one copy of a file ever saved and when modifications are made you get a new pointer to the changed file. Obviously it wouldn't make sense to do full copy on modifications for files over a certain size, but in this situation the filesystem could offer an abstraction over a patch and pointer to the original file until the system is idling and a full copy could be made.
The reason I ask about this is because it would make updating anything and rolling things back trivial since it would simply be a pointer change in the file hierarchy hash map from the new file to the old file and back again. Furthermore, such a system would give you dedupe for free and files could be marked for deletion only once the last pointer to the file in the CAS has been deleted.
Plan 9 was designed this way. Except it's designed to never delete anything, so you don't have to worry about the garbage collection.
Camlistore and TahoeLAFS are both designed this way. But they are more of a content store than a file system.
In fact, BTRFS is implemented this way. The content and the metadata can be separately treated with mirrors vs raid. You can balance just the metadata or both data and metadata. When you convert an ext2/3/4 file system to BTRFS, it just sets up it's own metadata pointing to the same blocks that the ext used. You get a free snapshot of your data pre-conversion and it's all COW from then on. I believe the B-Tree of BTRFS is the metadata and the content never changes on disk until no more pointers exist. If you decide to go back, it just restores the superblock and the old data is still in the same spot. You would only regain that space after you delete the snapshot and the last pointers to the data are gone.
Camlistore and TahoeLAFS are both designed this way. But they are more of a content store than a file system.
In fact, BTRFS is implemented this way. The content and the metadata can be separately treated with mirrors vs raid. You can balance just the metadata or both data and metadata. When you convert an ext2/3/4 file system to BTRFS, it just sets up it's own metadata pointing to the same blocks that the ext used. You get a free snapshot of your data pre-conversion and it's all COW from then on. I believe the B-Tree of BTRFS is the metadata and the content never changes on disk until no more pointers exist. If you decide to go back, it just restores the superblock and the old data is still in the same spot. You would only regain that space after you delete the snapshot and the last pointers to the data are gone.
Plan 9 had Venti, which was indeed a content-addressable file system. But it was not the main file system for day-to-day use; it was intended to store backups only.
Btrfs is not content-addressable, although everything else you say about it is correct.
Btrfs is not content-addressable, although everything else you say about it is correct.
Zfs, to take one example, does do approximately what you want - the file system (or rather, the underlying block storage) has a tree structure, and changes to files are propagated via copy-on-write rewrites up the tree, so that earlier snapshots still get to see the original file.
This does make rolling things back trivial.
It doesn't give you dedupe for free, though. Think about what would have to happen: every modification would mean rehashing the modified block (not a problem, that should happen anyway to verify integrity). Let's say we dedupe at the block level rather than the file level to avoid the need for more expensive hashing operations, and to increase the likelihood of actually sharing stuff. Now, to determine whether we can deallocate the new block, we need to look up the hash. So we need an index of every block on the file system by hash. That necessarily involves either a big chunk of memory or a bunch of random I/O. Both are at a premium for a filesystem - the former for cache, the latter for throughput.
If you just want file dedupe, it's a smaller problem, but is less likely to create gains - most people don't store many copies of the same file, unless they're in the third party file storage business. So it isn't really suited to a general file system. If this is something you want, you could periodically go through your file system, hash all files with only one link count in the inode, and hard link them using the hash as a file name, into an set of directories fanning out by hash prefix. There may be some wrinkles with permissions; I believe btrfs has a different kind of copy with copy-on-write semantics that might be useful here.
This does make rolling things back trivial.
It doesn't give you dedupe for free, though. Think about what would have to happen: every modification would mean rehashing the modified block (not a problem, that should happen anyway to verify integrity). Let's say we dedupe at the block level rather than the file level to avoid the need for more expensive hashing operations, and to increase the likelihood of actually sharing stuff. Now, to determine whether we can deallocate the new block, we need to look up the hash. So we need an index of every block on the file system by hash. That necessarily involves either a big chunk of memory or a bunch of random I/O. Both are at a premium for a filesystem - the former for cache, the latter for throughput.
If you just want file dedupe, it's a smaller problem, but is less likely to create gains - most people don't store many copies of the same file, unless they're in the third party file storage business. So it isn't really suited to a general file system. If this is something you want, you could periodically go through your file system, hash all files with only one link count in the inode, and hard link them using the hash as a file name, into an set of directories fanning out by hash prefix. There may be some wrinkles with permissions; I believe btrfs has a different kind of copy with copy-on-write semantics that might be useful here.
Deleting is not a time sensitive command anyway.
But I don't think you'd have this problem. Just like we have an inode telling every block of a file, a filesystem like that would need a similar structure telling every hash of the file. When you delete a block, you look at this structure, the same way you look at an inode.
The only thing missing is that you'll need a counter at the blocks. And this counter will create some synchronization problems that may turn out more important than saving disk space.
But I don't think you'd have this problem. Just like we have an inode telling every block of a file, a filesystem like that would need a similar structure telling every hash of the file. When you delete a block, you look at this structure, the same way you look at an inode.
The only thing missing is that you'll need a counter at the blocks. And this counter will create some synchronization problems that may turn out more important than saving disk space.
I haven't used freebsd for 5-6 years, so I've never tried to use it with root on ZFS. Wondering if it suffers the same problems as btrfs when used as root: last time I tried that on Ubuntu, the fsync() performance made a lot of stuff just horribly slow (e.g: dpkg operations two orders of magnitude slower).
I run FreeBSD with ZFS as root and it doesn't suffer from those issues. But then ZFS is quite significantly more mature than Btrfs anyway.
It's also worth noting that ZFS has been available as a root file system long before FreeBSD added ZFS to RELEASE. I remember running OpenSolaris (and some of it's forks, eg Nexenta) with ZFS root about 6 years ago. Possibly longer actually.
The issue with ZFS as root was more of a problem with the boot menu than the OS. OpenSolaris used GRUB where as FreeBSD obviously doesn't, so FreeBSD needs to either port their ZFS drivers to their bootloader, or employ a hacky method of having a UFS boot volume that then points to a ZFS root partition (which, sadly, is how FreeBSD currently works).
Interestingly, since GRUB is GPL, it meant that technically there were GPL ZFS drivers even before Btrfs started life (never mind the various Linux ports of CDDL-licenced ZFS drivers that have appeared since). Albeit those GPL ZFS drivers were read only
It's also worth noting that ZFS has been available as a root file system long before FreeBSD added ZFS to RELEASE. I remember running OpenSolaris (and some of it's forks, eg Nexenta) with ZFS root about 6 years ago. Possibly longer actually.
The issue with ZFS as root was more of a problem with the boot menu than the OS. OpenSolaris used GRUB where as FreeBSD obviously doesn't, so FreeBSD needs to either port their ZFS drivers to their bootloader, or employ a hacky method of having a UFS boot volume that then points to a ZFS root partition (which, sadly, is how FreeBSD currently works).
Interestingly, since GRUB is GPL, it meant that technically there were GPL ZFS drivers even before Btrfs started life (never mind the various Linux ports of CDDL-licenced ZFS drivers that have appeared since). Albeit those GPL ZFS drivers were read only
> FreeBSD needs to either port their ZFS drivers to their bootloader, or employ a hacky method of having a UFS boot volume that then points to a ZFS root partition (which, sadly, is how FreeBSD currently works).
A ZFS-aware loader hit CURRENT in late 2008, and a dedicated zfsloader for use from (gpt)zfsboot hit the stable branches in late 2009.
A ZFS-aware loader hit CURRENT in late 2008, and a dedicated zfsloader for use from (gpt)zfsboot hit the stable branches in late 2009.
AFAIK it's not in RELEASE yet though.
They were in 7.3-RELEASE, March 2010.
https://www.freebsd.org/releases/7.3R/announce.html
https://www.freebsd.org/releases/7.3R/announce.html
Just looked at the config on my file server and it turns out I'm booting FreeBSD in this way. I have no idea why I thought I was bootstrapping from UFS (possibly because I still had to manually create a boot GPT partition and since forgotten why?)
Anyhow, thank you for the correction :)
Anyhow, thank you for the correction :)
I don't know when this was fixed, but I have no longer had any problems with btrfs on root with ubuntu. I don't remember when it started working well, but I do remember those bad old days. I don't know if dpkg changed or if btrfs changed.
cp --reflink
One of the few feature btrs has which ZFS hasn't.
At this point, I don't think it's fair to imply that btrfs is lagging behind ZFS. Yes, there are quite a few things that ZFS does better than btrfs, but btrfs isn't following in ZFS's footsteps and has some killer features that ZFS will never have, like on-the-fly changing between RAID modes and resizing arrays in either direction.
Btrfs has a broken by design on disk format. Btrfs went with self describing checksums inside blocks instead of a Merkle-DAG with a round robin root. In doing so they ignored existing research at the start of the btrfs project and the only fix is to change the on disk format to add the children's checkums to the parent nodes.
That doesn't sound "broken by design" to me, just less thoroughly safeguarded than ZFS but still more than almost any other filesystem. It's completely consistent with my claim that btrfs isn't trying to follow exactly in the footsteps of ZFS. (And it's not like Merkle trees don't have any tradeoffs.)
ZFS would need block pointer rewrites to implement those features, right? I don't think ZFS developers are opposed to that, but progress is just stalled. So I think "will never have" is a bit strongly worded.
https://www.youtube.com/watch?v=G2vIdPmsnTI#t=44m53s
The above video is an explanation of a bunch of the barriers to implementing block pointer rewrites. The conclusion is that it would make the code a lot more complicated and break a lot of the layering, and probably make addition of other new features a lot harder. Even a standalone offline rewriting tool wouldn't necessarily be accepted into the OpenZFS codebase because of the maintenance burden. Their advice is that if you think you need that feature to solve a particular problem, you should be looking for a workaround to solve that problem without requiring the huge block pointer rewrite project (which nobody's working on), even if the workarounds have a significant and permanent performance impact.
When you take into account how long the feature's been in demand and been on the roadmaps under "eventually", it's clearly not going to happen anytime soon and won't happen without a major change to how ZFS development is being done. It's not definitely impossible, but it's perpetually several years away from happening. With btrfs already having it's equivalent to that feature and stealing an ever-growing slice of the users who need that feature, it's probably never going to happen for ZFS.
The above video is an explanation of a bunch of the barriers to implementing block pointer rewrites. The conclusion is that it would make the code a lot more complicated and break a lot of the layering, and probably make addition of other new features a lot harder. Even a standalone offline rewriting tool wouldn't necessarily be accepted into the OpenZFS codebase because of the maintenance burden. Their advice is that if you think you need that feature to solve a particular problem, you should be looking for a workaround to solve that problem without requiring the huge block pointer rewrite project (which nobody's working on), even if the workarounds have a significant and permanent performance impact.
When you take into account how long the feature's been in demand and been on the roadmaps under "eventually", it's clearly not going to happen anytime soon and won't happen without a major change to how ZFS development is being done. It's not definitely impossible, but it's perpetually several years away from happening. With btrfs already having it's equivalent to that feature and stealing an ever-growing slice of the users who need that feature, it's probably never going to happen for ZFS.
A feature similar to this was discussed at the OpenZFS Developers Summit earlier this month
http://open-zfs.org/w/images/7/71/Fast_File_Cloning-Pavel_Za...
http://open-zfs.org/w/images/7/71/Fast_File_Cloning-Pavel_Za...
I'm not an FS expert and others have answered your question much better, but I don't want you think I am ignoring you, so I'll talk about this part instead:
> the filesystem could offer an abstraction over a patch and pointer to the original file
I've implemented a delta-based patching system before: the idea is that, given two binary buffers (ostensibly files), encode the differences between them. I have no idea how Xdelta (VCDIFF-based) and bsdiff manage to do this at reasonable speeds (their code is too much for me to understand), but the best I could manage for this was O(n^2). It's a very complicated and difficult thing to do efficiently. But indeed it can result in massive file space savings. You could cheat a bit by intercepting fwrite commands, but that won't catch insertions or deletions. Nor programs that overwrite files instead of updating them in-place (eg most of them.) As you can guess, to really make something like this efficient would require program authors to rethink how they write to files, which is unlikely to ever gain traction.
What I'd really like to see, but know that we'll never get thanks to xkcd.com/927, is a metadata system for files that is portable. Instead of relying on file extensions or unreliable magic byte header detection, you'd have the MIME type included in this metadata. Along with the displayed file name that can have any characters in them (sans maybe the path separator), the file attributes (read/write/exec/user/group/owner/hidden), creation+modification+access times, etc. And then when you'd send a file through your e-mail client or FTP it up to some web server, it'd copy over the metadata along with it. So when you moved your file from extfs over to NTFS, and then copied that over to ZFS, you wouldn't lose all of that metadata.
But good luck getting all file system authors and browser vendors to agree to a common format to transparently wrap files with.
> the filesystem could offer an abstraction over a patch and pointer to the original file
I've implemented a delta-based patching system before: the idea is that, given two binary buffers (ostensibly files), encode the differences between them. I have no idea how Xdelta (VCDIFF-based) and bsdiff manage to do this at reasonable speeds (their code is too much for me to understand), but the best I could manage for this was O(n^2). It's a very complicated and difficult thing to do efficiently. But indeed it can result in massive file space savings. You could cheat a bit by intercepting fwrite commands, but that won't catch insertions or deletions. Nor programs that overwrite files instead of updating them in-place (eg most of them.) As you can guess, to really make something like this efficient would require program authors to rethink how they write to files, which is unlikely to ever gain traction.
What I'd really like to see, but know that we'll never get thanks to xkcd.com/927, is a metadata system for files that is portable. Instead of relying on file extensions or unreliable magic byte header detection, you'd have the MIME type included in this metadata. Along with the displayed file name that can have any characters in them (sans maybe the path separator), the file attributes (read/write/exec/user/group/owner/hidden), creation+modification+access times, etc. And then when you'd send a file through your e-mail client or FTP it up to some web server, it'd copy over the metadata along with it. So when you moved your file from extfs over to NTFS, and then copied that over to ZFS, you wouldn't lose all of that metadata.
But good luck getting all file system authors and browser vendors to agree to a common format to transparently wrap files with.
The basis for transferring file metadata is already there in zip in the form of -V for VMS file system metadata. This works well and can be used to transfer files via intermediate platforms which don't support that metadata.
It's not as seamless as one might wish; you do have to use zip. do the transfer and then unzip on the target, and of course remember to use -V in the first place.
FTP implementations also exist in the VMS world for transferring the file metadata, but I haven't used these myself so can't comment on their usability in practice.
It's not as seamless as one might wish; you do have to use zip. do the transfer and then unzip on the target, and of course remember to use -V in the first place.
FTP implementations also exist in the VMS world for transferring the file metadata, but I haven't used these myself so can't comment on their usability in practice.
Indeed, ZIP gets us part of the way there, and also handles the issue of transferring more than one file in one download request.
The downside to ZIP is that the information is cast away once you decompress it. If your file system doesn't maintain that metadata (eg Windows and file permissions), then it's just gone.
You also can't really just keep your files in ZIP because operating systems don't really natively integrate transparent ZIP support into files, and you probably don't want the file compressed in most cases (your app may want to read it often, and not want to pay the cost of decompressing the whole thing.)
But that is very close to what I am seeking, yes.
The downside to ZIP is that the information is cast away once you decompress it. If your file system doesn't maintain that metadata (eg Windows and file permissions), then it's just gone.
You also can't really just keep your files in ZIP because operating systems don't really natively integrate transparent ZIP support into files, and you probably don't want the file compressed in most cases (your app may want to read it often, and not want to pay the cost of decompressing the whole thing.)
But that is very close to what I am seeking, yes.
That's called copy-on-write (CoW) and is supported by a few modern filesystems (including ZFS). In fact ZFS does do some very basic deduping in the way you suggest (ie you copy a file instead of move it, and ZFS will just issue a pointer).
However full deduplication could never be free simply because of the overhead of keeping a table of all the duplicated data and scanning new content for duplications.
However full deduplication could never be free simply because of the overhead of keeping a table of all the duplicated data and scanning new content for duplications.
And ZFS deduplication consumes an absolutely frightening amount of RAM: 5GB of RAM per 1TB of storage is recommended.
Oh totally. ZFS gets a lot right but even ZFS can't make deduplication practical for all bar a few fringe cases.
That's not much. Our baseline config HP DL380s come with 64GiB RAM (!!)
File servers should really have Looooots of ram. after all its cheap cache (compared to a fusion io card) Our file servers have 384 gigs of ram. The next gen will probably have much more.
Copy-on-write is not the same thing as content-addressable.
ZFS has deduplication as an optional feature, which is implemented as a content-addressable store of filesystem blocks. In contrast to e.g. git the content-addressable aspect is an implementation detail that is not exposed to users.
http://blogs.sun.com/bonwick/entry/zfs_dedup
ZFS has deduplication as an optional feature, which is implemented as a content-addressable store of filesystem blocks. In contrast to e.g. git the content-addressable aspect is an implementation detail that is not exposed to users.
http://blogs.sun.com/bonwick/entry/zfs_dedup
> Copy-on-write is not the same thing as content-addressable.
I know that. But CoW does cover a few points raised by the previous poster.
> ZFS has deduplication as an optional feature, which is implemented as a content-addressable store of filesystem blocks. In contrast to e.g. git the content-addressable aspect is an implementation detail that is not exposed to users.
I know what dedup is and how ZFS utilises it (I've been running ZFS for about 8 years now - I'm quite familiar with it).
If you read my post again, you'll see I was discussing two separate points: 1) that CoW file systems do provide the pointer-like methods the former commenter raised. And 2) deduping isn't free.
What you're arguing with me is semantics and if you read the former post again, you'll understand why I chose the language I chose.
I know that. But CoW does cover a few points raised by the previous poster.
> ZFS has deduplication as an optional feature, which is implemented as a content-addressable store of filesystem blocks. In contrast to e.g. git the content-addressable aspect is an implementation detail that is not exposed to users.
I know what dedup is and how ZFS utilises it (I've been running ZFS for about 8 years now - I'm quite familiar with it).
If you read my post again, you'll see I was discussing two separate points: 1) that CoW file systems do provide the pointer-like methods the former commenter raised. And 2) deduping isn't free.
What you're arguing with me is semantics and if you read the former post again, you'll understand why I chose the language I chose.
openSUSE uses btrfs's copy-on-write behavior to allow rollbacks. Any time you use the package management system to change system state on a machine using btrfs the package manager actually snapshots the filesystem before (and I believe after) the install or remove. Due to COW this effectively only wastes the space for new versions of old files and snapshots can be cleared at will. It's a little weird to get used to, but it's actually a far more powerful "Oh Shit" button than package level rollback - a bad post-install script in a package that trashes /usr can usually be recovered easily if you read the docs and still have snapper (or can get a copy of it). Unfortunately RDBMSes don't usually play nice with copy on write filesystems, so it's much harder to do rollback there.
Thanks for everyone's answers. I now have a bunch of reading/learning for the weekend.
FreeBSD changed how the packages work last year
You now get the regular repository (binary packages updated once per week), or the 'Quarterly Branch' (a known-good snapshot of the packages, with security updates)
Or you can build your self from ports (or build your own packages using poudriere), which is up-to-the-minute bleeding edge.
You now get the regular repository (binary packages updated once per week), or the 'Quarterly Branch' (a known-good snapshot of the packages, with security updates)
Or you can build your self from ports (or build your own packages using poudriere), which is up-to-the-minute bleeding edge.
Your post is self-contradicting. You tell people not to use PC-BSD if they "want to know how stuff works". You then complain that to get a desktop working on plain old FreeBSD... you have to actually configure it... and know how it works.
"I just apt-get install xfce and I'm done" isn't learning how anything works.
If you want a ready-made desktop, use PC-BSD. If you want to learn to install a desktop from scratch, use vanilla FreeBSD. However, don't claim you want to know how it works, then whine when you have to gasp actually configure it to work.
"I just apt-get install xfce and I'm done" isn't learning how anything works.
If you want a ready-made desktop, use PC-BSD. If you want to learn to install a desktop from scratch, use vanilla FreeBSD. However, don't claim you want to know how it works, then whine when you have to gasp actually configure it to work.
> Your post is self-contradicting. You tell people not to use PC-BSD if they "want to know how stuff works". You then complain that to get a desktop working on plain old FreeBSD... you have to actually configure it... and know how it works.
Actually ... you're absolutely right. Sorry about that.
I guess a better way of putting it is that Debian is the upstream, and FreeBSD is the upstream, and that's what I was comparing. I'd personally feel a bit uneasy using PC-BSD, like I do with Ubuntu. But that's my hang up. It is a trade-off though. Things like the consolekit.pkla file I'd rather have done for me (there's only one way it should ever be done), things like font rendering I'm happy to know how to do myself now (in case I want to tweak things.)
But yes, for anyone looking to try FreeBSD on the desktop, definitely look into PC-BSD, as it may solve a lot of the complexities I discussed.
Actually ... you're absolutely right. Sorry about that.
I guess a better way of putting it is that Debian is the upstream, and FreeBSD is the upstream, and that's what I was comparing. I'd personally feel a bit uneasy using PC-BSD, like I do with Ubuntu. But that's my hang up. It is a trade-off though. Things like the consolekit.pkla file I'd rather have done for me (there's only one way it should ever be done), things like font rendering I'm happy to know how to do myself now (in case I want to tweak things.)
But yes, for anyone looking to try FreeBSD on the desktop, definitely look into PC-BSD, as it may solve a lot of the complexities I discussed.
I found it a particularly helpful comparison (since I've recently tried using FreeBSD after a long lapse, and considered trying PC-BSD), but I can see how you might find it deceptive. Debian is really effortless when you know what you're doing, but you still need to know a lot more to use it effectively than you do with Ubuntu.
> 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
These Just Worked for me. My only real annoyance with Xfce is that it's unresponsive to mouse clicks for the first few seconds after starting.
> I really, really appreciate Debian's branches. If you install Wheezy, you can get security updates for packages, but not get version bumps. With FreeBSD, you have to choose between "the packages made at release time", or "the absolute bleeding edge."
There are quarterly port branches now to give people more of a choice: https://lists.freebsd.org/pipermail/freebsd-ports-announce/2...
> encrypted swap
Be nice to see this on by default these days, but if you're not already using it: swapoff -a && $EDITOR /etc/fstab && plop ".eli" at the end of the swap device name && swapon -a. Done.
> I also really like pf a whole lot more than iptables
I just wish it were more actively maintained and kept at least vaguely in-sync with upstream. Makes me reluctant to switch from ipfw.
These Just Worked for me. My only real annoyance with Xfce is that it's unresponsive to mouse clicks for the first few seconds after starting.
> I really, really appreciate Debian's branches. If you install Wheezy, you can get security updates for packages, but not get version bumps. With FreeBSD, you have to choose between "the packages made at release time", or "the absolute bleeding edge."
There are quarterly port branches now to give people more of a choice: https://lists.freebsd.org/pipermail/freebsd-ports-announce/2...
> encrypted swap
Be nice to see this on by default these days, but if you're not already using it: swapoff -a && $EDITOR /etc/fstab && plop ".eli" at the end of the swap device name && swapon -a. Done.
> I also really like pf a whole lot more than iptables
I just wish it were more actively maintained and kept at least vaguely in-sync with upstream. Makes me reluctant to switch from ipfw.
> These Just Worked for me. My only real annoyance with Xfce is that it's unresponsive to mouse clicks for the first few seconds after starting.
Under a regular user account? I even added my user to wheel and operator, and no go. I've helped a few people on forums.freebsd.org set up this pkla file, too.
> There are quarterly port branches now to give people more of a choice
The quarterly branches are definitely a step in the right direction, but still not really what I want. I want patches for Heartbleed and Shellshock, but without any software version number bumps. I know their team is much smaller so it's just not feasible, but it's definitely something that would be greatly appreciated.
> I just wish it were more actively maintained and kept at least vaguely in-sync with upstream.
Definitely. Is OpenBSD's MP-safe yet? I believe that's partly related to why FreeBSD's has ALTQ disabled (but it's hard to find good information on why that choice was made.)
Under a regular user account? I even added my user to wheel and operator, and no go. I've helped a few people on forums.freebsd.org set up this pkla file, too.
> There are quarterly port branches now to give people more of a choice
The quarterly branches are definitely a step in the right direction, but still not really what I want. I want patches for Heartbleed and Shellshock, but without any software version number bumps. I know their team is much smaller so it's just not feasible, but it's definitely something that would be greatly appreciated.
> I just wish it were more actively maintained and kept at least vaguely in-sync with upstream.
Definitely. Is OpenBSD's MP-safe yet? I believe that's partly related to why FreeBSD's has ALTQ disabled (but it's hard to find good information on why that choice was made.)
> Under a regular user account?
Yep. Only special factors I can think of are VirtualBox guest additions and passphraseless sudo - though I don't recall any similar problems when I last had it on my laptop which had neither.
Also starting from console and not a display manager, because they're vile things that are almost as bad as splash/boot screens.
> I know their team is much smaller so it's just not feasible, but it's definitely something that would be greatly appreciated.
Very much so - the biggest thing I miss from the Debian world is unattended-upgrades. Maybe with some more commercial support..
> Is OpenBSD's MP-safe yet? I believe that's partly related to why FreeBSD's has ALTQ disabled
It's still under a big giant lock as far as I'm aware. They're also removing ALTQ in favour of a simpler framework: http://undeadly.org/cgi?action=article&sid=20140419151959
Yep. Only special factors I can think of are VirtualBox guest additions and passphraseless sudo - though I don't recall any similar problems when I last had it on my laptop which had neither.
Also starting from console and not a display manager, because they're vile things that are almost as bad as splash/boot screens.
> I know their team is much smaller so it's just not feasible, but it's definitely something that would be greatly appreciated.
Very much so - the biggest thing I miss from the Debian world is unattended-upgrades. Maybe with some more commercial support..
> Is OpenBSD's MP-safe yet? I believe that's partly related to why FreeBSD's has ALTQ disabled
It's still under a big giant lock as far as I'm aware. They're also removing ALTQ in favour of a simpler framework: http://undeadly.org/cgi?action=article&sid=20140419151959
> I just wish [pf] were more actively maintained and kept at least vaguely in-sync with upstream.
As much as I would love to have the newest OpenBSD pf config syntax available in FreeBSD I do appreciate them not breaking my firewall config as part of an OS update.
As much as I would love to have the newest OpenBSD pf config syntax available in FreeBSD I do appreciate them not breaking my firewall config as part of an OS update.
Ohh, and Re: ZFS using a lot of ram: You can limit it. The default is 95% of ram, and that is too high in all cases except a dedicated file server. PCBSD in 10.1 (released this week), changed the default to be much more conservative, since on a desktop/laptop type system, you probably only want to spend a fraction of your ram on increasing the speed of the file system.
I may be confused since I'm only now moving some servers to FreeBSD, but it sounds like you're suggesting freebsd-update brings in bleeding age, incompatible version if you want to get security fixes. Is that actually the case? I've got zero interest in running it as a desktop so I'm guessing that'll hit me less, but it's worrisome to hear.
As a side note, I'd love to have something like "freebsd-update rollback" for most Linux distros. I've seen attempts at it, but the only one that worked well for me was openSUSE integration of btrfs snapshots and the package manager. That's kind of swatting a fly with the complete works of Knuth, but it did the job.
http://www.freebsd.org/doc/handbook/updating-upgrading-freeb...
As a side note, I'd love to have something like "freebsd-update rollback" for most Linux distros. I've seen attempts at it, but the only one that worked well for me was openSUSE integration of btrfs snapshots and the package manager. That's kind of swatting a fly with the complete works of Knuth, but it did the job.
http://www.freebsd.org/doc/handbook/updating-upgrading-freeb...
For having the easy rollbacks, take a look at FreeBSD with ZFS on root with boot environments:
https://forums.freebsd.org/threads/howto-freebsd-zfs-madness...
https://github.com/vermaden/beadm/
http://wiki.pcbsd.org/index.php/Multiple_Boot_Environments
https://forums.freebsd.org/threads/howto-freebsd-zfs-madness...
https://github.com/vermaden/beadm/
http://wiki.pcbsd.org/index.php/Multiple_Boot_Environments
Not freebsd-update - Ports, the third-party package tree. There's no attempt made to create a "release branch" of Ports that gets kept up-to-date with security patches.
Correct, I should have clarified that. Since you mentioned server usage, keep in mind that the server software (Apache, PGSQL, PHP, OpenSSL, etc) are ports. Not that they're as unstable as desktop software usually is.
I have my VPS (production) and a local HDD I use for testing (stage), configured exactly the same way. I'll update stage first, and if all looks good, then I'll update production.
I have my VPS (production) and a local HDD I use for testing (stage), configured exactly the same way. I'll update stage first, and if all looks good, then I'll update production.
Thanks, I appreciate the clarification from you and vertex-four. I was indeed missing the ports part of what you were saying. I'm relatively comfortable with that since I'm not going to be using FreeBSD for any large-scale deployments and the software I care about tends to be reasonably good at backwards compatibility. In the case of PostgreSQL I'd test, but in an emergency I feel like I could do a live upgrade without too much stress. I'll have to keep an eye on Nginx and Sphinx, though.
>and just in general I favor the BSD/MIT/ISC licenses to the GPL.
Curious then as to your choice of licensing your Higan/BSnes emulators under GPLv3.
Curious then as to your choice of licensing your Higan/BSnes emulators under GPLv3.
I work on about 20+ projects, and my emulator is the only one that is GPLv3 licensed. The rest are all ISC licensed. (Note that parts of higan are ISC licensed, and I have granted other emulator authors exemptions, eg Snes9X now uses my audio core.)
The reason in higan's case, is because of the culture of the emulation community. There's a long, dark history of closed source emulators (even now with SuperGNES, no$sns and SNESGT), and I feel that emulation is a bit different from ordinary software: here, we are working under the threat of time. We realistically only have another 10-20 years to improve SNES emulation before finding a working system and persons interested in reverse engineering it are impractical.
I think it's very shallow and narcissistic to take the research of others, and not contribute back your own findings. I view this as more of an academic / historical preservation project than a regular desktop application. To end users, it's just for playing games, and not tied to any other system components, so I feel less bad about it.
To give a real world example, I encountered a bug in SuperFX (GSU1) emulation, and found that FuSuYa had a tracer-based fork of Snes9X: he basically added in a few fprintf() statements, and then refused to release the source to his changes. That would have been fine, but he botched something and introduced a very serious bug, one that I was also experiencing in my emulator. If I were able to diff his source to the official Snes9X source, I would have found and been able to fix that bug in a few minutes. Instead, it took me about two weeks to track it down.
Once I feel that SNES emulation has reached its limits in terms of research, I'll likely release the emulator under an ISC license as well.
Now I'm sure you can view this as me being hypocritical, and maybe it is, but that's my answer: I feel there's something more important than licensing at stake here.
The reason in higan's case, is because of the culture of the emulation community. There's a long, dark history of closed source emulators (even now with SuperGNES, no$sns and SNESGT), and I feel that emulation is a bit different from ordinary software: here, we are working under the threat of time. We realistically only have another 10-20 years to improve SNES emulation before finding a working system and persons interested in reverse engineering it are impractical.
I think it's very shallow and narcissistic to take the research of others, and not contribute back your own findings. I view this as more of an academic / historical preservation project than a regular desktop application. To end users, it's just for playing games, and not tied to any other system components, so I feel less bad about it.
To give a real world example, I encountered a bug in SuperFX (GSU1) emulation, and found that FuSuYa had a tracer-based fork of Snes9X: he basically added in a few fprintf() statements, and then refused to release the source to his changes. That would have been fine, but he botched something and introduced a very serious bug, one that I was also experiencing in my emulator. If I were able to diff his source to the official Snes9X source, I would have found and been able to fix that bug in a few minutes. Instead, it took me about two weeks to track it down.
Once I feel that SNES emulation has reached its limits in terms of research, I'll likely release the emulator under an ISC license as well.
Now I'm sure you can view this as me being hypocritical, and maybe it is, but that's my answer: I feel there's something more important than licensing at stake here.
Do you think the choice to compare FreeBSD to a particular distro, Debian -- indicates that the difference between FreeBSD and Debian is about the same as between Debian and other distros? Is FreeBSD essentially just like another distr (even though it's actually a separate OS, it's similar enough?)
FreeBSD is a concrete project in the same way Debian is.
Comparing a full system like FreeBSD to a kernel like Linux doesn't really get us anywhere. You can't really talk about the desktop experience comparisons when Linux can't even boot without a userland. If you tried to do it in an abstract sense, you'd be guaranteed to get responses of, "yes but Mouse Rat Linux supports ZFS and is also run by an elected core team!"; since there's pretty much a Linux distro for everything imaginable.
Comparing a full system like FreeBSD to a kernel like Linux doesn't really get us anywhere. You can't really talk about the desktop experience comparisons when Linux can't even boot without a userland. If you tried to do it in an abstract sense, you'd be guaranteed to get responses of, "yes but Mouse Rat Linux supports ZFS and is also run by an elected core team!"; since there's pretty much a Linux distro for everything imaginable.
It sounds to me then like what I was guessing is true -- the difference between the FreeBSD kernel and the Linux kernel, for most purposes, is of less importance than the choices made by the particular distro (FreeBSD or Linux distro of choice).
I'm curious if anyone who knows more than me would disagree, though (maybe for some purposes?).
I'm curious if anyone who knows more than me would disagree, though (maybe for some purposes?).
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.
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.
You can change the shell for a user in /etc/passwd, or with the command chsh.
It's funny how little things like this affect where you go with systems. On the uni systems, emacs was set up to reformat your code by default (as you typed it in). This drove me bananas, and I didn't realise it was configurable. So I went off and found another editor, and I'm still using it.
It's funny how little things like this affect where you go with systems. On the uni systems, emacs was set up to reformat your code by default (as you typed it in). This drove me bananas, and I didn't realise it was configurable. So I went off and found another editor, and I'm still using it.
Just don't change root's shell to something like bash. BAD THINGS WILL HAPPEN.
Care to elaborate? Does FreeBSD make assumptions about the root user's shell that Linux doesn't?
Yes, root's shell should be one provided by the distribution's base install.
I think the biggest worry is that if you need to do something like boot into single user mode for an emergency recovery, and /usr or /usr/local (with root's shell in it) is on a different or unmountable partition then you will not be able to do anything.
I think the biggest worry is that if you need to do something like boot into single user mode for an emergency recovery, and /usr or /usr/local (with root's shell in it) is on a different or unmountable partition then you will not be able to do anything.
Say there's a failure that forces you to bail into an emergency session where you can't mount /usr/local (which is where bash is typically installed on FreeBSD). All of a sudden, you don't have a shell.
This is a really bad place to be.
This is a really bad place to be.
I have no idea which shell you used, but this has worked for years in both zsh, and also in bash on FreeBSD.
With zsh you even get tab completion of ports, packages, and other command specific arguments.
With zsh you even get tab completion of ports, packages, and other command specific arguments.
I mean absolutely no disrespect by this: if enabling automatic tab completion stymied you a year ago, running FreeBSD (or other operating systems with a similar ethos) as a main install may not be for you just yet. Play with it in a VM with snapshots, use it as a learning experience for how to manage, break, and fix a *NIX install.
Personally I run Ubuntu on my work desktop so I can focus on work and not managing the OS. I run a private irc server on a busted old desktop running Arch Linux for the opposite reason :)
Personally I run Ubuntu on my work desktop so I can focus on work and not managing the OS. I run a private irc server on a busted old desktop running Arch Linux for the opposite reason :)
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.
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.
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...
[2] https://svnweb.freebsd.org/base/head/etc/master.passwd
[3] https://en.wikipedia.org/wiki/Tcsh
[4] http://www.tcsh.org/TipsAndTricks
The default root shell on FreeBSD is csh (tcsh) [1] and has been that way for at least 21 years (at least if I read the revision history [2] correctly, my own memories only go back about some 15 years).
As per Wikipedia article, tcsh natively supports tab completion since about 1983 [3] (which I can confirm always worked without an issue as far as my memories go, so again, give or take 15 years).
Permanently switching any user shell to tcsh (if it happens to be sh) is pretty much a single `chsh` command away, so as far as strictly tab completion goes, manual installation of bash is not required at all.
The required steps (step) to setup tcsh for tab completion can be found i.e. in this 2004 FAQ [4]:
Tip#7: List possible completions
I often see Bash users complain that Tcsh does not give a list of completions with the tab key. This is not true. Not only can Tcsh list complentions, but it can do it in color. Just add this to your ~/.tcshrc
set autolist set color set colorcat
[1] https://www.freebsd.org/doc/en/articles/linux-users/shells.h...
[2] https://svnweb.freebsd.org/base/head/etc/master.passwd
[3] https://en.wikipedia.org/wiki/Tcsh
[4] http://www.tcsh.org/TipsAndTricks
+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 ".
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 ".
...and /bin/sh has tab completion anyway (set -o emacs)!
The default shell in freebsd is probably still sh, which does not have tab completion
/bin/sh in 10.x has tab completion.
/bin/sh in 10.x has tab completion.
Thanks. This helps.
I didn't see tab completion when I was running the installer and I gave up.
Thank you for answering my question.
I didn't see tab completion when I was running the installer and I gave up.
Thank you for answering my question.
[deleted]
That's not a FreeBSD issue, that's a shell issue. Install bash and you'll have tab completion.
Really... /bin/sh has always had tab completion:
set -o emacs[deleted]
At a guess you're using sh or csh instead of bash?
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.
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.
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.
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.
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/>.)
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.
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/>.)
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.
Post more often please.
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.
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.
Facebook Seeks Devs To Make Linux Network Stack As Good As FreeBSD's: http://bsd-beta.slashdot.org/story/14/08/06/1731218/facebook...
(I don't want to start a flamewar, just add more stuff for a good discussion)
(I don't want to start a flamewar, just add more stuff for a good discussion)
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.
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.
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.
> 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.
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.
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.
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-Operat...
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.
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.
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
[2] https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/
- kqueue is a very powerful event loop similar to epoll [1]
- the FreeBSD ports collection is very simple to use as far as compiling from source goes. I only really prefer Debian's apt-get and Gentoo's emerge
- the FreeBSD Handbook is a very well-maintained text [2]. I freely admit OpenBSD has the best man pages ever written, but the Handbook is good too. Not bleeding-edge talk like the gentoo-wiki or archwiki, just reliable information.
[1] https://www.freebsd.org/cgi/man.cgi?query=kqueue&sektion=2
[2] https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/
I think the kqueue API is worse than the epoll API. They make it try to do too much by dealing directly with all kind of events. epoll on the other hand simply deals with file descriptors and there are other APIs to get file descriptors for events (timerfd, signalfd, eventfd, inotify, etc.). That makes epoll a lot more flexible. It's more of a "do one thing and do it right" approach and it adopts the "everything is a file" mantra to "everything is a file descriptor".
One way where the problem with this is showing, is the filesystem notification API of kqueue. It is a ridiculously bad API. E.g., you can't properly watch a directory with it. Replacing it with something saner would require changes to kqueue. If it had been designed like epoll then it would only require adding a different API to create a filesystem notification file descriptor.
One way where the problem with this is showing, is the filesystem notification API of kqueue. It is a ridiculously bad API. E.g., you can't properly watch a directory with it. Replacing it with something saner would require changes to kqueue. If it had been designed like epoll then it would only require adding a different API to create a filesystem notification file descriptor.
> 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.)
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.)
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....
(inetd) http://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/src/usr....
(ntpd) http://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/src/usr....
(httpd) http://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/src/usr....
(netcat) http://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/src/usr....
(inetd) http://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/src/usr....
(ntpd) http://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/src/usr....
(httpd) http://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/src/usr....
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.)
Well it has enough functionality to compile FreeBSD, which is a pretty complex project, so it has enough functionality for many purposes. But I have to admit to using Gnu-makeisms quite a bit.
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
[2] https://github.com/torvalds/linux/commits/master
Sometimes small size means things can change faster, eg NetBSD has had 64 bit time_t since 2012, while 32 bit Linux still has no roadmap to fix this (the BSDs are also have a different compatibility model). Other times it of course means that less is done and things take longer. You will often hear people say the BSDs are better designed, as perhaps prioritising limited resources leads to more design, or maybe there are just fewer people who need to solve a problem fast but not so well.
Including (some) userspace means that the tools are less bloated than the GNU ones which were designed pre Linux as portable tools, before the Gnu project had a kernel - remember GNU was the cathedral in the cathedral and the bazaar.
[1] https://github.com/freebsd/freebsd/commits/master
[2] https://github.com/torvalds/linux/commits/master
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Isn't that because ports are used compiled from source? You can do the same on Ubuntu with apt-get build-dep && apt-get source -b, which will install the build dependencies, download the source and compile it.
Isn't that because ports are used compiled from source? You can do the same on Ubuntu with apt-get build-dep && apt-get source -b, which will install the build dependencies, download the source and compile it.
If you have experience with ubuntu and the non rolling nature of the distro hurts you, then try debian testing. It's stable enough for desktop use, similar to ubuntu and has rolling updates. I personally run debian unstable (one up on the bleeding edge ladder), but I tolerate the occasional breakage.
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/)
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.
1) userland and kernel owned by the same group. this lends consistency to the experience, that is absent in linux, where it's clear that it's an amalgamation of many different tools.
2) (largely) one way of doing things
3) package management system (pkg-ng) that is a cross between gentoo portage and debian apt-get
4) extremely good documentation for an open source project (https://www.freebsd.org/doc/handbook/)
5) configuration is very simple (mostly driven from rc.conf)
6) excellent full-disk encryption support (geli)
driver support always lags a bit behind linux, on the other hand the drivers that do exist i'm confident are stable. i make sure to buy hardware which i know is supported.
> 4) extremely good documentation for an open source project (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...
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...
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/
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/
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 - you will need them for compiling software that assumes Gnu options for example.
Debian/kFreeBSD is a weird idea for me, you will have no support either form the FreeBSD community or the Debian community. I would go straight for FreeBSD proper, it is very well documented.
The Gnu tools are of course portable, so you can install them from ports - you will need them for compiling software that assumes Gnu options for example.
Debian/kFreeBSD is a weird idea for me, you will have no support either form the FreeBSD community or the Debian community. I would go straight for FreeBSD proper, it is very well documented.
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
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.
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.
Unfortunately kfreebsd will not be an official Debian 8 release architecture: https://lists.debian.org/debian-devel-announce/2014/11/msg00...
Freebsd has this Quickstart Guide for Linux Users[1] which is somewhat helpful.
[1] https://www.freebsd.org/doc/en/articles/linux-users/
[1] https://www.freebsd.org/doc/en/articles/linux-users/
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.
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.
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 ?.
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 ?.
I use http://nqhost.com/
Very affordable pricing, and these plans support FreeBSD: http://nqhost.com/freebsd-vps.html http://nqhost.com/unmetered-xen-vds.html http://nqhost.com/nq-vps.html
Very affordable pricing, and these plans support FreeBSD: http://nqhost.com/freebsd-vps.html http://nqhost.com/unmetered-xen-vds.html http://nqhost.com/nq-vps.html
How stable is FreeBSD on AWS
Very. You're more likely to run into problems running FreeBSD on physical hardware, in fact, because (a) a wider range of hardware means more potentially weird drivers, and (b) Amazon does a better job of weeding out flaky hardware than Joe's Dedicated Server Shop.
Very. You're more likely to run into problems running FreeBSD on physical hardware, in fact, because (a) a wider range of hardware means more potentially weird drivers, and (b) Amazon does a better job of weeding out flaky hardware than Joe's Dedicated Server Shop.
https://vultr.com/ is what I use. No complains.
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.
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.
http://atlantic.net/ has a 99 cent FreeBSD VPS available.
http://ovh.com/ has dedicated servers available with FreeBSD.
http://ovh.com/ has dedicated servers available with FreeBSD.
FYI- Azure also supports FreeBSD.
http://azure.microsoft.com/blog/2014/05/22/running-freebsd-i...
http://azure.microsoft.com/blog/2014/05/22/running-freebsd-i...
I can't speak to AWS and GCE since I don't use them (or freebsd for that matter), but the DO for BSDs is vultr.
I use Panix (panix.com) who also offers NetBSD and OpenBSD. They've been around for a long time.
http://www.panix.com/v-colo/plans.html
http://www.panix.com/v-colo/plans.html
Most of the AWS support for FreeBSD was done by Colin Percival, whom many hold in high regard.
Given that fact and the fact that Tarsnap runs on AWS I think it's safe to assume it's pretty stable.
Given that fact and the fact that Tarsnap runs on AWS I think it's safe to assume it's pretty stable.
Indeed, I didn't move Tarsnap over to FreeBSD/EC2 for a couple of years because the platform wasn't stable yet. But it definitely is stable now.
I have had good luck with https://www.arpnetworks.com/
Also see johncompanies.com - stable systems, excellent and fast technical support.
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.
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.
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).
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... (and even with how tiny it is, most of those lines aren't necessary for your average script, either.)
Further, rc.d really isn't anywhere near as bad as SysVinit. See an example of an rc.d script here: https://www.freebsd.org/doc/en/articles/rc-scripting/rcng-ho... (and even with how tiny it is, most of those lines aren't necessary for your average script, either.)
There isn't anything wrong with the systemd concept.
However, what many of the people I've discussed this have an issue with are:
* Becoming the default init in stable even though it's fairly new (and untested)
* Strong break from how common tasks are done (e.g. logging)
* Applications are very tied together and cannot easily be replaced or left out.
* NIH syndrome (e.g. their DNS resolver that just had a major caching issue)
However, what many of the people I've discussed this have an issue with are:
* Becoming the default init in stable even though it's fairly new (and untested)
* Strong break from how common tasks are done (e.g. logging)
* Applications are very tied together and cannot easily be replaced or left out.
* NIH syndrome (e.g. their DNS resolver that just had a major caching issue)
There is plenty wrong with the systemd concept.
Apart from your own list of things wrong with it, it is also monolithic, which goes directly against the Unix Philosophy,[1] which when concisely expressed is:
[1] - https://en.wikipedia.org/wiki/Unix_philosophy
Apart from your own list of things wrong with it, it is also monolithic, which goes directly against the Unix Philosophy,[1] which when concisely expressed is:
Write programs that do one thing and do it well.
Write programs to work together.
Write programs to handle text streams,
because that is a universal interface.
[1] - https://en.wikipedia.org/wiki/Unix_philosophy
You don't need to convince me systemd is doing it wrong! I'm in the process of switching to FreeBSD because I don't want the default system to contain something that hasn't been well tested. (Yes, it's a stupid thing, but I've been toying with switching for other reasons and this kind of made me do it :) I've also drunk the jails kool-aid for my next project.)
The "systemd concept", from what I understand (and is by no means specific to systemd), is to have a smarter init system for starting processes in order and better process management. Additionally, all the IPC "stuff" that's been happening and being touted reminds me a lot of microkernels where you could write small, simple services that do a single thing over a common, programmatic interface. Systemd however feels much too integrated and makes no effort to make it easy to swap components.
I'm also sort-of shocked that almost all the major distros just switched within a year or two of each other. Especially distros like RH and Debian (yes I know systemd is deved at RH) who bill themselves as "stable."
So there is nothing wrong with wanting a better init system and a common IPC platform, but that doesn't mean systemd is the best we can do.
The "systemd concept", from what I understand (and is by no means specific to systemd), is to have a smarter init system for starting processes in order and better process management. Additionally, all the IPC "stuff" that's been happening and being touted reminds me a lot of microkernels where you could write small, simple services that do a single thing over a common, programmatic interface. Systemd however feels much too integrated and makes no effort to make it easy to swap components.
I'm also sort-of shocked that almost all the major distros just switched within a year or two of each other. Especially distros like RH and Debian (yes I know systemd is deved at RH) who bill themselves as "stable."
So there is nothing wrong with wanting a better init system and a common IPC platform, but that doesn't mean systemd is the best we can do.
I've posted this before but
>goes directly against the Unix Philosophy
"Those days are dead and gone and the eulogy was delivered by Perl." -- Rob Pike
>goes directly against the Unix Philosophy
"Those days are dead and gone and the eulogy was delivered by Perl." -- Rob Pike
Well the concept of "systemd" have been explored multiple times over the years. But only systemd found the "need" to sprout tentacles everywhere.
> They clearly state that FreeBSD is in the same position....
I am not especially worried though, as it was just a presentation from [one guy][2] who is not a current member of the [core team][3] or [the FreeBSD foundation][4] and is probably not wholly representative of the entire FreeBSD project.
[1]: http://www.slideshare.net/iXsystems/jordan-hubbard-free-bsd-...
[2]: http://en.wikipedia.org/wiki/Jordan_Hubbard
[3]: http://en.wikipedia.org/wiki/FreeBSD_Core_Team#List_of_membe...
[4]: http://en.wikipedia.org/wiki/FreeBSD_Foundation
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.
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.
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
See the gist for results: https://gist.github.com/atmosx/14efea27eb2c1e38af09
I used FreeBSD out of curiosity. So far, I'm using my VPS to run services (mail, vpn, etc.) and found FreeBSD to be stable, easy to admin and fairly secure. Another interesting thing are the tools. BSD tools seem to be easier to configure: e.g. PF syntax > IPTABLES syntax, or OpenSMTPD (OpenBSD's smtp server) vs virtually-everything-else.
For reference see discussions here:
Ruby ML Discussion: https://www.ruby-forum.com/topic/5673725
See the gist for results: https://gist.github.com/atmosx/14efea27eb2c1e38af09
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.
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.
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.
* 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.
https://www.freebsd.org/doc/en_US.ISO8859-1/articles/linux-c...
http://www.onlamp.com/pub/a/bsd/2004/11/11/FreeBSD_Basics.ht...
http://www.onlamp.com/pub/a/bsd/2005/01/13/FreeBSD_Basics.ht...
http://www.pl.freebsd.org/doc/en/articles/explaining-bsd/art...
https://www.youtube.com/watch?v=y1puNK0xuhw
http://www.freebsdnews.net/
http://www.bsdnow.tv/
https://www.pfsense.org/getting-started/#overview
http://bsdtalk.blogspot.in/
http://www.openbsd.org/security.html
https://www.linkedin.com/pulse/article/20141028100615-571779...
http://www.embeddedarm.com/software/arm-netbsd-toaster.php
http://www.onlamp.com/pub/a/bsd/2004/11/11/FreeBSD_Basics.ht...
http://www.onlamp.com/pub/a/bsd/2005/01/13/FreeBSD_Basics.ht...
http://www.pl.freebsd.org/doc/en/articles/explaining-bsd/art...
https://www.youtube.com/watch?v=y1puNK0xuhw
http://www.freebsdnews.net/
http://www.bsdnow.tv/
https://www.pfsense.org/getting-started/#overview
http://bsdtalk.blogspot.in/
http://www.openbsd.org/security.html
https://www.linkedin.com/pulse/article/20141028100615-571779...
http://www.embeddedarm.com/software/arm-netbsd-toaster.php
https://www.freebsd.org/doc/en_US.ISO8859-1/articles/linux-c...
http://www.onlamp.com/pub/a/bsd/2004/11/11/FreeBSD_Basics.ht...
http://www.onlamp.com/pub/a/bsd/2005/01/13/FreeBSD_Basics.ht...
http://www.pl.freebsd.org/doc/en/articles/explaining-bsd/art...
https://www.youtube.com/watch?v=y1puNK0xuhw
http://www.freebsdnews.net/
http://www.bsdnow.tv/
https://www.pfsense.org/getting-started/#overview
http://bsdtalk.blogspot.in/
http://www.openbsd.org/security.html
https://www.linkedin.com/pulse/article/20141028100615-571779...
http://www.embeddedarm.com/software/arm-netbsd-toaster.php
http://www.onlamp.com/pub/a/bsd/2004/11/11/FreeBSD_Basics.ht...
http://www.onlamp.com/pub/a/bsd/2005/01/13/FreeBSD_Basics.ht...
http://www.pl.freebsd.org/doc/en/articles/explaining-bsd/art...
https://www.youtube.com/watch?v=y1puNK0xuhw
http://www.freebsdnews.net/
http://www.bsdnow.tv/
https://www.pfsense.org/getting-started/#overview
http://bsdtalk.blogspot.in/
http://www.openbsd.org/security.html
https://www.linkedin.com/pulse/article/20141028100615-571779...
http://www.embeddedarm.com/software/arm-netbsd-toaster.php
Start watching http://www.bsdnow.tv , great show focusing on the *BSD's.
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.
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.
Anyway, I like the first comments idea about a wiki. That would be helpful.
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.
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.
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.
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.
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.
The problem with binary packages on freebsd was that they are frozen at release. So when you use the package manager to install everything you need... then a large package has a security hole (or it already has a hole.. since the packages might be months out of date), and the only way to patch it is by using the ports.
THe only thing packages on freebsd are good for is getting up and running. You'll save a bit of time if you install the packages.. but you have to use ports to upgrade and maintain those packages.
I 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.
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.
I used it from 3.4-8.. nice to see that they addressed my problem with the new package manager.
Actually, they had been generating ~weekly snapshots of built binary packages in the past, but for some reason I don't understand, they weren't used by default, and the setup to actually use them was... obscure and not really officially documented. You had to set the right environment variable to point to the remote HTTP repository.
The new pkg uses the up-to-date repository by default. It has fixed all this mess, and turned binary packages from something very clunky that nobody really used to something fairly solid that can be used in production. The only reason I use ports nowadays is when I need to set custom build options on a package.
The new pkg uses the up-to-date repository by default. It has fixed all this mess, and turned binary packages from something very clunky that nobody really used to something fairly solid that can be used in production. The only reason I use ports nowadays is when I need to set custom build options on a package.
If you use saltstack, puppet or chef to manage your servers it shouldn't really make that much of a difference how many servers you manage... be they linux or freebsd.
" I just wouldn't advise rolling it out to lots of servers, unless you have a very specific reason to do so."
You mean like Netflix And Whatsap do?
You mean like Netflix And Whatsap do?
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
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.
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.
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.
>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.
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.
> Size seems like a really odd thing to bring up since every mainstream linux distro's "basic" installation is larger than the full OS of any of the four BSDs.
I don't think that's entirely true. The Debian install I do by default, with no tasksel tasks selected, is very minimal. I haven't checked recently how large it is (and one of the reasons I am considering moving away is that I suspect the minimal required system has been growing with the adoption of things like systemd), but I remember a few years ago noting that it was a fair bit smaller than a clean OpenBSD install. That's not including X and compilers IIRC.
Also, as I understand it, Arch Linux is becoming quite popular and it is also pretty spartan by default.
(Not that I think this really matters for most cases (embedded excepted); I would like to be able to uninstall tcsh, though.)
I don't think that's entirely true. The Debian install I do by default, with no tasksel tasks selected, is very minimal. I haven't checked recently how large it is (and one of the reasons I am considering moving away is that I suspect the minimal required system has been growing with the adoption of things like systemd), but I remember a few years ago noting that it was a fair bit smaller than a clean OpenBSD install. That's not including X and compilers IIRC.
Also, as I understand it, Arch Linux is becoming quite popular and it is also pretty spartan by default.
(Not that I think this really matters for most cases (embedded excepted); I would like to be able to uninstall tcsh, though.)
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.
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.
>Sorry, I'm going to have a hard time taking this seriously.
That will happen when you don't read it. Allow me to repeat it for you: 'There is no "basic linux installation"'. Linux is a kernel. There is no "basic linux installation". I do not know how it could possible be stated any clearer. Each individual distro is its own OS, which may or may not have a installation labelled "basic". Most of those are larger than any BSDs full OS. This is very simple.
>And, frankly, your statement about the "full OS" is meaningless
No it is not. You are awfully hostile for someone who just wants to learn. BSD operating systems are operating systems. The full OS means the full OS. Plain and simple. The lack of distinction between the OS and third party packages is unique to linux distros, where the OS itself consists almost entirely of third party packages in the first place. In BSD systems as in most systems, the operating system is everything included in the operating system, and third party software is third party software.
>it includes every possible package
This is one of the fundamental differences, which is why it seems to odd that you claim to be talking about the differences but you don't even know them.
>I meant small in terms of packages. The kernel, a shell, and not much else unless you specify it.
There is no mainstream linux distro where that is the case. Only specialized micro distros intended for embedded use and based on busybox provide anything like that. Debian, ubuntu, fedora, etc all have a few hundred MB more stuff in their minimal installation.
>but the point was that I'm used to specifying exactly what else I want
It is unreasonable to expect me to understand that was your point when you said something completely different. Nonetheless, you do not get that unless you are doing a custom LFS.
>The point you ignored or missed is that as a Linux user with no BSD exposure there's a basic difference in philosophy
No, that's the point you missed and instead talked about being minimal.
>I'm not "bringing up" anything in terms of absolute pros and cons
Saying "I love thing that is my own misunderstanding" implies that the other option lacks that thing. That's what pros and cons are all about.
That will happen when you don't read it. Allow me to repeat it for you: 'There is no "basic linux installation"'. Linux is a kernel. There is no "basic linux installation". I do not know how it could possible be stated any clearer. Each individual distro is its own OS, which may or may not have a installation labelled "basic". Most of those are larger than any BSDs full OS. This is very simple.
>And, frankly, your statement about the "full OS" is meaningless
No it is not. You are awfully hostile for someone who just wants to learn. BSD operating systems are operating systems. The full OS means the full OS. Plain and simple. The lack of distinction between the OS and third party packages is unique to linux distros, where the OS itself consists almost entirely of third party packages in the first place. In BSD systems as in most systems, the operating system is everything included in the operating system, and third party software is third party software.
>it includes every possible package
This is one of the fundamental differences, which is why it seems to odd that you claim to be talking about the differences but you don't even know them.
>I meant small in terms of packages. The kernel, a shell, and not much else unless you specify it.
There is no mainstream linux distro where that is the case. Only specialized micro distros intended for embedded use and based on busybox provide anything like that. Debian, ubuntu, fedora, etc all have a few hundred MB more stuff in their minimal installation.
>but the point was that I'm used to specifying exactly what else I want
It is unreasonable to expect me to understand that was your point when you said something completely different. Nonetheless, you do not get that unless you are doing a custom LFS.
>The point you ignored or missed is that as a Linux user with no BSD exposure there's a basic difference in philosophy
No, that's the point you missed and instead talked about being minimal.
>I'm not "bringing up" anything in terms of absolute pros and cons
Saying "I love thing that is my own misunderstanding" implies that the other option lacks that thing. That's what pros and cons are all about.
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...
[1] http://blog.dustinkirkland.com/2014/08/re-introducing-jeos-j...
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.
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.
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.
NetBSD takes bootstrapping most seriously - you can cross build it on any system with a vaguely functional C compiler, and it will bootstrap completely.
> release-upgrade can be either perfect or very painful.
This seems to be in the nature of the task. Freebsd-update is also often perfect, but if it goes wrong it can be very painful as well.
On the other hand, you do have a rollback feature, but then you're back to a probably working, outdated system.
This seems to be in the nature of the task. Freebsd-update is also often perfect, but if it goes wrong it can be very painful as well.
On the other hand, you do have a rollback feature, but then you're back to a probably working, outdated system.
FreeBSD: ZFS. Jails. Dtrace. Greatly easier to grok
GNU/Linux: Desktop
GNU/Linux: Desktop
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.
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.
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
I like FreeBSD, but I have yet to run the same stack on multiple operating systems in production. That's a LOT of work!
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
I like FreeBSD, but I have yet to run the same stack on multiple operating systems in production. That's a LOT of work!
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/
[0]: https://cooltrainer.org/a-freebsd-desktop-howto/
> 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.
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.
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.
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.
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.
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!
_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). 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.
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). 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.
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.
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
[1]: 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
[1]: 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
[1]: 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
[1]: http://www.amazon.com/Absolute-FreeBSD-Complete-Guide-Editio...
[2]: 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
It's likely that you know things that I don't, so please feel free to correct me if I'm wrong.
---
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
[1]: 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
[1]: 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
[1]: 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
[1]: http://www.amazon.com/Absolute-FreeBSD-Complete-Guide-Editio...
[2]: 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
It's likely that you know things that I don't, so please feel free to correct me if I'm wrong.
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).
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).
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.
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.
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.
This is only guaranteed with ECC RAM, right?
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.
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.
As an anecdotal data point, I see ECC corrections much, much more often than ZFS CKSUM errors. If you're in any way concerned about bitrot, ECC memory should be the first thing you go for regardless of your choice of filesystem.
Snapshots with LVM still imply a relatively costly(?) quiescing of the filesystem for however long it takes to complete pending writes and perform the snapshot. This is certainly my experience with snapshots on UFS2 - they're supported, but you're not going to be too pleased performing them automatically from a cronjob every 15 minutes.
Snapshots can also be promoted to fully-fledged filesystems using cloning, which is very handy for spawning off fully-featured jail environments and for setting up boot environments for a host.
Filesystem replication. My primary backups involve using `zfs send` to maintain remote copies of my snapshots on another machine with minimal cost in bandwidth and disk IO.
Filesystem compression. My root pool is just 0.63x the size it would have been thanks to lz4, basically for free.
As X-Isence says, end-to-end data protection. Every bit of data and metadata are checksummed so any errors are detected, and if possible automatically repaired. Crucial metadata is duplicated even on single-disk configurations.
Copy-on-write semantics make for more robustness in face of problems - active data is never overwritten in-place. This also makes for much safer parity RAID than traditional approaches.
Snapshots can also be promoted to fully-fledged filesystems using cloning, which is very handy for spawning off fully-featured jail environments and for setting up boot environments for a host.
Filesystem replication. My primary backups involve using `zfs send` to maintain remote copies of my snapshots on another machine with minimal cost in bandwidth and disk IO.
Filesystem compression. My root pool is just 0.63x the size it would have been thanks to lz4, basically for free.
As X-Isence says, end-to-end data protection. Every bit of data and metadata are checksummed so any errors are detected, and if possible automatically repaired. Crucial metadata is duplicated even on single-disk configurations.
Copy-on-write semantics make for more robustness in face of problems - active data is never overwritten in-place. This also makes for much safer parity RAID than traditional approaches.
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
$ uptime 11:23PM up 835 days, 5:33, 1 user, load averages: 0.07, 0.02, 0.01
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.
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.
Why aren't we talking about OpenBSD vs. Linux?
I mean, it's the only OS I trust anymore.
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
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.
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?
If you wanted to create Ubuntu today, would you use GNU/Linux or FreeBSD as base?
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.
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.
I started wondering about this when I heard Sony uses the FreeBSD kernel. If for a console, why not for the desktop?
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.
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.
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.
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.
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.
> 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/
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 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.
I don't believe any BSD has ever been certified for UNIX98 (or any version). 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 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.
[deleted]
no, or your comments will be banned :/
The worst part of FreeBSD is the license.
If you can't decide yourself just stick with your current OS.
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.