Don Melton, former Engineering Director of Internet Technologies at Apple, returns for a special follow-up episode with Guy and Rene to discuss the newly announced Google Blink and Mozilla/Samsung Servo HTML rendering engines, and to tell us what us which new bear he's trying to get dancing.
Show notes
- Blink: A rendering engine for the Chromium project
- Mozilla and Samsung Collaborate on Next Generation Web Browser Engine
- Úll conference
Guests
Hosts
- Guy English of Kicking Bear
- Rene Ritchie of iMore.com
Transcript
Rene Ritchie: The world needs to calm the fuck down a bit, I think. Sorry. [laughs]
Guy English: Alright, this is Guy English.
Rene: This is Rene Ritchie, and welcome to debug. Today we are revisiting Don Melton because the minute after we let him go the last time Google announced Blink, Samsung and Mozilla announced Servo, and the entire world went topsy-turvy. Is that fair Don?
Don Melton: Yeah, to talk about Blink first. By the way, I don't normal comment on Apple's current efforts, policies, and things like that but since Webkit is an open source project, I'll keep my comments narrowed to that. I was surprised it was that particular day from the announcement, but this was not unexpected. Something like Blink, well the name was unexpected, "Blink," who the hell came up with that?
I've really been expecting them to fork for a while. I figured they would fork after we announced Webkit2, so it's not unexpected. They're allowed to fork, Webkit is open source. Essentially, I did the same with KHML AND KGS almost 12 years ago.
It's not that big a deal. To get to it, everybody needs to chill the fuck out, to use the f-bomb again. It doesn't mean the death of Webkit, or the ascendency of Blink, or anything else like that. Some things just got easier and some things got harder for both projects and both teams. I get real annoyed at the press because Blink isn't suddenly more streamlined, since it's left the quote unquote crusty old Webkit.
I can guarantee you code is being jettison from Webkit2, maybe even more so than from Blink, but who knows? It's not that big a deal.
Guy: Do you think that the stated goal was to jettison a bunch of platform support that they don't need and try to clean things up a little bit?
Don: I think that's the stated goal, but in a way it's really about control.
Guy: OK, yeah.
Don: I mean all forks are about control. Doing a big cooperative project like that there's always body checking. [laughs] Especially when you have big companies and big personalities, but it's not really that big a deal. The thing is when you're in the web browser or web content engine business you know everybody after awhile.
I mean I've worked on... well depending on how you count three of these systems, and I know a lot of people, and there's nobody that I don't want to talk to. I mean, I still talk to folks from time to time. I still talk to Brandon Ike on occasion. Mike Shafer even though he's over at Facebook now. I talk to Dean Hasimovich at Microsoft every once in awhile. Hell, he's a Facebook friend.
These things are complicated and I don't want to project something onto the situation that was not there. I don't think anybody is particularly panicked or all that upset on either side. You have to remember that the projects are still more alike than they're different now and they probably will be for awhile.
Rene: Was it a reasonable fear that you know people would wake up and it would be IE 6 all over again and you would have to add special exemptions for Blink, and different code for Chrome, and the web would go back to having isolated islands? I think that was the panic response when the announcement came out.
Don: There's been a panic for awhile about the whole Webkit mono culture thing, and it may be the only good thing that comes out of this in the short term is it calms those people down because you've got two of these things now. I think that was some concern, but let's see what happens. It's too early. Anybody that claims to know what's going to happen here is full if shit. Including me.
[laughter]
Don: The other the thing to keep in mind is that like I said the press that I read about this was really annoying me because you know it's all the, "It's great for Google, it's bad for Apple," kind of thing, and that's kind of horseshit. It cuts both ways. Google is not going to have the crew that started Webkit.
They don't have Maciej Stachowiak, David Hyatt or Darin Adler, that are still working on Webkit. They don't have Adele Peterson, Sam Weinig or Jeff Garret. Those are kinds of things that they miss, too. They don't have the other resources. Apple's not going to have, obviously, some of their people and some of the other things, but it's not death. It's OK.
Guy: You feel it got spun into being a massive corporate kind of battle...
Don: Yeah, it's not really that big a deal. It's big corporations, and I think when you work on Webkit, you try to ignore that as much as possible. If you talk to some of the Webkit and Blink people, probably, dealing with W3C and other organization's more of a hassle that that, that's always been a headache over the years.
Rene: You're basically telling the kids that mommy and daddy won't live together anymore, but everything's still going to be OK?
Don: The thing is they're still going to have to live together. If you think that if Apple does a security patch in a piece of code that it needs to be shared, fixes some bug. You don't think Google is not going to go over and figure out what the div is patch and put that in. They're going to have to do that kind of work. They're going to have to work together and talk to each other still for that kind of thing, and it goes both ways.
If Google comes up with something in a piece of shared code they used to have, and Apple thinks that would be useful, the Apple guys...It's not just the Apple guys. There are lots of other people besides Apple working on Webkit, and there are other people besides Google working on Blink. Maybe, this is something that doesn't completely last.
There have been times when projects have forked and they've come back together. Who knows. One of the more interesting announcements was Servo. I wasn't quite expecting that.
Rene: Apparently, from the rumors at least, that was deliberately done right in front of Blink just to get out ahead of them. It was interesting.
Don: [laughs] If [indecipherable 7:55] , I would have done that...
[laughter]
Don: ...to get everybody distracted. They needed some press there. It's a...
[crosstalk]
Guy: What do we know about Servo? It's a whole new thing.
Don: Nothing. It that they're wanting to go out and rewrite their engine, and use the new language that they've been working on for several years called Rust to rewrite the engine. They're not rewriting everything in Rust. They're rewriting the core. They're essentially rewriting large parts of Gecko in Rust.
I don't think they're rewriting everything. I think it would probably be crazy to rewrite everything. I'm not sure. One of the reasons they said they needed to use Rust was for performance. I'm not quite buying that because C++ seems to have been working fine for Webkit and the LLVM Teams for years. I'm not buying that.
Guy: The other one was they said security, too, right?
Don: Yeah. I don't know why the language really...You can write secure code in COBOL.
Guy: [laughs] I think it has affordances that makes it easier to avoid buffer overruns and the basic stuff.
Don: That kind of stuff, yeah. We investigated things like that at Apple. You have to be very careful with that, because you can also introduce tremendous performance penalties if you try to do it in a generalized way in places where you don't actually need it. You want to focus on where the real problems are, so you have to be careful with that.
Rewriting an engine from scratch is not always wise. When we started Safari in Webkit, I didn't want to rewrite the engine from scratch. I knew that they would fire me before I was able to get something done. That's why I used something off the shelf. We eventually rewrote it. People don't realize is that WebKit has being rewritten multiple times. It's always rewritten, refactored, [laughs] and redone.
It's a subtle thing that the WebKit team has always been doing. That's why it's so up-to-date and cool, because it's always being reengineered. But it's done in small chunks, carefully.
Guy: I does seem a little foolhardy to just publicly say that you're going to be writing an engine with a new language. It's biting off a lot to chew.
Don: Props to them for having the stones to do it, if they can pull it off.
Rene: Yeah. I think the Samsung angle is really interesting here too, because they do Android, but they used to do Bada, now they're doing Tizen on the side. They have the Android browser, and the Chrome browser, but now they're doing Servo on the side.
Don: Samsung, I cannot figure out. It seems to me that there's somebody with a magic eight ball over there, just rotating it and trying to figure out technology choices, at least for software. Software, I can't figure out what the hell they're doing.
Guy: Yeah, I don't understand them at all. They're making money, so [indecipherable 11:32] , but I still don't understand what their thinking is.
Don: In the mobile space, it's basically the two people making money on hardware are Apple, who makes the most, and then Samsung, and nobody else [laughs] makes really any money these days to speak of. Hey, maybe they're up to something...
Guy: So did Gecko need it? Sorry, go ahead.
Don: I'm sorry, maybe they'll pull this off, who knows. Best of luck to them. I know some of the people over there working on that. They're good people, they're smart people.
Guy: That's certainly an interesting direction to go in, rather than just grabbing off-the-shelf stuff, trying to actually roll your own. It's an interesting play for them.
Don: Yeah. Being a Web engine geek, I'm sure I'll download it, try to compile it, and stuff like that, like I do occasionally when the fit hits me for other things and see what's happening. You know running WebKit nightlies and stuff, I've done that for years to keep appraised of what's going on, and to nag people I know about some bug or something else that I've had.
I do that for lots of other projects, just hobbies, but it goes back to having the superpowers. As a geek, you can do that stuff. I do not recommend this for other people. [laughs]
Guy: The nightlies aren't for everybody?
Don: No, WebKit nightlies are very, very stable, but I don't recommend them for everybody. I think a lot of people who run them are actually not the developers. The code developers there are website developers, content developers, who run the nightlies. I think that's actually a really good thing, because that's especially who you want feedback from.
Guy: Yeah, good valid testing.
Don: You need to listen to those people.
Guy: Is that true for Servo? Is this Servo public at all yet or is it just a name?
Don: I have no idea, I haven't looked yet. I'm waiting until I see something on Hacker News, and like, "Oh, OK. I'll go..."
Guy: Yeah, exactly. It seem like...
Don: That's what everybody does, right?
[laughter]
Don: Anyway, the sure thing is, everybody calm down about WebKit and Blink and let the teams do their jobs, Servo is interesting, and best of luck with that.
Guy: [laughs]
Don: Yeah, they're all going to work. There's not a...
Guy: I don't think we're going to get back to the time where the Web is so bifurcated between totally different engines. I don't think it's in anybody's best interesting.
Don: It's not the engines we should be worrying about with the Web. It's co-opting the Web in other ways, it's what we should be worrying about. If governments take over essential services and technologies, that's when you worry, because governments always know what they're doing. That's the kind of crap I worry about.
But this...these little pissing contests between engines and other stuff like that, or supposed pissing contests, because there's not really that kind of thing going on. For example, I know some of the people in the Blink team. Some of those guys, I hired, either at Netscape, at least one at Apple, one over there. These are nice people. They're not jerks...
Guy: Yeah. I don't think this needs to be a consumer level conflict, necessarily. It's just the way the code is going, and it makes sense to split it down the middle and go in different directions.
Don: Yeah, we'll see what they come up with, and yeah, whatever.
[crosstalk]
Guy: I love that this is the big news and you're just bored by it.
Don: No. As you said, that was several weeks ago. But my attention [laughs] span is very short, anyway.
Guy: It should be, because it's certainly not now.
Don: The thing to do is that a year from now I have a retrospective and, say, we still don't know [indecipherable 16:38] .
Guy: Yeah, and even a year from now, I can't see, anything huge. Like what? Like and extra [indecipherable 16:48] .
Don: I think a year from now...I think the projects are still going to be very similar. It's not that big a deal.
Guy: It seems like a huge codebase and it would take a long time to go in a radically different direction. Not only that, but the goal is to render everything the same anyway, so from a user's perspective, I don't see this being such a big deal.
Don: No, from the user's perspective it could be an improvement because of competition. Look at what happened when we came out with WebKit and Safari. I talked about this during my talk at Google, how we made Safari fast. We started the second browser war, it was a performance war. That was just better for everybody.
Guy: Yeah. When you're building this, you're making decisions. You're like, "This is the way we're going to go," and any one of those decisions might have gone either way. With WebKit and Blink, you get a bit of an A/B test. You can try different approaches.
Don: Right, and there's competition among teams. There certainly always has been. Remember the ACID test, the silly ACID test, that even Hicks says that they're silly. There's competitions between all the different browser teams to try to get the best scores on that. Some of that was just nonsensical, but in other ways, it improved everybody's engine. It's a shame that there's not going to be an Opera engine anymore.
Guy: Yeah, I forgot about that fellow. Poor Opera, man. What happened there? They decided to go with Blink?
Rene: Ice and Blink.
Guy: Well, they've decided to go with Chromium. What I get is they're really choosing is Chromium because they needed a GUI because they were not only letting go of members of the core team, they were letting go of members of UI team and stuff like that. They needed a project that was a browser too.
They'll naturally follow the Blink path rather than the straight WebKit path because they need GUI. I mean, Apple does not open source Safari.
Guy: That's a shame. I know they had weird, spotty support at times, but I like having that sort of biodiversity.
Don: Oh yeah. You know I'm a browser geek, so I have every browser ever made. I usually have...Let me go into Launchpad here. On my top row in Launchpad, I've got Safari, Firefox, Chrome, and Opera right up there.
Then I got VMware, so I can run, not VMware, VirtualBox, so I can run multiple versions of Internet Explorer. I got a simulator around here somewhere, so I can run the older versions of stuff just when I get nostalgic.
Guy: You have some browser cred is what you're trying to say.
Don: That's like being a browser fanboy, that doesn't mean cred. But a lot of content developers have that same thing. I've had that for years for testing purposes and stuff.
Guy: You mentioned breifly, but you were in Dublin for the Úll conference recently. You've got to talk about making Safari faster.
Don: Actually, it's pronounced "ul." Not "yul," "ul." I got dope slapped for that a couple of times at Úll conference. It was the best conference ever. Let me tell you, it was fantastic. The hosts, Paul Campbell and Dermot Daly, are just wonderful people.
They put together this conference that's not only wonderful for all the speakers but wonderful for all the attendees. If I was a sponsor of the conference, I think for the sponsors too. It was fantastic to go to Dublin, I'd never been to Dublin, and to meet all those wonderful people and listen to just some amazing folks.
I met Matt Gemmell and his silky smooth Scottish voice. I told Matt that I wish I could bottle that voice and take it back to America. I got to meet Gruber finally in person, he's hysterical, along with my old friend Michael Lopp, and Horace Dediu, and Michael Johnson, Dr. Wave, from Pixar. I got to have dinner with them and Neven Mrgan.
Guy: Neven's great too.
Don: Horace is a brilliant man. We were in the...I think it was one of the breaks in the afternoon. In this session, we were all in this pub. I think it was one of the pub sessions that was sponsored by either Dropbox or Github.
We're standing there next to the bar interfering with other people's ability to get Guinness [indecipherable 22:31] . Horace would say things and would talk about the industry and say, "Anyway, that's my theory. What do you think Don?" I was getting the point, and I was just joking with him and I was saying, "Damn it, Horace! You're right once again." At least in my opinion, he is a brilliant guy.
Of course, Michael Johnson, he's got so many stories from Pixar. He and I had probably, between the two of us, some of the best Steve Jobs stories there. We actually were to of the people, as we were both joking, we were two of the people who, Steve actually knew our names which was a good thing and a bad thing.
[laughter]
Don: Other people there, Jamiee Newberry from Black Pixel, she was great. Charles Perry, a guy I never heard of from the company called Leaf Hut Software. He did this talk on accessibility. Oh my God, It's the best talk on accessibility I've ever heard.
Guy: Yeah, I think that's an overlooked technology at times. I'd like more attention payed to that.
Don: Of course, Jim Dalrymple was there. He talked about, I think in his podcast last week, about his "panel discussion" he had with Dave Wiskus and Kyle Neath which was not a panel discussion at all. It was a performance.
They went out and set Dave and Kyle and one of the other people, I forget who it was, were introduced by, I think it was Durment, sat on these stools as if they were going to do a panel discussion. Then they said, "Here's Jim Dalrymple," and he walks out with a guitar. The panel was actually a band.
They did 12 cover tunes, all the original songs of course which are in my iTunes playlist, I don't know about your...classic kind of rock, Led Zep, AC/DC, Nirvana, and stuff like that. It was great stuff. Then an original composition by Jim, that was fantastic.
Guy: Sounds like it was a blast.
Don: Yeah, the people there were great. I got to meet the Lord Mayor of Dublin. He's hysterical. I had to practice pronouncing his name, spelled N-A-O-I-S-E. I guess it's pronounced "Neesha." My new friend, Oisín Hurley, he was one of the sponsors and his buddy, Barry Scott, from Converser. Oisín's name is spelled O-I-S-I-N. Gaelic, it's hard.
[laughter]
Guy: It's not even a word. It's not a name? It's not even a word.
Don: What you learn to do is you have another Guinness. Let me tell you, if you go to Dublin, if you go to Ireland, you need to have a Guinness because when I went to Dublin and I drank my first Guinness, and not my only Guinness let me tell you, it made every Guinness I've had in the States taste like piss. You know what they say, "It doesn't travel well," and they're right.
My wife went with me. We went to St. James's Gate Brewery for the tour which was fantastic and had one each poured for us up in the Gravity Bar up on the, I don't know, seventh or eighth story, where you can overlook Dublin, fantastic view. It was like this marvelous beer milkshake. Oh, my God!
Guy: [laughs] That sounds great. I got to go there. I'll try to go next year.
[crosstalk]
Guy: Don't worry. They'll put in a good word for you.
[laughter]
Don: Paul Derman! I love you guys. No, seriously, they're really fantastic.
Guy: You gave a talk about speeding up Safari. Do you want us the gist of it?
Don: It was a bit of history about how we made Safari fast. One of my jokes in the talk was, we made it fast by making it slow first. [laughs] Fortunately too slow. Why I wanted to do the talk is I wanted to delve into a bit of history, and inside baseball for people, because they seemed to enjoy that, and things that they may not have heard, that nobody had ever heard, as far as I know, outside of the fruit company.
Outside of my little sessions, I would do at Apple in my department...The new people in the department would sometimes say, "Gramps, tell us a story. Something about back when you and Al Gore invented the Internet."
Guy: You'd sit around the campfire in the office?
Don: Yeah, pretty much. Around the couches and stuff like that. I would tell stories, usually with Darin Adler hanging around too because Derin's got...Hell, he's got even more stories than I do in a way because he was back at Apple back in the late '80s and early '90s. He and I would have dueling bullshit going on sometimes. That was a lot of fun.
We, as you well know from talking to me, he and I could both talk for hours, so a lot of fun. The new folks would actually listen and were semi-respectful. Hopefully, they'll learn something from those talks. I'm hoping they make a lot of stories of their own now. That's what they're doing.
Guy: I'm sure that's happening. It's the way things go, right?
Don: Yeah.
Guy: What was the gist? What's the take away from your talk?
Don: Well, the gist was that...What the hell? I had my speech laying here. I'll just get out my notes. The gist of it was, I asked, at the end after I told the background story was, "What do you want to learn from this?" It's real simple principles that a lot of people know is you set the bar high and performance. You don't optimize ahead of time. You measure first.
This is something people always do wrong. You focus on the bottlenecks, and you just lather, rinse, repeat that. You make sure over time you add metrics. You never ever regress, ever, never. Did I say never? You never ever...
Guy: I think that's the big one.
Don: The other one is you make it your religion. Dante's sixth, not the seventh, circle of hell, it's good to be precise, has a place for people who invent their own religion. I'll probably be there right next to L. Ron Hubbard one day.
Guy: [laughs]
Don: I told a thing at the conference. I said, "Some teams out there like to have a performance month at the end of their projects." After they have an 18-month project and they have a performance month where they focus on performance before they ship, and we used to joke on the Safari team, we have perform months too, 12 times a year.
Guy: [laughs]
Don: Either you make it your religion, and you get serious about it, or you're not really focused on performance.
Guy: Yeah. When I worked on games, obviously performance is an issue, and so often, before some big milestone, there would just be a giant push to try to get everything performing well. It just felt like exactly the wrong thing to be doing. We should be more conscientiously keeping the frame rates up and keeping the times down.
Don: Yeah. [indecipherable 31:29] all the time.
Guy: Throughout the entire process.
Don: Yeah, yeah, that's what we learned. That's what the object lesson from the...The joke I made, it's how did we make Safari fast, well we made it really slow first. It was my fault. We took our eye off the ball. I was so focused in the beginning of the project, just getting that bear to dance that I was unaware that it was shuffling across stage, not dancing. We fixed that.
Guy: OK. [laughs] One interesting thing about Web engines is that the content isn't under your control.
Don: Oh. Interesting is not that's the word that I used for that.
[laughter]
Guy: What's your word, Don?
Don: That's like the Chinese [indecipherable 32:18] we live in interesting times.
Guy: [laughs] Exactly. What's your word? You can be as impolite as you like.
Don: O God, that would take more that the [indecipherable 32:33] .
Guy: [laughs] It's difficult to make something perform when you don't control the input, or you have no hope of controlling the input at all.
Don: Right. You have to realize that you have to approach a Web engine the way you would approach a operating system. It's almost as complex. Very, very close. People will do crazy-ass things with your APIs. You have to keep that in mind. That's why, when I said Webkit nightlies, I'm always delighted when I hear content developers are out there using it. I was like, "Yes! Yes! Please do that!"
Because if you notice something stupid in terms of capabilities, breakage, or, more importantly, performance on your site, we always encourage a lot of the big JavaScript framework folks, "Please use the WebKit nightlies, and tell us if you notice something going south right away," because one, we'll fix it, and two, we'll figure out a way to turn that into a test, another metric, because a lot of those systems are so complex they're very hard to test.
Guy: Was that something new that you...When you were at Netscape, did you guys do a bunch of tests all the time? Did you have a test suite and did you do the time test suite, the similar stuff that you do in Safari?
Don: It was not as rigorous back then as I'm sure the Mozilla team is doing now. They're much more rigorous now. Because after WebKit debuted and Safari really shot up there in terms of performance compared to other browsers and people were publishing stats on that, the Mozilla team had their "come to Jesus" moment and they really got serious about performance, too.
They adopted a lot of the same techniques and they developed other things. Especially the Mozilla conformance test, they're open-source, so everybody uses those. Some of the ones that we have, they use, because they're open-source. They do that now, but back in the old days, we didn't really have criteria before shipment, we didn't have policies during development that prevented regressions. We were not as focused on that.
Guy: How does that work at a mechanical level? There's a check-in, then there's an automated test that runs, and if the timing is slower, then the check-in is just rejected, somebody gets an angry email, or what?
Don: It's usually an angry email and then a club. [laughs] In the beginning, what I was talking about, my talk, when we discovered the sloth and stuff, we didn't have the automated test on Safari in the beginning. We had a testing harness that Ken Kocienda wrote, God bless him, and that we were able to use.
But it was very hard to get consistent results from it, because you're testing the network, the IO, and other things. Believe it or not, I was one of the few people on the team who could actually run the damn test and get consistent results. I used to aggravate the engineers.
Guy: [laughs]
Don: Being able to do that calls for this anal retentive psychosis.
Guy: [laughs]
Don: That's just perfect for me. In another life, I was a QA engineer. I run the tests, and if I detected we were slower, I closed the tree. That was the beginning of my policy, that policy that I pulled out of my hiney. Boy, talk about making yourself popular on your team doing that!
Guy: [laughs] Let's say you'd literally lock down any other commit until the speed was up?
Don: The engineers, at first, were like, "Why are you locking everybody out?" I was like, "Prove to me that it was just one check-in that's the failure. Unless we know what the problem is, I don't want anybody adding to the noise. I don't want to give up any gains." Why would you give up a gain? Never regress.
The thing is, with a no regressions policy...By the way, the engineers balked at first, but they very quickly, to their credit, the team, totally got it. They're carrying on in my place now. It's jihad now over there. They totally get it. The thing that we found out from the no regressions policy is, even if you're not focused on performance and you're just checking, making check-ins on other things, but you never regress performance, dumb luck...
Guy: [laughs]
Don: ...will make you faster. Entropy will make you faster. You're going to get gains not even trying. Why would you ever regress? That's crazy. Don't give up ground on good fortune. You're winning the lottery there. Maybe one percent, but one percent is one percent. If you could measure it and repeat it, well, ka-ching!
That's money in the bank. You certainly never want to give up gains on hard work. That's just crazy.
Guy: How do you balance that with...Let's say there's a certain CSS feature that you need to implement, but...
Don: That's a story in my talk right there. That's a great example. When Dave Hyatt, the brilliant Dave Hyatt, shortly after he joined the team, we noticed that...He noticed because he's much smarter than the rest of us, and he was the first person on the team that really allowed us to actually spank KHTML, because I had the rest of the engineers focused on making everything around the engine actually work until they got enough domain knowledge to go in and actually change things.
But Dave had been working on Web engines at Mozilla for a while, so he had the experience. He came in and, first things he started on, because he joined the project a year in, was that KHTML was really awful at DOM whitespace handling at the time. This would mean you would get an incorrect DOM being created, and it was causing all sorts of compatibility problems.
Dave worked on this huge patch for over a week, and we really needed this correctness improvement. He told me he was working on this and I thought it was a great idea. He came to me and said, "OK, the patch is ready." I said, "OK, what's the performance impact? How did you test?"
We put it on the scope, and it was eight percent slower. [laughs] I was like, "We really need this feature, Dave, but you can't check it in." [laughs] He was like, "But it's doing so much more work!" because it was doing a lot more measurements and stuff like that, and, "It has more features."
I would hear that thing from people over the years, and I was like, "Nope. Find a way to make it faster." He grumbled at first, but he went away for a few days and he came back with another version of it that was one percent faster than what was in the tree. He made a nine-percent improvement and posted on the line. Not only do we get the new feature, but we get a one-percent performance improvement.
That's what you do. You never regress. When I hear about people that are, "Well, it's doing all this extra stuff..." Now, you have to be very, very careful about what your metrics are, what your benchmarks are, upfront.
Guy: I was just going to ask that.
Don: Yeah. You don't want to bite yourself in the ass later on. Engineers have learned showing me demos of little things that they're working on at that time, not just showing me something that's really performing because it's not using real data or not connecting over the network, not a simulation, because if they show me the real thing after that and it's slower, that, I don't like it. Don't show me that's not going to be the real behavior, because that's going to make me angry.
Guy: [laughs] Yeah, I think that's a good point about the metrics. If you're not measuring the right thing, then this Middle Ages fervor to meet the metrics is just going to end up being misguided. I think that's probably the key is trying to dissect and figure out exactly what you want to measure and what you want to stick to.
Don: It's really hard. It took us a while the get the hang of that on Safari and Webkit, it really did. We had too many simplistic metrics in the beginning. These benchmarks are really hard, especially when you're dealing with live content, and making this stuff consistent. You have to deal with static pages, and then you have to simulate live connections, in other ways, it's maddening. But there are smart people working on this, much smarter than I am.
Guy: So there's hope. [laughs]
Don: Yeah, there's hope. The thing that I interjected in the process was anal retentiveness and a willingness to be an asshole, because that's what you have to be. If you're going to lead a project, you have to say, "No, we're going to do this and you have to be willing to be unpopular."
It's tough work, but in the end the engineers work is much harder. They were the ones doing the real heavy lifting. I just got to sit back and be a jerk.
Guy: [laughs] Cash a paycheck.
Don: Yeah, I'm sure they had a [indecipherable 43:59] . Obviously, I did more than that.
Guy: Of course, yeah.You haven't been writing. Last time we chatted, you said you were going to be writing, but you've been typing instead.
Don: Well, two things happen. One was the Úll conference. When I first wrote my talk, which was supposed to be for...25 minutes talk, and I wrote a 4,000-plus-word outline, and I just tried to stand and record myself and do the outline. I hit over 90 minutes and I went, "Oh, God! I'll have to stop and cut this," so I cut, cut, cut.
I was actually cutting until the night before Dublin again. [laughs] I cut some more stuff out there to try to fit in into 25 minutes. I was focused on that, and I just exhausted myself in terms of writing with that. But the other thing that happened was our family member, our dog, our little girl, a Labrador retriever, Penny, passed away.
When I say, "passed away," what that means is we had to make a decision, and life was not very pleasant for a while.
Guy: Yeah, that's tough. I've been there myself.
Don: Yeah. I just walked off the end of something, and just didn't want to anything for a while. But I had to get my stuff together and do something for Úll and focus on that. When I got back, [laughs] unfortunately I had to deal with the fact that we had a plumbing disaster in our house, water everywhere, and ruined carpeting, and walls with holes in them, and stuff like that, so I was...
Guy: Oh, that stinks.
Don: Yeah, literally. It did stink.
[laughter]
Don: Plus, we're having to get carpet pads replaced this week and some other stuff done, so we had to do that. The other thing is, I started writing again, but it was not on my website. It was code, stupidly. I don't know why. I just got a hair up my ass and started writing some code.
Guy: You're going to tell us what it is?
Don: Oh, yeah.
Guy: [laughs] You don't have to.
Don: No, no, no. It's fine. I'll probably put it on my git hub project page after a friend or two of mine looks at it and tells me, "Well, this isn't embarrassing, and won't ruin your career, or your street cred."
Guy: [laughs]
Don: But just to explain, it's not a big thing. I'm not trying to sell this. It's just a little utility. I feel embarrassed that it took me a week to write that damn thing. But I haven't been coding, especially...This is written in Objective-C. I hadn't written in Objective-C in a long time. People probably think I write iPhone apps every other day, or something like that. I just don't do that. I'm too lazy for that.
Guy: [laughs]
Don: I stopped my development of Objective-C and Cocoa geekiness when John Sullivan joined the Safari project, because he was so brilliant at it.
Guy: Yeah, that's the thing about being a manager. It's that you stop doing your trade and you start doing a new trade, which is managing people, which is a very different thing.
Don: Yeah. There are managers who can code and still code, but I didn't want to be the kind of manager, because there was so many things I had to deal with on, at first Safari, and WebKit, and then all the other projects I was managing, and then be the asshole that blunders into the tree, stomping around and ruining it for the developers.
As a manager, what part of your job is, as I always say, you stand at the backend of the elephant and you let it shit on you so it doesn't shit on your team. You deal with all that stuff, and you make your...
Guy: [laughs] That's graphic.
Don: Yeah, it's graphic, but it gets the point across. When I would have people in my department who wanted to be managers, who wanted to move into that role, I always gave them the talk, at first, to frighten them. I gave them the "shit's in," I like to call it, which is "Here's the good news. Glad you want to be a manager. Here's what it's really like. That's the poop in-between the layers of tasty bread. Yeah, I think you can do it, be on your way." Anyway, enough fecal humor.
Guy: [laughs]
Don: In this little project, basically, I just had a piece of software that was annoying me for a trivial reason and I decided to do my best at rewriting it. I'm a encoding geek. I like to encode video and audio and test it out, play with stuff. Before the podcast started today, Rene and I were talking about encoding a little bit. I was boring him about it.
Rene: Not boring me at all.
Don: [laughs]
Guy: Do you like the math side of it?
Don: No, not at all. In fact, one of the problems with doing this project was, I forgot...When I started writing it, I was like, "Oh, shit! They told me there was not going to be any math!" No. At least in this code, I like dealing with the whole system, but in terms of encoding itself, I like getting good video quality and good audio quality with the minimum amount of work, and time, and size, and figuring out what the tradeoffs are there.
I've gotten very good at that as a hobby over the years. Trust me, folks, this is something that you'd never want to do. By the way, I always say there's three tiers to consuming video and audio. What I always advise people when they see what I'm doing, "Oh, could I do that?" I always say, "Well, you could, but really, what you should do is, you should go to iTunes Store, or Netflix, or Amazon Prime, or something, and stream stuff and not worry about this crap.
Or if you have Blu-rays or DVDs, what you should do is, you should use a tool like MakeMKV, rip them, and play them back that way. Only an idiot like myself reencodes the Blu-rays and DVDs they have." In fact, as we're having this podcast, I've got a batch script with the Handbreak command line app that's been running for weeks now. Actually, since I was away at Úll, re-encoding my close to 300 titles of Blu-rays, in the background, because I want to see what the results of that are.
Guy: It's a bit of dedication.
Don: No, it's not dedication. This is insanity.
[laughter]
Don: Normal people should not do things like this. It takes a lot of disk space and time, but I'm retired, I'm patient. Anyway, I do this encoding stuff and you have to test it. I'm a command line geek. I obviously like GUI's and stuff. I spend, I swear, the...
There's a few apps I spend most of my time at. There are, Terminal, VBedit, Safari, mail. things like that, but Terminal I spend a lot of time in. Not to disparage my friend [indecipherable 52:31] who's in charge of the finder. I do well, too.
Guy: [laughs]
Don: I spend a lot of time in Terminal. I test stuff with Nplayer. The Nplayer command line utility. It's really good and because you can pass all sorts of different options to it and things like that.
It tends to decode h264 more consistently than actually VLC does or something like that. It has other problems, but anyway there's Nplayer on a Mac can actually put up a window and have it show you video and stuff like that.
It does annoying things, like they put up this beautiful video window and then the bottom corners of the window have turds in them, like white turds. When you go full screen there are these white turds in the corner. It's like, guys how hard is it not to put these white turds in the corner of the window?
Guy: Weird, it's what? Just part of the window chrome?
Don: It's the way they're rendering the open GL later, that they created, into the window. They're screwing up the mask or something.
Guy: That's weird, OK. Don: I'm looking at the code and it's hard to figure out. I thought at first about just going in and debugging it and running a patch. I hate running patched versions of things because then you have to keep running the patch when there are updates, running the patch and stuff like that.
I went, "Well there's this project out there called Inplayer OS10, and Inplayer OS10 Extended, Inplayer X. I think I'll actually all embed Inplayer, how do they do that? I bet I could do that, and write a littler wrapper for that."
Because I didn't like the way that they operated either, you can't operate them from the command line, and they do other annoying things even though they are nice pieces of software. I thought, "How the hell hard was that?" That's hubris and ignorance, once again. It twisted my arm and I'm such a sissy when they gang up on me, and so I just started typing. I had to relearn coco and objective c and stuff. I had this little app, its only about 600 to 750 lines of code. It's a command line app, which wraps Inplayer and dynamically becomes a coco app, which is fun.
Guy: Well that's a bit of a trick, right? Because you got to...?
Don: Yeah, because Nibs is for sissy's, and I'm doing all sorts of things I really didn't use before, core animation, OpenGL, Local event monitoring for the sense, nstask, nsconnections, because I've got to run Inplayer in another process and communicate with it. Having to use grand central dispatch and blocks, you know all the new toys the kids like.
Threaded connections and threaded rendering, full screen shenanigans with nsview and stuff like that. I actually asked a question on Twitter the other night because I got stuck, I got some good help from a friend of mine. It's fun and it works. It took me a while to reverse engineer Inplayer even though I have the source code in front of me. It's huge, it's old, and it's kind of corrupt, but it does work. To their credit it does work very well.
Don: It's almost done, I've got to do a few other things and make the code not look like it sucks and then I'll put it on my git hub page, and I thought, "You know, what I really need is a better player app," and so I may have convinced myself to actually write a real coco application that's a media player.
Guy: That could be good.
Don: Quicktime Player's full screen mode annoys the hell out of me, because it uses Mountain Lion full screen mode. I hate that.
Guy: Yeah, that used to be an awesome app, Quicktime 7. The current Quicktime player basically seems like a wraparound QT kit, effectively, which is fine, but...
Don: It actually is a nice GUI and I'm glad that they did something that a lot of people don't do with apps, they just sliced off an enormous number of features. The problem was, they sliced off the features and they didn't put them anywhere. [laughs] You have to have both apps around. If you're going to take features out, you have to make sure people have a way to do those things. That was a problem.
It was a nicely designed app, but I don't like the full screen mode. I've never liked the Mountain Lion full screen mode due to the slow ass switch. I want something instantaneous. It doesn't play very many formats. It's really good for MP4s and certain kind of AVIs, but if you have other things you can't play them with it.
Rene: Like MKV, it's just not...
Don: It just doesn't work, you need VLC, or one of the in player wrappers for that.
Rene: VLC is ugly. I don't like VLC either.
Don: The issue with VLC is it's got the iTunes disease. It's become everything. Now that works for iTunes. iTunes, especially the new interface in iTunes, people have laid a lot of hate on the iTunes team for I think is actually great.
Guy: It's definitely an improvement over the old one.
Don: It's definitely an improvement. It's simplifying the app without actually simplifying it. Which I think is a great thing. What I meant with the iTunes disease was a joke we used to make every once in a while, you keep putting features into it. VLC has too many features right now. I'm a maniac about, before I release any code or release anything, what I always go, "What features can I cut out of it? What don't we need?"
Even before I released my little piddle-y Magneto, my site generator? I cut features out of it. Not that it has a lot of features right now, but I thought, "Why am I doing that?"
Rene: Features that you weren't using yourself?
Don: No, they could be done another way, and one that I wasn't using myself, so why would I want that in there? They were pretty minor features, as an example. There are features in Safari that I've tried for years to cut out. I can't do anything about it now. Look at the preferences in Safari, I think you could probably take about half of those preferences out of there.
Guy: Yeah, that's a good focus.
Don: A really smart man, Darren Adler, taught me something years ago. He was talking about assessing features, assessing preferences, deciding on how to do a preference, and the thing to do when you're arguing back and forth about something. He said, "OK, it's a preference. But which is the default? If you're going to have a preference, you have to have a default setting."
You decide on what the default setting is, and then you get rid of the preference, because you decided on the default, and you never ship that. That's the whole point. Make decisions. Limitations are clarity, they're features too. That's really an Apple approach. Back in the old days at Netscape we used to joke, "How many preferences does Netscape Navigator have? All of them."
You could get really lost inside that preferences dialogue back in the old days. To the team's credit, with Firefox they've vastly improved that, but it's still pretty complicated.
Guy: I think not only is it good for the user, a giant preferences box is confusing, but it's good for the team and the software itself because it's just fewer places for things to go wrong, really. There's fewer pathways to disaster.
Don: Exactly. Exactly. Less stuff to test. Less things to confuse people. I know I've been responsible for features that I thought at the time were really good ideas and they turned out to be not popular or confused people about something else that you wanted people to use. I think Apple is one of the best companies out there doing software and hardware for keeping things simple and keeping the focus right. We still didn't do everything great.
That's why I really applied the iTunes team and the idea of trying to focus things down. That's very hard to do. It takes courage to do that and possible annoy people.
Guy: Especially with such a high visibility app, right?
Don: Yeah. I think they did a really good job walking that line. I use it. I find it's fine. It still has way too much stuff in it but they're doing a much better job of hiding it.
Guy: Hiding it without it being totally inaccessible, tucked away maybe more than hiding.
Don: Yes. Very, very hard to do.
Guy: You're working on an iTunes killer?
Don: No, no. When I say media player I'm considering writing something basically a video player, something that's very simple and straightforward, and something that could sit alongside QuickTime player to be pretty and to play other formats. MPlayer X has the potential to do that but it seems to be maintained sporadically, and there are certain design decisions in there that are just maddening to me.
Guy: I would like that because a lot of that stuff just seems janky to me. A lot of it seems like it came from the Linux world and got a Mac paint job.
Don: Right. Literally it did because it's got MPlayer which started out as the Linux movie player. What was his name? I don't know if I can even pronounce his name, [indecipherable 64:33] . I don't know where he's from. The guy who did the original MPlayer OSX project back in the turn of the previous decade. That's essentially what he was doing is he was putting a Mac wrap around MPlayer.
You can do that and you can do it the right way. You can basically hide the fact that that actually exists and make it look like a real McIntosh application. I think [indecipherable 65:12] , the guy who does MPlayer X, made a good stab at that, but there are certain behaviors and other things that still don't very well.
Then we have VLC whose interface looks like VLC. It's a good app, though. Anyway, I'm thinking about it. I'm thinking about it.
Guy: I'd encourage you to do so.
Don: I'll probably come to my senses.
Guy: [laughs] Please don't. Stay crazy.
Don: The worst thing about doing it, though, is then I'd have to maintain it. [indecipherable 66:01] because he has a real job and he's doing that on the side. I don't have a real job. I'd really have to maintain it. That's the worst thing about putting stuff out there is maintaining it. I don't want to just throw something over the wall.
Guy: You could. You just toss it out and have somebody else pick it up and run with it.
Don: Oh yeah, but I've got way too huge an ego. I put these pretenses on about being a humble guy but I'm just as much of an asshole as everybody else out there about that stuff. When I've worked on other open source projects I've obviously tried not to do that, back when I briefly worked on Lame, the MP3 encoder. I tried to play nice with that community and it worked pretty well back there. Thankfully, they've rewritten all my code by now. I had to stop contributing to it when I went to work for Apple.
Guy: I hadn't realized you'd been involved with Lame.
Don: Yeah. I didn't do any of the really hard stuff. I did the easy shit. Early on somebody had added the ability to do ID3 tag support, ID3 version tag support, and the world had moved on to ID3 version two, which was, in a way, an over-engineered, wacky...
Guy: Yeah, it's a nightmare.
Don: Yeah, it's a nightmare, but it was what everybody was using. I hated running a tagger after I would encode something so I started doing a hack and it just got out of hand. I developed it into a set of patches and asked the team if they wanted to use that and they accepted it in the tree. Robert eventually rewrote all of my stuff, thank God.
Guy: Would you say that that's how a lot of open source contributions happen? There's two things. We were just talking about Google and Apple and their splitting and forking and they've got full time employees working on stuff.
Don: Yeah, that's actually very rare.
Guy: I was going to say, most open source is just random people getting annoyed with something and fixing it.
Don: Yeah, it's scratching an itch.
Guy: Was that true for Webkit at any point or is that more of a professional?
Don: I think that's true for some of the people who joined the team from the open source world. They went in because there was something they wanted to do and it got out of hand and became a career because it was scratching an itch.
Guy: [laughs]
Don: I've hired plenty of people like that, just amazing engineers, that way. The projects that I've contributed to, which are very few, sometimes they started out that way, or this program that wrote this last week. It's like, "Oh, damn it, I want it to work this way. Not that way," and I did something really stupid. I wrote a completely separate program, rather than develop a patch for what was there, which is the height of ego-maniacal stupidity.
Guy: I don't know. I'm looking forward to it. [laughs]
Don: We'll see. I've got to make sure I don't have any bugs. I ran into a hideous big last night. There's this protocol in MPlayer, that I think was developed by originally one of the OS 10 contributors for communicating with a gooey app, and I supposed it was a good idea in its day, but it's really hideous. It sends the host app through an NS connection that you create.
Guy: Yeah. You mentioned that. That seemed odd to me.
Don: Yeah. It sends you the height, and width, and the aspect ratio. It sends you the aspect ratio as an integer.
Guy: [laughs]
Don: Which is just completely useless, so I had to come up with...Yeah, so all the arguments are integers, so it's completely nuts. It defines some functions that can be called. Start, render, and stop, which are supposed to be called in that order. Of course, except when they're not called in that order by Mplayer as it's running in the background. I had a crash error last night, I discovered, when it was calling stop before it ever called start.
Guy: I hate that kind of stuff. [laughs]
Don: That's classic communication protocol stuff.
Guy: Yeah, that's the worst.
Don: It would do that for every AVI file I would flow through it. I'd stupidly been testing it the whole week with MP4s and MKVs and stuff like that. I hadn't run an AVI file with xbit in it, and it was like, "Here's I'll stop before I start."
Guy: Why? It's weird that AVI is different. Is there a command stream in an AVI file, or something?
Don: I have no idea. This is why I'm such an idiot to do something like this, because a lot of those kinds of internals, I never really pay attention to. I'm more concerned with [indecipherable 71:41] . I actually enjoy writing all the pluming. It was just a boat load of fun figuring out how to run something as a separate task. I had set over code before, and talked to my engineers before, but I never actually sat there in an editor and wrote all the stuff, or put the distributive object type connection and stuff like that, done it myself, it was a lot of fun.
You know, I had other code to look at, some of which was very nice examples, and some of which was like "Ahh!"
Guy: [laughs] Yeah, distributive objects are cool, but crazy.
Don: Yeah, crazy. It's just a pseudo-distributive object. Basically what you do is you create an object locally, and say it has this protocol, and then you register via connection of this name. The crazy thing was it usually worked the first time I did it. I couldn't believe it. I thought I'd done something wrong.
That actually turned out to be one of the most straightforward parts of it. It was like the renderer. I spent all this meticulous time not even testing the open GL code, but just writing it and code reviewing. I ran it and I didn't get anything rendered at first. I went "Oh well...it's too hard".
Guy: It's open GL. That's...it never happens. It never works the first time. It doesn't do that.
Don: But the open GL code was perfectly fine. It rendered perfectly. I had passed the wrong parameter to one other function down the line, and that was the entire reason why it didn't work.
Guy: I don't know about you, but I never am more nervous about my code then when I run it and it works perfectly. Every time, like if I type it and it works, I'm like "Whoa, something is screwed up here, something really bad is happening."
Don: [laughs] Yeah, some of the more trivial things that didn't work that threw me...like, I ran into every noob's screwjob with NS notification center. I've got two threads running in the app, and I stupidly tried to notify the other thread with notification center, forgetting that that doesn't work at all. I was getting called back on the same thread.
Why does it work that way? That's because that's the way it's designed to work that way. That's a feature, not a bug. I go, "Oh, shit. What's the best way to communicate with another thread?" I gave it a quick iMessage to my old buddy and former engineer Ricky Adams, and I said, suggestions? He said "GCD is your friend", I went "oh yeah". A little asynch dispatch call took care of that painful swelling, and all was well.
Guy: Yeah. I'm pretty sure you got a contact list that can help you with a lot of these problems.
Don: [laughs] It's like crib notes during a test.
Rene: Or a lifeline during a game show.
Guy: It works, come on. Exactly
Don: Yeah exactly, lifelines that's what it is. Rene, that is perfect. I got a lot of lifelines, and they're all brilliant people, a lot smarter than I am. I'm sure they could have written everything I've written in like a day. [indecipherable 75:03] They probably wouldn't have wanted to write this. Who the hell would? We'll see what comes next, but I've got to get back to my website writing.
Guy: Yeah, please do.
Don: What I'm going to do is probably take this 4,000 plus pages of notes that I wrote for that talk, and turn some of those into blog posts. I just get so tired of repeating and rehearsing the talk that I don't want to look at the material. I actually told you...
Guy: Just read it into Siri. Have her dictate the posts for you.
Don: [laughs] A question for you. How often do you guys actually use Siri?
Rene: A lot.
Don: Wow. I'm impressed.
Guy: Yeah, seldomly. I use it for setting timers and alarms and shit that it can't fuck up.
Rene: I dictate posts while I am driving so I don't forget the hook that I had when I thought about it.
Don: Apple loves people like you Rene.
Rene: [laughs]
Don: I always think whenever I use it and it just works perfectly, and it does what I want, I think to myself why don't I use this more often?
Guy: Right, yeah.
Rene: Yeah, then it screws you.
Don: Occasionally it will get confused, but usually that's an amusing interlude...
Guy: One thing I do find cool about Siri is yeah, it's an amusing interlude. If I'm telling it to remind me or something and it gets it wrong, at least when the reminder comes up, there is enough phonetic information there that I know what it's talking about.
Rene: Yes.
Guy: Maybe it screws up the name and it says "Rave" rather than "Dave", and it's like OK, fine I know what it's talking about.
Rene: It's much faster UI to enter reminders, and calendar events, and anything that's touch based.
Don: Oh yeah, yeah. Doing it with Siri is much easier than typing it in on a phone. My friend [indecipherable 77:15] , he is the person probably most responsible for the keyboard interface for the phone, I still prefer talking to Siri for doing long things like that, rather than typing.
Guy: Really?
Don: I'm all thumbs, literally. I can actually type very fast on my Mac compared to some people on the phone or the iPad. I do type very fast. In fact, typing is probably the most useful thing I learned in high school. I swear, it's the thing...Not the math, not even English lit., it's typing, learning to type. I still hit the Cupertino's all the time and it drives me crazy.
But I never turn it off, because it also saves me more times than it screws me up. Yeah, because my spelling is atrocious. What I would write would look like Middle English. Spell checking.
Guy: Yeah. Spelling is over. Computers can do that now. Yeah.
Rene: I think I said this before, but I have a godson who is four years old and can't write, but he uses Siri to send me text messages, which is awesome.
Don: See, that's what it's perfect for. That was like Charles was saying at Úll. Charles Perry, saying at Úll, you don't realize it but there are sight impaired people out there who can use a phone right now to see. There are apps out there that exist that they can hold up to take a picture with a camera, and they can tell them the colors of what's in their room, or their garden.
Guy: That's so cool. I'm really fascinated by this kind of stuff. I think there's...so the way that the accessibility software works is that you basically describe the functionality, or the...I don't know, how would you describe it, Don? You don't describe the layout, it's not about the visuals or anything. It's about what the content represents.
Don: Right, and you have to realize that iOS, like MacOS is one of the most advanced operating systems out there for providing accessibility support, because most of the stuff you just get for free. You don't have to do anything, but there are parts, like the stuff you're talking about, Guy, that you do. But I'm not an expert on this.
Guy: No, no. Neither am I, but it totally fascinates me, and I love the idea that if you set everything up correctly in your iOS or Mac App, there can be a totally different interface to your application, put on top of it via the accessibility stuff.
It just so happens that voice over is the one that works, but the way the content is described when it works out, can work in so many different ways. It blows my mind, fascinates me.
Don: Charles had this video that he played during his talk, of Stevie Wonder talking. This was before Steve Jobs passed away, I believe it was the Spring when it was known he was very sick. It was from Stevie Wonder, one of his sessions, and he got up in front of the crowd after his set and asked people to pray for Steve Jobs, because he talked about how much he loved his iPhone. He said "Here, I finally have a device where I can do everything you can do."
Guy: Wow.
Don: It was very powerful and moving. That's why I loved Charles' talk, because it was just intellectually precise and then it was emotionally moving, which is both the best speaking coming from being trained as a Minister, and the best writing there is, you want to be able to ever do. When you think about it, it's not just prose. I always want to impress upon people when they create software.
You don't need to just make software that makes sense, that's well designed. You need, if you want, your software to be used you need to make software that delights people.
Guy: I agree.
Don: That tugs at them, right? That gives them a reason to use it even when they don't need to use it. That's the best stuff in the world. If you can do something like that, man that's...you know, I've had glimmers of being able to do that over the years and that's the kind of thing that always gets you back to writing.
Guy: Well I think that people feel that they should be playing all the time. That software should be a toy. That it's to be enjoyed.
Don: Yes, and that's the right way to approach it. That's what you want. You want people to play and get a shitload of useful things done. Even if that play is in a game itself. Gaming isn't just frivolity.
Guy: Well that's why I never really found the animations frivolous in OS standards.
Don: Exactly. Well, the...
[crosstalk]
Guy: OK, there's some of the animations.
Don: I just have this quirk in my personality I just don't like the full screen transition. And, I know the guy who wrote it. He's a friend of mine, but it just always bugs me. They're not frivolous.
Guy: Right. Yeah, it could bug you but it's not frivolous, like you know why it's there, right? It's for...
Don: Right.
Guy: Not you. It's just...
Don: Oh, no, it's not for me. In fact, the reason why the full screen animations transition there's a very good reason. It's to give people context for what's happening.
Guy: Exactly.
Don: The way people try to solve their problem before is what they would do is they would, the first time you went into full screen they'd put up a dialogue and say "Do you realize we're going to full screen now?" and it was like, "What the hell?"
I like instantaneous full screen but that's because I'm a geek working at a command line. That's what I like. The reason why it's done that way on OS 10, it's brilliants because people go "Oh, I can see my other desktops sliding away. I can see this other thing coming in." There was a lot of work put into that.
Guy: Right. It is quite slow. Yeah sure, it's quite slow but I think it's the right speed that people see what's happening.
Don: Yes. Yes.
Guy: Like they're thinking during that process, "Oh my desktop is going away, and here's my new thing coming in." For me, it's like just do it, just get it out of my way and just do it. That's fine. But, I can understand why it's so of laborious in that way.
Don: Let me ask you two, the first time you used OS 10, you didn't get the light and the animations. When I was trying to think of what I was going to do at easel as it was auguring into the desert floor dying. I borrowed that G3 iMac from Andy Hertsvel, and I was playing with OS 10, the thing that got me going back there even though I didn't have a lot of apps there.
I had like Terminal and Text Edit and something else. Whatever was in that first version of Cheetah. I would go down to the dock and I would minimize and expand Windows, and just watch that kind of thing happen. Drag stuff around, and I thought, "Man this is so cool."
Guy: I love that. At that time I was writing video games, and just the graphic stack on OS 10 just seemed, to me, to be the way of the future. To steal a phrase. Draw everything into a backing store and then blit it to the screen with a Windows Server.
Don: It's a video game approach. That was the great thing about it, right Guy?
Guy: It felt like that. Like put everything in a texture. It wasn't in that earlier version, but I could see the way it was going to be. Everything is fully buffered, just draw into the buffer and then throw a bunch of textures around the screen. Awesome.
Don: By the way, it's very mature doing that stuff now. I was really stunned and delighted when I was writing this little app about all of the wonderful stuff in there, like the first time I created a CG, or core animation texture cache. It was like totally easy.
You just attach a layer to a view. You say to the view, "Set once, layer, set layer," and it automatically re-sizes and moves around. Everything is taken care of for you magically.
Guy: It's so good, it's so good.
Don: It's like one of those Japanese toilets that wipes your butt and it's just so good. It's like an art.
Guy: [laughs] I don't know if I would have said that.
Don: Well that's OK, it's me being fecal again. This is the first time I've actually written something in Ark. It's like, "Oh my God," I'm never going back.
Guy: Yeah.
Don: It's like retain release, screw that. Before I do release, I have to put the scope on this and see if I actually am leaking anything and do some other measurements. Performance is really good, but you can have really good performance because you're leaking the world.
You can use Ark badly and having multiple threads and stuff like that, you have to be careful with. Syntactically, and the clarity, and the code, and everything else you're doing, I'll never go back from that. But, I still like the original name for Ark that we had.
Guy: Oh yeah, it was ARR.
Don: Yeah. ARR. Because we were walking...
[crosstalk]
Guy: Yeah, you were telling me that [laughs] .
Don: Yeah. Automatic Retain Release. ARR. But the marketing guys got a hold of it then it became Ark. Damn it. Because you can write C, because that's what objective C is with this weird syntax from small talk. You can write C like it's Ruby or Python.
It's just so easy. You have to take a few precautions, like this stunt where you have a command line app that becomes another application, I have to have my main function, I have to wrap that in an at-auto release pool, little thing there. You have to remember to do that on your thread entry.
Guy: Yeah, it's whatever.
Don: It's not that it's not a nice attempt. An at-auto release pool, the great thing about it is even if you're not using Ark, those directives will do all the other old stupid nonsense for you, anyway.
Guy: Yeah. There's a bunch of good stuff to consider. It still hurts my brain looking at, just calling eloquent on something, then not releasing it someplace later. I just still trip over that mentally, but I'm just being an idiot.
Don: It took me about a half an hour, and then there was no looking back. [laughs]
Guy: My main product that I work on is not Ark yet, but I'm working on a bunch of other stuff that is Ark. I'm slowly getting...
Don: You know what's not Ark yet, but will be hopefully this summer is XCode itself.
Guy: I sadly believe that. You know what, XCode was GC. It was garbage collected.
Don: Right. Because XCode always was the big [indecipherable 89:51] dog food thing. You got to respect the XCode team for that.
Guy: Oh, totally, yeah. It gets a lot of hate that it doesn't deserve, I think.
Don: Although, I was cursing it this week. The online documentation thing is fantastic. XCode is the best environment to work in, even though I'm not using it now. I'll explain why. To work in, compared to everything else that is out there, like if you're developing Android apps now, XCode is so much better than what the Android folks have.
The documentation viewer is so damn slow when you type into that little search field. Oh, I just want to strangle somebody. It's the indexing. I don't know what's going on there with indexing but it just makes me nuts. I can actually go into Safari, type what I want into a Duck-Duck-Go window, what I want, even saying site: developer.apple.com, and hit return and get results faster than I can sometimes looking at the documentation.
Guy: That is exactly what I do.
Don: Yeah.
Guy: But without the Duck-Duck-Go. [laughs] I should try that out a bit more. But like the documents windows...
Don: It's not built into Safari, but I try to reduce my surface area as much as possible with Google.
Guy: [laughs]
Don: No, not to dispirit. It's just privacy and other concerns.
Guy: Yeah. That's not a bad idea.
Don: I don't recommend that for everybody.
Guy: Go ahead.
Don: I said I don't recommend that for everybody. I also don't recommend the stunt that I'm doing now to develop the whole app. I am actually not writing in XCode, I am writing in VBedit.
Guy: That's pretty old school.
Don: Yeah. Well, I'm 56 year old, so there is nothing I do that's not old school.
Guy: Come on. You're still hip with the kids.
[laughter]
Don: Yes, that new lingo. Sometimes I try to talk like the pseudo-hip person just to annoy my 22 year old son, especially when his homies come over. They were over the other night.
Guy: [laughs] You swear far more than anybody that age, so don't worry about it. You're rocking.
Don: Anyways, I like to embarrass him. Getting back to VBedit and the way I was writing this, it's basically VBedit and a make file. It's all like one file because I'm heinous. What I'll do once I'm done is then I'll break it up into separate source files and probably stick it in to XCode just to make sure everything else runs. Also, so I can do some automated tests. It's nothing for me just to whip out a text file, do a make file in like five seconds, and boom you're good to go, right?
Guy: Yeah.
Don: This is crazy, but when you start a project and it's really small, doing it in a single source file is actually very useful because it makes it much easier to search and replace, and do everything else, and understand the context of what you have. Once you get to a thousand lines, well you're screwed.
Guy: Yeah. I had to help fix a project like that. It was like a game from the jailbreak world that we ported to run on the first iOS SDK. It was one giant file.
Don: How many lines?
Guy: Oh God, more than a thousand. It got out of hand, but it was just the guy having fun and just hacking on it, and it turned into a product. Wow, that was a bit of a pain in the ass.
Don: I'm sure that program was still shorter than the original NetgetURL function in Netscape Navigator Four, still shorter.
Guy: [laughs] I bet.
Don: Sorry, I interrupted you.
Guy: No, no, no. I was going to say that, yeah, I can see that joy of just having one file, and just typing in a bunch of stuff and having it work. That's how we got into programming, right?
Don: Exactly. It's like writing a script, right? But don't listen to the old crazy man.
Guy: Yeah, do not do this, but I can see the appeal.
[laughter]
Don: For me that was useful because I can scroll...it's funny, I can scroll it up and down in my head. I don't know about you, Guy, but after years of programming, when you're not in front of the terminal, you can scroll you're code up and down right in front of your eyes. Make the edits, and stuff like that.
Guy: Yeah, I can see the structure.
Don: Yeah.
Guy: I just know where stuff is.
Don: Yeah, that's creepy. You describe this to other people and they just think that you're some kind of serial killer. It takes the same capabilities to do that.
Guy: I don't know, I've been watching a lot of "Dexter" recently. I don't want to get...
Don: Oh, really? God, I'm like two seasons behind now.
Guy: I just started. I'm like in the middle of the second season.
Don: Oh really? Oh. I got to say, the first season of "Dexter" was one of my favorite...
Guy: It was brilliant. It was brilliant.
Don: ...episodes of television. Just terrible, in a way when you think about it, the morality of rooting for a serial killer.
Guy: It's horrible. [laughs]
Don: What they do to your head, it's like, "I can't..."
Guy: It's Soprano's morality.
Don: Yeah, exactly. It's like the Soprano's. I love that kind of stuff.
Guy: Yeah, I'm enjoying it.
Don: I don't know why I'm encoding all this stuff, because I got so much stuff queued up that I still haven't watched. I probably got a year's worth of TV and movies that I still need to watch.
Guy: [laughs] It's your affectation, and it's just what you got to do. What do you do? You encode. That's it.
Don: Yeah...I want to see if I can get the best possible thing at one time. I was talking to Rene before the broadcast started about getting stuff from iTunes, and Rene's saying, "Well it's still not Blu-Ray quality".
Rene: Yeah, we did that. One of our recordings we did in 4K and we're playing around with trying to get it online right now.
Don: I just think that's insane that it's 4K. Wow, I'm impressed, 4K.
Rene: Well we'll be impressed if it works. We'll see.
Don: At those bit rates you're never going to get Blu-Ray quality.
Guy: Yeah.
Don: But you can get something that is reasonable that 99 percent of people can see on their HDTV sitting across the room at five megabits, 1080 P. That is what iTunes, most of their 1080 P video is. The odd thing is, they're 720 P video, it's four megabits.
You go, "Hmm, wait a minute, I'm watching 720 P and it's four megabits, and the 1080 P is only 20 to 25 percent larger, in terms of number of bits and bit rate? How the hell does that work when the actual viewing area is two and a half times?"
It's the weirdities of our eyes and resolutions and stretching things that actually pulls it off.
Guy: I was watching "Zero Dark Thirty" over iTunes, and in that helicopter assault scene, it's awful. It's like blocky, it's like mpeg city. I was distracted to the point of just being angry.
Rene: I saw the movie, and that whole scene was poorly shot in terms of the darkness. They could have shot it all through infrared and made it much more legible to the viewer.
Guy: Oh yeah? OK.
Don: Not to dive too deep on encoding problems. There's a few problems that encoders run into. H264 converting, you run into, and that's the blockiness. There's also the thing where you can get a lot of blockiness where you have very subtle color change.
Guy: Yeah, because it doesn't' capture it, right?
Don: Make yourself sad and watch a couple of animated films on iTunes and you'll see some large, very tapered surfaces which seem to have some stair-step effect. The way to fix that is simply more bits. That's the only way you're going to get around that problem.
That's the problem that a lot of people make the mistake at. The big thing these days, a lot of people are really hot for, obviously doing things like, I don't know if you're familiar with X264. That's the encoder I'm using built into [indecipherable 99:28] .
They have a mode CRF, Constant Rate Factor, which you give it a quality setting and then it goes and does stuff, and you basically get a variable bit rate encode. This sounds like a wonderful idea. Except that to use the same quality setting on every movie, if you're going to take Blu-Rays, or DVDs as source bits, you're going to have to set it to such a high quality setting that, on occasion, you'll have output that is larger than your input.
Believe it or not, the way Apple is doing it, by doing essentially a fixed bit rate, is actually a better way to go with getting consistent quality, because really noisy stuff is going to look noisy anyway. If it's complex, the original was noisy, the encoded version was noisy, and for things that are very still, animations, or very quiet movies, you want a lot of bits in that stuff because your eyes will notice the details.
You can't use a lower quality setting, a lower bit rate. What I've developed is a way to do, believe it or not, single pass and codes with X264. They get a lot of the same benefits as CRF, and it's through a very simple little option that you pass to X264. It's called Rate Tolerance Equals Infinite.
You get a fixed bit rate, single pass encode that behaves like a CRF encode. It looks a lot like what iTunes is doing. It occasionally runs into some of the same quality oops', but not nearly as many.
Guy: That's cool.
Don: I can record a Blu-Ray on average in real time on my iMac that way.
Guy: That's pretty impressive.
Don: Yeah.
Guy: That is interesting.
Don: If you ever want to waste another two hours talking about encoding, boy can I bore you, because I've done a lot of things.
Rene: It's a date.
Don: Yeah, it's a date.
Guy: Perfect.
[cuts off]
Feedback
Yell at us via the Twitter accounts above (or the same names on ADN). Loudly.
