3 ms·

For me this post is very awkward because nVidia is the hassle-free graphics solution for the last two decades. https://www.freshports.org/x11/nvidia-driver/ ht

For me this post is very awkward because nVidia is the hassle-free graphics solution for the last two decades. https://www.freshports.org/x11/nvidia-driver/ https://www.freshports.org/x11/nvidia-driver/ "Port Added: 2003-01-20 07:29:31" As a FreeBSD user I haven't run anything else since 2005 and that has been the foundation of my workstation builds. Intel CPU/chipset and nVidia. FreeBSD driver was a bit slower to update to new version, and it never received any of the supplementary software, but that came along the line. Edit : the summary of quality of drivers is right in the last paragraph in the article.

drewg123 3y ago
Great post. I feel the same. I look at the heroics done to make the linux Intel and AMD drivers work, and it seems like the current nvidia driver is far simpler. Eg, a binary blob with native wrappers. The only time it breaks is when the wrappers are stale; eg the kernel APIs that it depends on have changed. I run current, and I've only had an issue around the driver failing to compile or run correctly a handful of times in 2 decades, which is saying a lot for an out-of-tree driver.
- olivettiM19 3y ago
  Absolutely. And those hoops that occasionally happened through the years would happen to any 3rd party kmod package, regardless. Nowadays for workstation usage RELEASE is good because it has quarterly. No need to track other branches to stay current with the packages, 4 times per year is enough for 99.9% of desktop users. So those kmod hoops are largely gone.
paulmd 3y ago
> Edit : the summary of quality of drivers is right in the last paragraph in the article. yeah, honestly the problem with linux is the unstable kernel ABI, which BSD does not suffer from. And BSD also doesn't have the copyleft "can't link to anything not GPL'd" problem either. it's not that NVIDIA's linux teams aren't good, actually they do a pretty good job with the linux driver, has a working GPGPU userland, etc (although the UI makes the windows one look futuristic, and there's been some spats around wayland etc). it's that the linux kernel doesn't care about ABI because of aggressive in-tree'ing of compatible modules, and proprietary binary modules will never be compatible with GPL unless there's some kind of a shim (like they've added). which does not apply to freebsd. as I said, freebsd is astonishingly boring with how competently engineered and well-documented and stable the whole thing is, and it's a shame that docker/k8s is where the momentum is going. Jails are a great option (and docker is only just now starting to tackle some of the security theoretically open up a lot of support for linux applications/etc. it's just something that most orgs (rightly) won't devote even a minute to looking into, because it's not where the momentum is going. not talking about backend services/etc here, but, if I had to design a long-life appliance where it needs to run for a long time with minimal supervision and oversight, and have minimal support costs, freebsd+zfs open up some neat options. FreeBSD is stable and long-life, so you're not going to find some critical system component churned out from under you by poettering or someone like that. And ZFS lets you deploy system updates as images/snapshots and do rollbacks to a known-safe version if something goes wrong or it fails to boot etc.

drewg123 3y ago

Great post. I feel the same. I look at the heroics done to make the linux Intel and AMD drivers work, and it seems like the current nvidia driver is far simpler. Eg, a binary blob with native wrappers. The only time it breaks is when the wrappers are stale; eg the kernel APIs that it depends on have changed. I run current, and I've only had an issue around the driver failing to compile or run correctly a handful of times in 2 decades, which is saying a lot for an out-of-tree driver.

olivettiM19 3y ago
Absolutely. And those hoops that occasionally happened through the years would happen to any 3rd party kmod package, regardless. Nowadays for workstation usage RELEASE is good because it has quarterly. No need to track other branches to stay current with the packages, 4 times per year is enough for 99.9% of desktop users. So those kmod hoops are largely gone.

paulmd 3y ago

> Edit : the summary of quality of drivers is right in the last paragraph in the article. yeah, honestly the problem with linux is the unstable kernel ABI, which BSD does not suffer from. And BSD also doesn't have the copyleft "can't link to anything not GPL'd" problem either. it's not that NVIDIA's linux teams aren't good, actually they do a pretty good job with the linux driver, has a working GPGPU userland, etc (although the UI makes the windows one look futuristic, and there's been some spats around wayland etc). it's that the linux kernel doesn't care about ABI because of aggressive in-tree'ing of compatible modules, and proprietary binary modules will never be compatible with GPL unless there's some kind of a shim (like they've added). which does not apply to freebsd. as I said, freebsd is astonishingly boring with how competently engineered and well-documented and stable the whole thing is, and it's a shame that docker/k8s is where the momentum is going. Jails are a great option (and docker is only just now starting to tackle some of the security theoretically open up a lot of support for linux applications/etc. it's just something that most orgs (rightly) won't devote even a minute to looking into, because it's not where the momentum is going. not talking about backend services/etc here, but, if I had to design a long-life appliance where it needs to run for a long time with minimal supervision and oversight, and have minimal support costs, freebsd+zfs open up some neat options. FreeBSD is stable and long-life, so you're not going to find some critical system component churned out from under you by poettering or someone like that. And ZFS lets you deploy system updates as images/snapshots and do rollbacks to a known-safe version if something goes wrong or it fails to boot etc.