Live data from Hacker News

Technical reasons to choose FreeBSD over GNU/Linux (2020)

unixsheikh.com

81–90 of 376 posts

Re: Technical reasons to choose FreeBSD over GNU/Linux (2020)

#81
post #62

I am using freebsd since version 8 for all my server needs (was using linux, but got repelled by its chaos which I dont care about on my laptop, but it pisses me off on server). Some more points: - bhyve, developed by netapp, they ditched all old technologies support and it works faster on my i5 server than kvm on my i7 laptop. Snapshoting using ZFS is not a feature to discard either. - FIBs, absolute miracle routing…

> It runs circles around the docker in everything except how much it was adapted by community.

...except?

Meh. People who want to engage in this argument are generally trying to argue about jails vs. the collection of linux container technologies. That's not Docker. Docker won because of Dockerfiles. Docker isn't, at its core, an interesting container technology. Docker is a simple metaphor and programming environment to leverage container technology to solve practical[1] problems.

And as it happened, it was done on Linux and not jails, owing in large part to the more configurable/toolkit-style/policy-free tools available there. Jails were indeed more mature, but they were solving the wrong problem.

[1] Also thorny, boring problems like configuration management of large apps developed piecewise from components and by large teams. The kind of thing that is historically not well served by the operating system, BSD included.

Re: Technical reasons to choose FreeBSD over GNU/Linux (2020)

#82
post #70
post #62

I am using freebsd since version 8 for all my server needs (was using linux, but got repelled by its chaos which I dont care about on my laptop, but it pisses me off on server). Some more points: - bhyve, developed by netapp, they ditched all old technologies support and it works faster on my i5 server than kvm on my i7 laptop. Snapshoting using ZFS is not a feature to discard either. - FIBs, absolute miracle routing…

> backward compatibility, this is where linux is really horrible, there was an article about compiling binary on freebsd 2 and running it on freebsd 10. Try this on linux, binaries are not compatible even on minor versions. What a completely bizarre claim. I have commercial linux/x86 binaries from the 90s that work perfectly well on my current PC running Linux 5.15.

I’m guessing the OP meant “where glibc is really horrible”, since bsd libc is rather more abi stable, largely because that’s where FreeBSD provides compatibility instead of the syscall layer. This is not to say you can’t use an old libc and fix up the loader paths or use a container and make it work, but it’s a different set of challenges.

Re: Technical reasons to choose FreeBSD over GNU/Linux (2020)

#83
I have to plugin Void Linux, a nice little distro that tries to mimick some of BSD philosophy (I believe w.r.t. simplicity and security). It's working very well here (it's somewhat analogous to Arch, meant for advanced users -- that said, following the docs it shouldn't be too difficult to get going).

https://voidlinux.org/

Re: Technical reasons to choose FreeBSD over GNU/Linux (2020)

#84
post #81
post #62

I am using freebsd since version 8 for all my server needs (was using linux, but got repelled by its chaos which I dont care about on my laptop, but it pisses me off on server). Some more points: - bhyve, developed by netapp, they ditched all old technologies support and it works faster on my i5 server than kvm on my i7 laptop. Snapshoting using ZFS is not a feature to discard either. - FIBs, absolute miracle routing…

> It runs circles around the docker in everything except how much it was adapted by community. ...except? Meh. People who want to engage in this argument are generally trying to argue about jails vs. the collection of linux container technologies. That's not Docker. Docker won because of Dockerfiles. Docker isn't, at its core, an interesting container technology. Docker is a simple metaphor and programming environmen…

I love FreeBSD and i love Jails, but you're right. Docker won because of simplicity.

Dockerfiles make it super simple. There is similar stuff for jails but you need a jails frontend that use it.

A few years ago i wanted to build the Jailfile equivalent, call it Warden, and have Warden manage the jails.

But honestly i doubt it would get traction outside a small community.

Re: Technical reasons to choose FreeBSD over GNU/Linux (2020)

#85
post #24

Earlier quoted context omitted.

Basic usage with Nvidia drivers works ok. Nvidia disables CUDA and NVENC/NVDEC on FreeBSD. CPUs/motherboards work great, at least in x86 (arm64 probably works well, too, but I'm less familiar). Wifi is very behind the curve. If you have a supported card (including some 802.11AC cards), 802.11N probably works -- but last I heard, AC does not.

Alright as expected then, Nvidia thing a bit unexpected. So, people do not do ML on FreeBSD?

> So, people do not do ML on FreeBSD?

I think that's essentially correct. Certainly, not using CUDA.

Re: Technical reasons to choose FreeBSD over GNU/Linux (2020)

#86
post #49

Earlier quoted context omitted.

I believe zfs fulfills all those requirements. I’m running freebsd on my NAS and it’s been great.

Not #3, but it's still the best option

Hmm I think you can mirror different sizes just fine but it'll predictably use the smaller size, no? Is btrfs different in that regard? I have only used it when it was released many years ago so my memory is rusty.

Re: Technical reasons to choose FreeBSD over GNU/Linux (2020)

#87
post #49

Earlier quoted context omitted.

I believe zfs fulfills all those requirements. I’m running freebsd on my NAS and it’s been great.

Not #3, but it's still the best option

as far as I know, you can put disks of different sizes in a mirror vdev, you’ll just obviously be limited to the size of the smaller disk.

Is that not what OC is asking for?

Re: Technical reasons to choose FreeBSD over GNU/Linux (2020)

#88
This post is not very robust in its arguments:

1. vulnerability list is not very relevant as a measure if you don't relate to SLOC, features available or something;

2. having a lot of configuration options for security is far from being good, security should be easy and by default; if the tradeoffs are unclear you enter FUD and avoid enabling them; is randomizing PIDs good? what are the downsides? :shrug:

3. I stopped reading given that the most prominent arguments seemed heavily biased;

Re: Technical reasons to choose FreeBSD over GNU/Linux (2020)

#89
post #60

Earlier quoted context omitted.

...or pick an operating system where you don't need to read the handbook to get working WiFi.

I'm on Linux and have to get a rtw8852 driver from some random-ish gitHub repo to get WiFi in a recent Lenovo. Does this mean WiFI is only for Win/Mac?

That's odd. My 2018 Lenovo Thinkpad had working Wifi out of the box from day 1.

The last time I had wifi driver issues on Linux was 2008.

Re: Technical reasons to choose FreeBSD over GNU/Linux (2020)

#90
post #62

I am using freebsd since version 8 for all my server needs (was using linux, but got repelled by its chaos which I dont care about on my laptop, but it pisses me off on server). Some more points: - bhyve, developed by netapp, they ditched all old technologies support and it works faster on my i5 server than kvm on my i7 laptop. Snapshoting using ZFS is not a feature to discard either. - FIBs, absolute miracle routing…

From a technological perspective, everything you say is true, and FreeBSD is better in so many regards. But, compatibility and community support is just a deal breaker.

The jails vs docker argument is a good example: while technically better, Docker (or rather, cgroups and image distribution) have been standardised and have tremendous community adoption. FreeBSD cannot tap into any of this at all. Yes, jails might be better, but because they lack widespread adoption, they’re far less useful.

It’s a sad state of affairs, I wish things went otherwise, but I feel Linux is sometimes a good example of the “worse is better” approach at work.

Post reply on HN