With Lavabit shutting down under murky circumstances, it seems fitting to repost an old (2009), yet still very good post by Ladar Levison on Lavabit's architecture. I don't know how much of this information is still current, but it should give you a general idea what Lavabit was all about.
The dsidx file is a Core Data store containing information about API symbols and where they are documented. Each symbol has a token type indicating whether it’s a class name, a macro name, etc.
[…]
The same technique applied to the 10.8 docset reveals the function name
IOBluetoothOBEXSessionCreateWithIOBluetoothDeviceRefAndChannelNumber. Its length is only 68, so iOS wins withMFMessageComposeViewControllerTextMessageAvailabilityDidChangeNotification(74), assuming there isn’t an error in the database or in my admittedly shaky SQL.
An article on TUAW today pointed out something I didn’t know: you can use Apple earbuds to snap the shutter on an iOS device when taking pictures. The article mistakenly says that you must snap the Volume + button; both volume buttons work for me.
Bradley Chambers (via John Gruber):
Also, photo stream needs to be reversed. Apple should store ALL photos/video taken with your iPhone and just store the most recent 1000 (or 30 days) locally on the device.
He then writes:
The kids born 2010 and beyond (when the iPhone camera actually got good), will have a ton of pictures taken of them. Parents largely don’t have a digital workflow that allows for backup, usability, and long term storage. Apple has always prided itself on making technology for regular people. This is a problem that regular people need solved. Photo storage and backup needs to be automatic and so easy that it’s nearly impossible to screw up.
I like the idea in theory. But trust your photos to the company that shut down MobileMe Photo Gallery?
Google (via Jonathan Tang):
Gumbo is an implementation of the HTML5 parsing algorithm implemented as a pure C99 library with no outside dependencies. It’s designed to serve as a building block for other tools and libraries such as linters, validators, templating languages, and refactoring and analysis tools.
Rosyna Keller (some years ago):
Repair Permissions won’t touch any files in any of the user’s home folders since Installer.app can’t target user folders specifically, only any folder or a specific path, and there are no packages in ~/Library/Receipts/. The only way it’d ever touch any files in a user’s folder is if you installed something that let you explicity select a folder to install in (there are very few of those, none are available from Apple publically) and you chose a folder inside your user’s folder. The receipt would still be installed in /Library/Receipts/ and it would only affect the user that installed it. It also won’t fix permissions for any files that were created during the normal (or abnormal) use of OS X. This means it won’t touch any cache files, database files, swap files, or settings files not created by the installer. If a file isn’t listed in a receipt, it doesn’t exist to the repair permissions process. It’s really as simple as that.
In my experience, file and folder permissions get messed up all the time, just not the ones that Repair Permissions can fix.
The cedilla in this blog post’s host name is also a good test for your URL-handling code. My RSS reader app wasn’t able to open it, nor was the Open URL system service.
Update (2013-08-21): Thomas Brand:
Starting Mac OS X v10.6 and later, Disk Utility doesn’t even look in the /Library/Receipts/ directory when you Repair Disk Permissions. All it does is reset the Base Systems disk permissions back to the default as specified by version of Disk Utility you are using.
Philip Langdale (via Edward Loveall):
πfs is a revolutionary new file system that, instead of wasting space storing your data on your hard drive, stores your data in π! You’ll never run out of space again - π holds every file that could possibly exist!
