Live data from Hacker News

John Carmack is reading and contributing to OpenBSD source code

marc.info

191–200 of 267 posts

Re: John Carmack is reading and contributing to OpenBSD source code

#191
post #164

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.

Binaries from all the way back from FreeBSD 4.0 work on -CURRENT just fine.

Re: John Carmack is reading and contributing to OpenBSD source code

#192

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

There was actually some period of time when the Tegra division (I think) contributed to Nouveau a bit (!) but that didn't really grow into anything good.

Re: John Carmack is reading and contributing to OpenBSD source code

#193

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

> changes in driver's EULA to deny the usage of consumer-grade GPUs in VMs

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

#194

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

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 their binary blob.

Re: John Carmack is reading and contributing to OpenBSD source code

#195

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

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.

Re: John Carmack is reading and contributing to OpenBSD source code

#196

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

Ahem. Tell that to all the binary drivers for network cards and raid controllers which relied on that functionality, which i happened to use not all that long ago.

Re: John Carmack is reading and contributing to OpenBSD source code

#197
post #195

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

It means you have a module from some vendor, or something similar to the NVIDIA installer for linux, which technically is nothing else than a batch compiled makefile, spitting out a kernel-module made for version 1.2.3 while you are running 2.4.5. It worked. I don't know why it shouldn't now.

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

#198

Earlier 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…

> Even AMD is often supported in a better way, be it opensourced, or relying on their binary blob.

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

#199

Earlier 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)

The original quake on Linux used svgalib and was done by Dave Taylor and GAlexand (EFnet #c??)

Re: John Carmack is reading and contributing to OpenBSD source code

#200
post #36

Earlier 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…

> box in a closet

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:

https://flak.tedunangst.com/post/ryzen-build-for-openbsd

Post reply on HN