terminus

Also a longer critique by John Siracusa here: http://arstechnica.com/apple/2011/07/mac-os-x-10-7/12/#hfs-p...

I wonder how this ties in with the whole Apple philosophy of "Design is how it works."

Clearly the innards look nothing like the facade.

> It's like a never-ending stream of lies, every word being a little more absurd than the last...

It's been my experience that most things are tractable once you spend long enough staring at them.

If you care enough about a subject to have strong sentiments like "never-ending pack of lies" then your time would perhaps be better served by spending time with the "adored" object, rather than these comments.

I'm guessing this was posted earlier than expected. Don't see much content beyond the Preface.

> From what I know (and I am not a finance professional), the hot-airiest phase of the dot.com bubble sort of looked like this. You had a ton of startups selling each other things and advertising with each other. It was not planned, but unplanned "emergent" bubbles are the most effective since nobody really realizes what's going on until the bubble is far enough along to keep rising out of greed and inertia.

Yup. Seattle Times had a detailed story on one of those: http://blogs.seattletimes.com/opinionnw/2014/03/27/naveen-ja... http://seattletimes.com/news/business/infospace/

You can watch it live (and I believe offline) using the Google IO app.

> Your only involvement is as the hook that enables the tax advantage.

Agreed. I think what a lot of people are uncomfortable about is that an employee's life is now a "tax-advantaged investment vehicle" for a company.

Anybody other than me commoditizing my life (and death) seems to lack human dignity.

I have been fascinated with chip diagrams like these for a long time:

http://www.chip-architect.com/news/2012_04_19_Ivy_Bridges_GP...

http://chip-architect.com/news/2003_09_21_Detailed_Architect...

Of course the ones he's planning to photograph are older generation ones but worthy nonetheless.

Would be interesting to map structures on the metal mask to chip level structures but that's for later.

> They might not be the most open of company but they had open source technologies that are awesome in their own right. LLVM is just one of them. Open sourced and won the ACM award. That by itself is a achievement hard to beat.

I don't understand how a community project became "Apple's achievement."

Apple did not open source LLVM. LLVM was an open source project (since 2000), which Apple used and open sourced their contributions to on the way.

> Granted building a fallback into the design at the beginning would have been a better way to do things

Notice that, that building the fallback is not building a fallback for the location API but for all the cloud based APIs that the app uses (or atleast the critical ones.) Then there is impedance mismatch between each of these APIs.

Definitely useful to do but sounds like a lot of work.

Two wrongs don't make a right.

I'll reserve judgement on whether Amazon's conduct is legal or not. But, Apple's collusion was decidedly illegal.

In any case if the DoJ feels that Amazon is misusing monopoly power, then the solution is to prosecute both and not, it'll all cancel out in the long run.

Try saylor.org.

Not to be pedantic or anything, but git != github.

AFAICS, none of this is about github. It's about git, the protocol, the versioned object store and markdown, the markup layer.

The two scenarios you outlined seem contradictory:

* I don't think you can minimize the boost android got by having eric on apple's board during a very critical formative point

* Google completely abandoned their earlier prototypes once they saw (in the apple keynote) what apple had brewing.

If being on the board was so helpful, then why would Google need to abandon their previous approach?

> Services like Netflix that send massive amounts of traffic in a single direction violate this assumption.

Netflix does not send any data. Comcast customers request lots of data from Netflix. Significant difference.

Another example (just in the other direction): A backup provider needs to pay up big-cable because their customers are uploading a lot of data?

That's a pretty interesting approach. Might even work!

I wonder if something simple (and stupid) like an LD_PRELOAD with an alternative fixed SSLVerifySignedServerKeyExchange would work. Won't work if the code ends up getting inlined.

Guess not, looks like SSLVerifySignedServerKeyExchange is static.

> But there is no guarantee of anything unless the reviewer is incapable of making mistakes, in which case you could just ask him to write the code in the first place.

Did you look at the bug? I'll quote it here:

    if ((err = SSLHashSHA1.update(&hashCtx, &serverRandom)) != 0)  
        goto fail;
    if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)    
        goto fail;  
        goto fail;  
    if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0)  
        goto fail;  

Even somebody with basic programming skills can see that's wrong. And, remember this is libssl. Any checkins to that warrant thoroughness if not paranoia.

Thanks for that extremely insightful analysis. Haven't looked at pandoc before but will do.

> If you argue that an obvious bug is evidence of NSA involvement, then you must also believe a subtle bug would be evidence against NSA involvement. You can't have it both ways.

Thanks for taking the argument to a mathematical plane. My reasoning was the following:

P(is-involved) = P(is-involved|subtle)P(subtle) + P(is-involved|subtle)P(~subtle)

Now, we know that 0 < P(is-involved) < 1. Assuming that there have been past instances of their involvement in both subtle and unsubtle bugs, I think my argument where I can attach a probability of their involvement in both the case was fair. Or do you think I missed something.

Note: I think I got it. Essentially your point is that given that I am using the unsubtle-ty of the bug to argue both ways, implies that this variable provides us no useful information and can be removed from the discussion.

Thanks for pointing out my muddy reasoning.

From the article:

> NSA itself planted it surreptitiously.

> Apple, complicit with the NSA, added it.

Neither seems very likely given how visible the goto is. Something just a little more subtle like a semicolon at the end of the if() clause might look better.

Of course given how glaring it is, it could be a case of plausible deniability: would we do something to stupid, so unsubtle.

> The foundation of our economy has just been proven to be on very very shaky legs.

Exactly. That sums up my feelings about it better than I could. Something so critical, something trivially easy to catch in a code review was not caught. And, the only scenario in which a code review might not have caught it: no code review. That's no code review for libssl.

If this is incompetence and not malice, it's incompetence of monumental proportions.

> entire code base being written with substandard style rules and no static analysis or tests, which suggests to me that incompetence got here first.

That and inadequate, bordering on zero, code review. Even a beginner C programmer looking at this code could see how fishy it looks.

No code review while checking in code to libssl. That takes a lot of incompetence.

Those are just the surface differences. The modes in which you use all of these are very different.

Word: explicit WYSIWYG control over typesetting.

LaTeX: semantic level control over typesetting. Additionally provides explicit low level typesetting commands.

Markdown: given how basic (trivial even) Markdown is (http://daringfireball.net/projects/markdown/syntax) I'm not sure why it's even in this list.

> We as developers in the Open Source community should be ashamed people are still using Vim to write LaTeX in Bash running on terminal emulators. (Yes, it gives me shivers just thinking about how much each of those technologies sucks when you think about how good it all could be.)

Let's deconstruct each of the pieces we are supposed to be ashamed about, shall we.

LaTeX the language: a wrapper language built on top of TeX for typesetting documents. The idea being to specify higher level document logic (for instance sections, subsections, paragraphs, tables) and if all else fails, then fallback to explicit placement commands. I fail to see anything to be ashamed of in the idea. And, as for your complaints about extendability in some of the comments below: maybe you should look at the texlive distribution or PGF/tikz here: http://www.texample.net/tikz/)

LaTeX/TeX compiler: that's a fair point. But, doesn't have much to do with the language.

vim: a text editor wrapped around using the keyboard efficiently, similar in idea to LaTeX the language in that it asks you to express yourself on a higher plane. Neovim is essentially a more maintainable repackaging of the same model keeping extendability in mind.

bash: wrapper over the early Unix model pipes, ttys, processes (and not threads) etc. The bash scripting language is not all it could be. But, as I said before, the basic model is fairly tied up with Unix itself and is similar in zsh/fish etc.

I would imagine that .inputrc would serve as a superset in that all programs (for instance gdb) whiich use readline would now default to vi mode.

And, he expected to be, and was arrested for it plenty of times.

Funny, but in light of recent events (see http://arstechnica.com/tech-policy/2013/11/uk-spies-continue... for example) things like Byzantine General's problems do not seem quite so far fetched.

More details: http://www.bloomberg.com/news/2013-12-13/visa-mastercard-swi...

Witness: iAds.

Or blocking Random House's ebook app if they did not agree to an iBookstore deal.

Chief Apple cheerleader Gruber himself finds that "worrisome" here: http://daringfireball.net/2013/06/siege_mentality_indeed

Thanks for all the work. That was an amazing read.

I've always wondered how people map chip-die photos into something like this: http://chip-architect.com/news/2007_02_19_Various_Images.htm...

or this: http://chip-architect.com/news/2003_09_21_Detailed_Architect...

I can see how figuring out the cache and the internal buses might be doable, but the rest... Any insights?