[clug] [OT] With Coders like these, how far can Apple go?

steve jenkin sjenkin at canb.auug.org.au
Mon Jan 14 19:41:34 MST 2013


Alex Satrapa wrote on 15/01/13 12:51 PM:
> On 15/01/2013, at 12:29 , steve jenkin <sjenkin at canb.auug.org.au>
> wrote:
> 
>> I was gob-smacked at some statements I saw on the Apple Developer
>> site...
>> 
>> They have a section entitled:
>> 
>> "Keep Out: Why You Should Avoid Programming in the Kernel" [It's a
>> black art and too hard/perfect for ordinary mortals.]
> 
> Are you suggesting that kernel programming is easy and that anyone
> should just hack around willy nilly without any concern for
> repercussions to the millions of people who rely on that kernel for
> their daily computing needs?
> 
> What happens if you try hacking in the Linux kernel? You get filtered
> by dozens of people before any patch gets to Linus' right hand men.
> Stuff only gets into the Linux kernel when it's been reviewed by a
> cadre of people smarter than you when it comes to kernel
> programming.
> 
> Then there are the manufacturers who package dodgy drivers with their
> hardware, which needlessly reaches into kernel space and messes it
> up. Sure, your scanner works, but after a few hours of operation the
> machine kernel panics. This is why people who don't know what they
> are doing should keep their grubby mitts out of the kernel.
> 
> Can you elucidate upon the reasons for your shock and surprise?
> 
> Alex

Alex,

Great question! Thanks very much for asking it.

I loved that John Lions wrote his commentary and gave Ken & Denis'
20,000 line kernel to third year students to study - with a "Oh, and by
the way, you have to learn 'C' in 4 weeks".]
I discovered I knew near *nothing* then and the more I know, the more I
know how little I Know. :-(

Reading that V6 kernel showed:
 - it was accessible
 - kernel coding was possible & learnable
 - real-time code had some complex parts to be very careful around
 - writing low-level code required a disciplined engineering approach:
     very few coding errors and simple, robust designs to avoid error.

If people came away from that experience thinking it was easy/trivial,
it wasn't my experience. Being exposed to code written by arguably some
of the best coders around, and trying to learn from that, was a
formative experience for me. It also gave me the confidence to take on
any low-level task I was given, or push further than others to trace
faults. Once I debugged a library fault in DOS Turbo Pascal. They'd got
their version control wrong and linked in an old module, compiled with
an old value of a constant. The patch was a single byte... Well worth
the week it took me to find and document.

I'm not suggesting that anyone should just hack on the kernel,
regardless of consequences, rather the reverse.
Thompson, more than adequately, gave the most penetrating critique of
the Linux kernel I know: it's of uneven quality.

The lack of understanding of, and respect for, Code Quality, is what
brought down Microsoft. In their great Longhorn Reset (2004?) they threw
away 25,000 man-years of effort (my estimate) because they didn't follow
basic Software Engineering practices...

What left me gob-smacked was that the Apple programmers seem *scared* of
kernel programming and wish to propagate that view.

Yes, it's "hard", but that's because it has to be optimised in many
dimensions simultaneously, but mainly it's a fully exposed, low-level
real-time environment, now with multiple CPU's & threads...
We have very few good tools to model and prove correctness in that
environment.

Yes, it has to be high-quality and designed to be robust, resilient and
error-free, to a level that few are trained in and fewer have
professional experience doing.

Apple are right in saying "this code has to be more reliable, with fewer
errors and exploits than all other code on the system"
 - even the system libraries depend on the kernel.

No code can be more secure or robust than the underlying layer.
The kernel & hardware drivers, as the lowest layer, define how
reliable/error-free the rest of the system can be...

I like that Linus doesn't push the view that "kernel programming is only
for Gods of Code" (I haven't got that message, others may correct me).

It's like the guys on Top Gear going "hey, we're ordinary blokes, we
should be able to drive a Jet Car or a Formula 1 racing car!"

Yep, Richard Hammond showed that an ordinary bloke *could*, sorta, do
both those things, almost dying in the attempt. [Not his fault, a tyre blew]

But for me the takeaway was "to actually drive those things
competitively/professionally requires abnormal skill and training".

The same that it takes to become and stay a captain of a large
Commercial Jet... The book QF32 gives us ordinary mortals an insight
into that world.

Commercial Pilots don't push the view that "being in charge of 500 lives
and $250M of plane is a 'black art' and 'incredibly hard'".

They talk about humility, dedication, training, practice, learning,
testing and discipline/focus - *not* 'this is soooo hard'.

To rise to the highest levels of human achievement in any field requires
the same focus, dedication and commitment to quality, whilst avoiding
the "perfection trap" - "Perfect is the enemy of Great".

Linus started out as an ordinary, albeit adventurous, undergraduate
fiddling with a little project (a terminal emulator).
As did Sergey and Larry with Google... (undergrad or postgrad?)

That story, that anyone with the ability, dedication *and* a
learning/improvement mindset, can seek to take on the hardest problems
around, is the one I'd like to think Linux tells.

Not the disempowering "it's soooo hard, you can't do it" [AAPL] or the
ill-disciplined and unperceptive "software is full of bugs, what's one
more?" [MSFT]

Sorry to ramble on for so long...

Thanks for a great question.
I'd be disappointed if you & others didn't "call me out" for making
bizarre/wrong/dangerous statements.
And fully expect you to take apart/challenge what I've said in this reply.

That's the power of the FOSS culture:
  Open debate without enforcement of a single "approved" or correct
viewpoint.

cheers
steve



-- 
Steve Jenkin, Info Tech, Systems and Design Specialist.
0412 786 915 (+61 412 786 915)
PO Box 48, Kippax ACT 2615, AUSTRALIA

sjenkin at canb.auug.org.au http://members.tip.net.au/~sjenkin


More information about the linux mailing list