I feel you are focusing on the literal aspect of what I wrote and ignoring the broader implications. The tradeoff here between "student OS kernel principles" and "grind through a USB driver implementation" will recur as you try to add drivers and hardware to run meaningful-to-users workloads.

So you wind up with a research operating system that has finger-painting graphics, can't talk to modern SSDs or networks cards... or you somehow conjure up the resources to build an enormous number of drivers.

If you "hack Linux or a bsd" - or even more timidly - use ebpf - the constraints of what you build are going to result in you basically building "more UNIX stuff". This isn't bad research, but the sheer mass of constraints you're taking on if you accept all the design tradeoffs of Linux/bsd/eBPF/whatever means you're certainly not doing the sort of OS research that the original author talked about.

The linked talk specifically complains about everyone building off of Linux, because doing so bakes in a whole bunch of assumptions that are decades old and might not be the best options for today's hardware...

> but you’d never need to do that.

Why not? Linux has plenty of core design flaws that can't be solved without starting from scratch.

Then start with something else. There are dozens of operating systems out that there make an attempt to be better (for some definition of better), choose one and work with it. Starting from scratch means you spend years doing all the things they all get right before you can work on the interesting parts.

I’d be curious to hear some examples.

As but one example, how are you going to conduct security research using an microkernel or exokernel architecture on Linux?