Hacker News Reader

> 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.

* https://www.gnu.org/licenses/rms-why-gplv3.en.html

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:

* https://www.youtube.com/watch?v=PaKIZ7gJlRU

> Licensing?

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.

I doubt this story about Linus and Steve. MacOS is NEXTSTEP-derived and that pre-dated Linux by several years.

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.

NeXTSTEP was always BSD4.3-Tahoe Unix, not AT&T Unix.

> On a side note, if I recall correctly, Steve Jobs wanted to use Linux for MacOS.

Steve offered Linus a job, using Linux was never on the table.

https://www.theverge.com/2012/3/22/2893581/linus-torvalds-li...

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.

https://freebsdfoundation.org/testimonial/isilon/ https://freebsdfoundation.org/end-user-stories/

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.

I tried FreeBSD once, thought it was kind of fun and interesting and went back to Debian and then Ubuntu, which works well for me.

I recall the good old flame wars, but feel kind of past that myself.

FreeBSD or Linux management plane on routers/switches is mostly irrelevant. The majority of the data simply flows through the asics untouched.

> 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.

Perhaps so, but this knowledge is post hoc for the incident and does not undermine the engineering value of the unified release.

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.

no one seriously uses Evo in the way JunOS powers things. they’ve managed to package FreeBSD inside some Linux flavors. it’s wild, imo.

Guess I'm nobody, I think the PTX line is great ¯\_(ツ)_/¯.

>It's the reason a FreeBSD derivative

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.