Archive for May 4, 2017

Thursday, May 4, 2017 [Tweets] [Favorites]

Hollywood Archivists Can’t Outpace Obsolescence

Marty Perlmutter (via Michael Love):

These days, the major studios and film archives largely rely on a magnetic tape storage technology known as LTO, or linear tape-open, to preserve motion pictures. When the format first emerged in the late 1990s, it seemed like a great solution. The first generation of cartridges held an impressive 100 gigabytes of uncompressed data; the latest, LTO-7, can hold 6 terabytes uncompressed and 15 TB compressed. Housed properly, the tapes can have a shelf life of 30 to 50 years.

[…]

As each new generation of LTO comes to market, an older generation of LTO becomes obsolete. LTO manufacturers guarantee at most two generations of backward compatibility. What that means for film archivists with perhaps tens of thousands of LTO tapes on hand is that every few years they must invest millions of dollars in the latest format of tapes and drives and then migrate all the data on their older tapes—or risk losing access to the information altogether.

[…]

The head of digital archiving at one major studio, who asked not to be identified, told me that it costs about $20,000 a year to digitally store one feature film and related assets such as deleted scenes and trailers. All told, the digital components of a big-budget feature can total 350 TB.

[…]

When Pixar wanted to release its 2003 film Finding Nemo for Blu-ray 3D in 2012, the studio had to rerender the film to produce the 3D effects. The studio by then was no longer using the same animation software system, and it found that certain aspects of the original could not be emulated in its new software. The movement of seagrass, for instance, had been controlled by a random number generator, but there was no way to retrieve the original seed value for that generator.

Software Pricing Damage

Matt Gemmell:

Has Apple created a huge market, in terms of potential customers? Absolutely. It’s just done so at the expense of its platform-invested developer community. Judging by the company’s value and income, it was a very wise move, and you can justify it on that basis if you choose. But don’t ignore the reality of the situation. Apple is not a benevolent entity; your human-centric partner in aesthetics and ethos. If that was ever true at all.

[…]

For developers who target the Mac, the last segment of the glass-and-aluminium Cupertino hardware line-up to still have plausibly sustainable economics, there’s only one course of action: pray that Apple remains disinterested.

See also: Paul Haddad.

Exception-oriented Exploitation on iOS

Ian Beer (via John Gordon):

My guess is that the developer copy-pasted the code for the entire function then tried to add the extra level of indirection but forgot to change the third argument to the copyin call shown above. They built XNU and looked at the compiler error messages. XNU builds with clang, which gives you fancy error messages like this:

error: no member named 'recipes_size' in 'struct mach_voucher_extract_attr_recipe_args'; did you mean 'recipe_size'?
if (copyin(args->recipes, (void *)krecipes, args->recipes_size)) {
                                                  ^~~~~~~~~~~~
                                                  recipe_size

Clang assumes that the developer has made a typo and typed an extra ‘s’. Clang doesn’t realize that its suggestion is semantically totally wrong and will introduce a critical memory corruption issue. I think that the developer took clang’s suggestion, removed the ‘s’, rebuilt and the code compiled without errors.

[…]

Perhaps most importantly: I think this bug would have been caught in development if the code had any tests. As well as having a critical security bug the code just doesn’t work at all for a recipe with a size greater than 256. On MacOS such a test would immediately kernel panic. I find it consistently surprising that the coding standards for such critical codebases don’t enforce the development of even basic regression tests.

App Store Sources and App Referrer Data

Apple:

App Analytics in iTunes Connect now provides insight on where customers discover your app, including App Store browsing and search, within other apps, or on the web. With key metrics based on source types, you can see your top referring apps and websites, making it easier to optimize your marketing campaigns.

Sounds like a good change, but I guess this must be iOS-only because the entire App Analytics section of my account is blank.