It's worth trying to grind through a few months of Free-BSD after using Linux to get a feel for it. One of my favorite quotes on the differences is, "FreeBSD is what you get when a bunch of old school Unix beard brigade hackers sit down to write a port to the PC. Linux is what you get when you take a bunch of hackers raised on Windows and PCs that try to port Unix to the PC". In a lot of ways that is two sides of the same coin, but really digging in to the BSD way of things opens up a new view point on Operating Systems . . . FreeBSD old school Unix assembly versus NASM, the Kqueue vs ePoll system implementations, FreeBSD's near instantaneous embrace for ZFS while the Linux community held back for "OS theological" concerns over the FileSystem implementation.
I've jumped between Debian and FreeBSD for my development boxes for a few years now. To butcher Dijkstra, "Operating Systems shape developers as much as violins shape violinists". When I find myself on FreeBSD I make great use of D-Trace - running vagrant FreeBSD boxes, the pulling the trace output into Instruments to analyze. With the release of Trim for ZFS, ZFS pooling for logging should be obscenely fast and offer some serious performance increases for things like proper Hadoop workloads. When I find myself on Debian I'm enthralled by the ease of use around layouts and the API ( kqueue / epoll excluded ). The package management system is far superior to portsnap, though neither system really does modern package management really well imo.
Personally, I think it's worth trying to run BSD and all it's tools just to understand the system better, and to see how it influences you as a developer. The active utilization of D-Trace changed me as an engineer just as much when I first started using functional programming concepts in my regular code
I switched a personal server over to freebsd (8 or so at the time) a while ago after battling with zfs on linux. (I was hitting some strange issues at the time which I can't really even remember at present)
After getting over the initial learning curve (files being in different places than I expect / named different things etc) I have really come to like freebsd. You get the sense that everything has been designed to fit together a bit more than the linux distros. I had been using ubutnu before and I got really tired of how much constantly changed between releases. With bsd I'm able to get very up to date software via the ports tree, but the overall 'system' design doesn't seem to change as much between releases as it did in linux land.
The freebsd handbook is great and makes it super easy to get up and running. I certainly don't think the differences for everyday use between freebsd / debian for example are enormous, but I plan on using freebsd for most of my boxes from now on, its just been really painless to work with.
I thought btrfs was going nowhere for a while because it seemed way behind zfs for a long time.
But now it looks like it's catching up, and has some nice userspace tools, and some features that I don't even think zfs has (like the option to do overwrite-in-place, but you give up checksums/compression).
The user tools seem worse than zfs, but it does look like btrfs will be a leading filesystem soon.
I wouldn't say soon. Btrfs needs much more robust userspace tools. At the moment, the tools tell you nothing, and recovery is basically impossible. I have lost data several times now. While I had backups since I was using btrfs, I didn't expect to lose data the way that I did. The drive filled up with metadata, and since it didn't have anywhere to rebalance the metadata it couldn't move it, and even if I deleted files it wouldn't make a difference. It happened to me on two occasions. The interesting thing is that btrfs filesystem df showed I only had 80gb total, with a 120gb drive. Decided to go back to xfs for that drive, and I use zfs for my raidz2 array.
They absolutely can ship it. They choose not to. There is a big difference.
It's what happens when ideology is allowed to trump technology, and it is sad.
The fact that various distros ship not-open video card drivers shows that for some things, there's a willingness to compromise. This is far "worse" than shipping an open source module, or open source code that is compiled into a module on install, either of which could be done for ZFS.
The non-free drivers are allowed to be redistributed by the copyright holders. The reason to not distribute them would be ideological.
Linux and ZFS's licenses are incompatible, which would make it illegal to distribute them together. Both ZFS and Linux copyright owners could choose to sue any entity that would distribute Linux with ZFS support.
Apart from that, e.g. each time you update your kernel you would have to recompile the modules for that specific kernel. ZFS is also an FS and i wouldn’t want to play jeopardy every time i do an update.
You depend on people outside your distribution to keep up, otherwise it might break when you upgrade your kernel. It's also basically in a perpetual beta.
If you want cool updates stick with linux. If you want a solid system that you can update feeling confident you're not going to break anything, on the other hand...
I've jumped between Debian and FreeBSD for my development boxes for a few years now. To butcher Dijkstra, "Operating Systems shape developers as much as violins shape violinists". When I find myself on FreeBSD I make great use of D-Trace - running vagrant FreeBSD boxes, the pulling the trace output into Instruments to analyze. With the release of Trim for ZFS, ZFS pooling for logging should be obscenely fast and offer some serious performance increases for things like proper Hadoop workloads. When I find myself on Debian I'm enthralled by the ease of use around layouts and the API ( kqueue / epoll excluded ). The package management system is far superior to portsnap, though neither system really does modern package management really well imo.
Personally, I think it's worth trying to run BSD and all it's tools just to understand the system better, and to see how it influences you as a developer. The active utilization of D-Trace changed me as an engineer just as much when I first started using functional programming concepts in my regular code