How little Johnny application doesn’t play well with others

Spotted this post on the ranchero.com RSS feed about New World vs. Old World computing, making the argument that Old World desktops are all-purpose machines, vs. New World computers (currently, mainly the iPhone/iPod) are more narrow-purpose machines, and even when they have more than one purpose, the purposes tend to be siloed and sandboxed.

Notwithstanding the arguments about the computational and energy savings of only running one app (and limited system services) at a time, there’s a good reason for the siloed/sandboxed nature of these applications, and that is that by default, applications do not work well together on an Old World desktop. Despite the best attempts by platform designers to engineer a product where you generally don’t step on other apps’ toes, and best practices published that try to bridge the gap between the platform’s strictures and programs’ capabilities, apps step on each other all the time. They incorrectly rely on shared state¹, or worse, destructively edit shared state that happens to work fine (for them). They are not uniform in the way that they share data between applications (copy/pasteboards and the formats provided, file system and the file formats of the files, sockets and the protocols that run over them). The data you want in one app might be data (perhaps slightly tweaked) that you want in another app, but unless you’re a Excel or Perl² wizard, getting from A to B is a whole lot of work. Even in systems designed by the same company to work together sometimes fail in these regards, especially as their feature sets and complexity grow³. Lastly, there is no nice model for assigning execution control to applications; customers rarely know when some hidden plug-in is monopolizing their system and causing scrolling or typing to slow to a crawl. How many times have you just wanted to read one e-mail, but some untold number of system agents conspire to time-share your processor enough to steal time from what you really need to do?

And that’s when you actually trust the application to run on your box. For most software manufacturers, you can generally trust that they didn’t mean to do any harm (and yet they still do). Then there’s the class of app-makers who write apps that are just-useful-enough that you install them and all the malware / exploits / junk that came along for the ride. Since the average Joe doesn’t know the difference necessarily, he’s either afraid to click on the utility that might just solve his problem, or he’s opening up his system to possible attack vectors by clicking on the utility, or he’s incurring the not-insubstantial overhead⁴ of running anti-virus/anti-spyware programs.

The siloed approach capitalizes on the generally limited way these programs communicate their data by making that the choke point–data flows can be to internet site(s) or the user through UI, and that’s it. No tromping on other apps’ data. No mismatched communication with another app on the same box through the traditional pathways (and even web services don’t work since you won’t have both apps up at the same time). There still may be issues about spyware, and it’s unclear whether an app validation service such as Apple’s could clearly tell whether a user’s privacy would (possibly) be violated. But for the most part, you running an app means pretty much that you can only really take down your own app, and spend as much battery as you want doing so. Siloing means pushing the problem of communicating that data between local services to be between cloud services (e.g., Facebook and twitter integration), where there’s now a whole new playfield where cloud apps won’t play well with others. But it does mean that your local box will do as well as its purpose-driven cloud support will do, and without interference. And that means a lot.
--
¹Can you say, “registry”? (Or machine state, but that’s not a problem solved by New World machines either.)
²Insert any reasonably advanced script language that parses (regexes) strings and byte data and permutes the same.
³Not that Microsoft has any examples of these. ;0
⁴Both in money and human/computer time.

Running ClickOnce apps at startup

We use an internal tool to keep a watchful eye on the various bug databases we might have bugs in, to get notifications when new ones come in and to provide a fairly reasonable summary UI. This was internally released as a ClickOnce (Wikipedia) application using .NET. I thought it best to put it in the startup group to run on login, but found after working a number of times, it stopped launching at some point. Turns out, this is because you can’t put the application reference in the Startup items since it might move as later versions get installed. Instead, follow this article by Keith Elder to create a regular old internet shortcut and get the right behavior.

Ellen's Black Beans and Rice recipe

---begin-tinykitchen---
Title: Black Beans and Rice
Serves: 8-10

1 lb black beans
1 lb smoked link sausage
0 - ham hocks (optional)
2 - onions (diced)
1 can RoTel tomatoes & green chilis
1 tsp Tony Chachere's Creole seasoning
1 can chopped tomatoes (large can)

Prepare black beans according to instructions on bag for quick cooking, drain, then cook in pressure cooker. Fry/steam the smoked link sausage in a frying pan, drain, and cut into small pieces. To the beans add the sausage, ham hocks, onions, tomato & green chilis, creole seasoning, and chopped tomatoes. Cook long and slow, simmering until sauce thickens. If you use a crock pot, leave beans uncovered so sauce can cook down. Serve over rice with salsa and sour cream.
---end-tinykitchen---