Scroogie Boy's blog

Well, I guess we're done watching movies at the IMAX theater... [Updated]

It used to be that our policy for seeing movies at the theater was "IMAX or nothing!" But then they had to go be jerks by threatening Ars Technica for quoting someone using the word "IMAX" in an interview.

Really? Is this the way they are going to defend their trademark -- by preventing anyone from mentioning it ever again?

So, instead of excitedly waiting for them to roll out Laser projectors at our local theater, I'm looking for alternative large-screen venues. Very annoying.

Update: IMAX changed their mind. I don't know that I have, though.

I can't swear off amazon.com completely...

...but I can do something.

Marco Arment puts the dilemma succinctly: Amazon are being dicks in their negotiations with publishers and studios, but it isn't like we can just swear them off and switch to a better alternative for everything they do.

On the other hand, where there are alternatives that don't suck... I am going to take them. For example, I think that iTunes is going to be getting all of my TV show purchases this year. The price difference with Amazon streaming video isn't significant enough to make up for my irritation. So, no, I can't swear them off completely, but I can vote with my wallet in other ways.

 

Swift

It's really easy to be cynical about Swift, Apple's new programming language -- that it is yet another vendor-specific programming language that does nothing but create more lock-in for iOS and OS X developers... While this is true, I have to admit being rather excited about it: the language looks really interesting and approachable for programmers familiar with other modern object-oriented languages.

They do seem to have created quite the win-win-win: Apple has a technology that is unique to them (porting applications to Android remains hard), existing iOS/OS X developers get a nice productivity step up, and new developers get to enter this world via a modern language that sheds most of the quirks of Objective C. Impressive!

 

Wading the App Store for an ePub reader that doesn't suck

While I've had really good success with iBooks on the iPad, finding an ePub reader for the Mac that isn't annoying in some silly way (like iBooks' obsession with pretending to have pages and columns) is harder than one would think...

Readium isn't a terrible (free) Google Chrome extension, but it has its quirks as to window positioning (it's stuck inside Chrome, duh!) and looking at the Mac App Store... Oh, my! So much crap and no idea what actually is decent. As it turns out, the reader I finally found was Murasaki -- a simple app from Japan that presents ePub books as scrollable sections (chapters) and pretty much just does that. It's not cheap by App Store standards, but it does exactly what I need (including the ability to override book styles when needed). Recommended.

The Mac App Store is not as filled with weird junk and clones of clones like the iOS App Store, but it still is quite the mess. Looking for oddball utilities like a CHM (Microsoft Compiled HTML Help) viewer is an overwhelming experience where most of the apps come from China or Russia, none of them are recently updated and, at best, come with one or two reviews. How is anybody expected to remain sane looking at this lot?

goto fail;

About the now-infamous bug in Apple's SSL certificate verification code (in both iOS and OS X), the apparition of a spurious "goto fail;" line in function SSLVerifySignedServerKeyExchange():

@marcoarment I did the same diff yesterday with just the function in question. Doesn’t seem very accidental. https://t.co/5DUO6qJEzH

— Rich Hong (@hongrich) February 24, 2014

 

...

if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)

    goto fail;

    goto fail;

if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0)

    goto fail;

 

...

 

fail:

- SSLFreeBuffer(&signedHashes, ctx);

- SSLFreeBuffer(&hashCtx, ctx);

+ SSLFreeBuffer(&signedHashes);

+ SSLFreeBuffer(&hashCtx);

return err;

 

}

It is very easy for (younger?) programmers to be hung up on the use of goto statements in code like this, but it actually is pretty idiomatic of system C code. Actually, to quote the Linux Kernel Coding style:

		Chapter 7: Centralized exiting of functions

Albeit deprecated by some people, the equivalent of the goto statement is
used frequently by compilers in form of the unconditional jump instruction.

The goto statement comes in handy when a function exits from multiple
locations and some common work such as cleanup has to be done.  If there is no
cleanup needed then just return directly.

The rationale is:

- unconditional statements are easier to understand and follow
- nesting is reduced
- errors by not updating individual exit points when making
    modifications are prevented
- saves the compiler work to optimize redundant code away ;)

int fun(int a)
{
	int result = 0;
	char *buffer = kmalloc(SIZE);

	if (buffer == NULL)
		return -ENOMEM;

	if (condition1) {
		while (loop1) {
			...
		}
		result = 1;
		goto out;
	}
	...
out:
	kfree(buffer);
	return result;
}

So, it is quite habitual to see this kind of construction. There is an acute problem here in that an extra goto was added, thus always exiting the function. The systematic problem is actually a bit more subtle: the code pattern in Apple's code relies on the test preceding the goto statement to set the return value, execution jumping to the 'fail:' label doesn't enforce that the function return value is not a successful value. Scratch one up to "it should never happen."

Anyway, I don't want to call out this code in particular... It's really bad luck for whoever made the crappy merge that resulted in this. My point is that Apple may be nearing the point Microsoft got to with Windows XP, where getting to the next level of security (starting from lower in their case, for sure) actually takes pretty systematic effort. Whether that is inveting in the tooling to detect these kinds of bugs through static code analysis or implementing specific security-enhanced coding techniques (let's say that not all C idioms are created equal on that front :-), they have a whole lot of work ahead of them.

Early adopter self-delusions

Listening to the guys on the Accidental Tech Podcast wrangle with justifications to buy the new Mac Pro is really quite humorous. Of course, we've all been there: wanting something new and cool before it is fully baked. But, the truth is that the difference between need and want is obvious when you really need something, completely invisible if you don't.

In this case, retina-class 4K desktop monitors are proverbially just around the corner -- but the only people that have any business putting up with the pain and suffering of fighting technology that isn't fully fleshed-out are those that really need it. Video editors working with 4K footage are going to bend over backwards to get the job done. However, like Marco Arment and John Siracusa on ATP, if you've experienced retina-class displays in smaller sizes and (correctly) extrapolate that retina-class desktop displays will be awesome, don't short-circuit the practical considerations: this is bleeding-edge technology and it is going to be saddled with compromises for at least another short while. This is the year where we can make it work -- at all -- not the year it actually works well.

The AnandTech 2013 Mac Pro review

As usual with Anand, it's an awesome hardware review. Read it.

One big picture take-away from the review for me is that high-end PC workstation performance is going to be really hard to scale from here. Aside from specialized workloads that take advantage of the massive (somewhat heterogenous) parallelism in these workstations, year-on-year performance scaling is pretty flat. This year's Mac Pro performance gains are mostly about its GPUs, which is awesome for some jobs (e.g., video processing -- admittedly, Apple's focus with this year's Mac Pro), but not so great for others.

Of course, the hardware design is nothing short of spectacular. They gave up the ability to create dual-CPU configurations (quite on purpose, if I read the review correctly: Apple clearly favors scaling GPUs over CPUs right now), but there isn't much out there that comes close for the compact, quiet performance that they intend the machine for. This is the Mac Pro for video editors. Maybe later than they would have liked, though. I guess that it's the penalty for trying something hard with this hardware generation.

But, let's face it: the real problem now is software. Scaling up from high-end consumer PC performance is going to be about parallelism and heterogeneity. Both are hard problems that have vexed developers for years and will continue to do so for quite a while, I expect.

Say what you want about the new Mac Pro..

...At least I can go to Apple's website and figure out what all the configurations will cost. I just tried to figure out the prices of equivalent workstation configurations from Dell and gave up in disgust -- not only are there three chassis sizes, umpteen starting configurations, etc. there doesn't seem to be any one configurator page that would allow me to pick all the options I want in one place.

Nothing says "Go Away!" better than a shopping site like that.

 

Understanding Workstations

Well, maybe I should put it in the negative: not undertanding workstations...

I read Marco Arment's analysis of the new Mac Pro CPU options with some interest -- not as a potential customer, but as a (Dell) workstation user myself at work -- and I have to admit that I don't really understand where Mac workstation users fit in the range of Intel-based configurations. By and large, workstations deliver three things (in some combination or other, depending on the configuration):

• CPU horsepower (e.g., dual 3.3GHz 8-Core Xeons)
• Memory (up to 192GB RAM on dual-socket machines)
• I/O (in the form of PCI Express lanes or storage bays)

The Dell T7600 I have at work is insanely good at the first two and surprisingly mediocre at I/O (it has PCI Express slots aplenty, but the usable drive bays are tied up with a wonky RAID controller). However, if you look at the new Mac Pro, it is pretty much the reverse: it tops out at a single socket (and not even the very fastest practical CPU option, at that) and just four memory sockets (for a total of 64GB), but the practical ability to expand storage at full speed via the gaggle of Thunderbolt ports on the back of the machine is pretty sweet. No, it isn't as cheap and easy as dropping in bare drives inside the box, but this is a practical solution.

I can understand some of the technical compromises Apple made with the new Mac Pro -- the T7600 at full tilt is like a space heater: hot and loud. On the other hand, seeing the 16 cores (32, if you count hyper-threading) in the top configuration hard at work is a thing of beauty. It is really, I mean, really fast! The Mac Pro would fall far short for the kinds of colossal models the high-end T7600 configuration is intended for in my work world. But, in the real world... Is it? If Apple did their homework, as they tend to do, they built a very different kind of machine that presumably meets the needs of real people. So, does this mean that workstations, at least in the Mac community, are all about GPU and I/O performance?

That's not to say that the new Mac Pro doesn't fit logically in the progression of machines in the Mac lineup: it allows 2 to 3 times more CPU, memory and I/O than the next machine down (the 27" iMac) and you couldn't get to these numbers with the consumer "desktop Mac" people have been asking for all these years. It makes sense in the lineup, but it seems unusually limited at the top end in comparison with other PC workstations. I really am curious...

The Open/Closed hardware principle

As it happens, Robert Martin's principles of object-oriented design have been the subject of conversation at work recently. Enough so, that it finally dawned on me how modern Macs seem to embody the open/closed principle -- that they should be open for extension, but closed for modification. While this may not be intentional, I think that it is an interesting way to view computing hardware these days.

In a way modern Macs represent a hardware manifestation of Richard Gabriel's worse-is-better for Apple while the market as a whole has a more literal interpretation of the philosophy? They certainly do strive for simplicity, often to maddening extremes. They do seem to be quite successful, too. One way they achieve their simplicity is through a minimum of (powerful) expansion options (thus open/closed).

This post probably constitutes analogy abuse, but I can't help think that there is a truth to it.