Dropbox has the opportunity to build a platform that sits outside all the platforms we’ve come to know. Their challenge is to get users to care whether they can connect their Dropbox data to the devices they use. So far, they’ve done better than anyone else. And they won’t have to deal with the second-guessing and turf wars that happen inside big companies. I don’t think it’s a slam dunk that Dropbox will grow to be a huge tech company, but I also don’t think their product is just a feature.
Archive for February 2012
When you use
NSAssert, ultimately the expanded code contains a reference to
_cmd, inside whatever method the line was used. This also prohibits use of
NSAssertin a block, because it creates a retain cycle. Just use
NSCAssertwhich looks slightly wonky but does not require being used within an Objective-C method, and does not allow the programmer to accidentally create retain cycles.
The app listed for sale for $29 on the store as “PDF Reader” is actually our free and open source Skim app, although no mention of the Skim Sourceforge project is made in the description, and the support link just goes to a livejournal post where the Skim web page ad copy has been pasted. There is also a $19 app called “PDF Expert” that appears to be another copy. That one even went ahead and used Adobe’s Acrobat trademark in their icon!
Skim’s BSD license allows others to use the code, but not without attribution. The Skim developers have not had any luck getting Apple to do something about this.
The PC that’s driving your iPad Windows experience is, in fact, a “farm” of computers at one of three data centers thousands of miles away. Every time you tap the screen, scroll a list or type on the on-screen keyboard, you’re sending signals to those distant computers. The screen image is blasted back to your iPad with astonishingly little lag.
So why was it so easy for me to use the TouchPad for work, but not the iPad? I think it’s because there are a number of things the TouchPad does that make it more suitable for work.
I consider it a fundamental freedom of the computer user that he be able to take the data he created out of the application he created it with, so that he may be able to use it with another application.
After Apple yanked Air Dictate 1.0 from the App Store, we scrambled and submitted a brand new Air Dictate 2.0 that satisfied all of Apple’s requests. We are pretty proud of the work we’ve done in this app. We no longer grab your tap on our big mic button and reposition it onto the little mic button on the hidden keyboard, which is what Apple objected to. In fact, we no longer have a button in the UI at all. Instead of tapping a button, you just raise the phone to your ear, start dictating, and then move the phone away from your ear to stop talking. We not only didn’t use private API for any of this; we didn’t use any API. iOS is doing all of the work.
The official reason is non-compliance with Apple’s trademark guidelines for Siri, however Air Dictate doesn’t use the word “Siri” or include its icon.
Update (2012-06-12): Avatron:
Today in the WWDC keynote, Apple announced that Siri-style diction will be part of Mountain Lion. Now we know why they unceremoniously removed Air Dictate from the App Store: we had beaten them to the punch. They hate that.
Apple has extended the sandboxing deadline again. There’s also a FAQ that states:
Apps on the Mac App Store prior to June 1 will remain on the Mac App Store.
We will allow bug fix updates to non-sandboxed apps that were offered on the Mac App Store prior to June 1.
This gives developers time to incorporate the new security-scoped bookmark APIs that were introduced in Mac OS X 10.7.3 (but not documented by Apple until a few days ago). The APIs make it possible to prompt the user once for access to each file/folder, rather than once-per-launch (with the original sandbox implementation) or not at all (pre-sandbox). There’s still the issue of these APIs being missing on Mac OS X 10.7.0 through 10.7.2, and there’s plenty more about the sandbox that still doesn’t work right. Nevertheless, this communication is a step in the right direction, and this time Apple didn’t wait until the day after the deadline had passed.
Update (2012-02-22): Daniel Jalkut describes the versioning issue. (I don’t think it’s as simple as the app checking the OS version, due to container migration.)
Maybe I could file bugs with Apple for exemptions, and reduce the functionality of my app to fit within the limits of the sandbox, but I’ve made the decision that it is just not worth it. I would much rather spend 100% of the time I have for Clipstart on new features only, not playing catch-up with Apple.
One problem is that you don’t know ahead of time what the costs will be. My apps required engineering work to comply with the original Mac App Store rules, then more work and some trickery to get around bugs in Apple’s verification tools that made them falsely think I was breaking the rules. There’s sandboxing in theory, with the promise of temporary entitlements to ease the transition. And then there’s the reality of the sandbox, which includes bugs in its implementation and guidance that even though the temporary exceptions exist you probably won’t be allowed to use them. At each step of the way, it looks like just a little more work to get into the Mac App Store, or to stay there. Until the next issue pops up. And then, if you’re successful, you’re sort of locked into it due to the reasonable expectations of your many customers.
To get around Safari’s default blocking, Google exploited a loophole in the browser’s privacy settings. While Safari does block most tracking, it makes an exception for websites with which a person interacts in some way—for instance, by filling out a form. So Google added coding to some of its ads that made Safari think that a person was submitting an invisible form to Google. Safari would then let Google install a cookie on the phone or computer.
When the IE team heard that Google had bypassed user privacy settings on Safari, we asked ourselves a simple question: is Google circumventing the privacy preferences of Internet Explorer users too? We’ve discovered the answer is yes: Google is employing similar methods to get around the default privacy protections in IE and track IE users with cookies.
Then, she explained, the iPhone came. There was no Office. People got things done. Then the iPad came. There was no Office. People got things done. Android came. People got things done. All of those things that they, just a couple of years ago, were convinced they needed Office to do. They got them done without it. And thus, the truth was revealed.
You can’t override -dealloc in a category. But thanks to associated objects, you don’t have to. If have some object A, and you associate a secondary object B with it, then when A gets deallocated, B will too. If you have something you really need to happen when A gets deallocated, you can call that code from B’s dealloc method. Bingo, deallocation code for A that runs in a separate class.
Mountain Lion is said to arrive this summer, with Apple returning to a yearly update schedule. More frequent upgrades should help speed the adoption of new APIs and Objective-C language features, but I question whether Apple has the resources to pull this off. Some would say that it’s already stretched thin between Mac and iOS development and that quality has suffered. Indeed, the yearly schedule had already proved unsustainable before the iPhone was released.
A new release every year means that Apple will need to produce a continuous stream of new user-facing features that can appear in screenshots and on feature lists. But what I want most from OS upgrades (and the developer tools) are bug fixes, stability, and polish. Despite the Lion-derived name, Mountain Lion seems to be more of a “feature” release than Snow Leopard. Have we seen the end of super-stable releases like Mac OS X 10.5.8 and 10.6.8? Developers can provide plenty of exciting new features and apps if they have a solid foundation to build upon. By the same token, if there’s a constant churn and the ground is always shifting, we burn development and support time without having much to show for it. It also makes it harder to be ruthless. So I question the wisdom of having yearly updates to both OS X and iOS.
Some of the more egregious problems with Lion’s Address Book and iCal seem to be fixed. (The skeuomorphic chrome remains in place, though.) And there’s some cool new stuff in Mountain Lion for developers. More in-depth discussion will have to wait until the NDA is lifted.
The biggest news is, of course, Gatekeeper and the Developer ID—which are along the lines of the system that Wil Shipley proposed. The technology behind Gatekeeper is good and unsurprising. What’s important is how Apple will use it and what comes next.
Is Gatekeeper proof that Apple wants a vibrant Mac software market outside of the Mac App Store? Or is it just another click of the ratchet to a future where all software must be approved by Apple? I think it’s a Rorschach test; the facts can interpreted either way. On the one hand, it’s encouraging that Apple is providing for a level of security between zero and fully sandboxed. That’s a win for users, developers, and Apple. On the other hand, adding a Gatekeeper-like feature would also be a necessary transition step towards a more restricted world. We went from total freedom to a Security preferences pane that offers three radio buttons for which types of apps are allowed. The next step could be reducing it to two or to one.
The bottom line: are you more worried about Apple having a killswitch for your favorite apps than you are about a family member downloading and launching a malicious app that said killswitch would have protected against? Right now, with almost no Mac malware, it seems unnecessary to make any sort of tradeoff. But it’s prudent to be ready in case that changes.
Here are some areas to watch going forward:
- What language will Apple use to describe apps that don’t use Developer ID? How strong will the implication be that they’re unsafe or second-class?
- Will Apple only use Gatekeeper to block true malware? Originally we were told that the iTunes App Store review process was to protect users and the cell network. Apple would provide some common-sense guidelines that determined which apps would be improved and rejected. What actually happened was that app review was capricious. Apple rejected some apps for business and political reasons. It approved others that clearly violated the guidelines. Some types of safe apps were unwanted. Other apps had “too many” competitors in their genre.
- Will Gatekeeper eventually step in below the file quarantine level?
- What recourse is there for an application that’s mistakenly identified as malware?
- Will apps from identified developers have access to the same APIs as apps in the Mac App Store? Currently the answer is No, and Mountain Lion has added more such APIs, widening the gulf. Actions speak louder than words, and Apple has yet to even say that it desires parity. Thus, I’m skeptical of the feel-good rhetoric to Panic about not poisoning the well.
- What will happen on March 1? It’s now been more than eight months since the sandbox’s semi-secret debut at WWDC 2011. At the technical level, it still isn’t ready for primetime. At the policy level, it’s still unclear what the March deadline means. And communication from Apple has been almost entirely absent on these important issues. Originally it made a kind of sense that, if the sandbox implementation had been complete and solid, it should be adopted before the next major release of the OS. Now, with Mountain Lion scheduled for this summer, I don’t see how Apple can justify imposing the sandbox on Lion. There isn’t even a mechanism to prevent sandboxed apps from launching, and causing harm, on the earlier versions of Lion that had more bugs.
- Will Apple add support for Developer ID apps to iOS? This seems incredibly unlikely, but it sure would be effective at restoring goodwill. It’s becoming increasingly clear to people that the App Store doesn’t guarantee safety, and Gatekeeper shows that other options are possible.
See also the posts from Matt Alexander, Marco Arment, Rainer Brockerhoff, Jacqui Cheng, Andrew Cunningham and Anand Lal Shimpi, Dustin Curtis, Chris Foresman, Dan Frakes, Steven Frank, Jean-Louis Gassée, John Gruber, Pierre Igot, Daniel Jalkut, Jesper, Rich Mogull, Dan Moren, David Pogue, John Siracusa, Jason Snell, Sean Sullivan, The Talk Show, Marcel Weiher, and Dave Winer.
To increase adoption, Apple should expand the current list of entitlements until it covers every reasonable behavior that users expect from Mac apps. A good test for this is any app that is currently available in the Mac App Store. Having been approved by Apple’s own reviewers, and purchased by Apple’s own customers, the merit of these apps should be considered implicit. If a Mac App Store app’s reasonable behavior cannot be achieved in the confines of the sandbox, it should be considered a sandboxing bug, and a new entitlement should be added.
I would go even further and say that there should be entitlements to cover applications that are not currently allowed in the Mac App Store. For example, SuperDuper has won two Macworld Eddy awards. It needs full access to the filesystem, but the sandbox could prevent it from accessing the camera, acting as a network server, etc. With the behavior appropriately limited by entitlements, there should be a way for Apple to allow it in the Mac App Store. Likewise for my own SpamSieve, audio utilities from Rogue Amoeba, etc.
I toss all my Mac app ideas that require more than the default sandboxing rules — no matter how cool the idea is.
The sandbox has a chilling effect on at least one developer. I’d be surprised if it were just me.
This does raise an interesting question: where are all the other developer tools? The most commonly used are included in Xcode. Instruments, File Merge, Application Loader, Icon Composer and Open GL ES Performance Detective can all be accessed from Xcode’s application menu. The rest of the developers tools are available via connect.apple.com in various packages. This should mean that the download for Xcode is lighter, though you won’t be guaranteed to get the most up-to-date versions of all the tools in one download.
This doesn’t make a whole lot of sense to me. Instead of a single download that installed a consistent version of everything, there are now multiple downloads from three separate places: the Mac App Store, the connect.apple.com Web site, and Xcode’s preferences window.
Stored inside the Xcode.app package, the auxiliary files and applications are now invisible to Spotlight.
Code completion now works within some macros. Unfortunately things have regressed with regards to the OCUnit macros.
This has been broken since Xcode 4.0. It really seems like Apple’s own developers don’t do unit testing. The text processing/scripting features that were present in Xcode 3 are still gone, too.
OS X 10.8 Mountain Lion was revealed yesterday. A few people have noticed a new feature that is somewhat similar to Growl. Apple calls it Notification Center. We would like to clear a few things up about how we view Growl going forward due to this announcement[…]
Some people are asking whether this means that Growl is dead, but I think that’s far from the case. Apple limits Notification Center access to its own applications and those from the Mac App Store. Users will want to see all their notifications in one place, yet this is not possible. Apple’s applications don’t use Growl, and many third-party applications will be barred from Notification Center. Enter a hypothetical future version of Growl. Growl is in the Mac App Store, so it can post to Notification Center. It could act as a bridge, receiving notifications from third-party applications and re-broadcasting them through Notification Center. Assuming, of course, that the guidelines aren’t changed to prohibit this sort of thing.
Every time you throw in a quick fix for something because it’s Getting Late(tm), stop and see if you can fix it correctly right then. Pragmatism says it might not be possible in the time remaining, and that’s ok; “Real artists ship” and all that but a ruthless artist will fix the problem first thing in the next release so they can keep shipping again and again and again.
In other words, don’t accumulate technical debt.
On March 1st, Apple will change the rules of the Mac App Store to require all applications to run inside of a ‘sandbox’. Unfortunately, this will disallow important SourceTree functionality that was previously acceptable under store rules. Complying with the sandboxing rules would force us to change SourceTree in ways that would remove features, damage the usability of the app, and hurt our users; therefore, we will no longer submit SourceTree updates to the Mac App Store after March 1st, 2012.
There is much that is wrong with Walter Isaacson’s biography of Jobs, but its treatment of software is the most profound of the book’s flaws. Isaacson doesn’t merely neglect or underemphasize Jobs’s passion for software and design, but he flat-out paints the opposite picture.
One of the most memorable parts of the book is Jobs at Jonathan Ive’s studio:
When Steve comes in, he will sit at one of these tables. If we’re working on a new iPhone, for example, he might grab a stool and start playing with different models and feeling them in his hands, remarking on which ones he likes best. Then he will graze by the other tables, just him and me, to see where all the other products are heading. He can get a sense of the sweep of the whole company, the iPhone and iPad, the iMac and laptop and everything we’re considering. That helps him see where the company is spending its energy and how things connect.
There is no corresponding description of Jobs meeting with a top software guy. It’s unclear whether this is because Jobs focused on the hardware (and was especially close to Ive), or because Isaacson chose not to write about it.
Gruber also mentions one of the book’s most egregious lines, a quote from Bill Gates:
Amelio paid a lot for NeXT, and let’s be frank, the NeXT OS was never really used.
Isaacson treats this as fact, yet it’s so wrong that it calls into question all of Isaacson’s judgements. How can he be trusted to tell us the story when he doesn’t understand where Mac OS X came from and thinks that the Intel transition was “akin to writing a new operating system”? I do, however, agree with Gruber’s overall assessment:
Steve Jobs is not literature, but it is a good book, but alas with several holes and egregious errors.
Within the next couple of weeks more than 40.000 users downloaded and tested our app. Besides the tons of valuable feedback, bug reports and feature requests we received (thank you!), it was also a confirmation for us that we were heading in the right direction.
Tower started off well, and they’ve done a great job of improving it. It’s one of my primary development tools, alongside Xcode and BBEdit. I do use SourceTree for certain kinds of searches, though.
For the system to provide security, however, it is essential that the secret prime numbers be generated randomly. The researchers discovered that in a small but significant number of cases, the random number generation system failed to work correctly.
Of 6.6 million distinct X.509 certificates and PGP keys (cf. ) containing RSA moduli, 0.27 million (4%) share their RSA modulus, often involving unrelated parties. Of 6.4 million distinct RSA moduli, 71052 (1.1%) occur more than once, some of them thousands of times.
Update (2012-02-20): Glenn Fleishman:
It’s not impossible that the RSA key generation software would have ”collisions,” in which the same primes were generated on multiple occasions by different systems. But it should be far more unlikely. Thus, there is some flaw that prevents the degree of randomness necessary to ensure the least possible repetition. In private use, this wouldn’t matter. But because public-key cryptography relies on publishing keys, such overlap may be found easily.
Thomas Houston interviews Christopher Forsythe:
We didn’t make any real tradeoffs with regards to functionality, there’s actually more functionality in the 1.3 line of releases than there is in the 1.2 line of releases. We did need to change from a free to a paid model in order for development to continue. There were a few big issues that caused us to need to switch to a paid model overall.
We had a few big soul crushing issues prior to Growl entering the app store, and the majority of those simply went away when Growl hit the app store.
Growl 1.3 is an improvement in many ways, but there’s a lingering bug that causes it to max out my CPU until I try to quit it, at which point it crashes.
It quickly became 80% to 90% of my work was done on the iPad. Many of us thought at Apple that the tablet market would become larger than the PC market, and it was just a matter of time before that occurred.
I think he’s right, and yet as a developer the only work tasks that are more pleasant for me on an iPad are reading PDFs and technical books.
The way that DDG does this is by trading off text directives for GUI/mouse interactions. Assuming you can type faster than move and click a cursor, this is a big difference. To me, its like the difference between using Vim and a GUI based text editor.
DDG calls this the bang syntax. What it allows you to do is pipe your search directly to another site’s search - for example, Amazon, Wikipedia, Google Image Search, or hundreds of other places.
I use LaunchBar search templates for this, but I can see how it might be handy when not searching from my Mac. I gave DuckDuckGo a try but went back to Google because the results seemed to be much better.
Below are some classic anecdotes and tips - many thanks to Brandon Sheffield who originally put together this article on Gamasutra. I have reposted a few of his stories and also added some more from newer sources. I have also linked on each story to the author's home page or blog wherever possible.
Mac developer Mark Munz, of Vancouver, Wash., says to comply with Apple’s new rules, he has to remove key features of his text-reformatting app TextSoap that integrate with other programs.
As a workaround, he’s working on a “helper app” that Mac App Store users could download separately to restore the extra functionality. “It sort of defeats the purpose of what sandboxing is about,” says Mr. Munz, who is president of Unmarked Software LLC.
Unfortunately, that approach isn’t an option if API bugs or omissions prevent core features of the application from working in the sandbox.
A person has a song on her computer hard drive. She clicks on the song and plays it. No one is getting paid. The same person pays iTunes $25 for iMatch. She now clicks on the same song and plays it through her iMatch service. Copyright holders get paid.
Two interesting points here. First, you pay Apple a flat fee for the ability to download, whether or not you actually do; Apple pays the music labels each time you actually download. So Apple is playing the odds here, hoping that the average user won’t have more downloads than expected. Second, the labels get paid even if you’re just downloading a backup of music that you’d already bought on CD. I can see why Apple likes this, but it doesn’t seem like a good precedent for users.
The Boston Phoenix says that The New York Times published a PDF of another newspaper’s article without obtaining permission (via Hacker News). However, I was unable to verify this because the paper of record has (apparently to avoid embarrassment) removed all references to said PDF.
In 2010, I wrote:
I don’t understand why iOS makes such a big deal about permission to access location data, when any random app, even one that shouldn’t need network access at all, can access my address book, photos, and clipboard and upload them to who-knows-where.
Yesterday, Arun Thampi wrote:
Upon inspecting closer, I noticed that my entire address book (including full names, emails and phone numbers) was being sent as a plist to Path. Now I don’t remember having given permission to Path to access my address book and send its contents to its servers, so I created a completely new “Path” and repeated the experiment and I got the same result – my address book was in Path’s hands.
John Gruber notes that the response from Path is not very satisfying. Is this really “currently the industry best practice”? See, for example, these questions from Matt Gemmell. There’s no automated way to get them to delete your data. Rule 17.1 of the App Store Review Guidelines seems to prohibit this sort of behavior without the user’s consent, yet Path has been in the curated App Store for over a year and Apple doesn’t seem to have noticed that it’s sending this information back to the server
in cleartext. Now that the news has broken, Apple has neither pulled the app nor approved the update that asks users to opt in. As Peter Maurer says, “No technology will ever protect us from Trojan horses. Rules that destroy functionality are mere security theater.”
Update (2012-02-08): The official response from Path:
We are deeply sorry if you were uncomfortable with how our application used your phone contacts.
That could have been phrased better. Also, Gawker quotes Path CEO Dave Morin, in November 2010:
Path does not retain or store any of your information in any way.
Good thing they will “continue to be transparent.”
Update (2012-02-09): Gawker:
The official version from Morin is that the statement was technically accurate, at the time he made it. He just changed his mind.
Peter Maurer links to this screenshot of Path’s new opt-in alert, noting that it isn’t very transparent. It just asks whether you want to invite your friends, without explaining what this entails for your personal data. However, Ole Zorn links to this screenshot in which the alert actually says “Path needs to send contacts to our server.”
I know a ton of developers, and I’ve never, ever heard this.
Update (2012-02-10): In the comments, CF quotes Steve Jobs at D8:
We take privacy extremely seriously. That’s one of the reasons we have the curated apps store. We have rejected a lot of apps that want to take a lot of your personal data and suck it up into the cloud. Privacy means people know what they’re signing up for.
Update (2012-02-15): Dave Copeland:
But Twitter, as reported by the Los Angeles Times, seems to be the biggest name to make a revelation so far. The company told the newspaper it is making changes to make the policy clearer to users of its app. The current policy does not clearly state that Twitter downloads the entire address book of users who use the “Find Friends” feature on the app, including names, email addresses and phone numbers, and stores the data on its servers for 18 months.
Facebook, Twitter, Foursquare, Instagram Foodspotting, Yelp, and Gowalla all upload either your contacts’ phone numbers or email addresses to their servers for matching purposes. Some of these applications perform this action without first requesting permission or informing you how they long they plan to store this data. Foodspotting is the worst of the bunch, as it appears to transmit your data over an unencrypted HTTP connection (in plain text), making it even easier for mischievous parties to intercept.
“Apps that collect or transmit a user’s contact data without their prior permission are in violation of our guidelines,” Apple spokesman Tom Neumayr told AllThingsD. “We’re working to make this even better for our customers, and as we have done with location services, any app wishing to access contact data will require explicit user approval in a future software release.”
Not mentioned: (1) the other types of personal data that apps can access without permission, and (2) the difference between letting the app access your address book and letting the app transmit it.
You may like, for most network purposes, the simplicity of version 6. It looks to me as though Apple has pruned at least half of the options available in nested dialog boxes and elsewhere. (You may also hate it for this reason.) For average users, having fewer choices with better presentation is a plus. For network admins and advanced users, you’ll be cursing Apple as you download the previous version.
Will the missing features be restored in an update to 6.0? AirPort Utility 5.6 works today, but what happens the next time Mac OS X and iCloud are updated? Since Apple has not stated its intent, I think you have to assume that the current 6.0 feature set is what they plan to support going forward.
As it happens, though, I’m no longer using AirPort Utility. A few months ago, I decided to retire a Time Capsule that I had inherited. I’d never been able to get Time Machine to work reliably with it. And something had changed so that, even though I never used its storage features, the hard drive was always spinning loudly. Apple’s $179 AirPort Extreme seemed like overkill. I just needed a wireless router with a few Ethernet ports—no AirTunes, printer sharing, or Back to My Mac. Plus, reviews mentioned that the newer Apple base stations make a high-pitched noise. That would drive me crazy when watching TV.
I ended up getting a $35 Cisco router. I ignored the sketchy looking software on the CD, which promised to copy over the settings from my old router, and just set it up via Safari. So far so good. Download speeds are actually faster than with the Time Capsule.
Ever since I upgraded to Lion last summer, I’ve been dealing with the usual, seemingly unavoidable collection of bugs that each and every major OS upgrade brings. What has been particularly irritating about the phenomenon this time around is that today, six months and several incremental OS updates later (we are currently at Mac OS X 10.7.3), most of these problems are still there, and there is no indication that Apple is taking them seriously enough that we can expect them to be fixed soon.
Although I’ve not been pleased with some of Lion’s user interface changes, and there are lots of bugs related to new features like Versions and the sandbox, in general use it has been mostly solid and reliable for me. It was perhaps the smoothest of any Mac OS X upgrade I’ve done. And it definitely seems more stable than Snow Leopard, the ostensibly more minor upgrade. However, general comments from my customers are more along the lines of Igot’s experience. Some people see Lion as Apple’s Vista: not a very compelling upgrade, a lot of stuff doesn’t work right, and they wish they’d sat out this round.
The test repo has 4 million commits, linear history and about 1.3 million files. The size of the .git directory is about 15GB, and has been repacked with 'git repack -a -d -f --max-pack-size=10g --depth=100 --window=250'. This repack took about 2 days on a beefy machine (I.e., lots of ram and flash). The size of the index file is 191 MB.
With the hard–working part of git on the other end of a network service, you could back it by a re–implementation of git which is written to be distributed in Hadoop. There are at least two similar implementations of git that are like this: one for cassandra which was written by github as a research project, and Google's implementation on top of their BigTable/GFS/whatever. As the git object storage model is write–only and content–addressed, it should git this kind of scaling well.
The February issue of ATPM is out:
- MacMuser: The Best and Worst Christmas Presents
- PEBKAC: The Normals’ View of Apple and the iPhone
- Segments: Slices from the Macintosh Life: An Achievable Dream
- Segments: Slices from the Macintosh Life: Digital > Analog > Digital
- Segments: Slices from the Macintosh Life: Smart Move?
- How To: Create Your Own iPhone Ringtones
- Desktop Pictures: From ATPM Readers
- The Spinning Beachball
- Book Review: The Information Diet: A Case for Conscious Consumption
- Software Review: MacJournal 6.0
- FAQ: Frequently Asked Questions
What we really need is a facility that provides access to at least some subset of WebKit HTML rendering capabilities at a level between CoreText and UIWebView—something that doesn’t require developers to essentially re-invent HTML and CSS but allows them to render at least some level of HTML formatted text to a native view or layer without the overhead and inflexibility of UIWebView—basically, a next generation version of Mac OS X Cocoa’s NSAttributedString. I’m sure providing such a facility in the limited environment of the iOS presents significant engineering challenges, but Android has such an API, and I think the absence of such an API on iOS is holding the platform back as a media platform more than almost anything else I can think of.
I used to think that rich text editing of some sort on iOS was just around the corner. I’ve even had folks at Apple tell me ”just wait,” as if it was almost here. That was years ago. At this point, I almost think it’s on purpose that we don’t have any sort of rich text editing. I just can’t figure out why.
It’s strange since NSTextView has been such a massive success on Mac OS X.
For reasons I don’t know, Yahoo laid off the highest level of Flickr’s customer support, the people that end up filing bugs against the developers and helping the trickier cases get solved for the members. Those guys getting shown the door is as bad as it sounds.