The state of documentation and man pages is indicative. Nearly everything in the BSDs has a well written up to date docs. Determining behavior in linux all too often comes down to reading opaque kernel code and old mailing list threads that may or may not be relevant.
It just goes to show how solid the BSDs really are. I use the hell out of keepalived (OSS vrrp daemon) + conntrackd on Linux, but strongly prefer carpd and pf. It moves a lot slower, but it caters to a different audience.
"Facebook is seeking a Linux Kernel Software Engineer to join our Kernel team, with a primary focus on the networking subsystem. Our goal over the next few years is for the Linux kernel network stack to rival or exceed that of FreeBSD."
[1] https://www.facebook.com/careers/department?req=a0IA000000Cz...
1. Throughput
2. Latency
Both are relevant for webapps like facebook.
When the company I was working for at the time's AC failed in the machine room and melted three racks of kit, all 7 of our FreeBSD machines at the time were back online from scratch on hot spare kit in under two hours.
Our Windows guys were still working on restoring the master Active Directory pair and DFS cluster TWO DAYS LATER even with a DR strategy in place.
Quality engineering, documentation and automation ability shits on everything else IMHO and that's where FreeBSD lands every time. Performance isn't a major thing for me.
Linux on the other hand is heading in the direction of windows. I'll probably get flamed by the systemd proponents here but it took me three hours to work out how to debug this command:
timedatectl set-ntp yes
Failed to issue message callI'd be overjoyed if I never had to admin Windows again, but it's a bit unfair to frame that as an OS comparison.
The most basic of direct from TechNet 'best practices' would reduce the impact of a failure of that sort to minutes.
That said, that sort of failure not at all uncommon. Further, I expect such disasters would happen far less often if an existing, poorly implemented Microsoft environment could be remediated into something better as directly as anything unix-like.
In this case, they had tested DR strategy etc in place. Unfortunately when it came to doing it for real (onto the same backup hardware the DR plan was tested against), TSHTF and Windows threw an obscure COM error loading the AD catalog. That required contacting MS 1st line who didn't know what it was so had to escalate it to the AD guys. One obscure registry key change and an ACL change (related to ESE) and it was back.
All best practices followed, yet complexity, poor design and secret knowledge crept in and shot the whole process.
Stuff like that scares the shit out of me having been on the end of it way too many times now.
Many a night have I spent up at 2AM trying to work out why the hell something odd has gone on inside Windows and taken something out in production. Not once in 20 years has a proper Unix (Solaris/FreeBSD) box woken me up or shafted me for hours.
Every system has bugs.
Never been a fan of Xen. It doesn't strike me as quality software. Then again no virtualization solution has to me, yet. I'd rather just deploy all the services to the base machine and use MAC to isolate them.
The DR environment was the staging environment for the patches. Periodically the production kit would be block copied back to the DR environment and sysprepped.
Every step to prevent differences between the two clustered environments were taken.
The reasons for this, in part, are the different mentalities in the Linux and BSD communities. The Linux community used to be quite adamant about how "Linux is not Windows" and sticking to their paradigms, but more recently they've been absolutely obsessed with pipe dreams of conquering the desktop, and have been completely undermining their technical workflow in the process. Instead of "Linux is not Windows", it seems companies and communities alike have decided to pander to a crowd that has no respect for computing and Unix culture, who are used to closed systems that hold your hand, and quality is suffering in the process.
The BSD people on the other hand, have stayed true to their heritage, and show no signs of compromise. BSD people also tend to be very familiar with Linux as well, whereas the opposite is much less common.
Reminds me of some mad attempts to debug some problem in Unity/GNOME... I gave up pretty fast after stranding on orphaned freedesktop.org pages.. I distinctly remember ranting on reddit about the problems and I've got a few .odt presentations from GNOME developers that not so really explained some concepts.. it's a different world. I can't judge if it's better this way for the Desktop but I've found it impossible to debug without sacrificing enormous time and energy about things I'd never wanted to deal with.
Stark contrast has been xCAT by IBM.. it's used to manage clusters of 10000 machines and it's only small readable Perl and Shellscripts.. totally awkward at the beginning but once you get a grasp it's a flexible power tool.
The sad part is it's still better than windows.
Oh dear Eris, don't get me wrong, I don't claim GNOME in particular is a software fit for any purpose.
My point was more like that the base system is still really good and systemd even with its failings is better than dealing with Windows. As for the desktop, there's enough choice that you should be able to find something that's maximally convenient while minimally retarded, with a small amount of customization. That something will most surely not be GNOME.
That's kind of what I mean - it's gotten worse in some ways, but you can still pick your poison and it's not as bad as having to deal with whatever retardation Microsoft come up with.
Failed to issue message call
That was enough to scare me away from CentOS 7 and systemd to be honest.
It's the rest of the utilities that they're trying to couple to it that are bullshit. Starting with the journal - asking for the last few lines of the journal can take half a minute for some reason. Fortunately you can ignore those parts and just use the smart init system, i.e. you can ignore the cron replacement and run plain cron, you can ignore the nptd replacement and run plain ntpd, etc.
https://wiki.archlinux.org/index.php/Systemd_FAQ#.22Failed_t...
I was a Solaris admin at a previous employer. We ran annual DR exercises, and saw similar issues with the Windows kit. Even with months to prepare for the exercise, it took the entire exercise, sometimes longer, to bring 'Windows stuff' back to life.
What we (the unix team) did was to write into _our_ DR plan a few paragraphs on how to be up and running without DNS, or Active Directory.
Solaris was nice and easy to get back apart from one machine I dealt with: the starfire E10k. The SSP failed on one that we had and the entire system uses crypto key exchange so only the original SSP can bring the system up. Fortunately we had an E15k being installed at the time so it was an emergency migration job.
I miss big iron. I had an old maxed out 1000E and a disk tray full of 4.3Gb SCSI disks at home for a bit (until I got the electricity bill!)
It gets _messy_ but I think it's worthwhile to write out in biz continuity plan how to function without DHCP, DNS, and AD.
Take my case: we sometimes had the tier 1 and 2 services (the unix-based ones at least) up _days_ before DNS and AD were available. In the real world the business can't wait for DNS and AD to have access to their tier one and two apps: customers are waiting for product.
Note that a lot of work went into getting the Solaris stuff to this point: in particular using ZFS and zones made the process or restoration a breeze. By the time of our fourth annual DR exercise, getting stuff up and running was essentially waiting for it to restore from tape, adjust for things like 'DNS y/n' and done.
I've always thought that BSD is superior from an admin perspective, as in it's easier to do it right and keep it solid.
I may be biased though as my first job was IT for a company that had BSD committers so everything we did was on BSD and I learned how to admin from arguably some of the best BSD admins in the world.
Still, in general I agree. I run OpenBSD as my main desktop system because it works and mostly stays out of my way.
http://undeadly.org/cgi?action=article&sid=20140827065755
Edit: Adding in the link to the actual commit: http://marc.info/?l=openbsd-cvs&m=140908174910713&w=2
I thought they replaced their custom Apache with (also custom) Nginx.
For some rationale, see this comment (by Reyk): http://undeadly.org/cgi?action=article&sid=20140827065755&pi...
Nginx is considerably larger than the old Apache was. Commits that took it to a new version were pretty big. I didn't see a whole lot of OpenBSD developers hardening the code. Simple and small seems to be the OpenBSD way. I like it.
This has been the history of FBSD since my exposure to 4.x back in 2000. A more recent example, FBSD 8.0 was announced Nov 2009. And now, nearly 5 years later, FBSD 8.4 is still a supported version.
Sure, technically each minor version of 8.x reached EOL after a year. But since keeping an 8.x installation up-to-date has been so seamless, it achieves an EOL >=5 years from introduction.
Anyway, how I see it based on real-world experience.
There was a period when non-x86 compatibility went through a similar low period (due to the decline of Alpha, SPARC, etc.), but increasing ARM market share is making architecture portability more practically relevant again.