Earlier quoted context omitted.
> The bsds are actually less stable than Linux. > Stable meaning changes, in this context, right? freeBSD changes ABI compatibility with every version. Every major version, right? From becoming -Stable to ending its support lifecycle, I'd think a FreeBSD version and its ABIs are supported as long as many Linux distro LTS releases.
The major difference being that if you have a statically compiled binary from linux 2.4 it will work on linux 5.5 The only difference will be any shared libraries and potentially the libc. But if we're speaking from a pure technical perspective, the libc is not linux.
John Carmack is reading and contributing to OpenBSD source code
191–200 of 267 posts
Re: John Carmack is reading and contributing to OpenBSD source code
#192Earlier quoted context omitted.
I concur.
Wayland support fiasco, changes in driver's EULA to deny the usage of consumer-grade GPUs in VMs are 2 things off the top of my head.
Re: John Carmack is reading and contributing to OpenBSD source code
#193Earlier quoted context omitted.
I concur.
Wayland support fiasco, changes in driver's EULA to deny the usage of consumer-grade GPUs in VMs are 2 things off the top of my head.
Which changes? Where? I'm looking at said EULA right now and I don't see anything related.
Re: John Carmack is reading and contributing to OpenBSD source code
#194Earlier quoted context omitted.
By NVIDIA supporting FreeBSD you mean that half-assed thing with binary drivers allowing you to get a picture, but no CUDA? Or is that old information which i should forget?
Unfortunately, half-assed vendor support is still quite compelling compared to no vendor support.
Re: John Carmack is reading and contributing to OpenBSD source code
#195Earlier quoted context omitted.
They could even do it with less churn, because of https://github.com/freebsd/freebsd/blob/master/sys/conf/opti... FreeBSD easily achieves binary compatibility with earlier versions. So no need to mess around with DKMS or their own thing. Or at least less so.
> FreeBSD easily achieves binary compatibility with earlier versions. So no need to mess around with DKMS Binary compatibility is for userspace programs, not kernel modules.
Re: John Carmack is reading and contributing to OpenBSD source code
#196Earlier quoted context omitted.
They could even do it with less churn, because of https://github.com/freebsd/freebsd/blob/master/sys/conf/opti... FreeBSD easily achieves binary compatibility with earlier versions. So no need to mess around with DKMS or their own thing. Or at least less so.
> FreeBSD easily achieves binary compatibility with earlier versions. So no need to mess around with DKMS Binary compatibility is for userspace programs, not kernel modules.
Re: John Carmack is reading and contributing to OpenBSD source code
#197Earlier quoted context omitted.
> FreeBSD easily achieves binary compatibility with earlier versions. So no need to mess around with DKMS Binary compatibility is for userspace programs, not kernel modules.
GP's link is to the COMPAT_FREEBSD binary compatibility for earlier versions of FreeBSD, oddly. I don't think it (or linux emulation) has anything to do with Nvidia's needs re: CUDA/NVENC.
Edit: I'm not having any FreeBSD systems in use right now, so i don't know if they changed the defaults. What i remember is at least the last two versions were compiled into GENERIC, so you didn't even had to compile your own kernel when that range backwards was enough.
Similar thing in NetBSD, a loooong time ago, even their own driver for 3Com905 relied on the equivalent of that functionality. That caught me by surprise, because i used NetBSD like Gentoo, found some Compat foobarjurassicBSD, wondered why i should use that at all, and had no working net. Fun! :-)
Re: John Carmack is reading and contributing to OpenBSD source code
#198Earlier quoted context omitted.
Unfortunately, half-assed vendor support is still quite compelling compared to no vendor support.
It depends on your use-case, i guess. If my intent would be using FreeBSD as my daily-driver "desktop/laptop-OS" i'd avoid NVIDIA like the plague, becaue without CUDA their unique selling point does not exist, but the hassle of some "switcheroo-black-magic" possibly persists. Which i wouldn't have with an intel-gpu, also less power draw. Even AMD is often supported in a better way, be it opensourced, or relying on th…
AMD binary blob? You mean that amdgpu-pro thing? That doesn't exist on FreeBSD.
Re: John Carmack is reading and contributing to OpenBSD source code
#199Earlier quoted context omitted.
Also id ran software on NeXTSTEP, itself a precursor of OSX https://en.wikipedia.org/wiki/NeXTSTEP#Legacy
yep, was going to say that this is probably the real source behind the mystery. Early OS X is basically NeXT when Jobs came back to Apple. Doom was developed on NeXT, so id Software and Carmack already had a history of using BSD. They also released Quake for Linux around 1996, which may have used X11 (I cannot recall, maybe it just depended on 3dfx/nvidia without X11 at the time... it's been so long)
Re: John Carmack is reading and contributing to OpenBSD source code
#200Earlier quoted context omitted.
I would suggest to just install OpenBSD and try it (maybe in a VM?), one of the selling points is the simplicity of the setup process. It can be a one evening project.
> maybe in a VM? But that's the thing. The real benefits from OpenBSD come when it's the only system you need. Who cares how simple and elegant the guest system is, if you need to maintain a linux installation to host it? A project on the scale of OpenBSD can't possibly support all the hardware that's out there. And the system is under active development, so there are constant regressions in hardware support. That's…
https://github.com/elad/openbsd-apu2
Mine is 4(?) years old, and has never crashed. I use it every day. If you want something newer, or have 10x the power budget: