And the man pages. Oh, how wondrous they were. This first thing I had to do was learn to NOT google for how to accomplish something, but just read the man page. Often, there's not much on google about something because there was no need for someone to document how they accomplished it, they just did what the man page said and it worked.
In linux, the man pages are generally skeletons outlining some flags and what something might support. In BSD (or at least OpenBSD) for core OS items, they are canonical. Compare:
http://linux.die.net/man/8/ifconfig
http://www.openbsd.org/cgi-bin/man.cgi?query=ifconfig
Note: One the reasons the OpenBSD ifconfig man page is so big is because on OpenBSD ifconfig does the job of multiple Linux utils, because it makes sense to have ifconfig control all the interface state.That said, I still mainly use Linux, specifically RHEL and derivatives, specifically because I think the enterprise Linux distros have a better support model for enterprise environments, where multiple machines need to be kept up to date or in sync, and you need to deploy identically (and repeatably) to systems.
Frankly, I'm surprised there's not a alternate, distro model for FreeBSD that's aimed at the enterprise to address these issues (or if there is, it's not popular enough for me to know of it). Maybe FreeBSD as an organization is coherent enough and does a good enough job at support for the distro in general that there's never been enough of push to really compete in the enterprise server market. Or maybe I'm just misinformed about how much BSD is in use in the enterprise. That's always a possibility.
And the man pages. [...] This first thing I had to do was learn to NOT google for how to accomplish something, but just read the man page.
I'm only learning, but I've had a very similar experience setting up and hardening a FreeBSD box using the FreeBSD Handbook (at least as my primary resource):http://www.freebsd.org/doc/en/books/handbook/
You just pick the section of interest (or sit down and start from the beginning) and.. start reading. And when you're done, you understand the overall design of the system, its processes and system tools. With GNU/Linux, I quite often feel that when there's a problem, I'm looking for a quick fix. (Granted, it may simply be due to my limited experience / few years of exposure.)
In any case, I do thoroughly recommend everyone dabbling with fbsd not to underestimate the power of fbsd's documentation, and the uniformity (and the resulting empowerment of the system administrator because of this) of the overall system. As I understand it, OpenBSD is very much alike in that sense.
It'd be interesting to know why the BSD man pages are so much better.
Do you know if iproute2 if it supports STP configuration? I used brctl in the past to configure that, and it's something I would expect in an interface configuration tool (although maybe not a command named "ip"). I don't imagine that would be hard for them to add in if not though.
I think a better example of my point regarding man pages would be CARP[1]. In my experience where Linux has really lacked in man pages is concepts. The BSDs will offer refer you to man pages that aren't for any one command or file, but for a system or feature to explain it in general.
See also ipsec[2] for a description of the protocol, and aac[3] for a description of their driver implementation for Adaptec "FSA" family of RAID cards, and documentation on how to work with bluetooth[4] at the kernel level on their platform. Really, most of section 4[5].
[1]: http://www.openbsd.org/cgi-bin/man.cgi?query=carp
[2]: http://www.openbsd.org/cgi-bin/man.cgi?query=ipsec
[3]: http://www.openbsd.org/cgi-bin/man.cgi?query=aac
[4]: http://www.openbsd.org/cgi-bin/man.cgi?query=bluetooth
[5]: http://www.openbsd.org/cgi-bin/man.cgi?query=(4)&apropos...
Task / BSD / Linux
set ip / ifconfig / ifconfig or now "ip" which is extremely confusing
wifi / ifconfig / iwconfig
speed / ifconfig / miitool or ethtool
duplex / ifconfig / miitool or ethtool
vlan / ifconfig / vlan
wol / ifconfig / miitool or ethtool
bridge / ifconfig / brctl
link aggregation / ifconfig / flags while loading module OR use distro network config scripts and restart all networking or reboot server
Want find out which nic is occupying ethX perhaps for tuning or scripting etc?
Linux = complicated, by distro/version
FreeBSD = nic by device eg em0
Most Linux distros are adopting consistent naming schemes, using biosdevname algorithm, e.g.
https://fedoraproject.org/wiki/Features/ConsistentNetworkDev...
> More addon tools simply proves the point.
I was only showing that comparing Linux’s ifconfig with BSD’s ifconfig is not fair, not really making any point.
I don’t see how this is all that confusing though, you get ip for managing routing and iw/ethtool/etc for managing interfaces or creating interfaces on lower networking levels or device level. It’s just different.
Also Dtrace & ZFS originally come from Solaries, so they are not FreeBSD projects. The only reason they do not work on Linux is because of license problems which Sun created.
btrfs does not even try to solve the problem I want zfs for; snapshots over the network.
You see, when you deal with a large amount of storage (especially if you deal with that storage as block devices that run arbitrary filesystems, and not just files on a filesystem) the bottleneck for backups becomes disk bandwidth, not network bandwidth, so things like rsync don't help much.
ZFS snapshots over the network? those help rather a lot. Unlike rsync and stuff, it saves me disk bandwidth, not just network bandwidth. Unlike inotify-based systems, I don't need to have knowledge of the filesystems I'm replicating.
(I know I harp on this a lot... I just want to point out that btrfs, no matter how good it is for the problems it attempts to solve, isn't even trying to solve the problem I need ZFS for.)
This a recent Ubuntu system (ie not using development trees etc)
$ btrfs send --help
usage: btrfs send <command> <args>
btrfs send [-v] [-i <subvol>] [-p <parent>] <subvol>
Send the subvolume to stdout.
$ btrfs receive --help
usage: btrfs receive <command> <args>
btrfs receive [-v] [-i <infile>] <mount>
Receive subvolumes from stdin.It may be awesome, but I'd say "soon" is a pretty optimistic timeline.
Our testing pretty conclusively demonstrated that btrfs was still a long way from production-ready; We've seen numerous problems with deadlocks; Filling up a filesystem pretty much ruins it forever -- And these are not new problems.
http://lwn.net/Articles/238655/
As far as I can tell, those forecasts have almost always come from outside the project. I don't recall Chris Mason ever saying that it's right around the corner.
In fact, searching for "soon" on the Btrfs wiki produces 0 results.
It's still a very active project, but there's still a lot of work to be done.
I may be an old Solaris hand now but ZFS works. Now, not in the future, my home fileservers on FreeBSD have worked for ages and had no issues. Unlike the many complete losses on BTRFS on Linux that I see happening time and time again. SuSE might be promoting BTRFS, but objectively I can't agree with their decision.
ZFS is stable and released. Pretty sure that makes it instantly "better" than btrfs right now.
One thing I like about FreeBSD, and the BSDs in general, is that they don't suffer from such problems.
It's odd that Oracle (who now own Sun's IP) paid to develop a whole new filesystem (btrfs) for Linux instead of just changing the licensing terms for ZFS. It would be nice to have a really good, Apache-licensed filesystem that could run across Linux, OS X, BSD, and Solaris.
http://www.pcbsd.org/en/download.html
Where FreeBSD really shines though, is web deployment -- i.e, it's an awesome platform to deploy your webapps on once they're ready.
First, keep in mind that some of the packages will simply not run on FreeBSD because it's often overlooked by developers. Same logic applies for technical support for applications that are running on FreeBSD powered machine.
You also will need to learn how port system works on FreeBSD and it might be a weird learning curve. Same applies for kernel patching/upgrading/etc.
I decided to try FreeBSD last year and was able to learn enough in a week to do some basic development work with it. In fact, I submitted patches for Mono 3.0 and F# 3.0 to the FreeBSD ports tree:
http://www.freshports.org/lang/fsharp/ http://www.freshports.org/lang/mono/
The folks on the FreeBSD forums are also very helpful (and patient!) so if you do run into trouble, you'll likely find the solution by asking there.