2006 (old posts, page 2)

Locations and Travel Time in Calendar apps

Now that we've got Google Maps, I'd like to see my calendar program (iCal) extended to pay more attention to the location of events. Show me how long it'll take to get to events I've scheduled, based on where they are. Traffic estimates would make this really killer (at least here in So-Cal)

It might sound like you would need to tell the app where you will be at every point of the day for this to work, but you could avoid that by storing a 'coming from' location for each event - it could be the previous event, but you could also just pick it from a list of default places, like 'Home', 'Work', and 'Hockey Rink'.

In my dream world, they'd look like error bars on a plot, they'd even have data about variability of the traffic estimates, and they'd be in the next version of iCal.

Here's a quick visual, in case I didn't describe it well enough:

Assume home is south of the office and the basketball court is north. Traffic is bad going north around 6. What it's telling you now is you can go home fast, and have 30 minutes there before you have to leave again, go straight to the court, taking 45 minutes in traffic and getting there 45 minutes early, or have about an hour at the office, wait out traffic, and get to the court on time in about 25 minutes.

Update: I changed the example to be a little clearer - I added an option to show traffic choices, showed the times by the routes, and made one event appear selected, since you probably only want this extra info for the selected event.

I also made it a basketball game because everyone knows you'd need to go home to get your gear if you were going to the rink anyway. Seriously.

UCSD nixes Google Desktop

As a Mac user, I don't have Google Desktop, but this email from UCSD's Vice Chancellor was still interesting:

SUBJECT: Google Desktop Security Exposure

Google Desktop V.3 contains certain features that raise serious security and privacy concerns. Specifically, the "share across computers" feature that introduces the ability to search content from desktop to desktop greatly increases the risk to users' privacy. If Google Desktop V.3 is set to allow "Search Across Computers" files on an indexed computer are copied to Google's servers. We recommend that individuals seriously consider the potential for information stored on their computers to be accessed by others if they enable this feature of Google Desktop V. 3 on their computers.

Employees of the University (whether student, regular staff or faculty) who have confidential data on their work or home computers should not enable this feature. There are both privacy laws and university policies that could be violated through the installation of this feature, specifically, SB 1386, HIPPA, FERPA and GLBA.

While some of the features of Google Desktop V.3 are enticing to faculty, students, and staff, it is important to understand how information is collected, stored, and shared through this application, and the potential privacy risk to individuals.

Please review and share this information widely.

Helpful References:

Google Info

UCSD Policies about Protecting Data

For a good summary of the privacy concerns related to Google Desktop V.3, see:

Electronic Frontier Foundation press release

Technical Paper from University of Michigan's IT Security group

Introducing LENS

I've just put up the website for my current project (to be part of my Ph.D. dissertation work): LENS, a framework for program information manipulation that presents a uniform interface to selective user and automated queries about many types of program metrics, including success and diagnostic information about compiler optimizations and code generation.

I'm not sure how many readers of my weblog will be interested, but there's a link to a technical report on there if you want the gory details.

Feedback and questions are very welcome - the more opportunities I get to explain what I'm doing, the better I get at it.

NewerTech Battery

I replaced my stock powerbook battery recently with a NewerTech 53.3 Watt-Hour Battery, which is higher-capacity than the Apple originals, which are 46 Watt-Hour batteries.

My old battery was so spent by the time I finally gave in that it would give about 20 minutes on a full charge before forcing sleep. The battery warning would show up after about three minutes. So I can't compare the extended capacity directly to a fresh Apple battery, but the new one has been doing fine so far. I saw at least three hours from a charge yesterday, and it's letting me work at a coffee shop without worrying about finding a plug, and that's a nice change.

Jorge Cham and "The Power of Procrastination"

Just went to see Jorge Cham's talk "The Power of Procrastination" about grad school. There were plenty of good grad-school jokes and a general feeling of relief that comes with being in a big room full of people who laugh at the same old chestnuts about how nobody ever really feels like they fit in and always feel guilty about whatever it is you spend your free time doing - you know, when you should be doing research!

If you get a chance to see his talk, go for it, even if you've read all the comics, it'll make you feel better. And if you haven't seen the comics, go read them all first, then see the talk. Now I'm going to get back to work.

Curious pasting in Mail.app

I just discovered something curious. I accidentally pasted when I meant to undo in Apple Mail, and it took the text on the clipboard and created a new mail message with the clipboard text as its contents. Not a new message ready to send, like if I had dragged the text to Mail's icon, but a new unread message in my mailbox that had the text as its body and no headers.

"That's strange," I thought, so I pasted again, into TextEdit, to see if I'd somehow copied a mail message or something - no, just text. I then added a Subject: and From: header line, copied and pasted again. The same thing, only this time with those headers. It only seems to work with plain text pasteboard contents, and I couldn't get it to work reliably in every kind of mail folder, but a local mailbox seems to work most consistently.

I feel like I've found Mail's vestigial tail - this is mostly harmless behavior, but a little confusing, and I can't really think of any use for it. I'm curious how it got in there.

What's hot in CS

Today, a group of graduating PhD students in our department met up to brief each other on what's new and hot in their respective fields, to remind each other of what's going on outside their respective specialties. The idea is that when interviewing for jobs, you have to hold up your end of a conversation with professors outside your specialty, and it helps to know a bit about their field.

To quote one professor in our department, "...there is a special circle of hell reserved for grad students interviewing for jobs who are unable to answer questions of the form, 'Oh, you're from UCSD. What's Professor so-and-so up to these days?'."

It took about six hours to get through talks from students working on Architecture, Bioinformatics, Systems, Graphics, Vision, Databases, Security, VLSI and more, and I'm not going to try to repeat any of the details, because frankly I'm numb. I will say that it was a great idea, and if you're a grad student and your department doesn't do something like this, you should start a tradition.

I will mention one thing: automatic detection and adaptation to network attacks is so hot right now.

Talk: Bart Miller and Dyninst

In a recent largescale systems seminar*, we had Bart Miller from Wisconsin talk about some of the upcoming work on DynInst. DynInst is an API for runtime code patching, which lets you do things like attach to a running program and insert your own code around every network call, or replace procedures with your own versions. You can even do something as insane as calling a function every time the instrumented program accesses memory. (We do roughly that here at PMaC with MetaSim.)

Bart talked about some of the challenges they've had to face with DynInst and the directions they're planning to take it in the future. The major news is that they're planning to improve support for binary rewriting, in which you use the same interface to instrument an object file and produce a new executable instead of just doing it in memory. Also, they are planning on breaking it up into a few smaller libraries so you don't have to link everything in if you're building a tool that doesn't need all of DynInst. These are both good news for users.

He discussed some interesting applications of DynInst (such as trapping and removing calls to license checking code), and some odd situations that have driven development, like users who needed to instrument binaries that were hundreds of megabytes large (not with linked libraries, just the one file). He also highlighted some cases where DynInst really shines, such as needing to instrument a program that you can't even relink, due to lack of source code access or simple overwhelming makefile confusion. The facility for removing instrumentation led to a clever code coverage tool that removed instrumentation on a block after the block was touched once, leading to a really impressive speedup.

They've also used it to observe viruses without allowing them to write to disk, including nifty tricks like waiting until the virus uncompresses itself, then saving the uncompressed virus for later analysis. The extensive work they've done on binary analysis is important here, because viruses don't really come with symbol tables for handy debugging.

I thought that the most interesting part of the talk was about the challenges they've addressed through the course of the project. For instance, it is surprising how often with production compilers, that the symbol tables contain entries which are totally bogus. An example he used was that the function size information in most symbol tables is never right. Few tools pay attention to this, so it goes unfixed. One reason for this inaccuracy is another reason to consider using DynInst or something like it to build program analysis tools - object code layout is getting pretty confusing, and they've done the hard work of analysis already. For instance, noncontiguous functions are common. Apparently that's rampant in Microsoft's products, due to optimizations that reorder hot basic-blocks. Other weird code arrangements are common, including functions sharing object code. Compilers sometimes appear to be active adversaries to program analysis tools, and many tools in common use are making assumptions about code layout that are increasingly less likely to be correct.

I asked how symbol table information needs to be improved to let tools keep up, and what more information one needs to get from the compiler, and his response was that expecting many-to-many relationships for mapping code to source is very important if your tools need to deal with real code.

Thanks to Bart Miller for the talk - any errors above are mine, the ideas and hard work described are all theirs!

*I had wanted to post about it right away, but I didn't get to it until two weeks later.

State of the Union

I completely missed this year's State of the Union address, but was pleased to see this quote from the speech:

First, I propose to double the federal commitment to the most critical basic research programs in the physical sciences over the next 10 years. This funding will support the work of America's most creative minds as they explore promising areas such as nanotechnology, supercomputing, and alternative energy sources.

Having supercomputing named specifically by the President ought to be a nice thing to be able to point to when selling our field. It happens less and less these days, but I've definitely had people ask me if supercomputing was a dead field - the answer is a resounding no, and this just adds to the list of indicators, including the DARPA HPCS program.