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

steve jenkin sjenkin at canb.auug.org.au
Mon Jan 14 22:09:52 MST 2013


Hal,

Just too much to meaningfully comment on. Some comments in-line.

Hal Ashburner wrote on 15/01/13 2:31 PM:
> 
> On 15 January 2013 13:41, steve jenkin <sjenkin at canb.auug.org.au
> <mailto:sjenkin at canb.auug.org.au>> wrote:
> 
> 
>     What left me gob-smacked was that the Apple programmers seem *scared* of
>     kernel programming and wish to propagate that view.
> 
> 
> I have a couple of friends employed by apple to hack on Darwin.
> Including one of the authors of IOKIt and I can assure you this is not
> the case. I doubt they have much to do with that document. Apple also
> released Darwin code under a reasonable Free software license as pushed
> by the guys hacking on it. The OS they have is still not as good as the
> one I prefer but I think this move from Apple was the right thing(tm) to
> do... You /can/ hack Darwin if you want to. Windows? Most other
> commercial Unix? Not so much.

Could you tell your friends in Apple:
 - well done! in design, execution and code-quality, and
 - brilliant work getting "suits" to release code as Open Source.

> I think it's pretty reasonable community advice to hack whatever-it-is
> in user space if you can.

Correct choice for sane folk... Jumping into any real-time code that's
1M LOC in *not* for the faint-of-heart.

> Discouraging enthusiastic people from hacking kernel when they don't
> have experience and guidance to know if that is really what they want to
> do to solve their problem is a good idea.

Ack.

>...  microkernel based operating systems are *hard* ask RMS about GNU and the guys who tried L4/Gnu)
...
> this giant wart of the Mach microkernel running in the same address
> space as their Monolithic BSD based thing that they call Darwin.
>  It's ugly.

Well said.

The design of L4 is light weight and, from the outside, appears solid.
It only takes into the microkernel {Memory, Threads, IPC, Scheduler} IIRC.
It's ARM and Intel, though only the ARM kernel source was formally
proven... (not the design, but the implementation).

There's a Linux on L4 out there:
<http://os.inf.tu-dresden.de/L4/LinuxOnL4/>

> So this brings us to a slightly different topic, which OS would /you/
> use to hack on if you do want to hack kernel for fun and because you're
> the kind of awesome person who just wants to get in there and do stuff?

- for fun, Inferno or Plan 9.
- for profit, has to be Linux or a variant, for Intel
  For ARM, I'd start with L4...

[delete great rundown on many O/S]

OS161 - hadn't heard of this. You've got very interesting friends!
[Which is important: we become those whom we surround ourselves with,
not that to which me might aspire.]

[deleted good stuff]


> I do not believe that Linus could have hacked on Linux in a
> fundamentally meaningful way as it is today when he started Linux 0.01
> He and all those who went on that ride learned a hell of a lot by doing
> it. Another system *may* be better to hack on while you get as good as
> those guys.

I heard Tridge say something similar: If they were starting the SAMBA
project today, it wouldn't pass muster [or something similar].

Because of all the high-quality, well-governed FOSS projects around, the
bar is set very high for new projects. The price of Success.

You've hit on a fundamental law, I think :-)
[Hal's Law: Care to formulate it for us?]


> IMHO writing your own OS is always, always, always a really, really,
> really good option. I would like to be more emphatic about that so just
> add your own adjectives to taste. ;-)

If you're concerned about Security, you have to write you own compiler
from scratch and probably your own toolchain too. That was Thompson's
Turning Award paper, "Reflections on Trusting Trust", no longer on the
ACM site. [links below]

If you want to have an OS that suits your needs, writing your own is a
good way to go :-) Will result in better design than taking an existing
design and hacking on it... Refactoring is one thing, changing designs
is like renovating: often it's Cheaper/Faster/Better/Quicker to
"knock-down, rebuild"... There's more work in changing the embodiment of
a design that implementing a new design from scratch.

John Lions in the 1980's asked his class a question:

  "In 1995 or 2005, how will new computer languages be received?"

He said that most students presumed that new languages would continue to
appear at the same rate, that a new language would be unexceptional.

John's view was that as languages (& toolchains/environments) matured,
significant new languages (== for O/S, compilers, general use) would
become increasingly rare and the release of anything new would be 'News'.

He got that exactly right.
The "lingua franca" of FOSS is POSIX-C and the GNU toolchain.

Things that we could've foreseen:
 - the collapse of diversity in CPU architectures and hence suppliers
 - the maturation of O/S's in the same way
 - the rise of specialist environments and languages, ie. not systems
 - SQL databases and later text-dbs and very large file collections...


Mobile computing: before iPhone in 2006, gnerally thought to be
small-scale and premium niche market (if you didn't count Symbian).

Android has redefined the marketplace...

The CSRG/Dept 1127 group gave us, 20 yrs apart:
 - Unix (1970)
 - Plan 9 (1990)
 - "go" (2010)

Pike says they have no plans for an O/S...
For these folk to spend a year or more coming up with something brand
new, means a) its going to have an "interesting" design and b) it will
be well designed and implemented...

Hope that ramble was useful in some little way...

cheers
steve


Thompson's paper:

<http://cm.bell-labs.com/who/ken/trust.html>
<http://web.archive.org/web/20040610122523/http://www.acm.org/classics/sep95/>

No longer considered 'classic' by the ACM:
<http://dl.acm.org/classics.cfm?CFID=169959929&CFTOKEN=39992008>

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