There is some room for disagreement, but I agree with most of the following. https://developer.apple.com/library/content/documentation/Da...
Kernel development, similar to algorithmic trading (incl HFT), some types of games, various embedded, actual production compilers etc requires a higher level of rigorous understanding from a variety of areas compared to the vast majority of webapps (often CRUD) and most software that IT professional work on. Kernel dev similar to other performance critical or safety critical systems has a much reduced set of tradeoffs and more numerous constraints, for one.
Of course, most applications require knowledge in disciplines such as design and domain specific knowledge that kernel development does not require, but that is besides the point. It requires a different type of thinking overall (one that is more unforgiving to lack of rigor and not as open to subjectivity cf. design) that low-level systems development/engineering and most app development are virtually unrelated disciplines outside of trivial similarities relating to them both targeting computers.
I don't say this to discourage anyone. But these reductions are unhelpful and outright condescending to those that might struggle to learn (oh it's just a slightly different domain than your JS TODO app....um no it's not.. it's harder for you to learn because it is actually harder and more complex).
i'm super confused. what equivocation are you refering to?
I'd absolutely encourage anyone with some C background to go and write themselves a "hello world" Linux kernel module to go convince themselves of this.
Looking up and down the aisles at Lowes and not finding a raised garden bed that met my needs, I inquired with a staff member:
“Sorry, we don’t carry anything like that.”
“Darn. Ok, I’ll try another store then,” I sighed with resignation.
“You know,” he said to me, “it’s just wood.”
It took me a moment to realize how liberating this statement was. To him, woodworking held no mystery at all - it was just a thing you did. If he wanted a garden bed, there’d be no question in his mind that he’d make it himself. Why spend more on something suboptimal when you can build exactly what you want?
— Bryan Kennedy (http://plusbryan.com/its-just-wood)
At least half of what I have learned has been because I was dissatisfied with what was available and thought I could do better myself.
Sometimes I could make a better thing, and sometimes I couldn't, but I always learned something. Even sometimes just the knowledge that it's harder than it looks.
Those were the days really. Barely having started my English studies I went looking for a single piece of information and found so much else on the way.. The tinkering and nights of frustration gave insights and a feeling of accomplishment that set me on the path to the profession I have today.
Then I started high school and someone showed me a shaded and textured cube they had rotating on their screen and I found out what math is good for :)
It's fairly new - started about a year ago, but there's quite a lot of stuff in there already (bootstrapped from the old XML stuff, I believe).
'However, that’s not too bad, because even the makers of GNU indent recognize the authority of K&R (the GNU people aren’t evil, they are just severely misguided in this matter)'
So much for the idea that kernel developers are super-smart programming "gods". Formatting code that way is brain-dead and Kernighan and Ritchie are false prophets. The real prophet, Allman, tells us the Truth - curly braces go on a line by themselves, aligned vertically and indented to the same level as their corresponding control structure.
I've got a fairly good idea of how many pieces work, but the whole thing together still puzzles me at times.
I think that it's one of the biggest achievements of the internet as a tool for progress, and it shows that good intentions and pragmatism (together with some good Linus insults as well) can go a long way
Complexity doesn't necessarily mean it's a masterpiece. A lot of it is just old and has been incrementally changed without being simplified in the mean time.
As a concrete example, the guide goes through the rather complicated mess of how syscalls worked. That complexity was the result of a series of optimizations and features added over time, but it wasn't a good design. These days Linux syscalls (on x86_64 anyway) are a good deal simpler than they are in the guide.
(Hey 0xAX, I don't suppose you'd like to update the guide?)
Any relation to the Borland/Delphi VCL?
But I can see clear lines for confusion.