Interview with Hansen Hsu, engineer at Apple during transition from OS 9 to OS X | Hacker News Reader

Interview with Hansen Hsu, engineer at Apple during transition from OS 9 to OS X

corecursive.com

103 pointsAustin_Conlon60 comments

Something I learned from interaction with apple engineers at IETF is a weird big/little thing.

Big: they can't speak to some things without legal review because FAANG have IPR. This causes a lot of friction. You may simply never know really why apple dropped ZFS. You can ask over beers. Sometimes hints is as good as it gets.

Little: there might be a team of 4 people on tcp/ip and only 2 of them have something like "commit" rights. You sort of expect its 20 phd and a bank vault of gold, and it's two guys. Smart guys, good guys, but if they both come to IETF then you know the tcp/ip buglist isn't moving and there's a "fall under a bus" risk, England 1966 football squad on one airplane risk..

Apple invents stuff which surfaces later. Appletalk over twisted pair had device discovery almost perfect. Printers shouted "I'm here" and everyone heard. It's taken years to get zeroconf and auto discovery out into the world of gigabit networks.

Apple does things other people don't do. They did some stuff in parallel path fetching, using mobile and WiFi to maintain the upper layer fetch in agile ways which was beautiful. The spec was there.

I kinda still hate OS9 and like OSX because UNIX but I also have gears grinding on the apple filestore and resource/data fork mapping into Unix .dotfiles which seeds were laid in the old OS world.

> Apple invents stuff which surfaces later. Appletalk over twisted pair had device discovery almost perfect. Printers shouted "I'm here" and everyone heard. It's taken years to get zeroconf and auto discovery out into the world of gigabit networks.

In fairness, this is hardly unique... if I had a dollar for every great thing someone got working and then it went nowhere, I could build a company to popularize solutions to all the dumb problems that still persist. Capability-based security, secure X11, ZFS, fully inspect/edit-able environments like smalltalk, 90% of everything Oberon was doing, graphical programming like hypercard, smartwatches as good as Pebble, Ada-level language safety, BeOS filesystem metadata... we barely need to invent anything new for the future, we could progress for ages just by mining the past...

Apple still does things that other companies won’t even consider, though. I mean look at the M1 and Rosetta 2. Nobody knew what their plans for ARM were, and out of the gate they had a processor that was not only faster than anything Intel or AMD could provide, but also a system for translating x86 applications such that they ran with comparable performance on ARM. Even Microsoft didn’t have that on the Surface Pro X!

I think it’s easy to forget because of how secretive they are, but it’s pretty clear from their output that Apple has one of the best software engineering teams in the world, if not the absolute best.

i think this is pretty misleading. apple silicon started in 2010, it was a decade in the making. how can this be reconciled with "nobody knew what their plans for ARM were"

In hindsight it’s easy to say that, but would you have guessed in advance that they would succeed like they have? In the span of a year they have made x86-based products look obsolete.

The jury is still out on Apple Silicon. Initial reception was incredibly positive but let's let it all marinate and see what happens.

One of the things I think Apple does best is reads the tea leaves on where things are headed, takes their time to develop a solid product but a couple years after they launch, are met with stiff competition on what is considered "best".

> The jury is still out on Apple Silicon.

In no sense is the jury still out. The x86 hegemony on laptops and desktops is dead.

no doubt the performance is impressive. it just sounded like you thought apple developed m1 faster than the process actually took. a very minor quibble

My biggest worry for Apple Silicon was that ARM’s obviously only suited for mobile devices, so it’d only really land in the Air, maybe mb13 - with the concern that this would cause fracturing where “pro” apps were intel only and armbook turned into an AppStore full of flatulent soundboards.

ARM seemed obvious but their results certainly didn’t.

>but would you have guessed in advance that they would succeed like they have?

Not guessed but projected. I was called an idiot, or son of bitch liar when I suggested its Geekbench score along with all other performance metric it was faster with A12. Only to be met with Intel Fan boys saying Geekbench is not reliable because of a Linus' comment ( That was on Geekbench 3 in case you are wondering, he is fine with GB4 ).

x86-based products look obsolete because Intel is now one and half node behind, and nearly 2 generation ( or three years ) of uArch behind their original schedule. And TSMC will officially leap ahead of Intel no later than 2020. I make that projection in 2014. That was before 99% of the internet even knew what TSMC was.

From 2011 to 2019. Dumb, stupid, idiot, Intel will get their 10nm done. Intel will have capacity expansion. You dont think the analyst would notice their lack of CapEx? Those were the words of many including senior analyst, two ex Intel engineers, current senior editor. It was only starting in 2020 everything was proven to be correct. ( And they shall remain nameless. But the records are still on certain forums and twitter )

It was painfully obvious. And yet somehow most want to believe the mainstream media narrative rather than actually think and analyse it themselves.

I'm not even the smartest person in my family and I figured out where Apple was going before they even announced the M1, like a year or more before... I am sure that many here on HN were well ahead of me.

Which is an understatement haha. Apple’s Rosetta 2 runs intel applications faster than it used to run natively on intel chips.

That's a great example - because they specifically built an Intel-compatible TSO memory model into the M1 CPUs that can be toggled at runtime to avoid a ton of fencing (and at about 70% the performance of ARM64 natively). This let Apple's Intel emulation on ARM run way faster than Microsoft's. They also added hardware support for ObjC/Swift reference counting. These are things no other vendor on earth would do.

> They also added hardware support for ObjC/Swift reference counting.

Not true. It just has fast atomics because it’s a single SoC.

Ah yes, it looks like it's just super-fast/almost-free uncontended atomic operations.

Chip support for reference counting goes back to 1960's microcoded CPUs, plenty of other vendors have done it.

Indeed, and I was also wrong about that, to be clear. I did some research based on your comment, it's really cool too see. I'm a huge fan of old CPU architecture.

> These are things no other vendor on earth would do

I really wonder why. Microsoft has some great engineers. I would assume some of the compiler or kernel people regularly meet up with people from Intel or Qualcomm and talk about future development.

It's not really the same, but when I was working in particle physics I remember some Intel engineers really trying hard to get into contact with researchers, and trying to figure out what we need, because they wanted to sell their Xeon Phi / Knights Landing cards to us (basically GPUs for general purpose computing based on X86, now discontinued).

Every time I'm doing a lift and shift, I'm glad I don't have to move an OS around on different chip architectures, maintaining performance speed. PowerPc to Intel, and now Intel to Arm. That's nuts.

>we could progress for ages just by mining the past...

How much of that progress would be hindered by the mines being patent incumbered?

A lot of this work, such as work done on Smalltalk, is old enough to where any patents on it would be expired. There's a treasure trove of technologies invented in the 1970's, 1980's, and 1990's that haven't been fully exploited. For example, there are some regular posters on Hacker News that rant and rave about the Lisp machine development environments of the 1980's, some going as far as to say these environments were the most productive environments they've worked in, despite all the advances in editors, IDEs, compilers, and other tools that happened since the 1980's.

It varies. As sibling comments, some of it is so (depressingly) old that patents don't matter, and a surprising amount was released as FOSS (the best thing Sun ever did for its legacy was OpenSolaris). Other could probably be safely recreated independently; things like Pebble where it wasn't even novel tech, just a well polished combination of parts that nobody seems to want to bother with, or things like capability-based security where the idea is in the open and all that's needed is for people to put in the work and for it to actually catch on.

But yes, some gems are lost to copyright and patents, or at least much impeded by them.

The general issue here is that compatibility and vendor independence are both highly desirable features in the market, which tends to favor lowest-common-denominator technology standards, since all of the vendors want to maintain their competitive advantage. This goes both ways: keeping the good stuff proprietary and locked in, and refusing to buy into attempts at open standards offered by a competitor.

"England 1966 football squad on one airplane risk..."

I don't know for sure given the context but I presume you are actually referring to the 1958 Munich Air Disaster which killed numerous members of the famous 'Busby Babes' Manchester United football team?[1]

1. https://en.wikipedia.org/wiki/Munich_air_disaster

Yea. Misrememebered the year, the squad. Good pickup.

That seems surprisingly typical, the TCP/IP team at Nokia used to be similarly tiny back in the 00s when I was working there.

I've also been under the impression the VC++ standard library team used to pretty much be STL (Stephan T. Lavavej, aptly named) and maybe a summer intern if the budget was flush.

If anything, this really makes me question why a typical "snapchat, but for parking spots"-startup has an engineering team in the triple digits. Maybe greenfield development takes a larger team?

> You may simply never know really why apple dropped ZFS.

We know because one of the Sun ZFS co-creators (Bonwick) gave the reason on the zfs-discuss list at the time:

* https://arstechnica.com/gadgets/2009/10/apple-abandons-zfs-o...

[But I take your general point.]

I'm the host. AMA.

Hansen's research into developer cultures is super interesting.

Here is a story of his time at Apple I can identify with:

   It’s like being a cast member at Disneyland, right? If you actually see the back lot of Disneyland, the magic is pulled away, right? It’s not the same, right? You don’t always want to know how the sausage is made. Being smack in the middle like OS 9 at a time when the winds were clearly shifting in OS X’s direction, it was like, the politics of the higher ups, it was definitely being felt.

   I was looking on the file system team and three months in, they said, “Okay, well, we’re not doing any new features in the file system. We’re going to reassign you to help them work on the multiprocessing API’s with this other guy”

   I was doing some unit testing for that for like a couple of months.

   Then, it was announced, “Oh, we’re not doing any new features for that either.” Okay, so then now what I’m going to do?

   Then, my boss assigned me to write this app showing these two bars for the dual processors. That didn’t go anywhere. He kept telling me, “No. Keep working on it. This is not busy work. This is not busy work.”

   It turned out to be busy work.

---

Edit: bedtime, but will check-in and answer questions in the morning if anyone has any. (Feedback and Guest suggestions welcome)

I listened this morning. Great interview, thank-you. Refreshing to hear someone with both an honest appraisal of their skill set (although perhaps a little too hard on himself) and also a willingness to make drastic changes for a happier life rather than just playing it safe.

Thanks for listening!

I found his take on his skillset tragic. It's a downside of working with the best of the best, that you feel your own inadequacies very directly.

Perhaps if I had started out at a place like the OS team at Apple right out of school I would have left software engineering behind as well.

Or perhaps you would have found out that the best of the best are also winging it like the rest of us.

Just want to say I've recently started listening, and I really love the podcast. The last few interviews have been fascinating and really well done!

Thanks! I've been learning as I go and putting more effort into it and I'm glad the effort is paying dividends.

Adam, I've learnt so much from your podcasts. Amaaazing work. Yours is the only podcast I listen to when I have time and I'm beyond impressed by the quality of it.

Thank you from a long time Fan

Thanks for listening! Spread the word :)

Just wanted to express my thanks to you for your podcast. Fascinating, educational, inspiring and sometimes a little tragic. Very cool!

Thanks for listening! It's a hobby project that is slowly taking over a lot of my free time but I really enjoy it.

The interviews are quality stuff, and your accent and demeanour is inviting to listen to. Looking forward to the next one!

Thanks for listening!

> The interviews are quality stuff, and your accent and demeanour is inviting to listen to.

It's funny to hear comments on my accent because I think it's relatively uninteresting, but I guess everyone innately thinks only others can have an accent. Anyhow, thank you!

Thank you so much for posting a transcript.

I ignore so many podcasts with clearly brilliant, interesting, valuable content in them because I just can't tolerate the tedium of having to listen to audio.

Thanks!

It's surprisingly hard to get good technical transcriptions done.

I have been amazed by otter.ai and like autotranscribe. I have to do the corrections from otter on our conferences, with a variety of English as a second language and idiomatic English accents and it's not perfect, but it's good. The models are improving and it feels like the science behind their methodology, how it learns a new ontology is pretty solid (I believe the corrections we do inform the next run in the same domain of discourse)

We used to use court recorders and do the same polish on their product. Automated is worse but not by as much as people might think.

Very cool, I have not tried otter.ai

What I'm doing is preparing a glossary of all the tech terms and what they sound like and then using rev.com human transcription server with provided glossary and then doing a read through and finding any issues.

That's not far off what we did with the court reporter transcription service staff for live transcripts at meetings. Give them a list of acronyms, jargon, names. After the first two or three meetings they had it down pat.

I've heard podcasters rave about descript for transcription and editing (podcast audio changes as you edit transcribed text), you might want to check it out if you haven't already.

I'm kinda curious what the direction they intended to go in to add more modern operating system features to OS 9.

Is there a paper design for a preemptive multitasking OS 9 that someone thought about?

There was an entire promised-for-years Mac OS 8 codenamed Copland that was to, among other things, add preemptive multitasking and process memory protection to the "classic" Mac OS. That project was a disaster on the order of Apple deciding it needed to cancel it and start over working from an OS it would acquire (BeOS and NeXTstep being the big publicly known candidates with the latter being what they went with). A few things from Copland appeared to survive into what became the much less ambitious actual Mac OS 8 and Mac OS 9. Namely the full-filesystem content indexing system, the platinum UI, and a kind of intermediate "nanokernel" that offered some improvements to multitasking, like not locking up the whole system when the mouse button was held down and allowing other stuff to happen while intensive disk/peripheral IO were happening. From memory I think it make have also added some basic improvements to memory protection, but by way of padding around the address spaces that applications had allocated to them rather than real memory protection. I can't quite remember anymore. I was a teenager at the time.

Just for historical interest I wonder if it would be possible for some Copland, Gershwin, or Pink docs to leak.

No real need for Copland — there’s an entire book about it — search for Mac OS 8 by Tony Francis.

Thank you! I had no idea this book existed. To save others from searching: https://archive.org/details/mac_Mac_OS_8_Revealed_1996_raw-p...

Gershwin was always vaporware. As far as I know, no real code was written; it was all planning.

Pink did exist in various forms, and it would be fascinating to have that material available, though.

ICU (https://icu.unicode.org) started as a Pink/Taligent project.

There is a Taligent (Pink) book whose first chapters are available online.

http://www.wildcrest.com/Potel/Portfolio/InsideTaligentTechn...

It's a crazy little thing to remember, but I used to have not one but two demo CD's for Copland. For some reason I even remember when I threw them out...

> There was an entire promised-for-years Mac OS 8 codenamed Copland that was to,

It was codenamed Maxwell, Copland was the marketing name.

Since applications recompiled against the Carbon framework used the framework to access what was traditionally global state on the classic Mac OS, it could have just been to make Carbon applications preemptive and run in their own protected address spaces. The nanokernel already supported that; MPTasks were preemptive since their introduction with the Multiprocessor API.

Not a chance.

I don’t know specifically what this person was told, but there was low confidence before the turn of the century on the classic Mac OS side that the NeXT people would developer a consumer-grade OS capable of replacing classic Mac OS[footnote]. So there was ongoing speculative development on various things.

However, by Mac OS 9, Mac OS X was clearly where all of Apple’s resources would go, whether it was any good or not. Most classic work at that point moved to building bridges to OS X via Carbon. Mac OS 8.5 was the last chance to build major new features into classic Mac OS. None of the ongoing work then or later was on the scale of Copland or putting a new kernel under the OS or anything of that sort. Mac OS 9 was known to be a dead end internally, and nothing like that would have been funded.

Footnote: This skepticism was well-placed: arguably it didn’t actually happen until Mac OS X 10.4. (You can argue that 10.3 was usable — or say “but UNIX” — but I don’t want to hear from you unless you actually tried to support that version on the machines of your less tech-savvy family members.)

That mirrors what Hansen says in the interview. That the classic mac side had low confidence in the OS X team right up until the end.

What is your connection to this time at Apple? It sounds like you might have been involved.

I always like the covers of Big Nerd Ranch books. I can’t quite describe it but there’s something very aesthetically pleasing about them which stood out from all the other tech books at the time. It almost made me want to become an iOS developer because it was so cool.

Reply on news.ycombinator.com