Jesper at waffle is starting an open-source web browser project to revive the spirit of OmniWeb, called rouse. He coins the phrase “delight innovation”. I love that phrase. He’s talking about taking a browser, something that’s relatively stable, and looking for ways to make it noticeably better again. I love that impulse – it’s something I’m hoping to see in email clients too.

Another place that delight showed up (along with Surprise and Joy), was at 52 weeks of UX in a post called “design for delight”. That post seemed to be a little more about the parts of design that don’t affect functionality, but do add personality. I really agree with this angle too – I like a program that has little details that are just for fun.

The Workstation - RIP 2010?

Marco Arment wrote yesterday about mobile computing being more exciting than what he called “Desk” computing. I’m a fan of Marco’s writing, and I usually agree with him, but that post got me thinking. I can’t argue that mobile isn’t exciting, but I disagree with his assertion that desktop computing is a solved problem. He’s right that the pace of innovation has slowed. Certainly the last couple of OS X releases have fewer and fewer compelling differences. In fact, I’m writing this on OS X 10.5 — 10.6 didn’t impress me enough to make me bother upgrading.

Still, when Marco asks what I want out of 10.7, I think “what don’t I want”?

I think there’s tons of room to improve on and even rethink the workstation.

Maybe now that the consumer train has shifted toward more custom-designed tools for browsing, games, and social apps, there’s room for workstation OSs to grow in ways that might improve them without worrying about leaving the home user behind (or boring them).

I’m not asking for unintuitive design. What I’m asking for is powerful tools – system and apps – for people who use computers for work every day. I certainly hope that these power tools will be built with elegance and style. I’m not asking for dual cameras and four speakers.

Market forces have limited development of crucial daily-use work tools to what will appeal to the home & leisure market. For instance, Apple ships Mail and iCal with the OS. Both are fine programs, but are clearly trying to ride the line between work features such as meeting planning, and consumer features like stationery. Meanwhile, the market for alternatives is limited, and even some of the alternatives have taken the approach of adding consumer-related features. Postbox, for instance, has added facebook and twitter support. That’s not helping me get work done – quite the opposite, really.

But am I really just talking about incremental improvements and a few more work-oriented features here and there? I don’t think so. To be more specific about what kind of big improvements I think are possible in desktop systems, I did a few minutes of brainstorming. Here’s what I came up with:

Like the personal jetpack, I’m still waiting for the system that knows what I’m trying to do and co-ordinates to help me get it done. The one that learns (even crudely!) about my habits and the time of day, my colleagues, their schedules, etc. The one with this knowledge baked in everywhere in the system. For instance, it knows which app’s notifications can be ignored for later.

As a start, I’d even settle for a single system that actually uses all the good ideas that have come up in the past 30 years. Let’s at least catch up to Douglas Engelbart’s vision of the NLS system for augmenting collective knowledge work before we call it a day.

Good search everywhere has been a real improvement, but what about full support for smart annotations for files, events, people and other data? The BeOS file system comes to mind. Search is better when there’s better info to search for. If I push it a little, some smart background prediction of categories for documents that’d help me find them later — that couldn’t hurt. Why doesn’t a file know who emailed it to me?

Another blast from the past – maybe OpenDoc was a stretch, but more open document formats and easier flowing data between applications isn’t a bad idea – can we expand on that?

This one ties in with mobile devices – Real, honest to god multi-computer network syncing. It can be done – it should be baked in! What if your filesystem was actually an easily merge-able version-controlled document oriented database like CouchDB? Can we use some ideas from distributed version control to make sharing documents on disconnected filesystems work right automatically? I still think the best solution doesn’t depend on storing everything on servers (especially public servers).

That leads to the oft-repeated idea of getting rid of “saving”. I shouldn’t have to commit changes – maybe I want to tag a version, but the data should always be written to disk.

Every app should be able to know about communication (mail, IM, SMS, whatever) that might affect what you’re working on in it. Today’s apps have uniform access to your files – but not to your messages. This seems like a bad historical distinction – they’re both relevant data. For example, why do I have to “save attachments”? It’s already on my disk…

What about application and system scripting that really works – that’s easy enough for quick things but powerful and fast enough to grow a real program from? Let me start them as visual or spoken one-off commands but then edit and share them as text.

System support for Quicksilver/Launchbar/Ubiquity-style text command lines. Tie this into the scripting system. Make it feel like I tell the computer what to do instead of finding the right app to tell, opening it, etc.

System-wide hypertext – I should be able to create robust links between document parts, messages, people, and other entities. It should be fast to view an annotated list of changes across versions of a document, showing who did them and what they said about it in emails. This shouldn’t have to all reside on some central server to work.

Do you have any ideas to add to the list?

Each post got plenty of responses. Dissenters have a wide variety of reasons for why it’s no big deal, ranging from “tomorrows tinkerers will just play with different technology, like bio-mecha” (fascinating!), to a lot of people saying, essentially, “Just don’t buy the appliance if you want a computer” (obvious!).

Others have made a solid point that the iPad is the next big computing paradigm. Steven Frank calls it a “New World” device. I can’t help but agree, and of course powerful devices that empower instead of confuse the user are a good thing. Replacing most of the world’s overcomplicated, fussy laptops with focused and reliable devices is a good thing.

Of course, general purpose, hackable computers are not really going away, not soon. Even if everyone uses an iPad for personal stuff and a Chrome OS netbook to access private cloud services for business work, there will still be a need for workstations, and I hope the people building complete personal systems out of Free Software don’t give up.

However, in a response to comments on his post, Mark Pilgrim made a gloomy prediction: “People haven’t figured it out yet, but Mac OS X is on its last legs. By 2015, Apple will make appliances and developer add-ons. Not general purpose computing devices.”

If you ask me, this is the real problem.

The problem is that hackable computers that I want to use could very well be fading out. Maybe Mark’s overstating things, but I would not be surprised to see the Mac, and OS X, as a relatively low priority for Apple in the near future. Design and development effort and creativity will naturally go increasingly toward the more profitable platform – the one making computing finally pleasant for the normal person.

I’m worried that this will happen for third-party developers too. I’m not the only one. Back in 2002, Brent Simmons described developing user code for the Mac as “the show”. Is there any doubt that Apple’s mobile OS is “the show” now?

Where does that leave the rest of us who still have to or want to use a more powerful platform?

It’s about computer usage as a creative act, something that becomes harder and harder to experience the more proficient one gets with a computer.

I feel this way every once in a while too – It used to be fun just getting a computer to do something. Once you know enough about how it works and most of what you do is handled pretty smoothly, some of the fun goes out of it. The problem with high-quality free apps like Mail and Address Book is that they remove the motivation for people to tinker with new ways of using computers for the same old things.

This urge to tinker is pretty strong, at least for me, and I think it might be one reason why I’m not so excited about web and mobile (at least iPhone) programming. Both platforms have a lot going for them, but the barrier to tinkering with my data is high – sometimes I can’t get my data out of a service, and if I want to write scripts to combine two web apps, where do they run?

For example, I’ve seen a lot of great things come from the community built around BibDesk’s scripting interface, and if it were a web app, none of that would have happened.

Because I always have more than one project going, I don’t actually wait much. I just switch workspaces and try to make progress on the next thing. If I can’t make progress on anything immediate, I’ll end up checking email or looking up something for a side project.

This kind of multitasking is inefficient, but inevitable when I might have to wait for 20 minutes or more for a compute job or a compile to finish.

The problem with this approach is that the things I’m waiting for often finish while I’m off doing something else, and if I get too involved, the low-priority research or emails will eat up my day while the high-priority work sits waiting for me.

I’ve attacked this problem in the past when using OS X with growl, but I can’t call growlnotify from remote systems. However, I just found dzen for X Windows, a lightweight notification display utility that compiles easily on every system I’ve tried, and works remotely with ssh X forwarding.

I wrote a simple script called go, which just executes its arguments and runs dzen when it’s done. Now I type (for example) go make and I can switch over to something else, confident that I’ll see a big popup window letting me know when I can get back to working on my highest priority project.

Here’s basically the entire go script:

!/bin/ksh

echo $@ $@ echo $@ completed on hostname \ | dzen2 -p -h 64 -bg darkblue

It’s simple but it’s working great for me. I’ve tried some improvements like randomizing window placement to avoid overlapping notifications, but the simple version above really does all I need.

Finally, a couple of details. zsh always seems to want to spell-check ‘go’, so I really named it ‘~/bin/executeAndNotify.sh’ and just aliased ‘go’ to that. Also, I’ve found it can mess with shell quoting as is, so sometimes I have to do 'somecommand ; go echo done'. If someone has a tip on getting the quoting right in the script, I’d love to hear it. The problem crops up when you try something like ‘go make CC=”cc -g”‘ – the quotes don’t make it through.

The latest version of PyObjC is 2.0, it’s installed by default on OS X 10.5, and XCode now includes templates for starting a PyObjC project. There’s even code autocomplete in XCode for PyObjC and IB integration, so aside from some smart-indenting issues, writing PyObjC in XCode is almost as natural as writing in ObjC.

I thought I’d post a few nice shortcuts and tips here.

You can use tuples for NSRect/Range/Point, for instance, this -

r = NSInsetRect(((0, 0) ,
                 (100, 100)),
                10, 10)

creates this NSRect -

NSRect origin=<nspoint x=10.0
                       y=10.0>
       size=<nssize width=80.0
                   height=80.0>>

Passing python arrays as NSArray instances (and dictionaries as NSDictionaries) works great, but sometimes you need to pass a C array. The Python ‘array’ module handles that nicely:

import array
g = NSGradient.alloc().
   initWithColors_locations_colorSpace_(
    [NSColor.whiteColor(),
     NSColor.blackColor()], <br/>
    array.array('f', [0.0, 1.0]),
    NSColorSpace.deviceRGBColorSpace())

ObjC selectors are just python strings in PyObjC.

defNC.addObserver_selector_name_object_(self,
  'windowDidResize:',
  NSWindowDidResizeNotification,
  self)
# or
self.performSelectorOnMainThread_withObject_waitUntilDone_('doIt:', None, False)
# or
if o.respondsToSelector_("fun:"): return o.fun_(a)

Finally, something that comes in handy when working with KVC, the ‘_’ method now defined on NSObjects in PyObjC:

o = <some ObjC object>
print o._.myKey
o._.myKey = 44
# is equivalent to:
print o.valueForKey_('myKey')
o.setValue_forKey_(44, 'myKey')

That last example is straight from the NEWS page, where lots of other useful info can be found.

I’ve collected some links to public info about the job.

The Google channel has a promotional video from one engineer about the role – he tells a quick story about being on call to monitor and address problems with Google talk.

A set of slides from a talk by James Youngman at the UK Unix & Open Systems User’s Group gives a good description of the general task, and dives deeper into two specific examples – powering down failed disks, and protecting data with checksums, exploring how straightforward ideas can explode at scale. (These slides also have potentially the best proprietary-information disclaimer I’ve ever seen: “This has been written entirely in ASCII. No EBCDIC or animal fat.”)

Here is another set of slides with a quick overview, from a ‘lightning talk’.

A sampling of what Google SRE engineers put in their public resumes about their job includes quite a span – from troubleshooting mission critical services to writing automation software (in Python).

And finally, an interesting post from 2006 about the theory behind Google’s hiring strategy, summarized as “only hire candidates who are above the mean of your current employees”.

HPCWire is a well-known news source for HPC. It has daily news updates, and occasional columns by guests from around the industry. Most of the news is press releases from companies and government labs, but it’s nice to have a single place to check for them. However, there is apparently no RSS feed, and to get email updates, you have to buy a subscription. I haven’t, but I do check back occasionally to read the columns.

Supercomputing Online is another professional news outlet, which reads a little less like a press release, seems to have more coverage of academic news, and does have an RSS feed.

insideHPC.com is more of a weblog than either of the first two – John E. West covers news stories in brief with some added perspective and analysis. I like his approach, and I’ve joined him to help cover academic HPC issues, both computing research and issues affecting computational scientists.

One of many blogs at Sun is the HPC Watercooler, covering Sun’s HPC products and services, as well as some non-Sun related news. I’ve found it pretty interesting already, and I’d be interested to see weblogs from other HPC vendors.

Finally, a couple of blogs that are less directly related to HPC but still very relevant for computing researchers, are Dan Reed’s weblog at the Renaissance Computing Institute, and the CRA Computing Research Policy Blog, both of which cover computing research policy and funding issues that don’t often show up in news coverage of either government or computing.

* – if anyone wants to start an LTU-alike site for HPC research, or point me to one, I’ll sign up and contribute in an instant.

This is a pretty interesting attempt to get around the problems facing processor design today. Clock speeds have stalled, but the actual Moore’s Law – the one about transistor count, not “speed” – is still going, so we have the problem of what to do with just a lot of copies of basically the same old chip?

A lot of answers you hear involve pushing that complexity up to the programmer, forcing more people to become parallel programmers. This is almost certain to happen at least a little, but let’s hope we don’t have to give up on the sequential programming model completely. If you think software is bad now…

The TRIPS processor is an example of another approach – placing more of the burden of finding and using parallelism onto the compiler and architecture, keeping programmers’ heads above water. It’s pretty exciting to see something this different make its way into actual silicon.

The basic idea is that instead of a single piece of control logic organizing the actions of multiple functional units, finding concurrency within a window of instructions using reordering, the TRIPS processor is distributed at the lowest level – each functional unit is a mini-processor (called a tile), and instructions executing on separate processor tiles communicate operands directly, not through a register file. Usually this is described as executing a graph of instructions instead of a single instruction at a time.

Current processors certainly don’t just execute one instruction at a time, and they do plenty of moving instructions around, so I tend to see this explicit-data-graph description as just the far end of a spectrum that starts with old superscalar designs, continues through out-of-order processors and multithreaded architectures, and currently seems to end here.

A TRIPS processor can run four thread contexts at once, with an instruction window of 1024 instructions to reorder and 256 memory operations in flight at once. For comparison, the late ’90s Tera MTA ran 128 threads at once (128 different program counters), and the 2003-vintage Cray X1 processors kept track of 512 memory operations at once. Just like TRIPS, each of those architectures required extensive compiler support for good performance.

A particularly interesting point is the fully partitioned L1 cache – meaning that there are multiple distributed L1 caches on the chip, so where your instructions are physically executing will be important for performance – if they’re near the cache bank holding their operands, they will execute sooner.

The natural question when looking at a new and interesting architecture like this, especially one that promises a tera-op on a chip, is whether it will make its way to a laptop you can buy anytime soon. I have no idea if the UT team has any industry deals in the works, but I would bet against something like this becoming mainstream quickly – the fact that these architectures rely so much on a custom compiler with aggressive optimization means that a lot of dirty work is required to move existing software to it.

It will be interesting to follow this project and see how their actual hardware performs.