The Rush to Be Obsolete

Plugging leaks is not impossible, neither is fixing VM code or finding better frontend people.

Get It Try It

The following comes from a leaked memory check of Safari. Safari's leaking 1920 bytes already on launch. And it only gets worse as things go on.

Process:         Safari [1934]
Path:            /Applications/Safari.app/Contents/MacOS/Safari
Identifier:      com.apple.Safari
Code Type:       X86-64 (Native)
Parent Process:  launchd [129]

Process 1934: 98379 nodes malloced for 16217 KB
Process 1934: 14 leaks for 1920 total leaked bytes.

This is Apple. They're the people who set the standards. They're the people who made a version of /usr/bin/leaks available so users and developers could see how well their apps are performing.

And yet they, time and again, release versions that, in the above context, are abominable; some of these releases are so horrendous that users have no alternative but to spend great time and go to great lengths to restore older versions, something the update system is otherwise engineered to prevent.

Plugging leaks isn't easy for ISVs. The leaks don't have to originate in their own code. They can have their origins in Apple's own system code. But it's necessary to rid software of leaks, and ISVs, without access to Apple system code and the means to communicate with the teams responsible for the leaks, have to work in the dark. Finding workarounds for leaks triggered by system calls is a black art.

And yet this site did it some months ago, auditing ALL code so that NOTHING leaked. Is it too much to ask the esteemed Apple system and especially Safari developers to do the same? When such a process is so much easier for them? When they have more resources at their disposal than anyone else on the planet?

That Safari doesn't have to leak: that's a given. It's more than a given: there are older, now obsoleted, versions of Safari that don't leak a thing.

And most Apple on-disk software doesn't leak either. Most of it has never leaked. But not Safari.

But that's on the local side. Then there's the other side - the web side. And one web application, above all others, can be counted on to be a Royal Ridiculous Pain in the Arse™.

Twitter.

There's no denying that the 'backend' engineers have done a titanic job. If one merely stops to think about what that social media ticker tape monster is really up to - it's a breathtaking achievement in systemware and hardware design.

But up front? That nebulous crew of Ruby freaks? No matter the current technology: they're still the same freaks.

Not everyone can be a software engineer such as those who craft the support structures for mega-sites. But to have such a quality drop-off from backend to frontend...

Not Google, not Facebook, not Wikipedia: none of the software crews at those companies have caused consternation like the Twitts at Twitter. Google, Facebook, Wikipedia all run with relative stability. There are bugs in all three sites, but the overall situation is under control. Not so with Twitter.

It's tempting to call Twitter the clowns of the Internet, so let's! How many remember the fiasco known as 'New Twitter'? How Twitter reps bragged online about their 'golden ratios' in the design? And this in a coming mobile world where real estate was at a premium?

How many remember how Twitter management were so clueless that they hired in a consultant company to find out why everyone hated their 'New Twitter'? Or how they kept intimidating users to update to 'New Twitter' - 'or else'?

How many remember that most of the most useful conventions in Twitter were invented by users and not by Twitter designers? And how time after time, when Twitter tried to co-opt such conventions, they fell flat on their faces? When's the last time anyone looked at Twitter source code? Does one really need 700 KB for a single page of Twitter feed?

The latest Twitter - on the latest Mac - is ridiculous. Undo/redo don't work correctly; the DM popup, reduced in size for no sensible reason, jumps around onscreen, character spacing can be so bad that the first line of text is illegible until one tries a 'select all'. For all intents and purposes, it's unusable and getting only worse. Legacy Macs flip automatically into 'Mobile Twitter' which puts the old 140-character limit on DMs. Changing the user agent to fool the Twitts at Twitter can resolve the issues with no harmful side-effects. And funniest of all: if you go directly to Mobile Twitter, and don't start with 'ordinary' Twitter, the page tells you that you've been flipped from 'ordinary' Twitter anyway! This is programming that is substandard, and should never and won't normally be found in any serious software house. Multiply this by the fact that Twitter is online software, that even the most minuscule of errors get multiplied by the hundreds of millions in a fraction of a second, and one sees in a comparable fraction of a second that Twitter's software testing is, if it even formally exists, deplorable.

Twitter is an amazing concept. A worldwide ticker tape with input from and output to hundreds of millions of users in realtime. Correlating follows and followers, mutes and blocks, for both feeds and sidebars... All in realtime. Exposing an API for ISVs, of which there are many, running on myriad platforms. Getting such a backend to work, even with a few paltry million users, is a gargantuan task. But then dropping off the deep end with one's own frontend that is historically such an epic fail?

Only Twitter could be capable of such a dubious achievement.

SSD has made it easier to overlook and sidestep memory leaks. Apple's virtual memory system isn't the world's best, to say the least. The days of the spinning beach ball are not gone, thanks to leaky apps like Safari and Apple VM, at least when users are still running HDDs. But depending on SSD - hardware - to cover up gross deficiencies in software: it's neither new nor acceptable.

Plugging leaks is not impossible, especially when one sits on the actual system source code at the corporation with the biggest market cap in the world. And a company capable of building a backend to accomplish the impossible tasks needed for a realtime ticker tape can afford to hire on better frontend designers and developers.