OpenBSD is a modern, innovative Operating System that has retained classic Unix sensibilities. I also think that, even as a lover of Linux, a Linux monoculture is bad for the world.

The simplicity of OpenBSD makes it much easier to learn deeply than Linux. Where Linux has tended to create magical veneers over complexity, OpenBSD has tended to simplify the underlying systems.

Also, the OpenBSD project is shouldering the weight of the world and deserves more credit for this. So much of OpenBSD has made it into other parts of the Internet ecosystem.

> OpenBSD is a modern, innovative Operating System that has retained classic Unix sensibilities.

Like being quite bad for graphics programming and game development.

I don’t know enough about these domains to know whether there is anything intrinsic to the design of OpenBSD that makes it better or worse in this regard, but I suspect that if you are correct, it’s more a function of mindshare and number of people doing the work.

I think some of us feel that portions of the Linux world have made some wrong or at least undesirable turns for some things. It seems the choice is to either go along with those choices or improve other paths.

Also, not sure what issues you see, but there appear to be a bunch of the standard open source games in OpenBSD as you’d see in Linux. Obviously not the commercial games that have Linux ports, but that strikes me more as an issue of popularity than technical limitations.

> intrinsic to the design of OpenBSD

Design and implementation are two different things. I can imagine an OS perfect for game programming, but I can't use it, because it's not implemented.

I tried OpenBSD for 2 months, and went back to MacOSX. First, package repositories were meh (either pay, or recompile from source, or never update).

Second, OpenBSD graphic driver support was just very bad - no drivers for GPGPUs.

Third, lack of drivers, applications / services for interfacing with the real world and external devices.

I come home, open my laptop, click on select monitor, and I see 3 monitors available in the WiFi network (two TVs, and a desktop monitor). I can just click one, and my display is mirrored in real time to them - I can play a video, and it is mirrored perfectly, and with audio. Same at work, want to show a video in the presentation room? Connect to the beamer per wifi with a single click, display mirrored, great. Phone detects wifi, laptop backs it up to network storage, synchronizes media, updates software, Smart watch synchronized, etc.

None of that worked with OpenBSD. I had to find a HDMI cable in the basement to connect the laptop to the TV, monitor, beamer,... I had to use a USB cable to connect the phone to the laptop, which I then couldn't back up or synchronize without a gazillion brittle workarounds, etc.

Losing support for all modern devices felt like going back to the stone age. Linux isn't really much better, but while I like OpenBSD design, philosophy, and parts of the implementation. The current implementation doesn't work for me.

Yeah, that was my point: of course the more popular platform is going to have broader support. So the question is whether or not it’s possible to improve the less popular thing. My guess is that, with investment in time, there is nothing that prevents straightforward improvements in support in OpenBSD.

Why would OpenBSD be worthy of that expenditure of effort? Because it does some other things very well—perhaps better than Linux (Unix simplicity) and macOS (fully open). Not to mention security.

It sounds like you want a feature set that isn’t in OpenBSD. Fine, use macOS if those features are must-haves for you. Or, if OpenBSD’s feature set is compelling to you, start hacking! As I said elsewhere, I think it’s an easier path to make OpenBSD into what I want than it is to make macOS / Windows into what I want.

As for hardware support, I selected hardware that is well supported by OpenBSD, and it works great. Is there hardware I wish was better supported? You bet. But I’ve felt that way since I started using Linux and BSDs (and OS/2 and BeOS) in the 90s.

I encourage you to do that.

In todays world of "throw-away" electronics, there are a lot of devices that I just want to "just work". By the time these are supported on OpenBSD (if I were to implement it), I'll probably be owning a different device.

This is sad, because while I can select the hardware for my laptop, I can't really select the hardware and devices I need to interface with.

That would be quite interesting, since it uses the exact same graphics rendering code Linux uses, both in the kernel via DRM, and in userspace via Mesa and Gallium.

Which is also not known for being the best graphics and game development platform out there.

Anyone that actually cares about top graphics or game development tooling is either on Apple or Microsoft platforms.

Linux graphics support is quite good as long as your driver is open source and in-tree. I was just talking the other day with the graphics team about how we haven't really had any problems on Linux/Intel because everything just works.

Mac, on the other hand... oh boy. It's pretty much a disaster. There is no end of bugs in Apple's graphics stack, and no, Metal doesn't solve them all. The first time I ran the Metal port of my library, my MacBook Pro instantly kernel panicked. I have never had that happen on Linux.

As long as, that is the key expression.

Besides, the driver is only a tiny portion of the whole tooling for any graphics, professional game engine minded developer.

Even the NVIDIA drivers on Linux are superior to macOS' drivers. The problem with the NVIDIA drivers is that they don't play well with the rest of the ecosystem, but they do work. The only area where Linux is behind in graphics is on mobile, where the GPU vendors are perpetually unable to write working drivers.

I'm a professional graphics developer and I prefer the tooling on Linux to that of macOS.

Back to graphics drivers.

Most professional graphics developer I know rather user better tooling than only bare bones graphics drivers and RenderDoc.

I guess that is the same point of view that gave us OpenGL and Vulkan without any kind of tooling beyond drawing framebuffers with hardware support.

I does appeal to some, but not the majority, otherwise Linux adoption would have moved beyond 1% by now.

Like most software developers, graphics developers develop where the users are. That's why they predominantly use Windows. Some use macOS, primarily to develop iOS apps, which is, again, where the most valuable users are, particularly in North America.

Linux desktop market share, or lack thereof, has nothing to do with graphics tooling.

Sure it does, why bother with a market that not only lacks customers, it makes it a major hurdle to develop for?

While anyone on Apple and Windows platforms can enjoy Metal Frameworks, DirectTK, Unreal, Unity, CryEngine, PIX, Poser3D, Photoshop, Houdini, Cinema 4D, AfterEffects,...

On Linux, I guess having the freedom to use half baked copies of them, or hunting for libraries that should come out of the box with any graphics stack like 3D math, mesh handling and loading materials, is more important.

> Metal Frameworks, DirectTK, Unreal, Unity, CryEngine, PIX, Poser3D, Photoshop, Houdini, Cinema 4D, AfterEffects

I don't know them all, but FYI Unreal, Unity, CryEngine, PIX,Houdini, and Cinema 4D have native Linux versions.

I don't know about Metal Frameworks, DirectTK, Photoshop, and AfterEffects though, you might want to look into that.

I suspect there are plenty of people in this thread who’d love to see top tier games and development AND run on an open platform. In that sense, OpenBSD and Linux are both closer to supporting high-end games development than Windows and Mac are to being fully open platforms.

Your initial analogy is wrong, then, since—if modern Linux is also bad for those things—then OpenBSD being bad for those things wouldn't thereby make it an example of the OS "retaining classic Unix sensibilities" that modern Linux does not.

So other than SGI and NeXT, which although UNIX based had their focus on other kind of development stacks, which UNIX sensibilities are so great examples of graphical applications and game development tooling?

I think you misread my statement? I wasn't disagreeing with you. Rather, I was pointing out—in way of explaining why everyone was jumping to argue with you or downvote you—that the most obvious reading of your comments are an incoherent argument, and you should probably clarify what you mean.

In your first comment, when you said "Like being quite bad for graphics programming and game development", you were implicitly forming the larger sentence: "[Retaining] classic Unix sensibilities ... like being quite bad for graphics programming and game development."

And—since the topic of the thread was "OSes that are better because they avoid going down the road of RedHat-like 'modern' Unix sensibilities"—you were implicitly forming a larger assertion: "[OpenBSD, because it retains] classic Unix sensibilities [unlike RedHat] ... [is] quite bad for graphics programming and game development[, unlike RedHat, which is okay at those.]"

And so that's what people tried to argue with you about, which I hope makes people's rebuttals to your first comment make more sense to you.

But then, in your second comment, you went ahead and said that modern Linux is equally bad at doing these things. So clearly the expanded form of your assertion isn't what you meant.

So... what were you actually trying to argue?

I guess I might have.

I was arguing that only NeXT and SGI had a graphics workstation culture, where having UNIX underneath was more of a detail than anything else.

No one cared that much of writing POSIX daemon and CLI tooling, the whole point was making the best use of the GUI frameworks, IDEs and their GPUs.

Even when SGI offered IrisGL as the basis for OpenGL, they kept the best parts for them.

RenderDoc works great on Linux. I prefer it to the Metal debugger for the simple reason that it actually works without regularly crashing and popping up a "please file a radar" box.

Yeah, pity it only offers half of the features.

RenderDoc offers more useful features than the Metal debugger too. For example, RenderDoc is scriptable.

Your choice of platforms is highly questionable.

Either you're talking about high-end gaming, in which case Apple isn't in the game at all - the only players are Microsoft and Sony, though Google is making a bid now as well with Stadia.

Or you're talking about low-end gaming, in which case Google probably matters most because of Android.

Which mobile platform got Fortnight first?

As long as you like your userspace software 3-5yrs out of date.

OpenBSD isn't performant enough to be a daily driver on a laptop, unless your laptop spends all its time plugged in.

The battery life on my X220 was a solid hour less under OpenBSD than under Debian, and it ran some 10 degrees hotter. Yes, this is post-apmd improvements.

I want to like OpenBSD but code correctness just isn't enough for me.

OpenBSD (and the other BSDs too) are also pretty far behind on things like wireless hardware. There just aren't enough active developers to get a lot of the 802.11ac stack implemented (and ax or Wi-Fi 6 is coming around the corner too).

If there was a current port of Docker for FreeBSD and Wi-Fi ac support, it would totally be my daily driver right now. Currently I still use Gentoo on my laptops.

Does docker do anything for you that a jail couldn't?

It has been a long time since I used a BSD in anger, but aren't jails pretty much a take-it-or-leave-it system? Docker containers are an aggregate of Linux namespaces and cgroups and can be manipulated in a pretty granular way. I can, for example, share a networking namespace between two containers to have one inspect the traffic of the other (and do so easily).

Not saying you'd want to do that, but my understanding is that this is part of a lot of the clever networking you see in orchestration systems.

FreeBSD jails have some flexibility. You can choose to pass through the host networking as-is, or pass a limited selection of ips; I think there's a way to have a more separated stack that that too, but I haven't used it. You can allow raw sockets or not, you can shield the processes or not, same with IPC.

I haven't had a need to have a jail inspect traffic of another, I suspect that might be tricky. However I've used them successfully as a lightweight alternative to a vm for QA/dev environments -- use hard links for the base OS to save space, and give each jail its own ip and you get fairly cheap multiple boxes. I've also used it them to contain statically compiled binaries -- TLS terminator runs without access to much of anything, if the next vulnerability after Heartbleed was worse, it would be a lot harder to escalate vs common deployment with OpenSSL linked into a webserver; similar with an environment running ffmpeg.

There are already so many Dockerfiles out there and guides based on them. Plus you get filesystem layering, the cgroups, process limits ... I have a feeling it would be possible to build a container system that's Docker API compatible, but uses zfs and jails under the surface. I think that's what the old "unmaintained" port did a few years back.

and Gentoo.

I love Gentoo. It's a great developer distribution. I've been using it since 2003 I think, and the current Gentoo install I use I have continually updated since 2012. When I get a new machine, I just copy the existing install over and build a new kernel.

Same, been using it since 2002, my current image has been rolling since 2008, that's when I switched to amd64. Never cared about the performance tuning aspect, it's all about flexibility and control.

Would Gentoo not be subject to the effects of dodgy upstream patches too?

Gentoo doesn't use systemd by default, it has its own init system called OpenRC that's kinda sorta like a framework for sysv. Despite being shell based, it's very fast, my system can get from GRUB to Firefox in less than ten seconds if you enable autologin and add Firefox to your.Xsession.

Gentoo maintains forks of udev and logind, imaginatively named eudev and elogind. I use eudev, but elogind is unnecessary for me because I don't use Gnome3. But if that's your thing I'm not stopping you.

Pulseaudio is easy to remove by virtue of Gentoo's source based package model. Dbus less so; many applications have a hard dependency on it.

I think it's possible to use a BSD kernel, but you will very likely deal with a lot of breakage.

Gentoo is just so much easier to administrate that other distros it's unreal.

Unless you are trying to run software that explicitly depends on some of the brokenness from upstream (Gnome3) you can just setup a classic system that will behave the same way you're used to and honestly, I didn't encounter problems with software in that configuration

Gentoo tends to maintain out of tree patches (possibly to remove upstream changes), or complete replacements (like eudev/elogind).