Hacker News Reader

Comment by LatencyKills | Hacker News Reader

I was a dev on the Visual Studio and Windows teams in the 90s. I’m retired but mentor CS students at two local universities.

I haven’t had a student in two years that was even remotely interested in ring-0, internals, or really understanding a debugger.

I’m not being critical; they are just focused on higher level abstractions.

View on HN

It’s fun to understand just for intellectual curiosity’s sake but the number of people who get to work on shipping code where ring-0 knowledge is useful has to be minuscule as a percentage. It feels like a minor miracle I got to work on device drivers in my career. I imagine students might be more worried about completing assignments and good grades than the ins and outs of debuggers, too, though understanding those is important for problems one is more likely to come across in work projects versus smaller school assignments.

> the number of people who get to work on shipping code where ring-0 knowledge is useful has to be minuscule as a percentage

I wonder if it it is more that the percentage of people who choose to dedicate themselves to that type of work is miniscule. I work in graphics and performance, and it seems similar.

Few people really work on it specifically at any given company, and I've heard people warn others that there are few jobs in it.

But video game companies really want people for those roles and will pay well because they're hard to find. Still, few programmers show any interest in specializing in those skills. If you're passionate about it and willing to learn the details you'll eventually find a lot of job opportunities. I know people who want to work with this and do so - I know many more who have specifically said they want to stay away from it. I don't know anyone who wants to and can't.

How would one start learning about it?

Before listing resources, let me state that the single most important thing is to learn by doing. Write a lot of rendering code, experiment a lot with your own ideas and variations on each exercise. Once you move past the basics don't be afraid to spend several evenings in a row failing to fix what in hindsight seems like an embarrassingly simple math error. That is how you go from having read and sort of understood something to really knowing it. Also, the best approach is usually to devour as much content as you can from several sources to get a wider perspective.

There are a lot of great resources out there. The best modern beginner friendly resource I am aware of is Scratchapixel[0]. Back when I was first learning 3D I used to follow tutorials on places like NeHe Productions[1], which is probably a bit dated these days.

For more comprehensive information on all kinds of techniques, with examples from big games for each technique, the absolutely best resource is the book Real-Time Rendering[2].

If you're interested in ray-tracing rather than rasterization (i.e. more film than video games) a lot of people recommend "Ray Tracing in One Weekend"[3]. If you want to learn state of the art ray-tracing in depth, with all the math and and theory, the best resource is "Physically Based Rendering: From Theory to Implementation"[4], which is freely available online.

[0] https://www.scratchapixel.com/

[1] https://nehe.gamedev.net/

[2] https://www.realtimerendering.com/

[3] https://raytracing.github.io/

[4] https://www.pbrt.org/

If you want to learn more about how computers work I would recommend the following:

- The OS Dev wiki - Open Source Firmware Conference — TKey (shameless plug) - Tiny Tapeout - wafer.space

In rough hierarchical order from software to metal.

> I’m retired but mentor CS students at two local universities.

> I haven’t had a student in two years that was even remotely interested in ring-0, internals, or really understanding a debugger.

I know quite a lot of such people (even in student age) who are interested in such topics. I really have a feeling that you chose the wrong students at the wrong universities.

Evidence for my point: rather recently, No Starch Press published quite a lot of about such topics - I am rather certain that a publisher knows quite well which kinds of books do or don't sell well at a given time:

- The Book of Debugging https://nostarch.com/book-of-debugging

- The Linux Memory Manager https://nostarch.com/linux-memory-manager

- The Art of 64-Bit Assembly, Volume 2 https://nostarch.com/art-64-bit-assembly-v2

- The Ghidra Book, 2nd Edition https://nostarch.com/ghidra-book-2e

- Building a Debugger https://nostarch.com/building-a-debugger

- Microcontroller Exploits https://nostarch.com/microcontroller-exploits

- System Programming in Linux https://nostarch.com/system-programming-linux

- The Art of ARM Assembly, Volume 1 https://nostarch.com/art-arm-assembly-volume-1

- Getting Started with FPGAs https://nostarch.com/gettingstartedwithfpgas

- The Book of I²C https://nostarch.com/book-i%C2%B2c

> System Programming in Linux https://nostarch.com/system-programming-linux

Any ideas how this compares with Kerrisk's The Linux Programming Interface? I've only so much time to read one 1000+ page book...

> Any ideas how this compares with Kerrisk's The Linux Programming Interface?

Unluckily, I don't know, but comparing the Table of Contents for both books

> https://man7.org/tlpi/toc-short.html

> https://nostarch.com/system-programming-linux

I would claim that The Linux Programming Interface covers a broader range of topics, and I also think this book goes more in depth. On the other hand, System Programming in Linux seems to be more pedagogical, and is more targeted towards people who profit from doing exercises and programming projects to get their hands dirty.

> you chose the wrong students at the wrong universities

I work with Duke University, the University of North Carolina, and Carnegie Mellon.

You don't know that "young engineers" are buying those books. I didn't claim that no one is interested in low-level development. My point is that most younger developers couldn't explain the difference between a mutex and a critical section, or how the OS handles a thread quantum, if their lives depended on it.

I could list a dozen new books on how to build an LLM from scratch. That doesn't mean that most developers understand LLM internals.

As an aside, I love your username. I have a tattoo of Aleph One. ;-)

> My point is that most younger developers couldn't explain the difference between a mutex and a critical section, or how the OS handles a thread quantum, if their lives depended on it.

To my knowledge this is taught in some "Operating System" course, and typically students have to do a hands-on implementation of at least some central parts of an operating system. So I guess these students simply did not pay attention in the respective course. :-(

I'll help you out: all CS students are required to take an entry-level OS course. Again, you are making incredibly weak arguments given that most students are required to take an English writing course but then can't remember most of it.

It isn't that they didn't learn it: the issue is that most CS students graduate and work in areas that require zero OS knowledge. For example, when would I spin up a thread versus a fiber? Even ring-3 devs need to have some level of understanding if they want to create performant software.

First, I didn't work with the right universities. Now the students I work with "didn't pay attention".

/ignored

> First, I didn't work with the right universities. Now the students I work with "didn't pay attention".

I can only say that my university-time experience was so much different, and I do observe a similar interest among younger students. So I am hypothesizing what could be the reasons.

But concerning your point, I would indeed claim that the hypotheses "wrong university" and "students did not pay attention" are positively correlated: I think a university where many students are not actually not very interested, excited and curious about the topics that are taught in the lectures does not form a good learning environment.

And for some books about Windows system programming:

- Windows Internals, Parts I and II

- Windows 10 System Programming, Parts I and II

- Windows Kernel Programming, Second Edition

- Programming Windows, 5th and 6th Editions

Arguably the lower level abstractions are more interesting too! how exactly Windows does ring-0 is less interesting than writing your own ring-0! And unless you care about writing driver-level software for Windows or contributing to the kernel, learning this is also less useful.

I'm essentially arguing that unless you work at MSFT, there's next to no reason to learn that specific abstraction layer.

> I'm essentially arguing that unless you work at MSFT, there's next to no reason to learn that specific abstraction layer.

Really? Understanding the cost of ring transitions is incredibly useful. I recently consulted with a company that was having horrible performance issues, and it came down to the fact that the primary developer didn't know that certain Win32 calls forced ring transitions. The entire fix was switching from a mutex to a critical section (one causes a ring transition, the other doesn't).

Treating the OS like an impenetrable black box will bite upcoming engineers/companies... eventually.

This makes sense, and I guess as someone who’s never written Windows software I didn’t realize it was a leaky abstraction!

Speaking of debuggers...

I still twitch whenever someone says "use ddd" and they are not referring to Evans' seminal work.

:-D

Reply on news.ycombinator.com