3 ms·

Admittedly, I got a B in 410 and only managed to TA 213, but I do work in the space now. Yes, it’s hard to do research if you start at “let’s design a kernel f

Admittedly, I got a B in 410 and only managed to TA 213, but I do work in the space now. Yes, it’s hard to do research if you start at “let’s design a kernel from scratch,” but you’d never need to do that. You can just hack Linux or a bsd, or even use something like bpf to extend it. The thing that annoyed me about 410 is that when I switched to Linux I realized that pusha/popa didn’t matter at all. It was a good course for writing reentrant C and learning the very basics of hardware, but the really hard stuff is in the weird dynamics of memory management on NUMA systems and work conserving io, which you can’t get anywhere near if you are starting from scratch.

naasking 5y ago
> 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.
- deleted 5y ago
  [deleted]
- wallscratch 5y ago
  I’d be curious to hear some examples.
  - naasking 5y ago
    As but one example, how are you going to conduct security research using an microkernel or exokernel architecture on Linux?
- bluGill 5y ago
  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.
seoaeu 5y ago
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...
glangdale 5y ago
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.

naasking 5y ago

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

deleted 5y ago
[deleted]
wallscratch 5y ago
I’d be curious to hear some examples.
- naasking 5y ago
  As but one example, how are you going to conduct security research using an microkernel or exokernel architecture on Linux?
bluGill 5y ago
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.

seoaeu 5y ago

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

glangdale 5y ago

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.