:space
:vision
do not step out
:wire
twitter.com/mikeysan
speedbump
20/Sep/2009 | 23:12

Here's a list of the most popular issues in the current release of Sandbox:

- The dsrunner tool (internal Sandbox support tool) may crash in some Open Directory environments. This prevents Sandbox from populating its users and groups list, and results in a user-visible crash notification dialog. Sandbox will still function, but you will have to know the name or UID of the user or group you need. This problem is understood and will be fixed in the next update. It is not specific to Snow Leopard.

- Under Snow Leopard, the first time you click "Inspect Folder...", you may encounter an error dialog. This sucks, but it's harmless. Retrying the button should work on the second try, but this isn't guaranteed, unfortunately. I have a good idea of what's happening here, and will be fixed in the next update.

- Under Snow Leopard, scrolling in the file system browser may also generate error dialogs and erroneous browser items. There is no workaround for these problems. They're also benign, if you consider really fucking annoying benign. I have a good idea of what's happening here, and will be fixed in the next update.

- Under Snow Leopard, you cannot enable or disable ACLs on volumes via Sandbox. The fsaclctl tool has been removed from Mac OS X as of 10.6, so either I disable this functionality or come up with a different solution. I haven't decided how best to handle this.

Where does that leave us? What's the roadmap here?

THINGS I DON'T LIKE:

1. Maintaining shitty code bases.
2. Announcing release dates before things are done.
3. Disabling existing functionality.

I'm going to do the first two right now, and try not to do the third. It shouldn't be a lot of work to fix the three "definitely fixable" bugs, so even though I've sworn to myself I won't touch the 2.x code base anymore, I'll be doing that in the next two weeks. And with that, I've done #2.

3.0 is still on the table, but my work schedule really cuts into my time and energy for personal software endeavors. It'll be a ton of new code and some pretty serious interface changes, so you probably won't hear a peep about it until it's pretty far along and I'm sure I can finish it.

See you soon. Thanks for your patience.

Update (25 Oct 2009):

Okay, pulling a release date out of my ass was a bad idea, as I expected it would be. It's more work that I thought, and I haven't had any time to work on it because of my day job. Stay tuned.

link to: speedbump

file under: breaking things | comments (0)

sandbox 2.2
04/Jun/2008 | 14:05

After four months of starting work on it, Sandbox 2.2 is now available. People have been (very patiently) waiting for a Leopard-compatible release for way too long, but I needed to do a lot of things behind the scenes that simply took longer than expected. That whole "spare time" thing also got in the way a bit. For these reasons, I'm glad I made the decision to release betas early and often. In this sense, Sandbox has been available for Leopard users since March.

I didn't get as much feedback on the betas as I'd hoped, but you never do. People are busy, and it's difficult to take the time to stop what you're in the middle of, document an issue or enhancement idea, and then submit it. That's an entirely separate article. I'm happy people did use the betas, however, and that no one e-mailed me in a frenzy about their RAID being turned into charcoal or something else equally oh fuck.

It's fitting, I suppose, that this (rather major, though it isn't obvious) update coincides pretty closely with Sandbox's third birthday. What can I say, I stick with what I choose to do. Thanks for being my users for the last three years.

The official changes list for 2.2 is below (and in the update feed for the app itself, if you use the built-in software update in 2.0 and later).

Tear it up, kids.

Sandbox 2.2 icon

Sandbox 2.2 is an important update for all users. It contains many bug fixes, performance enhancements, and brings full Mac OS X 10.5 Leopard compatibility. Additional features include:


link to: sandbox 2.2

file under: breaking things | comments (0)

damage 005
29/Apr/2008 | 01:49
record cover

Anasazi Symphony Orchestra

The Decline of Civilization

link to: damage 005

file under: stacks | comments (0)

bee three
17/Apr/2008 | 02:14

Dear Mac OS X administrators,

Sandbox 2.2 beta 3 is now available for download. It brings Leopard compatibility, speed improvements, and fun stuff under the hood you'll never care about. The beta will expire at the end of May, 2008.

Here are some general release notes.

Questions and bugs can be sent to the e-mail address in the readme.


xoxo,
mikey-san

link to: bee three

file under: breaking things | comments (0)

twitterpence
05/Apr/2008 | 01:02

Social Network Equity

Call me nuts, but Twitter has its own economic system, and I've become fascinated—no, obsessed with it lately. As I see it, the monetary ebb and flow of a social networking site can be described, in an absurdly non-useful sense, by the ratio of nodes to which you're linked in either direction.

Given:

Following a person's Twitter feed adds information to your stream.

Gaining a follower sends information you produce to another person's stream.

We can elaborate:

  1. At a specific moment, there are a finite amount of people in the Twitter Information Economy.
  2. Each person you follow costs you time, and each person who follows you gains you some mindshare.
  3. Some people have a fairly equal ratio of followers:following.
  4. Some are richer than others, and have followers:following ratios that tip in the followers direction.
  5. Some are "poor" and their ratios tip toward following more people than they are followed by. (The funny juxtaposition is that in reality, they're information-rich.)
  6. Because it doesn't take following a thousand people to flood you with information, it's possible to be overwhelmed even when your ratio tips toward phat bank.
  7. Once the rich get rich, they always get richer; those with popular feeds continue to snowball followers through little work of their own. (I'm reminded of a saying: "Turning $1 into $100 is work; turning $1 million into $10 million is inevitable.")
  8. Even though there's no real-world cost or barrier involved, the economy will always be this way.
  9. Every day, the finite amount of producers and consumers increases, and with that the economy inflates further.

Anything I missed? Endless subtleties guarantee that there's no way I'm completely right. Twitter at me with your thoughts for a follow-up article and I'll be your best friend.

link to: twitterpence

file under: analysis | comments (0)

browsed
18/Mar/2008 | 05:09

I thought it would be neat to give people an update on Sandbox in screenshot form. Click for big:

sandbox file browser

I wish I had the time to rewrite the entire thing Cocoa-style right now, but it's a pretty big job. I've moved the rewrite to the 3.0 roadmap, which will allow me to sit down and really think about it. For today, Sandbox 2.2 is a chimera, internally, of several languages and environments.

Roads? Where we're going, we don't need roads.

link to: browsed

file under: breaking things | comments (0)

privacy
12/Mar/2008 | 03:52

Encouraging Failure: A Brief Tutorial

Dave Jewell has written an article over at RegDeveloper regarding Mac OS X preferences windows. He titled it "A Better Way to Build OS X Preferences". I hoped that with such a title, the article was going to be insightful and informative. Instead, I found ignorance and arrogance posing as a qualified advice.

Or as I said to a friend, I'm calling this guy the fuck out.

#import <GenesisKit/GenesisKit.h>

In the beginning, there were some developers working day and night to ship an operating system. This operating system included some modules—frameworks, as it were—that were created to provide common, useful functionality. Along the way, the frameworks changed frequently in both how they worked and how they were supposed to be used. There came a point in the development of the frameworks where the engineers plotted out what parts they could let everyone use, including third-party developers, and which parts they'd have to keep to themselves.

The problem, they realized, was three-fold:

1. If Feature X of a framework was still changing internally, they couldn't give it out. They knew that if Feature X's implementation was in too volatile of a state, they may introduce bugs for anyone using it.

2. Volatility exists outside of the implementation of Feature X. Once they released a public API for using Feature X, they couldn't just change it up later or yank it completely without causing problems for everyone involved. Especially third-party developers, who'd be mighty pissed, and rightly so. Once they put forth a public API, they knew they'd have to support it. In that respect, it needed to be well-designed and well-tested.

3. Once these public APIs were settled upon, they would need to be well-documented. This is no easy task, and it's extremely important. During documentation of public APIs, it is often discovered that a piece of the public API didn't work well, or something important was missing. Now they'd have to start part of the cycle over again. And then come back to finish, review, edit, review, and publish the documentation.

This is a pretty big order.

You're wondering what any of this process has to do with the article. It all ties together, baby. Don't move.

Typecasting

Since we have a good picture of what went on behind the scenes, let's take a look at who's going to be using these frameworks. At the most basic level, there are four kinds of mindsets when it comes to developers and private APIs:

A. "I will not use any private APIs, period. They're completely unsupported, undocumented, and I can't rely on them. I need my code to be reliable and future-proof, and if I can't find a way to do something with a public API, I won't do that something."

B. "I really don't like using private APIs. They're unreliable, undocumented, and I can't rely on them. I prefer my code to be reliable and future-proof, so I try to avoid them. Once in a while, I find something that I need to do that can't be done with a public API, so I weigh the importance of what I need to do against the dangers of using things the developers didn't want me using. If I don't really need to, I won't; but I won't rule it out."

C. "I prefer to ship code written with public APIs, but I love exploring private stuff. It's a hell of a lot of fun to dig around inside the wiring and put together neat shit I wouldn't normally be able to implement. Sometimes the product of this ends up in an app I release, but I try to keep it from happening too much because I can't predict when something's going to change."

D. "Private APIs are just features like anything else, but secret. There's nothing wrong with using these even though they're undocumented and we have to figure out how they work. The API developers wanted to keep all the toys to themselves, but I'll do whatever I think is best. It's not really going to cause a problem."

Take a strong guess as to which kind of developer the author is. To demonstrate how I arrived at this conclusion, let's do some surgery.

Coming Together to Pull Things Apart

We're going to take what we've learned so far and apply it to the RegDeveloper article. Deep breath.

Here, on a regular basis, Dave will introduce you to unknown and undocumented aspects of the Foundation and AppKit class libraries that Apple has, er, neglected to tell you about...

Think back to the section that described the development of the operating system and its public and private APIs. Now reread this quote and tell me if you think Apple "neglected to tell you about" something that they don't think is ready for public, widespread use. Sounds much less secretive now, doesn't it?

The author is just setting up a justification for bad advice, it seems.

In my opinion, there's no sense in re-inventing the wheel if Apple has already done the job for you.

This is the second in Dave Jewell's Series of Bad Assumptions. Apple hasn't done the job for you already; they've done the job in a way that isn't ready for other people to use. They have deemed it not to contain unshippable issues, but it has either not been finalized or documented well enough to be used in real, shipping third-party applications. Or both. There's also a really strong chance they know about quirks that they haven't worked out, which makes the API unsuitable for mass adoption.

Over the coming months you'll find there are an amazing number of undocumented wheels within the Apple libraries that let you get on with writing great applications without having to reinvent what Apple have already done.

Undocumented "wheels"—which is a misleading way of saying "shit that wasn't designed for you to use"—usually have nothing to do with writing great applications. The two are mutually exclusive concepts when the mass of public APIs are as rich and powerful as they are. We're not talking about things that are essential to creating good software being hidden from developers.

Alternative thought: Fuck, he's going to keep recommending people use private APIs in shipping applications. And green developers are going to listen to him.

They are just waiting for you to set 'em spinning!

No, they're really not. That's the point of being private.

At this point, a few folks will doubtless be sharpening their quill pens (or even wooden stakes!) and preparing to chastise me for using undocumented features.

Using a private method once in a while is common practice in software development, though usually not recommended; commandeering an entire private CLASS is almost always frowned upon. And when what you want to do is so trivial as what we're about to encounter, it's silly to go out of your way to dig into private APIs to accomplish your task unless you're just tinkering for the sake of curiosity.

I'm not chastising anyone for using private shit, but I am taking the author to task for encouraging people to ship applications to people that needlessly make use of PRIVATE FUCKING UNDOCUMENTED FUCKING UNRELIABLE FUCKING STUFF.

That's true, but I'd offer a couple of counter arguments in return.

I braced for the bullshit excuses and pressed on . . .

First, Leopard (OS X 10.5) has only recently been released, and is likely to be good for several years - it's very unlikely that minor system updates would impact what I'm describing here.

Is Dave Jewell privvy to the past, present, and future engineering plans of the AppKit team? No? Then perhaps he should pretending he's some kind of authority on what private APIs will not undergo unannounced changes. They're private, they're 100% subject to change, and private changes don't get announced.

And if they do, I'll obviously make every effort to bring you a work around.

Excellent idea. Should I set up a POP forwarder to your e-mail address so you can also handle bug reports and incident support from people using my application when one of the private APIs changes in an update? And will you help implement and support the "workaround"? How soon can I expect a workaround?

I mean, if you're gonna push someone down this path, you'd better not ditch them in the woods when they bump into a tree. It's almost like . . . having to support an API you encourage people to use. Sounds familiar, yeah?

Next, and more importantly, you can spend more time making your great Mac application even greater - and surely that's what we'd all like to see, including Apple. Right, Apple?

Apple wants to see developers make great applications. They don't want developers making applications that break because their engineers need to change something internally and no one was supposed to have been relying on what got changed in the first place.

This is also how internal API engineering gets jammed up sometimes. When it becomes apparent that third-party developers have come to rely on some undocumented private API, it makes decisions based around that API more difficult. In a perfect world, whatever people were using would've been public anyway. But things are rarely that simple in the real world.

You'll also note that evil-looking call to _nsBeginNSPSupport. This is a fairly recent addition by Apple that is designed, I suspect, to prevent third party use of NSPreferences. Without a preceding call to this extern void routine, the call to super init will return nil.

1. Developers who have used this private API in the past have been bitten by a change to the API. I'm shocked.

2. It's extremely easy to find function calls buried in libraries. Apple knows people will find things that they go searching for. As a result, the addition of a private function like _nsBeginNSPSupport() does not mean that Apple's trying to prevent third-party use. It's too easy to find, and people will find it, as the article shows. What the article doesn't show, however, is what evidence is behind this "suspicion" other than the same shortsightedness from the rest of the article.

3. A corollary of #2: "Evil-looking"? Are you serious? Painting things in a malicious light does not make your article any better.

Remember, an API often remains private because it's volatile or hasn't been documented to give developers the information they need to use it properly or debug problems encountered while using it.

This Could Have All Been Avoided

I sludged through the article and realized something:

This guy wrote two pages about how a developer could use a completely private system to do something as trivial as making a preferences window for his or her application. That's pretty weak. Not only is it weak, but it's very lazy thinking.

It's just a preferences window. With the exception of the individual preference bindings, it's an extremely generic thing. A better solution would be to write solid, supported, portable code using documented APIs, with the intent of reusing the generic preferences window base you built.

This is exactly what Apple did with NSPreferences and NSPreferencesModule. They have their own simple interface for creating and managing preferences windows. It's not that hard to use public APIs to build your own generic preferences classes like these. Once you've built it, you can reuse it. Maybe Apple will finalize a public version of what they're doing for themselves, and that'd be great, but they aren't exactly withholding the secrets of the atom here.

The article suggests that you should hack around with Apple's private, unsupported APIs instead of letting work get in the way of building your next great application. I posit that a better article would've taught you how to build your own reusable preferences window construction kit just like Apple.

link to: privacy

file under: analysis | comments (0)