yeah I know I’m a month late with this, but this is the highest res I’ve found so I’m taking it.
would have worked on me. holy crap.
wake up, sheeple!
After tonight, I’m convinced.
Google makes billions of dollars in revenue each fiscal quarter. That money comes about by the same process that all companies use: They sell a product to their customers. Their customers pay money for that product.
Who’s Google’s customer? You? Really? When’s the last time you paid Google for anything?
Advertisers are Google’s customer. What do they sell to advertisers? They sell you. Or, at least, they rent you out, or provide access to you.
And I’m actually OK with that, here’s why:
I’m going to see ads on the internet anyway. If they’re more relevant to me and help me find what I was looking for, my total experience is improved.
Would I rather no ads at all? Yes. But realistically speaking that is not going to happen.
The Dog Days of Winter on Flickr.
poor guy was cold, so we gave him a blanket.
I met Craig Federighi last year, and I liked him immediately. He is personable, well-spoken, and smart.
I chatted with him about the past, present, and future of Mac OS X in his office at Infinite Loop, interrupted only by a call from SJ, for which he gracefully excused himself. In fact, during our whole meeting, it was impossible to find anything out of place with him—he’s got his shit together.
There’s a bit of discussion that Scott Forstall should have been picked for the job, but I disagree. Scott is exactly where Apple needs him to be, on the cutting edge of the still-young mobile space. It’s not that he’s not qualified, quite the opposite is true: he’s doing a hell of a job right now, and I can’t think of anyone who could fill his shoes while keeping everything on track.
Craig is going to do a great job. Congratulations.
And Bertrand, it was a pleasure to work for you. You did a great job, and I wish you the best of luck in your new endeavors.
Becoming the sole provider of the user-facing interfaces to your service so you can generate revenue is a good tactic for a service the scale of Twitter, but things start to taste sour with the added context of recently ousting the CEO and soon after trying to turn a quick buck in your own apps with things like annoyingly-pervasive trending topics (which are both sponsored advertisements and an annoying reminder of what mentally-13-year-olds everywhere are thinking).
While some folks have stepped up to Twitter’s defense on the topic of the dickbar, people voted with their app reviews against what they saw as a step back for a client that had a tradition of great design:
Twitter for iOS, #dickbar edition, is now at ★☆☆☆☆ × 1161, after two days in the hands of users.
It’s good to remain skeptical, so let me walk you through what went through my head after reading Ryan Sarver’s email to the Twitter Development Talk list, ostensibly telling all third party client developers to give up and go home:
Still, our user research shows that consumers continue to be confused by the different ways that a fractured landscape of third-party Twitter clients display tweets and let users interact with core Twitter functions.
Developers have told us that they’d like more guidance from us about the best opportunities to build on Twitter. More specifically, developers ask us if they should build client apps that mimic or reproduce the mainstream Twitter consumer client experience. The answer is no.
While third-party clients do vary in their presentation, the ones I’ve used are all pretty intuitive. The people who are still confused by the simple concept of a tweet are not the users you care about if your concern is the quality of your service and its contents. They are who you worry about when you want more eyes on your ads.
Twitter’s appeal was that it allowed you to be (fairly) effective in insulating yourself from the noise of the internet by choosing who to follow, while avoiding the butthurt that comes with equating following to befriending someone, while being simple to understand without help.
We’ve grown from 48 million to 140 million tweets a day and we’re registering new accounts at an all-time record.
According to our data, 90% of active Twitter users use official Twitter apps on a monthly basis.
As a student of statistics, this statement immediately sets off alarms. For a service which is already a household name, growth should not be a major goal. The quality of a service whose content is user-generated is the quality of its users, and the high quality users can not be assumed to be distributed across the different clients in the same pattern as the general populace. In fact, while I do use the official apps (and consider myself to be a quality poster), a full ⅓ of my carefully-chosen followees do not. The users that stand out most in my mind as fitting both “uses official clients” and “registers at an all-time record pace” are spammers. Assuming that Twitter has achieved market saturation, if new account registrations continue to get more frequent, they are facing a growing fight against spam which, for a publicly-available service, means spending more money to solve.
To make matters worse, spammers are not very good at noticing promoted trending topics and other ad-like revenue models, and they make quality users lose interest in the platform (though follow insulation helps mitigate this). The ad impressions lose their value, and a vicious cycle is created with one myopic strategy.
The only way to make a quick buck often enough to make a living is to be a venture capitalist, leaving a trail of used-up companies in your wake. And we’re watching it happen here.
(thanks to ars technica for the article idea, and Daring Fireball for the easy title)
A while ago I was trying to get descriptors asynchronously from devices since in some situations, like if you catch a Mass Storage device while it’s busy servicing a CDB, the device could drop control pipe requests on the floor, causing DeviceIoControl to block until Windows loses patience with the device and resets it (about five seconds).
The naïve approach is to use an OVERLAPPED structure with DeviceIoControl, since that’s how you do all async IO on Windows, but this doesn’t work. It’s up to the device driver to determine whether the call will be completed synchronously or not, and the Windows USB drivers complete all calls synchronously unless the pipe gets stalled by the device (normally between a URB submission and completion the device just NAKs until the result is ready). This is extremely uncommon, and impossible for the control pipe (which is where descriptor requests go) because the control pipe is used to clear a pipe stall. Stall the control pipe and you wedge the device, leaving a device reset as the only option. In five seconds.
The solution I wound up using is not one I’m particularly proud of, but it does have the advantage of working: I didn’t mind a synchronous call (in fact, it made things easier), but I didn’t want to deal with getting wedged when a device went out to lunch, so I spawned a thread and used WaitForSingleObject to set my timeout. If you can’t afford the cost of a new thread, use a worker thread to service your request and plan on waiting 80ms or so per quarter-kilobyte expected. Measured very unscientifically, a config descriptor without interfaces (nine bytes) takes less than 10ms, average 4.7ms, standard deviation 0.00831.
Note that you want to open the HANDLE you’re using in the DeviceIoControl call in the thread too—if there’s another request in flight, opening the file handle will block until it’s completed, which is exactly what we’re trying so hard to avoid. You shouldn’t really be calling for another descriptor from the same device right after it’s failed though, because it’s likely about to be reset by Windows.
Ok, bonus pitfall you didn’t expect: For configuration and string descriptors, you don’t know how big the descriptor is, so you can grab a portion of it, get the bLength (wTotalLength for configuration descriptors) and use that to get the rest of the descriptor, or you can just request UINT16_MAX and cross your fingers.
It turns out that neither of these approaches work for all devices for any value of n. To save some space, but keep the number of round trips to the device low, I always used a 256 byte buffer in my requests, and failed over to a larger buffer if the descriptor was too big. Unfortunately, in the classic “just bang on it until it starts working” approach of USB vendors, some devices will just not respond if you make a request with a buffer size that is not the exact size of the descriptor or sizeof UsbConfigurationDescriptor (nine bytes). The reason for this appears to be one of convenience—Windows itself only requests either nine bytes or the entirety of descriptors, so some device firmwares were written with only these two cases in mind.
In the physical world the race to the bottom is won by mass manufacturers in third world countries paying their workers 2¢ an hour. That’s bad. Not only do those workers suffer, but product quality suffers as well.
In the software world there are no significant manufacturing costs, so commoditization doesn’t rely on reducing per-unit product cost and actually benefits from higher product quality. This is achieved when someone builds and releases a functioning Thing for free with the source code available, and other people take interest and offer to help. Game over, this thing is free and getting attention and if it doesn’t exactly fit your needs, you can adapt it for less cost than writing another one from scratch. The result is always better than something you built yourself. This allows you to concentrate on truly new and unexplored work that results in the great products of today.
Every great product today contains an open source component. Without it, they would still be in development. Everyone who has enjoyed a product with a processor in it has benefitted from open source.
But open source is not The Only Way. People are entitled to be rewarded for coming up with new and interesting things that other people want. The best free software is the stuff that other people have written many times before. These projects benefit most from the “collective bargaining” development style of open source, with the mistakes of all those previous implementations in mind and addressed in a package that anyone can use.
The open encryption libraries OpenSSL and OpenSSH are great examples of this. Encryption software is terrifically hard to write, and everyone should be using it. Any bug could mean that someone owns your sensitive data, and even if it runs correctly, you’re probably vulnerable to side channel attacks that monitor timing, power usage, sound, or math faults. Everyone who writes their own security routines falls for this stuff, including the open source libraries.
That’s the best part about commoditization in software: you’re better off using OpenSSL instead of DIYSSL because they’ve already run into these problems. Early versions had security vulnerabilities, but those have been fixed and the library is under constant analysis and attack by others and you benefit from it directly just by consuming it (as long as you don’t screw with it). You stand on the shoulders of giants.
It’s not just security either. Want high performance code? Someone probably wrote a free library that does what you want. And someone else came along later and improved it. This iteration is what makes open source software such a powerful force.
Open source software has a place in the world, and everyone in the ecosystem relies on it. Great things are not possible without it.
Pretty much all superchargers are Roots Type blowers, which are a method of pumping fluids that I hadn’t heard of before this week.
Today I learned about gravity. In retrospect it makes sense that it’s constrained by the speed of light.
I especially love the lack of any physics in Fig. 7: boxer twin, and the first inertia force that goes off the diagram in Fig. 10: thumper.
typography is art.
(via The Ministry of Type)