4 ms·

This is entirely wrong, and I'm sorry that those who do work at the hardware/software interface have done their work apparently so well as to allow you to harbo

This is entirely wrong, and I'm sorry that those who do work at the hardware/software interface have done their work apparently so well as to allow you to harbor this delusion. Hardware is complex -- exceedingly so -- but (just as the talk relays) more of that complexity is in hidden cores running operating systems you can't see. Indeed, the talk addresses you (yes, you!) more or less directly at ~31:47: "This is called 'ignorance.'" While you are not entirely to blame for your ignorance (if the talk errs, it's in pretending that these hidden systems are well documented -- or even documented at all), you are complicit it in. Please educate yourself as to the massive complexity that lies beneath you, perhaps by just watching the talk that you are commenting on.

throwawaylinux 5y ago
Get off your high horse and shove your accusations of complicity and ignorance, and you educate yourself before you start throwing stones: Re-read my post and don't bother replying unless you can understand and accept that I never once suggested hardware was not complex. I said the software interfaces to them have not exploded in complexity, i.e., specifically refuting the suggestion that we don't "have the resources to cope with the monstrous complexity of hardware now", from the point of view of driving them with software. You utterly failed to refute anything that I actually wrote, but after your tantrum is over feel free to have an attempt. And I work at the line and on both sides of it logic, architecture, and software, so don't bother with the vapid appeals to authority.
throwawaylinux 5y ago
I haven't listened to the whole thing but that part of the talk you linked is really cringey actually. To paraphrase, "don't trust a person to write software if they haven't written a first level interrupt handler". Utter rubbish. And he goes on to talk about programming for an embedded SoC, etc. Hah. Some of the most utterly wretched code, vhdl, and development practices I've ever had the displeasure of being acquainted with have been in embedded devices, devices, device driers, firmware, etc. And first level interrupt handlers? He's saying that like it takes some genius to do it, or the process of doing it confers some deep understanding on the writer. It doesn't. It's not particularly complex, outside buggy or stupid architecture but even that's just grinding work. And the there is some horrific buggy crappy interrupt handler code around and I can say that because I've written some. And it sounds like you may well have too, if your interactions with David Miller relating to the the performance of Sun OS system calls is anything to go by. Arguably it's more valuable to understand how the C environment (stack, etc) is set up and how to wrangle the toolchain into emiting code at particular locations and such. But you can get all that many other ways. And even then, I don't actually agree that you need to know the minutiae of those details in this day and age which is a great thing. This is not where most of the interesting work is happening, like it or not. This kind of elitist gatekeeping attitude is just sad. It reeks of the has-been (or maybe never-was) mindset. I would just as well trust code written by someone who deeply understands what they do writing a word processor or video game or distributed database, than someone who has hacked out an interrupt entry vector. And the sad fact is that being an OS developer does not require or confer a deep understanding of how to get the most out of hardware, understanding caches or multiprocessing or branch predictors or performant scalable data structures and synchronization techniques. No more than writing a web server prevents a person from understanding all those things deeply.

throwawaylinux 5y ago

Get off your high horse and shove your accusations of complicity and ignorance, and you educate yourself before you start throwing stones: Re-read my post and don't bother replying unless you can understand and accept that I never once suggested hardware was not complex. I said the software interfaces to them have not exploded in complexity, i.e., specifically refuting the suggestion that we don't "have the resources to cope with the monstrous complexity of hardware now", from the point of view of driving them with software. You utterly failed to refute anything that I actually wrote, but after your tantrum is over feel free to have an attempt. And I work at the line and on both sides of it logic, architecture, and software, so don't bother with the vapid appeals to authority.

throwawaylinux 5y ago

I haven't listened to the whole thing but that part of the talk you linked is really cringey actually. To paraphrase, "don't trust a person to write software if they haven't written a first level interrupt handler". Utter rubbish. And he goes on to talk about programming for an embedded SoC, etc. Hah. Some of the most utterly wretched code, vhdl, and development practices I've ever had the displeasure of being acquainted with have been in embedded devices, devices, device driers, firmware, etc. And first level interrupt handlers? He's saying that like it takes some genius to do it, or the process of doing it confers some deep understanding on the writer. It doesn't. It's not particularly complex, outside buggy or stupid architecture but even that's just grinding work. And the there is some horrific buggy crappy interrupt handler code around and I can say that because I've written some. And it sounds like you may well have too, if your interactions with David Miller relating to the the performance of Sun OS system calls is anything to go by. Arguably it's more valuable to understand how the C environment (stack, etc) is set up and how to wrangle the toolchain into emiting code at particular locations and such. But you can get all that many other ways. And even then, I don't actually agree that you need to know the minutiae of those details in this day and age which is a great thing. This is not where most of the interesting work is happening, like it or not. This kind of elitist gatekeeping attitude is just sad. It reeks of the has-been (or maybe never-was) mindset. I would just as well trust code written by someone who deeply understands what they do writing a word processor or video game or distributed database, than someone who has hacked out an interrupt entry vector. And the sad fact is that being an OS developer does not require or confer a deep understanding of how to get the most out of hardware, understanding caches or multiprocessing or branch predictors or performant scalable data structures and synchronization techniques. No more than writing a web server prevents a person from understanding all those things deeply.