> YouTube / Google CDN is much bigger than Netflix
Youtube and Netflix are on par. According to Sandvine, Netflix sneaked past Youtube in volume in 2023[1]. I believe their 2024 report shows them still neck-and-neck.
> you can make pretty much everything work on modern solution
Presenting a false equivalence without evidence is not convincing. "You could write it in SNOBOL and deploy it on TempleOS". Netflix didn't choose something arbitrary or by mistake. They chose one of the world's highest performing and most robustly tested infrastructure operating systems. It's the reason a FreeBSD derivative lies at the core of Juniper routers, Isilon and Netapp storage heads, every Playstation 3/4/5, and got mashed into NeXTSTEP to spawn Darwin and thence macOS, iOS etc.
It continues to surprise me how folks in the tech sector routinely fail to notice how much BSD is deployed in the infrastructure around them.
> All the benefits they added to FreeBSD could be added the same way in Linux
They cannot. Case in point, the bisect analysis described in the presentation above doesn't exist for Linux, where userland distributions develop independently from the kernel. Netflix is touting here the value of FreeBSD's unified release, since the bisect process fundamentally relies on a single dimension of change (please ignore the mathematicians muttering about Schur's transform).
> There's a reason it's the core of Juniper routers, Isilon and Netapp storage heads, every Playstation 3/4/5, and got mashed into NeXTSTEP to spawn macOS.
Licensing?
FreeBSD is a fine OS that surely has some advantages here and there, but I'm also inclined to think that big companies can make stuff work if they want to.
PHP at Meta seems like a pretty good example of this.
The permissive, freewheeling nature of the BSD license is touted by some as an advantage for infrastructure use but in practice, Linux-based devices and services aren't particularly encumbered by the GPL, so to me it's a wash.
Could be lawyers at some companies just didn't want anything to do with the GPL, especially if they're fiddling with the kernel itself. Maybe they're not even correct about the details of it, just fearful. "Lawyers overly cautious" is not an uncommon thing to see.
Having seen the screams from some people when you use GPL legally I can't blame the lawyers. You might be correct but you will still get annoying people yelling you are not. there is also the cost to verifying you are correct (we put the wrong address in for where to send you request for sorce, fortunately a tester caught it before release, but still expensive as the lawyers forced the full recall process meaning we had to send a tech to upgrade the testers instead of saying where to download the fix)
> […] Linux-based devices and services aren't particularly encumbered by the GPL, so to me it's a wash.
Linux uses GPL 2.x. If we are talking about GPL 3.x things may be different:
> One major danger that GPLv3 will block is tivoization. Tivoization means certain “appliances” (which have computers inside) contain GPL-covered software that you can't effectively change, because the appliance shuts down if it detects modified software.
If you want to ship (embedded) GPL 2 Linux-based devices things are fine, but if there's software that is GPL 3 then that can cause issues. Linus on GPLv3:
I think you've hit the nail on the head. I used to work for a very very large company. And they had a very strong preference for BSD licensed software, if we were building something using outside software. A few years ago, Stever Balmer and others spent a lot of time calling spreading FUD by calling Linux and GPL a "cancer". Believe it or not, that stuff had a massive impact. Not on small shops, but large company lawyers.
Over the years, Steve left Microsoft and Microsoft has become a lot more Linux friendly. And the cancer fear has subsided. But it was very very real.
On a side note, if I recall correctly, Steve Jobs wanted to use Linux for MacOS. But he had licensing concerns and called up Linus and asked him to change a few things. Linus gave him the middle finger and that is how we got MacOS with BSD.
Fun fact! NeXT was a commercial att unix fork. The transition from the unix base to the BSD base did infact happen at apple after the acquisition. The value of next was in its application library, which would eventually become the mac foundation libraries like coreaudio and cocoa etc. The earliest releases of Rhapsody are very illuminative about the architecture of XNU/OSX. I don't doubt that linux was considered. There's a specific time when the actual move of rhapsody to a freebsd base occurred and it was at apple sometime in 97 or 98 iirc.
It's a mix of licensing and performance/stability. The licensing ensures that a company can implement their own IP and not have to contribute that back to the community as open source.
The performance/stability of FreeBSD is no joke, that's why, as mentioned previously, storage vendors like Isilon and Netapp choose FreeBSD as the base. They can contribute upstream when needed, but they don't have to provide any source for how their storage appliance software.
Be all that as it may, this is still a “why not Linux” line of thinking, rather than “why FreeBSD”, which is the more interesting question. And it is not a binary choice.
Because FreeBSD is a perfectly fine OS for server type stuff, and maybe it's better for this, that, or the other thing. So someone probably picked it and it has worked ok for them.
Just to be clear, you don't need to convince me - I've been preferring BSDs for my own infrastructure since the 90s. But I'm mindful that the discussion can quickly become polarised and winds up with negative framing or binary assumptions, which isn't helpful for others asking the same question.
> Incorrect. Case in point, the bisect analysis described in the presentation above doesn't exist for Linux, where userland distributions develop independently from the kernel.
You can certainly bisect the Linux kernel changes though. And the bug in question was a kernel bug. For a project like this, IMHO, most of the interesting bugs are going to be kernel bugs.
Probably, if you were doing this on Linux, you'd follow someone's Linux tree, and not run Debian unstable with updates to everything.
You might end up building a lightweight distribution yourself; some simple init, enough bits and bobs for in place debugging, and the application and its monitoring tools.
Anyway, if you did come across a problem where userland and kernel changed and it wasn't clear where the breakage is, the process is simple. Test new kernel with old userland and old kernel with new userland, and see which part broke. Then bisect if you still can't tell by inspection.
> It's the reason a FreeBSD derivative lies at the core of Juniper routers
Juniper is a particularly poor example to start the list with as they have been moving away from FreeBSD for years now with Junos OS Evolved being Linux based and specifically about how being based on FreeBSD was no longer a benefit to them.
A reason. Licensing also plays a role. Some may say the most important one.
>Case in point
Not really. This is an advantage, yes, but was inherent to BSD development style. Not an addition they did. Assume GP refers to other presentations, talking about the optimizations needed to get the performance Netflix needs from FreeBSD.
>doesn't exist for Linux
But can be done by putting kernel and userland in same repo as modules.
> YouTube / Google CDN is much bigger than Netflix
Youtube and Netflix are on par. According to Sandvine, Netflix sneaked past Youtube in volume in 2023[1]. I believe their 2024 report shows them still neck-and-neck.
> you can make pretty much everything work on modern solution
Presenting a false equivalence without evidence is not convincing. "You could write it in SNOBOL and deploy it on TempleOS". Netflix didn't choose something arbitrary or by mistake. They chose one of the world's highest performing and most robustly tested infrastructure operating systems. It's the reason a FreeBSD derivative lies at the core of Juniper routers, Isilon and Netapp storage heads, every Playstation 3/4/5, and got mashed into NeXTSTEP to spawn Darwin and thence macOS, iOS etc.
It continues to surprise me how folks in the tech sector routinely fail to notice how much BSD is deployed in the infrastructure around them.
> All the benefits they added to FreeBSD could be added the same way in Linux
They cannot. Case in point, the bisect analysis described in the presentation above doesn't exist for Linux, where userland distributions develop independently from the kernel. Netflix is touting here the value of FreeBSD's unified release, since the bisect process fundamentally relies on a single dimension of change (please ignore the mathematicians muttering about Schur's transform).
[1] https://www.sandvine.com/press-releases/sandvines-2023-globa...