Running on bare metal usually means not in a VM or container. It means they talk to the hardware in the most direct way. Sure, it takes drivers, kernel, etc but that's about it.

Operating systems can run on VMs or containers. When comething runs on top of those OSs, they are not running on bare metal.

This is not what whot meant. He meant "bare metal" in that Xorg is the display server talking to your input (evdev) and output devices (drm/kms), rather than running as a rootful or rootless child of another display server as is the case with Xwayland or Xephyr.

A "bare metal" display server can run in VMs, or even in containers (although the latter is a little pointless as the device access violates sandbox safety).

Thanks, this is an interesting point-of-view, and thinking back and re-reading the article, it seems you're right.

I'll have to say though, I find that particular definition of bare metal quite strange.

It's also a bit of a weird thing to describe. Native? Master? Normal?

"Nested" is more or less the de-facto term in Wayland-land for the child scenario (pretty much all Wayland display servers natively support a rootful child mode either as real feature or for testing/debugging, some even under X), but there isn't really a good word for the normal case.

A container is simply a process with isolated namespaces — an OS does not run within them, and any hardware access they have is mediated by the OS in the same way as any other process. This being from Linux’s POV anyway: once you’re running Docker on other OS’s, there’s a Linux VM in the middle.

You can absolutely run a separate OS in a container. Not the kernel, but everything else.

It's true that you don't have to, but you certainly can.

In fact, the first implementation of containers in Linux - Linux Containers, or LXC - works exactly that way.

This may or may not be as great a distinction as you might want in order to consider it bare metal vs. not. I'll leave that up to you.

I think this part of the discussion is just a disagreement as to what constitutes an OS, and whether running a process with a different rootfs entails "running a different OS".

Sure, the average container in fact brings along an entire OS distribution like Alpine or Ubuntu or whatnot, but there’s still no extra layers added (save perhaps for the filesystem). Then again, running an OS at all is not “bare metal” by some definitions… it’s all various amounts of alloys I suppose.

Means that the X server directly communicates with the display driver to do the low-level rendering. Compare that with Xwayland, in which the server is an application talking to wayland or Xephyr which renders to a frame buffer in another X.

Compare it to the other servers in the same `hw` directory:

    ├── hw
    │   ├── kdrive
    │   ├── vfb
    │   ├── xfree86              <- this one is Xorg
    │   ├── xnest
    │   ├── xquartz
    │   ├── xwayland
    │   └── xwin

Xorg/xfree86 is the one that renders to your display hardware (metal), compared to `vfb` which renders to the Linux Virtual FrameBuffer API, `xnest` which renders to another X server, `xquartz` which renders to Apple's "quartz" display system, `xwayland` which renders to a wayland server, and xwin which renders to Win32.

And, uh `kdrive`, which renders to... um... something or other.

Edit: Also, while Linux now has Atomic ModeSetting and the Direct Rendering Manager APIs, for a lot of Xorg/Xfree86's history it didn't, and the X server did a lot more direct manipulation of the display hardware than it does now. Switching virtual consoles between X consoles and Linux terminal consoles used to be a weird dance between Xorg in userspace and the kernel to make sure that the hardware handoff between them didn't mess up. This dance took about a second to complete (which is forever in CPU time) rather than being the instantaneous sort of switch it is now. But even now, with DRM and the other stuff, Xorg still does a lot of talking directly to the hardware.

> This dance took about a second to complete

What's really weird about reading this is that I can hear, in the back of my mind, the sound my CRT makes while doing this switch. But I have no memory of ever switching from X -> virtual console since LCDs were a thing. I guess... that's when X stopped crashing routinely? Weird stuff!

(Also, am I crazy or is there also a smell associated with this operation? I swear I remember something like that. When the mode switches, the monitor degausses itself, and then there is a faint smell of ozone? Computers used to be weird!)

Me too! It sounded like something was being done to the monitor that it did not enjoy at all.

Entering hyperspace in 3…2…1… [high frequency sound]

kdrive is this alternative X server, I suspect: https://www.irif.fr/~jch/software/kdrive.html