Yahoo and FreeBSD (1997)(zer0.org)
zer0.org
Yahoo and FreeBSD (1997)
http://zer0.org/daemons/yahoobsd.html
11 comments
This story reminds me of Jan Koum (of Whatsapp) when he donated a million dollars to FreeBSD: "one of the main reasons I got a job at Yahoo! is because they were using FreeBSD, and it was my operating system of choice. Years later, when Brian and I set out to build WhatsApp, we used FreeBSD to keep our servers running. We still do." (https://www.facebook.com/jan.koum/posts/10152852986375011)
It would be interesting to read about their experiences over the last 18 years.
I recently installed FreeBSD on a home server and was very pleased both with the process and the result. Also, the documentation is just impressive (that goes, in my experience, for all the BSD systems).
I recently installed FreeBSD on a home server and was very pleased both with the process and the result. Also, the documentation is just impressive (that goes, in my experience, for all the BSD systems).
I was at Y! from 2004 to 2011, when I started it was FreeBSD only except for acquisitions. When I left it was a mix of FreeBSD and RHEL, with everyone being strongly encouraged to move to RHEL.
I think the justifications were better support for running on Linux (storage drivers, Java, MySQL, oracle), better support for virtualization (although bsd jails are better than virtualization in my opinion, and a better fit for Y!), and it would be easier to support one os instead of two and acquisitions (including inktomi) really wanted to run on Linux.
The drop dead date for getting off FreeBSD kept getting pushed back, but I'd guess they've moved almost everything by now.
I think the justifications were better support for running on Linux (storage drivers, Java, MySQL, oracle), better support for virtualization (although bsd jails are better than virtualization in my opinion, and a better fit for Y!), and it would be easier to support one os instead of two and acquisitions (including inktomi) really wanted to run on Linux.
The drop dead date for getting off FreeBSD kept getting pushed back, but I'd guess they've moved almost everything by now.
I never really understood why Jails never really took off, but everyone now is going crazy about virtualization.
This could be a much longer answer, but jails have nowhere near the level of control and isolation a "real" VM does even with the relatively recent additions of things like vimage and HRL's. Jails are awesome and I have used them for many years, but they are not a replacement for a hypervisor for many(most) use cases.
That said, when a young upstart was trying to sell me on Linux superiority and described Docker to me, all I could do was snicker.
That said, when a young upstart was trying to sell me on Linux superiority and described Docker to me, all I could do was snicker.
For my uses at Y!, jails were great: I was using them to setup test environments that were closer to production: each jail had software to match one of the machine types in production, but I didn't need to get a whole bunch of machines that would mostly be idle.
As I was my own jailer, lack of resource limits wasn't a real problem. I greatly benefited from the lack of performance penalties; everything ran at the same speed in or out of the jail. I had one or two systems running in VMs and they were terrible: a) things were clearly slower, b) virtual disk provisioning is terrible, c) timekeeping (hopefully things have gotten better since 2011)
As I was my own jailer, lack of resource limits wasn't a real problem. I greatly benefited from the lack of performance penalties; everything ran at the same speed in or out of the jail. I had one or two systems running in VMs and they were terrible: a) things were clearly slower, b) virtual disk provisioning is terrible, c) timekeeping (hopefully things have gotten better since 2011)
Explain yourself. A hypervisor is not a security layer, so what is your reasoning?
> A hypervisor is not a security layer
Of course it is.
Of course it is.
It is an expensive container, that is all. Attackers can escape or even steal data from another running VM.
> Attackers can escape or even steal data from another running VM.
Then there is a bug and you fix it just like any other security layer.
Then there is a bug and you fix it just like any other security layer.
Docker is not the same thing as FreeBSD jails. Docker is available on FreeBSD (as of June this year) and uses jails.
> Docker is not the same thing as FreeBSD jails.
No it is not. Like Norton Anti-Virus, it has a much bigger user base. Other than that...
> Docker is available on FreeBSD (as of June this year) and uses jails.
Huh? I wonder why?
^sarcasm.
No it is not. Like Norton Anti-Virus, it has a much bigger user base. Other than that...
> Docker is available on FreeBSD (as of June this year) and uses jails.
Huh? I wonder why?
^sarcasm.
Other than that, they're different things. It's like the difference between lxc and lxd.
See https://www.youtube.com/watch?v=LrHW7Vvbie4 for a demo of what lxd can do. Maybe that will clear it up for you.
See https://www.youtube.com/watch?v=LrHW7Vvbie4 for a demo of what lxd can do. Maybe that will clear it up for you.
If the point you're trying to make is linux users love reinventing the wheel and making it more complicated and prone to failure, there really is no need. I believe you.
lxd has absolutely no relevance to this discussion. They are not jails, they are not like jails. As noted in my OP in this thread, jails are not a replacement for hypervisors.
lxd has absolutely no relevance to this discussion. They are not jails, they are not like jails. As noted in my OP in this thread, jails are not a replacement for hypervisors.
lxd has relevance because it's the same kind of thing as Docker.
> They are not jails, they are not like jails.
That's what I've been saying.
> They are not jails, they are not like jails.
That's what I've been saying.
You need to do your research again on docker and lxd. They aren't the same thing at all.
> That's what I've been saying.
No, you've been saying Docker is so much better than jails. Either you don't know jails or docker or both, I can't tell. Just you really want Docker to be awesome.
> That's what I've been saying.
No, you've been saying Docker is so much better than jails. Either you don't know jails or docker or both, I can't tell. Just you really want Docker to be awesome.
they did, if you were a FreeBSD user. it never got (many) more FreeBSD users on it's own, however.
[deleted]
They're still using FreeBSD, and happy with it as far as I know.
Completely not true. Around 2008ish there was a big migration towards using RHEL. There's still some FreeBSD boxes, but the vast majority have been switched at this point to Linux.
I don't completely agree with the reasoning, but it mainly came down to driver support, maintenance cost, and debugging tools.
I don't completely agree with the reasoning, but it mainly came down to driver support, maintenance cost, and debugging tools.
Note that we didn't run stock freebsd. It was a custom freebsd4 with a custom gcc 2.95 toolchain. I don't remember all the mods, but migrating from 4 to 6 was a nice undertaking, and it was done in parts. People who worked there will remember the term "4 on 6". After the migration, the kernel was 6 (and you got the latest drivers) but we were still running those weird 4 user-land binaries.
Inktomi (YST) was acquired in 2003, later Overture (YSM) and both were linux shops. YST was the biggest property by far and we didn't have any kernel developers. We were doing just fine with stock debian, then stock RHEL. (I did a few very minor patches for 32-bit, like splitting user-space/kernel to 3.5/0.5G instead of 3/1G, and some caching improvements for /proc, but I wasn't a kernel developer). Linux just worked. Drivers were available and supported for the HW we needed. Oprofile, systemtap worked fine for the most part. We later hired one kernel developer to help Mail move to linux, but we always had more freebsd kernel developers.
For freebsd you needed to write the drivers and the tools. That took time and money. The community was also smaller and it was harder to hire people with experience. Acquisitions were running on linux too.
The decision was not easy. Y! already had great freebsd engineers. By announcing that linux would be the supported platform going forward it was a given that many of them wouldn't be happy and leave. Fortunately not all of them left. For example Peter W. still works there.
In any case I don't think there was really an alternative.
Inktomi (YST) was acquired in 2003, later Overture (YSM) and both were linux shops. YST was the biggest property by far and we didn't have any kernel developers. We were doing just fine with stock debian, then stock RHEL. (I did a few very minor patches for 32-bit, like splitting user-space/kernel to 3.5/0.5G instead of 3/1G, and some caching improvements for /proc, but I wasn't a kernel developer). Linux just worked. Drivers were available and supported for the HW we needed. Oprofile, systemtap worked fine for the most part. We later hired one kernel developer to help Mail move to linux, but we always had more freebsd kernel developers.
For freebsd you needed to write the drivers and the tools. That took time and money. The community was also smaller and it was harder to hire people with experience. Acquisitions were running on linux too.
The decision was not easy. Y! already had great freebsd engineers. By announcing that linux would be the supported platform going forward it was a given that many of them wouldn't be happy and leave. Fortunately not all of them left. For example Peter W. still works there.
In any case I don't think there was really an alternative.
I doubt it. Ever since Rick Reed left, the share of BSD is declining. They have standardized on RHEL, as far as I've heard.
Even when Rick was at Y! the push to move to linux was there. Rick had written most of the base libraries for freebsd originally (mdbm, ylock, ylock_kern, yfor, etc.), and tools like the package manager yinst and ysar, but being the great engineer he is, he ported them to linux and got the same or better performance. (In the yinst case he delegated the maintenance to a very capable engineer)
Note that Yahoo! was employing a few very bright freebsd kernel engineers but when the decision was announced that linux was the future many of them decided to leave. That made the path forward even clearer. It wasn't just a matter of integrating new acquisitions easier, and the fact that it was easier to hire people with linux experience than with freebsd experience. That was around 2008 IIRC. I left in 2010, and Rick less than a year later.
Note that Yahoo! was employing a few very bright freebsd kernel engineers but when the decision was announced that linux was the future many of them decided to leave. That made the path forward even clearer. It wasn't just a matter of integrating new acquisitions easier, and the fact that it was easier to hire people with linux experience than with freebsd experience. That was around 2008 IIRC. I left in 2010, and Rick less than a year later.
[deleted]
We used FreeBSD exclusively at my first startup in 1999 (flashbase), partially because of Yahoo's success with it (I was at Stanford). We found the base OS to be very stable and the networking stack to be especially robust. But, the mysql port was not that stable and drivers for proprietary products, like Oracle, were hard to come by.
Back in the day, Oracle did a freebsd driver partially for Yahoo. The Oracle drivers were not open source and hence there were few options to connect without Oracle's help.
I worked in the kernel networking group at SGI in the 90s and there was a lot of freebsd loving there. Also, the FreeBSD license was more relaxed and commercial products (like NetAPP) could include and extend FreeBSD without disclosing their modifications.
Our frustration with lack of support for FreeBSD moved us to choose Linux and Windows (for SQL server support) the next time around in 2004.
Back in the day, Oracle did a freebsd driver partially for Yahoo. The Oracle drivers were not open source and hence there were few options to connect without Oracle's help.
I worked in the kernel networking group at SGI in the 90s and there was a lot of freebsd loving there. Also, the FreeBSD license was more relaxed and commercial products (like NetAPP) could include and extend FreeBSD without disclosing their modifications.
Our frustration with lack of support for FreeBSD moved us to choose Linux and Windows (for SQL server support) the next time around in 2004.
FreeBSD has been my server platform since early 2000's, chosen for reliability and relative ease of configuration (vs. Linux, etc.). The primary server for my business was running FBSD since 2005, stopping only for of power outages, or periodic maintenance. (Still works too.) I have used FBSD on desktop systems too, though that has significant limitations.
It's my impression that the pace of FBSD development has been increasing in the last couple of years, hardware/driver compatibility included. As well, it seems recently there's been more "cross fertilization" among the BSDs, and Linux to a lesser extent, signs of health and vigor for these projects.
While there are former FBSD users deciding to go with a different OS, such switching is not new or a one-way thing. I think it's a safe bet some enterprises are choosing FBSD over something else, anyway there's little risk any major FOSS OS project will soon disappear.
It's my impression that the pace of FBSD development has been increasing in the last couple of years, hardware/driver compatibility included. As well, it seems recently there's been more "cross fertilization" among the BSDs, and Linux to a lesser extent, signs of health and vigor for these projects.
While there are former FBSD users deciding to go with a different OS, such switching is not new or a one-way thing. I think it's a safe bet some enterprises are choosing FBSD over something else, anyway there's little risk any major FOSS OS project will soon disappear.
Fun fact: Russia loves FreeBSD. (https://www.google.com/trends/explore#q=freebsd)
I tried both as a teenager. At the time I ended up sticking with Linux, but even in retrospect it's hard to quantify why. I remember though that it felt more understandable and "approachable" somehow. It was little stuff like bash vs csh or the presence of ever so slightly more modern editors and utilities.
I think if FreeBSD would have put a bit more effort into modernization and community in the early to mid 90s we'd all be using it more now. It's guts were superior at the time and in a few ways still are.
I think if FreeBSD would have put a bit more effort into modernization and community in the early to mid 90s we'd all be using it more now. It's guts were superior at the time and in a few ways still are.
There's not being modern, and then there's not chasing every rabbit down every hole. Right now I feel like FreeBSD is a wonderful mix of advanced, modern tech like ZFS and bhyve, married with an absence of "oooo-shiny!" misadventures like PulseAudio and systemd.
And in particular, right now I'm grateful that the BSDs are small enough to be ignored by the herds of people migrating away from Windows and bringing their mindsets with them - that all seems to be landing on Linux.
And in particular, right now I'm grateful that the BSDs are small enough to be ignored by the herds of people migrating away from Windows and bringing their mindsets with them - that all seems to be landing on Linux.
I wonder how much the reason they are landing on Linux is that there are multiple companies actively trying to pitch Linux to existing Windows users.
RH for instance seems to be heavily pitching RHEL (never mind Fedora and CentOS) towards corporate and the Military-Industrial complex. The latter in particular are interested in RHEL after some poor experience using Windows on warships and similar.
But at the same time there is a pile of MSCEs running around in these organizations, and so there is a incentive to make daily Linux management at least superficially similar to reduce retraining costs.
RH for instance seems to be heavily pitching RHEL (never mind Fedora and CentOS) towards corporate and the Military-Industrial complex. The latter in particular are interested in RHEL after some poor experience using Windows on warships and similar.
But at the same time there is a pile of MSCEs running around in these organizations, and so there is a incentive to make daily Linux management at least superficially similar to reduce retraining costs.
I had precisely the opposite experience. My father bought me RedHat 5.2 and no matter what I did, I could not get anything but a stuck X -- no mouse, no window manager, no login prompt. every time, just the immovable X.
Returned it for The Complete FreeBSD and never, ever looked back. FreeBSD got me jobs at interesting places, and a handful of life long, interesting friends.
I agree with some of the other replies here -- I'm perfectly happy and even glad the BSDs have exactly the size and composition of users they do.
well, NetBSD needs much more public love, in my opinion.
Returned it for The Complete FreeBSD and never, ever looked back. FreeBSD got me jobs at interesting places, and a handful of life long, interesting friends.
I agree with some of the other replies here -- I'm perfectly happy and even glad the BSDs have exactly the size and composition of users they do.
well, NetBSD needs much more public love, in my opinion.
In the early 2000's i almost exclusively used FreeBSD. The hardware i used were always a bit behind the curve, and still i could max my network connections.
What made me move to Linux eventually, was the ability to keep all my software easily updated, including the kernel.
What made me move to Linux eventually, was the ability to keep all my software easily updated, including the kernel.
I've tried FreeBSD on occasion and that's exactly what kept me away from it. Keeping (multiple) systems current is always where most of the work is (if you do keep them current, that is), not on initial installation/configuration.
Honestly, I don't know if this is still the case.
Honestly, I don't know if this is still the case.
FreeBSD has made leaps and bounds with this.
You can use `freebsd-update` to update the OS itself from binaries instead of having to build world. https://www.freebsd.org/doc/en/books/handbook/updating-upgra...
You can use also `pkg` to install/upgrade software packages like `apt-get` on Debian derived distros. https://www.freebsd.org/doc/handbook/pkgng-intro.html
You can use `freebsd-update` to update the OS itself from binaries instead of having to build world. https://www.freebsd.org/doc/en/books/handbook/updating-upgra...
You can use also `pkg` to install/upgrade software packages like `apt-get` on Debian derived distros. https://www.freebsd.org/doc/handbook/pkgng-intro.html
freebsd-update still implies semi-manual /etc/* merge. Both freebsd-update and pkg are no way close to apt-get and more importantly Debian 'unattended upgrades' feature.
> freebsd-update still implies semi-manual /etc/* merge
freebsd-update.conf
> Both freebsd-update and pkg are no way close to apt-get and more importantly Debian 'unattended upgrades
Exactly, it's better.
freebsd-update.conf
> Both freebsd-update and pkg are no way close to apt-get and more importantly Debian 'unattended upgrades
Exactly, it's better.
It's much better than the old days. pkgng and freebsd-update make it pretty straightforward to keep updated... not really any different than on any of the Linux flavors I use. The ports tree is hooked up with pkgng too, so you can mix and match (before they used to recommend you only use one or the other).
The major problem is at an enterprise scale (hundreds of thousands of servers and above) it becomes untenable due to the nature of ports tracking upstream and constantly in flux.
It makes it difficult to support the applications and services that run on the OS as a result.
Whereas with something like RHEL/CentOS, we're guaranteed stability for years and can patch without too much concern of major breakage.
This is the part that really appeals to most enterprise users.
It makes it difficult to support the applications and services that run on the OS as a result.
Whereas with something like RHEL/CentOS, we're guaranteed stability for years and can patch without too much concern of major breakage.
This is the part that really appeals to most enterprise users.
Everywhere I've worked (from places with a handful of VM startups to 20k machine enterprise) it's also a cop out to completely abandon care and feeding of systems. I call it Long Term Suck, and I've yet to see a place where it has not caused long term harm to an organization big or small. If you aren't equipped to deal with gradual shift in API of dependencies, you shouldn't be doing whatever you're doing or the code has a half life and should be trashed after the employees that understand it have moved on.
What _is_ important is ABI stability of the kernel, because it lets you figure out how to deal or not deal with Long Term Suck on your own terms and lets proprietary software vendors figure out independently how they want to do deal with it. Both Linux and FreeBSD kernels do this pretty well.
What _is_ important is ABI stability of the kernel, because it lets you figure out how to deal or not deal with Long Term Suck on your own terms and lets proprietary software vendors figure out independently how they want to do deal with it. Both Linux and FreeBSD kernels do this pretty well.
The recommendation from the guys in #freebsd in freenode was for [you] to build pkg's yourself from ports, which means you always have versions you know work lying around.
I thought it was a nice idea, and they really push this as being "an easy thing anybody should be able to do".
which fits with my philosophy of "severs should not have/use compilers"
I thought it was a nice idea, and they really push this as being "an easy thing anybody should be able to do".
which fits with my philosophy of "severs should not have/use compilers"
Why do you feel this way? Security?
If I can get a shell on your server I will just download my own compiler.
If I can get a shell on your server I will just download my own compiler.
no, it's that there should never be a need to compile on machines dedicated to a purpose.
I don't need source files, I need a machine to be a compute node.. or a storage node.. what use is a compiler if I do it right..
the new generation of this is: "I should never need to shell into my machine if I did config management right."
I don't need source files, I need a machine to be a compute node.. or a storage node.. what use is a compiler if I do it right..
the new generation of this is: "I should never need to shell into my machine if I did config management right."
I understand and agree with that.
There is a stable/quarterly ports tree now and it's the default package set. It's not so caustic anymore.
No [proper] NUMA -> no go for my tasks.
I was downwoted for that not long time ago, but again, NUMA ... Source https://wiki.freebsd.org/NUMA
In 1996 I began working at a very bootstrapped Internet Service Provider (ISP). Some of you younger people might not even know what an ISP is - there used to be companies other than Verizon and AT&T that you could get Internet access from.
Any how, aside from an NT server or two, and a Sun IPX box, our servers were generally Linux (Slackware and Debian) and FreeBSD. Mostly FreeBSD.
FreeBSD had a lot going for it. A lot going for it over Linux at the time, for our company. Often we would get our hands on an x86 box of one type or another and have to make it into a server. These boxes usually had no CDROM, and usually we installed network cards, which themselves were coming in randomly, on their bus (usually ISA, sometimes PCI).
To get the latest version of Slackware, we'd have to download all five of the Slackware base "A" disks. Then the compiler was on the 10 "D" series of disks. Then the 4 "N" disks would have networking. Plus more if you want ghostscript (another set) or emacs (another set), or God help you, a workstation with X-windows running fvwm...
FreeBSD was two disks - boot and root. Then you go into ports and install from there. Because boot and root were enough to get your network card working - when Slackware and Debian often did not have those cards working at all. Many a time I was going to install Linux, couldn't get the network card working, put in the FreeBSD boot/root disks, got the network card working with no problem, and the would-be Linux box became a FreeBSD box.
It was not just network cards - these two disks had a great system for not just recognizing all Ethernet cards and getting them to work, but being able to install a full-out system over a modem and 56k (or 28.8k, or 14k) baud POTS connection. FreeBSD just made it real easy to install itself.
This was not just my opinion, others I knew thought the same thing. Not until Ubuntu did I find a Linux system that worked to make installing it easy. When wireless ethernet cards became more ubiquitous, I had left FreeBSD behind years before, but most Linuxes had trouble with every other card out there, even Ubuntu initially. FreeBSD never seemed to have these problems, being able to install easily was something they prioritized - and I think it helped them.
Also, our Linuxes at the time were vulnerable to the "ping of death" and these sorts of security problems. I still know companies which use FreeBSD. They started years ago and never changed.
I'm not sure when and why Linux started overtaking FreeBSD. Linux had this pre-GRUB boot loader called LILO which was horrible, but it did allow people with Windows boxes to be able to turn their desktop or laptop into a dual boot machine on which they could play around with Linux. Linux was more advanced on the multi-boot front if I recall, and that was probably one of the reasons it got ahead.
Also another mentioned reason is commercialized BSD like BSDI was under a cloud of lawsuits in the early 1990s, whereas commercial Linux companies like Red Hat were free of all of this, and this served to help Linux as well.
Any how, aside from an NT server or two, and a Sun IPX box, our servers were generally Linux (Slackware and Debian) and FreeBSD. Mostly FreeBSD.
FreeBSD had a lot going for it. A lot going for it over Linux at the time, for our company. Often we would get our hands on an x86 box of one type or another and have to make it into a server. These boxes usually had no CDROM, and usually we installed network cards, which themselves were coming in randomly, on their bus (usually ISA, sometimes PCI).
To get the latest version of Slackware, we'd have to download all five of the Slackware base "A" disks. Then the compiler was on the 10 "D" series of disks. Then the 4 "N" disks would have networking. Plus more if you want ghostscript (another set) or emacs (another set), or God help you, a workstation with X-windows running fvwm...
FreeBSD was two disks - boot and root. Then you go into ports and install from there. Because boot and root were enough to get your network card working - when Slackware and Debian often did not have those cards working at all. Many a time I was going to install Linux, couldn't get the network card working, put in the FreeBSD boot/root disks, got the network card working with no problem, and the would-be Linux box became a FreeBSD box.
It was not just network cards - these two disks had a great system for not just recognizing all Ethernet cards and getting them to work, but being able to install a full-out system over a modem and 56k (or 28.8k, or 14k) baud POTS connection. FreeBSD just made it real easy to install itself.
This was not just my opinion, others I knew thought the same thing. Not until Ubuntu did I find a Linux system that worked to make installing it easy. When wireless ethernet cards became more ubiquitous, I had left FreeBSD behind years before, but most Linuxes had trouble with every other card out there, even Ubuntu initially. FreeBSD never seemed to have these problems, being able to install easily was something they prioritized - and I think it helped them.
Also, our Linuxes at the time were vulnerable to the "ping of death" and these sorts of security problems. I still know companies which use FreeBSD. They started years ago and never changed.
I'm not sure when and why Linux started overtaking FreeBSD. Linux had this pre-GRUB boot loader called LILO which was horrible, but it did allow people with Windows boxes to be able to turn their desktop or laptop into a dual boot machine on which they could play around with Linux. Linux was more advanced on the multi-boot front if I recall, and that was probably one of the reasons it got ahead.
Also another mentioned reason is commercialized BSD like BSDI was under a cloud of lawsuits in the early 1990s, whereas commercial Linux companies like Red Hat were free of all of this, and this served to help Linux as well.
Well, you have a very different memory of the era than I do. I never had any problem getting an ethernet card working on Linux: there was never any work to do! They just worked out of the box.
I believe it was almost entirely due to the work of Donald Becker. I don't know anything about the guy, other than he had a NASA email address, but I kept seeing his name mentioned when looking for anything network card related.
I remember the floppy disk pain though. Few machines had CD-ROMs so basically it was copying 30 images overwriting Microsoft Windows & Office floppy disks (they were better quality than the cheap 3.5" disks you generally got supplied with and there were always spare ones) and then swap, swap, swap...
I believe it was almost entirely due to the work of Donald Becker. I don't know anything about the guy, other than he had a NASA email address, but I kept seeing his name mentioned when looking for anything network card related.
I remember the floppy disk pain though. Few machines had CD-ROMs so basically it was copying 30 images overwriting Microsoft Windows & Office floppy disks (they were better quality than the cheap 3.5" disks you generally got supplied with and there were always spare ones) and then swap, swap, swap...
It's interesting that because the OS was ahead in one key area, probably only for a couple of years, they spent 18 years using it.
That's why Apple chose FreeBSD to base OSX off and Juniper chose it for JunOS, because of something 18 years ago...
Or maybe BSD has maintained its technical superiority in some areas for some users.
Or maybe BSD has maintained its technical superiority in some areas for some users.
Actually, those choices were for licensing, not necessarily technical superiority, but nevertheless FreeBSD does maintain technical superiority in some areas and falls behind in a few others. It still has a great firewall, for instance.
After installed several linux distros, I decided to try my chance with free BSD. I still remember how I suffered to setup my ADSL. But It was 10 years ago. I am sure the installation process is easier compared to the past but I am not that brave anymore.