Evenson.not.org

Winter had come to the Temple in full bitter force, so a novice of the Clan of Iron Bones chose to spend his leave time visiting brethren in Phong Province to the south. The monks of that place worked on the planes of a great render farm, where the directional light was gloriously warm regardless of the season.

All morning the novice watched as learned brothers scurried to and fro, planting random number seeds, building bounding-boxes, or wrapping wire frames around even the tiniest model so that its pixels would blossom in just the right places. Thus were produced succulent scenes of every shade and hue, to please the tastes of the Imperial Court.

As midday approached, the novice’s stomach began to rumble. Since he required an escort to venture into the temple proper, the novice approached a pleasant-looking boy about his own age, who was rigging artificial light sources above a grove of small quadtrees. The boy’s clothes were of a rough sturdy linen, yet as testament to the rigor of his duties the once-solid hues had been worn down to dithered bits, both knees were covered with bi-quadratic patches, and the right cuff showed signs of aliasing.

“Ten thousand pardons,” said the novice (feeling all the more guilty for his own idleness) “but this miserable body will gnaw at me until I feed it a bowl of rice. Where is your master, that I may beg or barter with him?”

“In his chambers, where very soon I must go to bring him his bowl,” said the boy. “Walk with me as I fetch it and I will fill your own as well, for at this time of year our buffers are always full.”

The novice accepted a generous helping of rice, then followed the boy on his errand up the dim spiralling staircase which was the temple’s only hallway. It was built thus, the boy explained, to baffle stray photons.

“For glare is ever our enemy,” said the boy, pushing open the door to his master’s chamber. “Although there are greater perils, as my master could certainly tell you, if he were here.”

The novice followed the boy inside, puzzled. The high windowless room was lit only by the diffuse glow of a monitor on a solitary desk. The surface of the wide monitor could not be seen from this angle, but the glassy stare of the motionless, drooling old man behind it made the novice’s hair stand on end as surely as if his scalp had commanded every follicle to indicate its normal vector.

The boy slowly set the bowl down in front of his master, then backed away, taking care to avert his eyes from the screen.

“He is lost,” explained the boy bitterly. “You see, long ago he devised an ingenious algorithm for rendering any part of the mandelblob in the wink of an eye...”

“I have heard of this shape,” interrupted the novice, unable to tear his gaze from the master’s visage. “Rumors, only... a dread equation so small it may be inscribed on my little finger, yet describing a fractal sphere of infinite complexity.”

“Not just a sphere,” continued the boy. “A world; a worm-eaten world, implicit in the laws of number theory. Permeated by caves within caves within caves, their walls scarred by gaping chasms, yawning cracks and belching crevices. Pick any taffy-twisted tunnel, the smoothest you like, and if you zoom in far enough you’ll find that the surface wriggles and blisters and boils like putrid flesh on the cusp of liquescence, sprouting flaccid stalagmites a-crawl with mushrooms, mushrooms on mushrooms on mushrooms too tiny to be imagined, until they vanish into their own asymptotes, erupting on the other side as spores above spores above spores; and each spore is its own worm-eaten world as infinitely complex as its progenitor, yet perversely different from it too...

“My master had barely begun to explore this shape when by some accident he zoomed too deep into one particular nanoscopic nodule, one random spore among billions, and found—or so he claimed—that it was a verisimilitudinous image of our own world. Yes! Mathematical mountains exactly where our mountains lie, bursting with needled protuberances like ferns or fir-trees—all the same sickly amber hue, like the virtual cumuloids that hover above, and the simulated shorelines gritty with picoparticles of amber sand, where amber waves of graininess stand poised to break but never do; for this is a three-dimensional world, and for want of fourth nothing moves, not even the people. Yes, people! Monochromatic statues grotesque in face and form, yet human down to the eyelash-hairs, to the pores in their nostrils, like caves within caves...

“But in his trembling haste to plumb the depths of this flyspeck world, my master clicked left instead of right. His cursor jumped sideways and the crucial coordinates were lost forever. I am told his howls of anguish could be heard in the surrounding hills. Every monk of the temple rushed to this chamber, frantic to learn what great disaster had befallen. And thus did he relate the tale of his discovery.

“The other masters laughed at him, called him a liar or mad. Even monks of low station shunned him. So he set out to clear his name by finding those fateful coordinates again.

“Days became weeks, became months, became years, and now see what he is reduced to: a prisoner of the Unit Sphere, forever wandering while going nowhere, held captive by his own obsession. For a time, perhaps, he believed he had stumbled onto some Great Truth of the Universe, a calculable correspondence between the world of flesh and the one of figures. Now I cannot guess what landscapes he wanders, or why—nor would I wish to, lest I succumb to some irresistable fascination and so share his fate. It is said that fore-warned is fore-armed, but for me at least... I fear my mind. When the real meets the imaginary, their product is always complex.”

The novice edged forward to peer around the edge of the screen, but the boy stopped him.

“Take your rice and leave this cursed place,” said the boy. “And bring this one truth back to your own temple: that the Render Farm of Phong Province is no better than a poppy field, where daily we sow the doom of our people.”

“I do not see,” said the novice.

“The Emperor has but to name a pleasure—the thrill of battle among the stars, the viewing of immodest persons engaged in lecherous activities—and we will serve it to his private chambers in six million pixels of sixteen million colors at sixty frames a second. But do not envy him this. Instead fear the day that you and I enjoy the same liberty. For though we have created an eternity of wonders here, none of us are given an eternity to explore them. How precious is time; and how empty, ultimately, is any world but our own.”

Comments

New social movements such as Occupy need institutions to help elaborate their ideas. Where will a modern collective intellectuality spring from?

The recent Occupy and Indignados movements around the world have shown the extent of the backlash against the injustice generated by the ongoing crisis of capitalism and the difficulty in articulating a co-ordinated alternative, and as such have been a source of abundant political commentary.

One rarely commented-upon aspect is the way intellectuals have responded to them. During the Zucotti Park occupation in New York in autumn 2011, acclaimed critical intellectuals – among them Slavoj Žižek, Judith Butler and Cornel West – came to support the occupiers, and to give speeches in front of them, aired through the "human microphone". A weird law in New York forbids the use of electric microphones in public space so the only way for the speaker's voices to get through was for the front rows of the crowd to loudly repeat each of their sentences. The resulting litany resembled a kind of postmodern ritual. These speeches were then rapidly posted on YouTube.

This of course is not the first time committed intellectuals have spoken in support of a movement of occupation. The Zucotti Park scene recalls a famous speech given by French philosopher Jean-Paul Sartre at the Renault automobile plant, at Boulogne-Billancourt near Paris, in 1970. Perched on a cask, Sartre addresses the workers on strike, and tells them that the alliance between intellectuals and the working class that once existed should be rebuilt. These were times of revolutionary upheaval, in France and elsewhere, and intellectuals were urged to take sides.

Despite visual similarities, these two scenes, separated by more than 40 years, are in fact very different. For one thing, Sartre used an electric microphone – modernity had not yet become postmodernity. Sartre also wore a fur coat that only militant hipsters would dare to wear these days.

More seriously though: Sartre spoke in front of automobile, ie industrial, workers, whereas Žižek, Butler and West addressed a more indeterminate audience. The exact sociology of the current global movements is still up for debate. A more "middle class" recruitment than the worker's movement of the 19th and 20th century, with higher "cultural capital", seems indisputable, though important sectors of the working classes are also involved. Žižek, Butler and West, moreover, spoke not in front of an occupied factory, as Sartre did, but in a public place. The occupation of public places is a trademark of these new movements, and the difference is crucial. If occupying public spaces is a matter of "reclaiming the street", or of demanding a "right to the city", then it is simultaneously a symptom of their not knowing what else to occupy.

There is a second crucial difference between the two scenes. Sartre was never actually a member of a working class organisation but his political and intellectual universe was organised around their existence, and they structured the political field in which he spoke when he addressed the workers. What about Žižek, Butler and West? It may be a good thing or not, but today's critical intellectuals, no matter how committed they may be, are "free-floating" and not organically linked to any kind of organisation.

A final difference between these two scenes is that Sartre was not an academic. He was so distrustful of bourgeois institutions that he refused the Nobel prize for literature in 1964 (as Guy Debord said at the time, refusing the Nobel prize is nothing, the problem is having deserved it). Sartre was very successful as a novelist and a philosopher, which permitted such "aristocratic" dismissal of all things vulgarly bourgeois. Žižek, Butler and West, on the other hand, are academics, as are most, if not all, critical thinkers today. Exceptions may be found, such as Bolivian vice-president Alvaro Garcia Linera, who is one of Latin America's finest philosophers and sociologists. But today, the production of influential critical ideas is more and more the monopoly of academics.

Universities have changed considerably since the end of the 19th century, transformed from small, elitist institutions to mass learning ones. However, the political and intellectual fields have grown more and more apart since the second part of the 20th century, to the point that non-academic intellectuals (even among fiction writers) are a species virtually extinct.

For the Italian Marxist Antonio Gramsci, the purpose of a political party of the working classes is not only to organise collective action, but also to organise collective thought and knowledge. And such serious thinking takes time. It requires permanent organisation, and not only "temporary autonomous zones", to quote a widespread slogan in today's movements. It also requires "mediating" institutions that permit theory and political practice to interact. What else has been the purpose of the worker's daily paper, the cadre training school, the radical publishing house, or the theoretical journal?

Each epoch comes up with its own forms of collective intellectuality, its own original mediating institutions. What will these look like in the 21st century? This is a question of utmost strategic importance. In the nascent field of so-called "distance education", universities have a considerable advantage, but the international left has to catch up. However deep the current crisis of capitalism, the majority of the people will not be convinced to participate in grand-scale social transformation processes unless the "where next?" question is answered – and these mediating institutions are precisely the place where it should be tackled.

One should start by acknowledging that, despite all the fuss about the internet, Facebook, Twitter, and "horizontality", all recent interesting ideas coming from the left have been elaborated in rather old-fashioned journals, such The New Left Review, the Socialist Register, Historical Materialism and their equivalents in other countries. These now come with websites and social media accounts. But this has in no way altered the content and style (for instance, the length) of their articles. The same can be said about books written by critical thinkers. Alain Badiou, Butler, Žižek, Antonio Negri, Leo Panitch or Donna Haraway write books that are no less substantial than the ones published by previous generations of critical intellectuals.

This doesn't mean that the left shouldn't use new media, of course. These were abundantly taken advantage of, for instance during the Arab spring, to mobilise and organise. But when it comes to elaborating relevant ideas by way of the new media, much remains to be done. One pioneering initiative has been that of David Harvey, the British radical geographer based in New York, who recorded his classes about Marx's Capital and posted them on his website, where they have been seen by thousands around the world. More of this is needed.

This is not to say that the teaching only goes one way. The ongoing social movements have produced and will produce in the years to come innovative knowledge and political knowhow. One striking example is the question of "gratuity" – the claim for free access to public services, such as parks in Turkey or public transportation in Brazil, has been central to these movements. Yet there exists no serious theory of gratuity in critical theories today, which would provide a history of this demand, or analyse its anti-capitalist potential. Hence, more than ever, intellectuals should learn from the movements from below. This means not only supporting them "from outside" once they have occurred, as many have done, but conceiving of one's intellectual activity as part and parcel of a collective intellectuality. Only then will the monopoly of academics on the production of influential critical theories be broken.

I ventured forth into the fair(y) realm of LISP, and all manner of strange and wonderful things came to be.

Actually, not that much. It’s that time of the year when pre-Xmas madness starts settling in, and as a result there has been entirely too much going on for me to devote a time to my personal projects.

Things have been a bit quiet on the Clojure front, too, at least as far as active coding is concerned. I’ve had to tend to (many) other matters since my last foray into heavy parallelism and got somewhat quagmired in Cascalog (and its rather unhelpful documentation) to boot.

But I’ve been asked to review Clojure High Performance Programming and am about halfway through, so you can expect a little more about that in a few days.

Still, in between work and other affairs, I managed to sneak in a bit more LISP in the guise of Wisp and Hylang. In case you’ve never come across either, here’s a short introduction:

JavaScript done right?

Wisp is a Clojure-like LISP dialect that compiles down to (very nice) JavaScript.

It’s self-hosting, and even though it requires a compilation step (and a working Node setup) I find it more practical than ClojureScript — if only because the compiler is instantaneous (unlike lein-cljsbuild) and the resulting code doesn’t require a runtime if you stick to standard JavaScript data structures.

That turns out to be one of the main differences between Wisp and ClojureScript — Wisp doesn’t involve the use of Clojure-like immutable data structures, and the ease with which it interoperates with JavaScript makes it trivial to use existing JavaScript libraries like Knockout (which we use internally) and Angular (which I’m currently fiddling with).

Another big difference is its nice, readable compiled output. The clear one-to-one match with your own code (which, by the way, includes sourcemaps) makes it a pleasure to use. And that’s before you start using macros — then it gets really interesting.

For my own use, I built a set of different browser bundles with varying capabilities (bundling the read/eval/loop and compiler, a minimal runtime, etc.). That way I can compile and run Wisp directly on the browser (via application/wisp scripts), allowing for very tight iteration.

But for mid-to-large projects I suppose I’ll need to stick to the “normal” approach and set up a build step.

Saying Hy

Hylang is a rather different beast. It’s been around for a bit, and is a LISP dialect that ties directly into the Python runtime. It generates Python ASTs, and is therefore indistinguishable from “regular” Python — which means it works perfectly with PyPy, making it a very fast language.

It too lacks Clojure‘s immutable data structures — that may deter some purists, but the resulting mix of Clojure-inspired syntax and Python libraries is delightfully pragmatic and very enjoyable to code in.

The mind-boggling thing about it is how seamless the interop is. I can import and use Python modules directly (of course — and this makes Hy one of the most immediately useful LISP dialects, right off the bat), but Python can also import and use Hy modules. And the language is so well integrated that debuggers like pdb “just work”.

In between these two and Clojure, I think my immediate needs are covered — I can quickly prototype stuff in Hy, paste a fair amount of the resulting code into a Clojure project, and build a web front-end with Wisp.

With a few macros and some careful tweaks, I might even be able to run the exact same code on all of them, although that will of course depend mostly on what kind of data structures I’m using — and you can’t really take full advantage of Clojure without buying in to the whole thing, not just the syntax.

But it’s a nice way to slide into the groove, so to speak, and lessening friction when switching between environments helps a lot.

☯

Comments

Apple Mac OS X 10.9 suffers from a hard link memory corruption issue.

Novelist Dave Eggers new book the Circle calls to mind one of the most detailed and entertaining accounts of life at Google, a 2005 novel called Virtual Love written by a then-Google executive named Kim Malone Scott.

The Change

Very simply put, you can no longer sign a bundle (like your .app) if any nested bundle in that package is unsigned. These nested bundles are things like helper executables, embedded frameworks, plug-ins and XPC services.

The result is that you’ll need to update your Xcode projects as soon as you start building on 10.9. It’s taken me several days to understand what these changes are, and with the help of Perry Kiehtreiber on the developer forums, I’d like to share what I’ve learned.

(Yes, I realize this essay is going to break the NDA, but since Apple is asking us to submit apps for Mavericks, I want as many developers as possible to avoid the utter confusion I faced earlier this week.)

The Effect

So what happens when you do your first app build on 10.9 using Xcode 5.0.1? If you embed a framework that’s unsigned, like the very popular Sparkle.framework, you’ll see a message during the final CodeSign build phase:

CodeSign build/Release/xScope.app
    cd /Users/craig/Projects/Mac/xScope
    setenv CODESIGN_ALLOCATE /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/codesign_allocate
    Using code signing identity "Developer ID Application: The Iconfactory"
    /usr/bin/codesign --force --sign D2A3FE1814B0BA31B1924F1C3C3B5C89643FBED5 --requirements =designated\ =>\ anchor\ apple\ generic\ \ and\ identifier\ \"xScope\"\ and\ ((cert\ leaf[field.1.2.840.113635.100.6.1.9]\ exists)\ or\ (\ certificate\ 1[field.1.2.840.113635.100.6.2.6]\ exists\ and\ certificate\ leaf[field.1.2.840.113635.100.6.1.13]\ exists\ \ and\ certificate\ leaf[subject.OU]\ =\ \"RYQWBTQRPT\"\ )) /Users/craig/Projects/Mac/xScope/build/Release/xScope.app
/Users/craig/Projects/Mac/xScope/build/Release/xScope.app: code object is not signed at all
In subcomponent: /Users/craig/Projects/Mac/xScope/build/Release/xScope.app/Contents/Frameworks/Sparkle.framework
Command /usr/bin/codesign failed with exit code 1

** BUILD FAILED **

The codesign command is reporting that “code object is not signed at all” and Xcode is adding the “In subcomponent” to tell you which framework is at fault (it could just have easily been HockeyApp or any other third-party framework you use.)

So how do you go about fixing this?

The Wrong Way

In the past, many developers have relied on codesign‘s --deep option to make sure the entire bundle is signed. Specifying this option in “Other Code Signing Flags” will get rid of the error during the build, but all you’re doing is just postponing the pain.

The reason is that --deep recursively signs the nested bundles. As it does this, it applies the parameters for the top-level bundle to all the nested bundles. Things like your app’s entitlements will cause the resulting bundles to not be valid.

In fact, if you try to download and install the resulting app, Gatekeeper will notify your customers that your app is damaged and can’t be opened, with a default button to move it to the Trash:

You’ll see the same thing if you check the binary using the command line:

$ spctl --verbose=4 --assess --type execute build/Release/xScope.app
build/Release/xScope.app: a sealed resource is missing or invalid

The Right Way

What’s the right way to make sure the embedded framework is correctly signed? The answer is to add another Build Phase to your target.

If you’re embedding frameworks, you’ll have a “Copy Files” phase that moves things like Sparkle.framework into the Frameworks destination. Just after this Build Phase, add a Run Script with the following shell commands:

LOCATION="${BUILT_PRODUCTS_DIR}"/"${FRAMEWORKS_FOLDER_PATH}"
IDENTITY="Developer ID Application: The Iconfactory"
codesign --verbose --force --sign "$IDENTITY" "$LOCATION/Sparkle.framework/Versions/A"

This short script tells Xcode to sign the framework that’s just been copied into the build product. In this case, it’s using the Developer ID for Gatekeeper. If you were doing a build for the Mac App Store you’d use your “3rd Party Mac Developer Application” identity. Add a codesign command for every framework you use.

If you have other embedded code, such as helper executables, plug-ins or XPC services, you’ll need to sign them appropriately after copying them into your app bundle.

Updated October 18th, 2013: Another alternative is to set the code signing identity in the Build Settings of the frameworks you’re building from source. The trick here is that the identity of the framework needs to match the identity of the app itself. You can’t have have an App Store distribution identity for the framework and a Developer ID for the app. I found it much easier to explicitly re-sign the frameworks than to pass configuration settings from MyApp.xcodeproj to MyFramework.xcodeproj. It’s also easier to manage because the project changes are the same for binary-only frameworks (like Sparkle) and frameworks we build from source (like Chameleon).

The Checks

You’ll want to do a quick check of the build product before uploading it to either your website or iTunes Connect. The first thing you’ll want to do is check the signed bundle meets its designated requirement:

$ codesign --verify --verbose=4 build/Release/xScope.app
--validated:/Users/craig/Projects/Mac/xScope/build/Release/xScope.app/Contents/Frameworks/Sparkle.framework/Versions/Current/.
build/Release/xScope.app: valid on disk
build/Release/xScope.app: satisfies its Designated Requirement

If there’s a problem, you’ll see a message that the app “does not satisfy its designated Requirement”. To view information about the signed code or the designated requirements, you can use these commands:

$ codesign --display --verbose=4 build/Release/xScope.app
$ codesign --display --verbose=4 build/Release/xScope.app/Contents/Frameworks/Sparkle.framework
$ codesign --display --requirements - --verbose=4 build/Release/xScope.app
$ codesign --display --requirements - --verbose=4 build/Release/xScope.app/Contents/Frameworks/Sparkle.framework

If this is a build you’ll be uploading to your website, you’ll want to make sure it will be accepted by Gatekeeper (and not display the “damaged” dialog.) Use spctl to do this:

$ spctl --verbose=4 --assess --type execute build/Release/xScope.app
build/Release/xScope.app: accepted
source=Developer ID

If this is an App Store build, you MUST check the .pkg file that gets uploaded to iTunes Connect (see the next section and you’ll see why I say MUST.) If you use productbuild to create the package manually, you’ll already have a .pkg file to test.

For those of you who submit archives directly from Xcode, you can generate the .pkg file using the command line:

$ xcodebuild -exportArchive -exportFormat PKG -archivePath /path/to/your.xcarchive -exportPath /tmp/CHOCKS -exportSigningIdentity "3rd Party Mac Developer Application: CHOCK LOCK INK” -exportInstallerIdentity "3rd Party Mac Developer Installer:  CHOCK LOCK INK"

You can find the path to your .xcarchive by selecting it in the Organizer and then using the Editor > Show in Finder menu item. The command above will create a /tmp/CHOCKS.pkg. Yes, you now have CHOCKS PACKAGE IF YOU KNOW WHAT I MEAN

(A quick side note, if you use xcodebuild, it got a lot of love in Mavericks. Make sure to check out the man page.)

To check out CHOCKS.pkg, run the installer with the -store option:

$ sudo installer -store -pkg /tmp/CHOCKS.pkg -target /
installer: Note: running installer as an admin user (instead of root) gives better Mac App Store fidelity
installer: CHOCKS.pkg has valid signature for submission: 3rd Party Mac Developer Installer: The Iconfactory
installer: Installation Check: Passed
installer: Volume Check: Passed
installer: Bundle com.artissoftware.mac.xScope will be installed to /Applications/xScope.app
installer: Starting install
installer: Install 0.0% complete
installer: Install 13.8% complete
installer: Install 22.2% complete
installer: Install 47.6% complete
installer: Install 88.3% complete
installer: Install 100.0% complete
installer: Finished install

Now, sign out of the App Store and launch the app that was just installed in your Applications folder. If everything is OK, you’ll see the prompt for your Apple ID and a receipt will be written in the app’s _MASReceipt folder.

But not always.

(For more information on testing installer packages, check out the Testing section in my Mac App Store Guide.)

The Suckage

After being installed for the first time, some apps never get a receipt when they are launched on Mavericks. The app starts up, sees that there’s no receipt in /Contents/_MASReceipt and signals that it’s missing by exiting with a 173 code. Normally, storeagent will recognize this and prompt for an Apple ID. After valid credentials are provided, the receipt is written and the app is launched again.

Several developers, myself included, have noticed that after exiting with a 173, only the following is logged in the console:

Oct 17 11:59:03 Myrtle.local storeagent[72031]: Unsigned app (/Applications/Twitterrific.app).

If this happens to you, it seems your only course of action is to not validate the receipt. Your code will launch fine if you never return a 173. Which, of course, sucks because it’s then trivial to pirate your the app.

For any Apple folks that might be reading this, check out the Radar: rdar://problem/15254213

Updated October 18th, 2013: Developers that are doing their builds on 10.8 also need to watch out for this problem. As a workaround, I tried building the product on 10.8.4 using Xcode 5.0. The resulting .pkg exhibited the same behavior at launch time as the one created with the Xcode GM on Mavericks.

The Workarounds

Xcode sometimes has problems generating a valid designated requirement. When you check the designated requirement, you might see this:

$ codesign --verify --verbose=1 build/Release/Twitterrific.app
build/Release/Twitterrific.app: valid on disk
build/Release/Twitterrific.app: does not satisfy its designated Requirement

$ codesign --display --requirements - build/Release/Twitterrific.app
Executable=/Users/craig/Desktop/BugReport/Ostrich/build/Release/Twitterrific.app/Contents/MacOS/Twitterrific
designated => anchor apple generic and identifier Twitterrific and (certificate leaf[field.1.2.840.113635.100.6.1.9] /* exists */ or certificate 1[field.1.2.840.113635.100.6.2.6] /* exists */ and certificate leaf[field.1.2.840.113635.100.6.1.13] /* exists */ and certificate leaf[subject.OU] = RYQWBTQRPT)

If you look closely, you’ll see that the identifier used for the requirement is incorrect: it should be com.iconfactory.Twitterrific, not just Twitterrific. The workaround for this bug is simply to set the identifier explicitly in your Build Settings. In our case, we added --identifier com.iconfactory.Twitterrific to Other Code Signing Flags.

Updated October 18th, 2013: It looks like this bug happens when you precompile your Info.plist. Thanks to Chris Liscio for verifying that problem. Make sure to dupe it, if you’re affected!

As to why you’d want to precompile your Info.plist, there are two good reasons.

The End

There you have it: a short summary of my last three days of confusion caused by new Gatekeeper requirements, issues with Xcode and bugs in Mavericks. Hopefully, this essay will save you some of that same agony.

Jellyfish, scourge of the seas, have prompted the shutdown of a nuclear plant in Sweden. Time for those jellyfish-killin' robots to get to work.

Read more...

There's a mobile ecosystem battle raging, with Apple and Google racing to build end-to-end mobile monopolies. According to VisionMobile, "The triumph of iOS and Android is a testament to the superiority of ecosystems economics over legacy business models." Sadly, this triumph has a casualty, and that casualty is you.

It all worked great when Apple was a hardware company that dabbled in software, and when Google focused on cloud services but didn't veer into hardware. Now that these companies are encroaching on each others' turf, some essential things are getting lost in translation.

Like sync.

Apple Sinks On Sync

We live in an increasingly mobile world, which requires correspondingly tight synchronization between these devices. Sadly, even when buying into one vendor's end-to-end stack (hardware, software, cloud), sync is not guaranteed. At least, not with Apple.

I've written before about Apple's hit-or-mostly-miss approach to cloud services. Perhaps once a year I take up the topic, and each year the story is the same: Apple sync always feels like a kluge. 

This isn't because it hasn't had smart people working on the problem. I've worked with a number of people from Apple's MobileMe/iCloud team, and they're exceptional. But Apple never placed a premium on the work they did. Apple's DNA is amazing industrial design with elegant interfaces. Cloud? Not so much.

So I've dumped iCloud for everything but synchronization of Notes from my MacBook Air to my iPhone and iPad. It mostly works. Sometimes. Cloud is Apple's Achilles Heel.

Google's "Standard" Approach To Sync

Which is why I have turned to Google to handle synchronization of my most important data across devices. But even Google's sync has started to falter, though in its case the problem seems to have less to do with technical ability and more to do with political maneuvering. 

If you're an iPhone user that depends upon Google services like Gmail, Google Calendar or Google Contacts, life was great when Google supported Microsoft's Exchange ActiveSync (EAS) technology. You'd make a change on your phone and it would immediately be reflected on every other device. Brilliant.

But it also made life easy on rival platforms. So in a move ostensibly to embrace open standards like CalDAV and CardDAV, but very likely done to burn bridges to rival ecosystems, Google announced that starting January 30, 2013, new users wouldn't have access to EAS, and instead would need to use IMAP (email), CalDAV (Calendar) and CardDAV (Contacts). 

Suddenly, syncing Google's services with Apple's products doesn't work nearly as well. I can use Google's Gmail app, but it's not deeply integrated into Apple's iOS experience. If you want the premium integrated ecosystem experience of yesteryear, you're out of luck. Or out of sync, as the case may be. 

Sync At A Snail's Pace

The genius of EAS was that it was push-based, rather than Google's pull-based approach (or "fetch," in Apple's iOS terminology). In an iOS fetch world, things get around to synching every 15, 30 or 60 minutes, or you can arrange to only sync manually. 

This sounds like a minor thing until you move from a push-based world back into the fetch-based Stone Ages. I've been experimenting with Google's CalDAV and CardDAV today, and have found it somewhat infuriating. I made a change in my browser then had to run out the door to an appointment, and waited... and waited... and waited for the appointment to make its way to my device. There is a refresh button which I repeatedly tried pressing to get a manual sync moving, but it didn't seem to do anything.

Almost as bad, for those of us who use Google's services for both work and home, Google's sync has a range of known issues with iOS, including serious limitations in how it handles managed calendars. That is, in order to avoid jumping back and forth between tabs for home and work calendars, both of which are stored in Google, Google lets me manage my home calendar from my work calendar. 

But not on my iPhone. And enabling my work Google account and a separate personal Google account results in Google sending me double alerts for every event (I can't seem to turn one off). So not only is Google's new and improved sync terribly slow, but it's also overly chatty.

Can't We All Just Get Along?

Third-party tools don't help. I bought CalenMob to help me tame sync by completely bypassing Apple's iOS calendar app, and I almost as quickly decommissioned it. The interface is pretty, but the functionality is lacking. CalenMob entries make it to my iPhone Calendar app, but not to the Google server. (Bizarrely.) SMS notifications get turned into standard pop-up notifications. And so on.

Has anyone else found a way to live happily on Apple's hardware using Google's cloud services? Don't tell me, "Android comes with native integration of its services. " I know that. But the point is that I, and much of the market, isn't interested in an end-to-end, cradle-to-grave affiliation with one particular ecosystem. We want choice. And right now our only choice is broken-by-design sync.

Dan Goodin / Ars Technica:
Google confirms critical Android crypto flaw used in $5,700 Bitcoin heist  —  Google developers have confirmed a cryptographic vulnerability in the Android operating system that researchers say could generate serious security glitches on hundreds of thousands of end user apps, many of them used to make Bitcoin transactions.

There are several new data points this week in the ongoing cratering of IBM as an IT vendor. The state of Pennsylvania cancelled an unemployment compensation system contract that was 42 months behind and $60 million over budget. Big Blue has been banned from the Australian state of Queensland after botching a $6.9 million SAP project that will now reportedly cost the people of Queensland $A1.2 billion to fix. That’s some botch. Credit Suisse analyst Kulbinder Garcha says IBM has a cash flow problem and downgraded the stock. At IBM’s Systems & Technology Group, management announced to employees a one week mandatory furlough at the end of August or beginning of September. And finally, I’m told that there is now a filter on the IBM corporate e-mail system that flags any messages that contain the word Cringely.

I’m flattered.

These are acts of desperation and I can only conclude that IBM can no longer make the decisions necessary to save itself.  It is so fixated on its goals and so sure its process is the only right way of doing things, it cannot see alternatives.

The Australian IT project debacle is a classic example of IBM’s unique way of managing projects. The core of project management is “documented deniability.”  They will do exactly what you tell them. They will document it.  They will work against the documented requirements.  When done, you have to pay them because they did exactly what you told them. The key problem to this approach is “does it work?”

The ultimate goal of every project is to build something that produces value or income. A factory makes products.  A bridge assists transportation.  In IBM’s project management IBM does not care about the ultimate goal. That is their customers concern, not IBM’s. This is very important for IBM’s customers to understand. It is the reason so many big IBM projects are failing.

This is the way IBM historically does its business, even in better times. Remember the mantra has always been to fulfill customer requirements. But somewhere along the line the whole idea went horribly, horribly wrong.

IBM will sell you hardware, software, programming, and support services.  What you do with it is your responsibility.

When a highway department wants to build a bridge, there are both stated and unstated requirements.  The project manager and engineers start with the stated requirements and find and analyze all the unstated requirements.  A highway department will have a general idea where the bridge should be built.  In the analysis the bridge building firm may discover important reasons to build the bridge in a different location.  The firm will look at traffic patterns and recommend and optimal design to meet the highway departments ultimate requirement — to make long term improvements in transportation.

If IBM built that bridge, they’d build it exactly where the highway department suggested and how they suggested.  If the foundation was weak the the bridge started to tilt, it’s not IBM’s fault. You told them where to build the bridge. They did what you told them. They also never analyzed every aspect of your requirements. They did no testing. They did no prototyping. They just do what you tell them to.

They fulfilled customer requirements.

Fixated solely on its 2015 earnings target, IBM is making decisions based solely on their balance sheet.  They are ignoring and damaging the overall operation of their business. They have the time and the money to save the company.  Yet they are doing more and more things that are ultimately destructive to the very survival of IBM.

 

• Share Post
• Twitter
• Facebook
• Google +1
• Email19

The post Fulfilling customer requirements is a weapon at IBM appeared first on I, Cringely.

Comments

Display

Audrey Watters, Hack Education, August 1, 2013

---

Seymour Papert was injured in a traffic accident in 2006 and carries the effects to this day. Audrey Watters takes the occasion of the latest Mindstorms robotics kit (sent to her as a promo by Lego) and a visit to Maine to interview Papert and reflect on his work. She cites  a line in a 2011 Wired Magazine article about Khan Academy where Bill Gates dismisses (with an expletive) Papert's constructionism. "It highlights Gates' dismissal of established learning theories, his ego, his ignorance," she writes, ""the huge gulf between those like Gates who have a vision of computers as simply efficient content delivery and assessment systems and those like Seymour who have a vision of computers as powerful and discovery learning machines." To my mind, it's the work of people like Gates who use computers to (as Papert says) "put children through their paces" that should be dismissed with an expletive. (p.s. I was never a Lego person, but I spent a lot of time with Meccano.)

[Link] [Comment]

Comments

“Next to reasoning, the greatest handicap to the optimum development of Man lies in the fact that this planet is just barely habitable. Its minimum temperatures are too low, and its maximum temperatures too high. Its day is not long enough, and its night is too long… These factors encourage depression, fear, war, and lack of vitality. They describe a planet, which is by no means perfectly devised for the nurturing or for the perpetuation of a higher intelligence.” -James Thurber

It’s been just about three years, now, since the first announced discovery of a planet in another star system found within its parent star’s habitable zone.

That star happened to be Gliese 581, a red dwarf star — an M-class star — located about 20 light years away. There are a whole slew of relatively nearby stars named “Gliese” followed by a number; that’s because in the second half of the 20th Century, the German astronomer Wilhelm Gliese started doing a massive survey of stars located within 20 parsecs (or 65 light-years) of Earth. It’s been extended since then, and we now have a very extensive catalogue of thousands of stars located in our local neighborhood of 82 light-years or so: the Gliese Catalogue of Nearby Stars.

The vast majority of these stars are M-class stars, the lowest-mass, reddest, and longest-lived type. It turns out — as we’ve learned from this and other surveys — that these red dwarfs, the M-class stars, are by far the most common type of star in the Universe: some 3-out-of-every-4 stars are like them! The Sun, a G-class star, is a relative rarity, as it’s brighter and more massive than 95% of the other stars out there.

So it’s no surprise that the first star that they discovered a planet potentially capable of harboring life-as-we-know-it (i.e., a planet with Earth-like conditions) was around one of these nearby M-class stars. Initially found to have four planets labelled a-through-d, where “c” was just a little too hot and “d” a little too cold, subsequent data and analysis showed evidence for a planet in between those two: Gliese 581 g.

It was determined to fall dead-center in its star’s habitable zone, making it a prime candidate for life as we know it, and the first discovered planet outside of our Solar System that’s potentially habitable, as far as we understand it.

But just because something’s potentially habitable doesn’t mean it’s actually inhabited! Still, you’d never know it from the 2010 nterview with Steven Vogt, the lead author on the paper announcing its discovery:

I’m not a biologist, nor do I want to play one on TV. Personally, given the ubiquity and propensity of life to flourish wherever it can, I would say that… the chances of life on this planet are 100%. I have almost no doubt about it.

There are some things that are really worth thinking hard about before we make the leap from habitable to inhabited. Here are some of them.

Here in our Solar System, Earth is the largest of all the rocky bodies present. The next largest body, after Earth, is Uranus, which outweighs us by a factor of around 15, and is a little more than double our planet’s diameter.

No one seriously considers that gas giant planets are good candidates for Earth-like life to develop. That isn’t to say that life couldn’t develop on a gas giant, just that it would likely be very, very different from the life we find on our world. And yet, what we typically call super-Earths might actually be more like mini-Uranuses; Sara Seager calls them gas dwarfs. With a mass of around four times our Earth, it’s far from clear that a rocky planet like Earth is the right analogy for this world.

There’s also the important issue of heat transfer. On the surface of Earth, we have relatively warm days and relatively cool nights, but the short duration of our day means that the night side of the planet doesn’t freeze solid, and the day side doesn’t boil away. But the story would be very different if Earth were tidally locked to the Sun, the same way the Moon is locked to us. If the Earth had a permanent day-side and a permanent night-side, it might make habitability a pretty interesting question.

Well, guess what? Gliese 581 g is tidally locked to its star! In a worst-case scenario, that means there’s only a thin ring, on the border between night-and-day, that has a shot at life, but in a better-case scenario, a thicker atmosphere does an excellent job at transferring heat from the day side to the night side, keeping it in relative thermal equilibrium, like Venus. (Although hopefully it’s not some 700 Kelvin like Venus, with its awful, poisonous atmosphere is!)

My point is, there are some unknowns here, and they’re some big ones.

Some other things worth considering?

1. This star is older than the Sun: at least seven billion years old and possibly as much as 11 billion years old. If there ever was life on this world, could it have sustained itself this long without catastrophically poisoning its environment, and rendering it uninhabitable?
2. This star contains just 46% of the heavy elements that the Sun contains, an indication that there are fewer dense, heavy elements in the planets in this Solar System. Does that make it impossibly hard for life to develop?
3. The average temperature on this planet, based on its distance from the Sun, is cold, as in well-below-freezing cold. Is there a sufficient greenhouse gas effect to have liquid water on its surface, what we typically think of as the “gold standard” for habitability?

And finally, does this planet even exist? It’s actually very controversial, because the follow-up studies we typically do to confirm an exoplanet’s existence have turned up empty-handed on this world. It may still exist, but it remains unconfirmed.

That isn’t to say that it’s likely that there are no inhabited planets out there; there almost definitely are.

It’s just that we’re a long way from being able to state anything with 100% certainty as respects the most ideal planetary candidate for life, and Gliese 581 g is far from ideal. I’d still bet on life if you offered me even odds, but 100%? There’s a big difference between potentially habitable and actually inhabited.

Streaming video is now available for the talks at the QStart conference, a couple weeks ago at Hebrew University in Jerusalem.  If you’re the sort of person who likes watching quantum information talks, then check out the excellent ones by Ray Laflamme, John Martinis, Umesh Vazirani, Thomas Vidick, Jacob Bekenstein, and many others.

My own contribution—the first “backwards-facing, crusty, retrospective” talk I’ve ever given—was called The Collision Lower Bound After 12 Years (click here for the slides—and to answer the inevitable question, no, I have no idea how to open PowerPoint files in your favorite free-range, organic computing platform).  Briefly, the collision lower bound is the theorem that even a quantum computer needs at least ~n^1/3 steps to find a duplicate in a long list of random numbers between 1 and n, even assuming the list is long enough that there are many, many duplicates to be found.  (Moreover, ~n^1/3 steps are known to suffice, by the BHT algorithm, a clever adaptation of Grover’s search algorithm.  Also, for simplicity a “step” means a single access to the list, though of course a quantum algorithm can access multiple list elements in superposition and it still counts as one step.)

By comparison, for classical algorithms, ~√n steps are necessary and sufficient to find a collision, by the famous Birthday Paradox.  So, just like for Grover’s search problem, a quantum computer could give you a modest speedup over classical for the collision problem, but only a modest one.  The reason this is interesting is that, because of the abundance of collisions to be found, the collision problem has a great deal more structure than Grover’s search problem (though it has less structure than Shor’s period-finding problem, where there famously is an exponential quantum speedup).

One “obvious” motivation for the collision problem is that it models the problem of breaking collision-resistant hash functions (like SHA-256) in cryptography.  In particular, if there were a superfast (e.g., log(n)-time) quantum algorithm for the collision problem, then there could be no CRHFs secure against quantum attack.  So the fact that there’s no such algorithm at least opens up the possibility of quantum-secure CRHFs.  However, there are many other motivations.  For example, the collision lower bound rules out the most “simpleminded” approach to a polynomial-time quantum algorithm for the Graph Isomorphism problem (though, I hasten to add, it says nothing about more sophisticated approaches).  The collision problem is also closely related to Statistical Zero Knowledge (SZK) proof protocols, so that the collision lower bound leads to an oracle relative to which SZK is not in BQP.

Probably the most bizarre motivation to other people, but for some reason the most important one to me back in 2001, is that the collision problem is closely related to the problem of sampling the entire trajectories of hidden variables, in hidden-variable theories such as Bohmian mechanics.  The collision lower bound provides strong evidence that this trajectory-sampling problem is hard even for a quantum computer—intuitively because a QC can’t keep track of the correlations between the hidden-variable positions at different times.  The way I like to put it is that if, at the moment of your death, your entire life history flashed before you in an instant (and if a suitable hidden-variable theory were true, and if you’d performed an appropriate quantum interference experiment on your own brain during your life), then you really could solve the collision problem in only O(1) steps.  Interestingly, you still might not be able to solve NP-complete problems—I don’t know!  But you could at least do something that we think is hard for a quantum computer.

I proved the first collision lower bound in 2001 (actually, a week or so after the 9/11 attacks), after four months of sleepless nights and failed attempts.  (Well actually, I only got the weaker lower bound of ~n^1/5; the ~n^1/3 was a subsequent improvement due to Yaoyun Shi.  Before ~n^1/5, no one could even rule out that a quantum computer could solve the collision problem with a constant number of steps (!!), independent of n—say, 4 steps.)  It was the first thing I’d proved of any significance, and probably the most important thing I did while in grad school.  I knew it was one of the favorite problems of my adviser, Umesh Vazirani, so I didn’t even tell Umesh I was working on it until I’d already spent the whole summer on it.  I figured he’d think I was nuts.

---

Bonus Proof Explanation!

The technique that ultimately worked was the polynomial method, which was introduced to quantum computing four years prior in a seminal paper of Beals et al.  In this technique, you first suppose by contradiction that a quantum algorithm exists to solve your problem that makes very few accesses to the input bits—say, T.  Then you write out the quantum algorithm’s acceptance probability (e.g., the probability that the algorithm outputs “yes, I found what I was looking for”) as a multivariate polynomial p in the input bits.  It’s not hard to prove that p has degree at most 2T, since the amplitudes in the quantum algorithm can be written as degree-T polynomials (each input access increases the degree by at most 1, and unitary transformations in between input accesses don’t increase the degree at all); then squaring the amplitudes to get probabilities doubles the degree.  (This is the only part of the method that uses anything specific to quantum mechanics!)

Next, you choose some parameter k related to the problem of interest, and you let q(k) be the expectation of p(X) over all inputs X with the parameter equal to k.  For example, with the collision problem, it turns out that the “right” choice to make is to set k=1 if each number appears exactly once in your input list, k=2 if each number appears exactly twice, k=3 if each number appears exactly three times, and so on.  Then—here comes the “magic” part—you show that q(k) itself is a univariate polynomial in k, again of degree at most 2T.  This magical step is called “symmetrization”; it can be traced at least as far back as the famous 1969 book Perceptrons by Marvin Minsky and Seymour Papert.  In the case of the collision problem, I still have no explanation, 12 years later, for why symmetrization works: all I can say is that you do the calculation, and you cancel lots of things from both the numerator and the denominator, and what comes out at the end is a low-degree polynomial in k.  (It’s precisely because I would never have predicted such a “zany coincidence,” that I had to stumble around in the dark for 4 months before I finally discovered by chance that the polynomial method worked.)

Anyway, after applying symmetrization, you’re left with a low-degree univariate polynomial q with some very interesting properties: for example, you need 0≤q(k)≤1 for positive integers k, since then q(k) represents an averaged probability that your quantum algorithm does something.  You also need q(1) to be close to 0, since if k=1 then there no collisions to be found, and you need q(2) to be close to 1, since if k=2 then there are lots of collisions and you’d like your algorithm to find one.  But now, you can appeal to a theorem of A. A. Markov from the 1890s, which implies that no low-degree polynomial exists with those properties!  Hence your original efficient quantum algorithm can’t have existed either: indeed, you get a quantitative lower bound (a tight one, if you’re careful) on the number of input accesses your algorithm must have made.  And that, modulo some nasty technicalities (e.g., what if k doesn’t evenly divide the size of your list?), is how the collision lower bound works.

---

So, in the first half of my QStart talk, I explain the collision lower bound and its original motivations (and a little about the proof, but no more than what I said above).  Then in the second half, I survey lots of extensions and applications between 2002 and the present, as well as the many remaining open problems.  For example, I discuss the tight lower bound of Ambainis et al. for the “index erasure” problem, Belovs’s proof of the element distinctness lower bound using the adversary method, and my and Ambainis’s generalization of the collision lower bound to arbitrary symmetric problems.  I also talk about Mark Zhandry’s recent breakthrough (sorry, am I not allowed to use that word?) showing that the GGM construction of pseudorandom functions is secure against quantum adversaries, and how Zhandry’s result can be seen—in retrospect, anyway—as yet another application of the collision lower bound.

Probably of the most general interest, I discuss how Daniel Harlow and Patrick Hayden invoked the collision lower bound in their striking recent paper on the AMPS black hole “firewall” paradox.  In particular they argued that, in order to uncover the apparent violation of local quantum field theory at the heart of the paradox, an observer falling into a black hole would probably need to solve a QSZK-complete computational problem.  And of course, the collision lower bound furnishes our main piece of evidence that QSZK-complete problems really should require exponential time even for quantum computers.  So, Harlow and Hayden argue, the black hole would already have evaporated before the observer had even made a dent in the requisite computation.

Now, the Harlow-Hayden paper, and the AMPS paradox more generally, really deserve posts of their own—just as soon as I learn enough to decide what I think about them.  For now, I’ll simply say that, regardless of how convinced you are by Harlow and Hayden’s argument (and, a bit like with my free-will essay, it’s not clear how convinced the authors themselves are!), it’s one of the most ambitious syntheses of computational complexity and physics I’ve ever seen.  You can disagree with it, but to read the paper (or watch the talk, streaming video from Strings’2013 here) is to experience the thrill of seeing black hole physics related to complexity theory by authors who really know both.

(In my own talk on the collision lower bound, the short segment about Harlow-Hayden generated more questions and discussion than the rest of the talk combined—with me being challenged to defend their argument, even with Patrick Hayden right there in the audience!  I remarked later that that portion of the talk was itself a black hole for audience interest.)

In totally unrelated news, Quantum Computing Since Democritus made Scientific American’s list of best summer books!  I can’t think of a more appropriate honor, since if there’s any phrase that captures what QCSD is all about, “sizzling summer beach read” would be it.  Apparently there will even be an online poll soon, where y’all can go and vote for QCSD as your favorite.  Vote early and often, and from multiple IP addresses!

David Yanofsky, writing at Nieman Journalism Lab:

Today Quartz is open-sourcing the code behind Chartbuilder, the application we use to make most of our charts. Along with the underlying charting library — called Gneisschart — the tool has given everyone in our worldwide newsroom 24-hour access to simple charts at graphics-desk quality. It has helped all of our reporters and editors become more responsible for their own content and less dependent on others with specialized graphics skills.

Very cool.

Craters once brim-full with sediments and water have long since drained dry, but traces of their former lives as muddy lakes cling on in the martian desert.

The images were taken on 15 January by ESA's Mars Express, and feature a region just a few degrees south of the equator within the ancient southern highlands of Mars. The unnamed region lies immediately to the north of an ancient riverbed known as Tagus Valles and east of Tinto Valles and Palos crater that were presented in an earlier release.

The 34 km-wide crater in the top left of the main images perhaps draws most attention with its chaotic interior. Here, broad flat-topped blocks called mesas can be found alongside smaller parallel wind-blown features known as yardangs.

Both mesas and yardangs were carved from sediments that originally filled the crater, deposited there during a flood event that covered the entire scene. Over time, the weakest sediments were eroded away, leaving the haphazard pattern of stronger blocks behind.

Tagus Valles in context.

Further evidence of this crater's watery past can be seen in the top right of the crater in the shape of a small, winding river channel.

Clues also hang onto the ghostly outline of an ancient crater some 20 km to the east (below in the main images). While the crater has all but been erased from the geological record, a long meandering channel clearly remains, and flows towards the crater in the centre of the scene.

Colour-coded topography of Tagus Valles region.

This central complex of craters is seen close up in the perspective view below, showing in more detail another channel-like feature, along with a highly deformed crater. Perhaps the rim of this eroded crater was breached as sediments flooded the larger crater.

Deformation in a flooded crater.

The crater is also seen from a different angle and in the background of the second perspective view below. In the foreground is one of the deepest craters in the scene, as indicated by the topography map.

Numerous landslides have occurred within this crater, perhaps facilitated by the presence of water weakening the crater walls. Grooves etched into the crater's inner walls mark the paths of tumbling rocks, while larger piles of material have slumped en-masse to litter the crater floor.

Landslides inside a crater

A group of interconnected craters with flat floors smoothed over by sediments lie in the lower right part of the main image. One small crater with a prominent debris deposit - an ejecta blanket - lies within the crater.

Ejecta blankets are composed of material excavated from inside the crater during its formation. This particular crater exhibits a 'rampart' ejecta blanket - one with petal-like lobes around its edges. Liquid water bound up in the ejected material allowed it to flow along the surface, giving it a fluid appearance.

Tagus Valles region in 3D.

But it's not just water that has played a role in this region; volcanic eruptions have also had their say. A dark layer of fine-grained ash covers the top left corner of the main image that may have been deposited from the Elysium volcanic province to the northeast. Over time, the ash was redistributed by wind, and buried deposits exposed in localised areas by erosion.

This region is one of many that exposes evidence of the Red Planet's active past, and shows that the marks of water are engraved in even the most unlikely ancient crater-strewn fields.

- Full size images.

When the DefCon hacker conference celebrated its 20th year last summer, the passage of time was evident; hackers who attended their first con in their teens and 20s returned to tow their children to the DefCon Kids segment. That tick-tock of time gets a nod this year in the Uber badge -- the black badge handed ...

The RDFa Working Group has published a Proposed Recommendation for HTML+RDFa 1.1. This specification defines rules and guidelines for adapting the RDFa Core 1.1 and RDFa Lite 1.1 specifications for use in HTML5 and XHTML5. The rules defined in this specification not only apply to HTML5 documents in non-XML and XML mode, but also to HTML4 and XHTML documents interpreted through the HTML5 parsing rules.

The Working Group has also published two Proposed Edited Recommendations for RDFa Core 1.1 and XHTML+RDFa 1.1, folding in the errata reported by the community since their publication as Recommendations in June 2012; all changes are editorial.

Over the years, the Internet has democratized the flow of information. Unfortunately, in parallel, authoritarian regimes and other entities (such as ISPs) for their vested interests have curtailed this flow by partially or fully censoring the web. The policy, mechanism, and extent of this censorship varies from country to country.

We present the first study of the cause, effect, and mechanism of web censorship in Pakistan. Specifically, we use a publicly available list of blocked websites and check their accessibility from multiple networks within the country. Our results indicate that the censorship mechanism varies across websites: some are blocked at the DNS level while others at the HTTP level. Interestingly, the government shifted to a centralized, Internet exchange level censorship system during the course of our study, enabling our findings to compare two generations of blocking systems. Furthermore, we report the outcome of a controlled survey to ascertain the mechanisms that are being actively employed by people to circumvent censorship. Finally, we discuss some simple but surprisingly unexplored methods of bypassing restrictions.

Among several possibilities for what reality could be like in view of the empirical facts of quantum mechanics, one is provided by theories of spontaneous wave function collapse, the best known of which is the Ghirardi-Rimini-Weber (GRW) theory. We show mathematically that in GRW theory (and similar theories) there are limitations to knowledge, that is, inhabitants of a GRW universe cannot find out all the facts true about their universe. As a specific example, they cannot accurately measure the number of collapses that a given physical system undergoes during a given time interval; in fact, they cannot reliably measure whether one or zero collapses occur. Put differently, in a GRW universe certain meaningful, factual questions are empirically undecidable. We discuss several types of limitations to knowledge and compare them with those in other (no-collapse) versions of quantum mechanics, such as Bohmian mechanics. Most of our results also apply to observer-induced collapses as in orthodox quantum mechanics (as opposed to the spontaneous collapses of GRW theory).

While many network vendors are busy standardizing code to implement software-defined networking (SDN), PLUMgrid, based in Sunnyvale, Calif., launched itself on to the scene Tuesday, with customers and use cases in tow. The timing could work to the startup’s advantage, and so could its alliances with other network vendors.

PLUMgrid comes to the market with a bunch of partners that can offer virtualized network applications outside of PLUMgrid’s own capabilities. Rather than try to look like the top SDN provider, PLUMgrid is pushing more of an App Store model. The approach is a clear acknowledgment that one company isn’t necessarily the answer to all SDN problems. And the humility could pay off. With a wider feature set, the company could find success.

Along with some other network vendors, including Juniper, PLUMgrid prefers not to support OpenFlow, at least for the time being. One advantage of that stance is customers won’t have to rip out old switches replace them with those with support for the protocol. Instead, PLUMgrid runs everything based on custom technology called IO Visor overlaid on physical infrastructure.

From there, customers can fire up domains through which a bunch of network functions can be implemented. Some features, such as load balancing and routing, are from PLUMgrid itself, while others can be implemented through services other companies can provide. Outside applications come from such partners as Check Point, Citrix, F5 and Palo Alto Networks.

And while the company has built a clean graphical user interface to manage networks, it doesn’t want the software to just sit unused as yet another interface. So it comes with a plug-in for OpenStack’s widely used Quantum networking project.

The software has been deployed at Cavium, Oppenheimer & Co., Richard Fleischman and Associates and the AT&T Foundry in Palo Alto, Calif. A key benefit for companies deploying PLUMgrid inside data centers so far is the ability to spin up a slew of network functions immediately as they stand up Infrastructure-as-a-Service (IaaS) offerings, said co-founder and CEO Awais Nemat, one of a few executives with Cisco ties. What’s more, applications can be rolled out as much as 20 times faster, and engineers can get much quicker access to development and test environments, without having to wait for system administrators to spin up resources, Nemat said.

To be sure, PLUMgrid isn’t the only vendor thinking outside its silo. Cyan has been thinking about how software and hardware from multiple companies can give customers a larger set of SDN capabilities. But it looks as if PLUMgrid is a bit more prepared to offer an ecosystem models to customers now.

After all that, the launch comes at a good time. The SDN market has been like a game of freeze tag as of late. Last year there was lots of excitement about programmability, centralized configuration and new revenue streams, as vendors drew up roadmaps, made acquisitions or did SDN-washing. But since the beginning of the OpenDaylight Project consortium for standardizing SDN, it’s been quieter, as if everyone is freezing in place and waiting to see if official OpenDaylight code should be worked in to networks, or if existing software would suffice. That’s why it’s as good a time as ever for PLUMgrid to come out of stealth and rack up a bunch more customers and use cases.

Related research and analysis from GigaOM Pro:
Subscriber content. Sign up for a free trial.

• The internet of things: a market landscape
• Private PaaS: the next generation platform for enterprises
• Getting your organization ready for SDN, Part II

A new logic for verification of security policies is proposed. The logic, HyperLTL, extends linear-time temporal logic (LTL) with connectives for explicit and simultaneous quantification over multiple execution paths, thereby enabling HyperLTL to express information-flow security policies that LTL cannot. A model-checking algorithm for a fragment of HyperLTL is given, and the algorithm is implemented in a prototype model checker. The class of security policies expressible in HyperLTL is characterized by an arithmetic hierarchy of hyperproperties.

I’ve been traveling this past week (in Israel and the French Riviera), heavily distracted by real life from my blogging career.  But by popular request, let me now provide a link to my very first post-tenure publication: The Ghost in the Quantum Turing Machine.

Here’s the abstract:

In honor of Alan Turing’s hundredth birthday, I unwisely set out some thoughts about one of Turing’s obsessions throughout his life, the question of physics and free will. I focus relatively narrowly on a notion that I call “Knightian freedom”: a certain kind of in-principle physical unpredictability that goes beyond probabilistic unpredictability. Other, more metaphysical aspects of free will I regard as possibly outside the scope of science. I examine a viewpoint, suggested independently by Carl Hoefer, Cristi Stoica, and even Turing himself, that tries to find scope for “freedom” in the universe’s boundary conditions rather than in the dynamical laws. Taking this viewpoint seriously leads to many interesting conceptual problems. I investigate how far one can go toward solving those problems, and along the way, encounter (among other things) the No-Cloning Theorem, the measurement problem, decoherence, chaos, the arrow of time, the holographic principle, Newcomb’s paradox, Boltzmann brains, algorithmic information theory, and the Common Prior Assumption. I also compare the viewpoint explored here to the more radical speculations of Roger Penrose. The result of all this is an unusual perspective on time, quantum mechanics, and causation, of which I myself remain skeptical, but which has several appealing features. Among other things, it suggests interesting empirical questions in neuroscience, physics, and cosmology; and takes a millennia-old philosophical debate into some underexplored territory.

See here (and also here) for interesting discussions over on Less Wrong.  I welcome further discussion in the comments section of this post, and will jump in myself after a few days to address questions (update: eh, already have).  There are three reasons for the self-imposed delay: first, general busyness.  Second, inspired by the McGeoch affair, I’m trying out a new experiment, in which I strive not to be on such an emotional hair-trigger about the comments people leave on my blog.  And third, based on past experience, I anticipate comments like the following:

“Hey Scott, I didn’t have time to read this 85-page essay that you labored over for two years.  So, can you please just summarize your argument in the space of a blog comment?  Also, based on the other comments here, I have an objection that I’m sure never occurred to you.  Oh, wait, just now scanning the table of contents…”

So, I decided to leave some time for people to RTFM (Read The Free-Will Manuscript) before I entered the fray.

For now, just one remark: some people might wonder whether this essay marks a new “research direction” for me.  While it’s difficult to predict the future (even probabilistically ), I can say that my own motivations were exactly the opposite: I wanted to set out my thoughts about various mammoth philosophical issues once and for all, so that then I could get back to complexity, quantum computing, and just general complaining about the state of the world.

Chelmsford, UK (SPX) Jun 19, 2013
e2v has announced the launch of a space qualified version of the Power Architecture PC7448, the first GHz class microprocessors in the world which can be integrated onto space qualified equipment. The PC7448 is the first product from e2v's Power Architecture series to have a space variant produced. It is a RISC microprocessor that is already widely adopted in the computing platform of airc

The SpaceX software recruiting event at DFJ last night.