Monthly Archives: October 2007

Leopard, Java, and Open Source

38 Replies

I haven’t gotten around to upgrading to Leopard yet for several reasons, probably the most prominent of which is that Lightroom doesn’t work correctly, and I’m starting to use it a lot (more on that in a later post, perhaps). But it’s not for lack of Java 6. I’ve been following the Java on Leopard thing with bemusement, but John Gruber’s most recent post sparked a few thoughts.

Since I haven’t posted in a while, let me remind you of the context. For a while I was a Java developer, but that was another life ago, and since then, I’ve been a Python developer, and am now a manager of Java (and Javascript) developers. I’d agree with John that Java is not directly important to the Mac. No important piece of Mac software that I am aware of is written in Java, and the only important (unless you count Azureus, which Mac folks would not) client side Java apps are Java IDE’s or custom corporate applications. So it is hard to make a compelling argument that a late Java is directly bad for Macintosh sales, which Apple is surely focused on.

Nonetheless, I do think that Java, and all those Java developers (who many in the Mac community look down their nose at) are important. Their pushing for Titanium Powerbooks and MacBook Pros helped (in a lot of situations that I am directly familiar with) to improve Apple’s credibility in development shops, which helped Apple get to where it is today. I might still be using Windows if I hadn’t gone to ApacheCon 4-5 years ago and started to see the Mac’s, which were being used by my Java developing friends.

Gruber says that Java is not made to “just build” on any Unix-like OS:

Several irritated Java developers suggested that I’d feel differently if it were a developer runtime that I personally cared about — that I’d be irate if, say, Perl or Ruby or Python were dropped or degraded in Leopard. But that’s not a good comparison; Perl, Python, and Ruby pretty much compile out of the box on Mac OS X. Apple doesn’t have to do much at all — at least relative to Java — to include them on Mac OS X. Why? Because that’s how these tools are designed and engineered — they’re made to “just build” on any Unix-like OS. It’s not Apple’s responsibility that Java isn’t like that — it’s Sun’s.

Actually, I don’t think that he is correct here. When I worked at Apple, one of the projects that I worked on was a port of Java 2 to run atop the Newton operating system. I personally wrote the driver code for networking and the file system, and I can tell you from first hand experience, that Java definitely builds fine on Unix like operating systems. That’s not the problem. The problem is where OS X is not a Unix like operating system.
The places where there seem to be problems are the places where Java needs to talk to Carbon to do all that client side GUI Java stuff. I don’t think that you can claim that Carbon is part of “any Unix-like OS”.

I do think that there is something important buried in the quote from Gruber’s post. Look at the difference between the runtimes that got “kept” in Leopard. Perl, Python, and Ruby (Let’s leave aside for a moment the sad truth that hardcore Python and Ruby developers end up installing their own local runtimes). Not only were these runtimes bundled, but 2 of the 3 were actually improved – things like bridges to Cocoa, DTrace probes, and so on. What’s a critical difference between these runtimes and Java? How did all these improvements happen? Many of them were done by people outside of Apple, on a schedule that was not Apple’s, but which coincided with Apple’s. The Ruby DTrace probes were done by Joyent, the Python Objective-C bridge was done by people outside Apple. Apple pretty much just had to pick up the changes that were made. How did this happen? Those runtimes are open source, as were all the improvements that I just mentioned.

A few years ago at JavaOne, Sun took a poll of Java developers to see if open sourcing Java was important to them. If I remember right, about half those developers said no. From where I sit, it looks like an open source Java would have contributed substantially to having Java 6 ready to go for Leopard. Today, Sun has opened up the source code for Java, but a version of Java based on that opened codebase has yet to arrive. Maybe open source Java really is important after all. I guess we’ll have to wait for OS 10.6 and Java 7 to find out.

Leopard hasn’t even shipped yet, and I am already mad…

2 Replies

I found Leap via TUAW today. I’ve been watching Yep because I collect PDF’s like candy, and it’s just getting a little out of hand. So the idea of a “tagging Finder” sounded pretty good to me. I installed the demo and briefly played with it. It relies heavily on Spotlight for finding the files and for doing things like excluding directories — I had to exclude a bunch of files in ~/Library/Application Support, for example. My big question was whether or not Leap tapped into Spotlight facilities for storing additional metadata. Before firing off a message to the authors, I dropped into the Google Group for Leap, and a little poking around produce this message thread. Unfortunately, the upshot is that even in Leopard there is not system level support for user defined metadata on files, despite the proliferation of third party tagging solutions. I’ve avoided looking at those solutions because I was expecting to see major improvements in Spotlight in Leopard, but it looks like that is not to be.

On Scoble’s Chandler interview

1 Reply

A couple of days ago, Scoble paid a visit to the OSAF office in San Francisco and did a video interview with Mimi Yin, the product designer for Chandler, and Katie Parlante, the General Manger of OSAF (and my boss). Of course, I heard about how the interview went, but I was curious to see how the interview would go. Robert and I have talked briefly about Chandler over the years, but not in any detail, and I wanted to know what he thought about what we have done so far. When someone says “I want it”, that’s generally a good indicator, and I was glad to hear that phrase pop out of Robert’s mouth. Also, he asked almost all the questions that I could have wanted him to ask, so if you watch the interview, you’ll get a pretty good idea about some of the most important ideas in Chandler. It should be no surprise that I want to expand/clarify some of the things in the interview, so here goes:

Where’s my Outlook?
If you watch the video, it’s clear that Chandler Desktop today is not very much like Outlook, in the sense that it is not an e-mail centric application. If you believed the Wired-induced hype about Chandler being an Outlook killer, you’re probably disappointed. How did this happen? When we sat down and looked at what people were using PIM’s for, how they worked, and what they needed the most support for, we discovered that there was a big need for supporting groups of people working together as opposed to individuals just managing their own information. That’s why you see an emphasis on sharing and collaborating. A bunch of the infrastructure that we built early on for supporting customized personal information is supporting what you see, so there’s still the capability for doing individual personal information management, but we haven’t focused on those capabilities. Developers take note.

Web-based Chandler
This came across unevenly in different parts of the interview, so I want to make this clear. Chandler Server/Cosmo, which powers our free Chandler Hub service, is a web based version of Chandler. It doesn’t yet have all the features of the desktop version, but we are getting there, and we plan to get all the way there. Not only that, the back end of Chandler Server can provide you with data in a variety of formats/protocols. We want to make sure that you can get data into and out of Chandler Server as easily as possible.

Edit-Update / Sharing (or turning e-mail into a Wiki)
In the interview, Robert latched onto the edit/update features of Chandler. These are still in a primitive state, but you can see the value of them already. He had a great summary of how it works – “you turn e-mail into a wiki”. Exactly. You can create and share a collection with any number of people, and they can all edit/update items in that collection and see each other’s changes, without groveling through endless e-mail reply chains. At one point in the interview, Mimi said something about e-mail being the hub of people’s usage. Truth of the matter is that e-mail is more like the glue that holds batches of information together. Collections of items with edit/update is a different kind of glue.

Plugins/APIs
Robert asked about a Chandler that could slurp data out of Facebook/Twitter/blogs/blog searches and manage all that stuff via the dashboard (the triaging workspace) and Chandler collections. This is a topic near and dear to my heart, and solving that problem is actually the biggest reason that I came to OSAF to work on Chandler. Personal Information Management is no longer about the tiny set of data types that Outlook typically manages. Today, most of my personal information (by volume) lives in the cloud, so any system that is going to manage that information must be integrated with the cloud.

If you look at the Plugins menu of Chandler Desktop, you will see hints at being able to do what Robert asked for. There are demo quality (read: proof of concept) plugins to yank data out of Amazon.com wishlists, EVDB/eventful.com calendars, RSS feeds, and Flickr. We had a plugin for grabbing your del.icio.us bookmarks, but it got way out of sync, but it wouldn’t be too much work to put it back. All these parcels turn their data into Chandler items, which can then be stuck into collections or managed via the dashboard.

On the server, we’re a bit further behind on data type extensibility. It’s possible (I mean it’s code, right?) but it’s going to be a bit more difficult to do because of the server environment. The server does provide good access to calendar data via a number of calendar protocols, including webcal, CalDAV, and Atom feeds. In addition, the AJAXY web UI talks to the rest of the server using Atom feeds and AtomPub, so in theory you could implement a different client by using those feeds and AtomPub. I am quite sure that we will be doing more work on data access API’s for Chandler Server in the months ahead. If you have ideas, suggestions, or code, come by the cosmo-dev mailing list or the cosmo IRC channel.

What’s Left to do?
If you watched the interview, you’ll know that there are a bunch of things that Robert asked about which are not there yet. This is not the 1.0 release of Chandler, and there’s plenty to do. At the same time, the desktop and server are done enough that people can use them and developers can get an idea of what we are trying to do and where we are trying to go. In the server project we’ve already had some good contributions from people outside of the OSAF staff (the hibernate based storage engine, and the minicalendar in the web UI). We’d (the desktop and server projects) love to see even more people get involved.

To keep up on Chandler happenings, visit the Chandler Project blog.

Dopplr should be looking over their shoulders

1 Reply

A few days ago I signed up for the new TripIt service. I didn’t have very high expectations, and I’ve already planned the rest of my trips for the year, namely my trip to ApacheCon. That trip was booked by a regular travel agent, and the form in which I got the documents was unlikely to be parseable by Tripit, so I just entered it by hand. I was really impressed by how much Tripit knew about my plane flight. I wish that it was similarly informed about my hotel. The itinerary management is pretty compelling for my uses.

There is also a social networking component to TripIt, which allows you to coordinate travel with other people, and you can generate a location stream and calendar feed. If TripIt can do what Doppr does, which is tell me who else will be in a location during the same time range, then I’d say that Dopplr should be pretty worried. Actually according to the TripIt blog, they are planning to do just that. They are also planning to do restaurants, which means that they might be able to act as a kind of evite/renkoo for groups of people looking for restaurants to eat at while traveling together. Yow. Call that the “Greg Stein feature”.

Aperture vs Lightroom: My Take

6 Replies

It’s funny how timing works in the real world. Last week, Fraser Speirs put up a post comparing Adobe’s Lightroom with Apple’s Aperture. Just before I left for San Francisco on the 23rd, I got a copy of Adobe Lightroom via a friend at Adobe, and I spent some time messing with it on the flight down (at least until I ran out of battery). I’ve also spent some time talking to James Duncan Davidson about Lightroom when I saw him at OSCON in July (his comments on Fraser’s post are here).

I’ve been a fan of Apple’s Aperture since it came out, but I started looking at Lightroom for some very specific reasons:

  • Twice I have run into problems with Aperture’s vault system. This is the cool system which will backup your Aperture library to another volume, sparing your mind the overhead of figuring out which photos, etc, have been back up or not. I have my Aperture library on an external Firewire drive, and my primary vault (backup) on separate external Firewire drive. Twice in the last 6 months, I have told Aperture to update my vault and instead gotten a message saying that there was something wrong with the vault. The only way that I could work around it was to delete the vault and rebuild it. When the library is well over 150GB, this is not a message that you are happy about seeing. Kind of negates the value of vaults if you ask me.
  • Performance – Aperture eats machines. I have an original 1.83GHz Macbook Pro w/ 2G of memory in it. If I don’t have 1G of memory free when I launch Aperture, I am going to feel pain. Once it loads, most things are reasonable, except for those that aren’t. Like straightening. I had a few pictures that I tried to straighten. Trying to do that sent my machine into paroxysms with the beachball cursor.
  • Toning Curve – When we went on vacation back in June, I did some HDR and panorama stuff using the new features of Photoshop CS3. Those images were definitely not going to be in Aperture, and while I worked on those images, I finally played with the curves adjustment in Photoshop. Which is when I finally understood the complaints of those who said that Aperture’s levels were not in the same league as curves. I was hoping to pick up curves in Lightroom.
  • Round tripping to Photoshop – Up until recently, I have had very little need for Photoshop, but as I am growing in my photography, I am realizing that there are a definitely somethings that I need photoshop for – dodging and burning, adding vignettes (Lightroom can do this), and doing stuff with layers to selectively edit parts of a picture. I’ve gotten to the point where I understand that pre-digital, printing a photo was as much a part of the art as making the photo. If you want to do that stuff digitally, there isn’t really much alternative to Photoshop.
  • Community – Photography is a singular pursuit, but I am finding that I am spending more and more time hanging with the Flickr folks in Seattle, and there’s an advantage to using the same toolset. That same advantage applies to things like presets of various kinds, web galleries, etc. And assuming that Adobe does really get around to that plugin API for Lightroom, plugins.

Having said all that, some thoughts on Lightroom:

The UI
I really dislike the modality of the UI, the Library/Develop distinction doesn’t make any sense to me. It’s also weird to have to go in and out of a compare mode, and even weirder that you need to switch to survey mode to deal with more than 2 pictures at once. It’s clumsy to go into full screen mode – you have to toggle through varying degrees of it to get there. Even so, you get there faster than in Aperture. You can’t use multiple displays, and I really miss that. I also miss the HUD’s in Aperture – they were a great way to keep pictures big while letting you adjust them. In Loupe mode, I found it very hard to find/see the metadata indicators. Aperture does a great job of letting you customize the information that is displayed in the different views.

Library/Project Management
Lightroom is much weaker than Aperture here. You can import your files without changing their location (as you can in later versions of Aperture), but there isn’t that much to help you organize pictures beyond collections of pictures. I made heavy use of Aperture’s projects and albums, and I miss that functionality. I can use collections, but the way I shoot, there will be lots of collections, to the point where collection management itself will become a problem. One way of managing this is to use multiple catalog files, but switching catalog files means relaunching Lightroom, which seems lame, and then you have the problem of not being able to find/search across multiple catalog files. I guess I am also having angst about putting my pictures into a directory hierarchy and having to back them up myself. You can create stacks, but you can’t create stacks inside a collection, which is irritating but not a show stopper. And as I mentioned, there’s no backup of the library, although you can get Lightroom to backup your RAW files as they are imported, and then have it backup the catalog file periodically. There’s an option to have Lightroom write XMP files, but there doesn’t seem to be a way to get those backed up. I am also a fan of the Lightroom Metadata Browser, now its easy to ask about common aperture, shutter speed, iso and focal length usages. It is also nice to have the fully interpreted EXIF data in the metadata display for a picture. The keyword browser also looks promising, but I don’t have enough keywords in it to know how it will scale up. I wish there was an option to erase a card after importing all the images on it. I miss that from Aperture

Adjusting
I really like the Lightroom Develop module, well the functionality, at least. I think that the histogram is way better, as is the white balance control, particularly because there are some default presets that you can switch to by name as opposed to being stuck with having to figure out the right temperature/tint settings for yourself. I also like the way the that Lightroom white balance eyedropper blows up the area that it would be sampling. Aperture does not have the Clarity or Vibrance adjustments, and those are pretty useful, at least to me. The tone curve is much better too, although I’m still learning it in comparison to Photoshop’s which seems more flexible. I like the ability to select point curves, like you can do in Photoshop. I like the HSL/Color/Greyscale tool, and while I haven’t done any split toning, I expect to be doing some of that. I was hoping to see more in the noise reduction, but guess Adobe doesn’t want to put all the noise plugin folks out of business — I’d expect those to be some of the first plugins out of the gate. The masking control on sharpening provides a degree of extra flexibility that Aperture doesn’t, but I hardly every sharpen a photo. The lens vignetting tools are probably ok for actual lens vignetting, but when I tried to use them to add a vignette to a picture, they weren’t much use. I did have one issue with the adjustment sliders, which is that it was hard to click on either side of the slider thumb in order to make a setting (which is what I normally do in Aperture). You have to grab the slider with the mouse and then let go before you can see the effect of the change.

Performance
Lightroom is definitely much zippier than Aperture for just about everything. I tried straightening, and that was no problem. Going in and out of full screen was no problem. There is the same kind of loading delay for images as there is in Aperture. It does appear, as Fraser pointed out, that some of the adjustments are kind of laggy. Then again, I experienced this at times in Aperture. The program is less resource hungry than Aperture too. I didn’t feel that I needed to quit one of my other memory hungry apps in order to do some work in Lightroom (I am so jealous of people whose MacBook Pro’s go to 4G of RAM).

Export/Printing
I actually like the Lightroom exporting, if for no other reason than that I can export in the background and be doing something else (either in Lightroom – impossible with Aperture, or elsewhere on the system – sluggish with Aperture). I did use Lighroom’s ability to send images to alias of OS X apps to setup a Flickr export preset. It’s not FlickrExport, though, which means no metadata comes through, the titles, etc get lost, and after the export, there’s no additional metadata on the images (FlickrExport adds the flickr id and url to the images, which is a great way to know if you’ve uploaded that image before or not). I’m feeling the pain on this one

I haven’t had a chance to play with printing from Lightroom, so I don’t have anything to report from there yet.

Other Features
The slideshow feature of Lightroom looks pretty good. Better than Aperture, anyway. On the other hand, Aperture can do books, and has the light table. It seems like the Lightroom web module is stronger, but that also an area that I need to play with some more.

Photoshop round tripping seems to be a little bit better than in Aperture, but I haven’t really put that to the test yet.

I’m wondering where that API/SDK is. Since Lightroom is written in Lua, there ought to be some good scripting/automation type stuff that could be done if Adobe would document how to do it.

Interop
Just for laughs, I did export a single Aperture project’s worth of RAW files and XMP sidecar files and then imported them into Lightroom. To my amazement, all the keywords, ratings and adjustments were there. That was pretty impressive if you ask me.

Where I’m at with Lightroom
Thus far, I’ve done a test import of a single project from Aperture, as well as importing all photos that I’ve shot since I got Lightroom — I’ve been double loading them into Aperture just in case. It’s a big deal to think about switching programs for something like this. I”m kind of unhappy with the rate of development of Aperture — I’m sure this is in part attributable to Leopard delays, but this shows the danger of having the program too tightly bound to the operating system. If I had picked up a Canon 40D, I’d be pretty unhappy, since Lightroom has support for the 40D and we’re still waiting for 10.4.11 or Leopard for that. My assumption is that Aperture 2.0 is coming sometime this month, so I will probably hold off on a full scale switchover to see what Apple does. But I’ve convinced myself that I could switch if I wanted to, with most of the pain centered around organization and library management. I am sure that Adobe knows these are problems, just as I am sure that the Aperture team has heard many earfuls about performance.

In the meantime, pointers to good Lightroom resources would definitely be appreciated.