TedPage

It is truly amazing how many examples that you can find displaying information, not just on computers, but in real life. Here is an example of my favorite coffee shop in LA (though not just because of their good display of information)

While it's tricky to see in the cell phone picture all of the carafes have a label on the handle describing what type of milk is inside. Which makes a ton of sense. When people replace the milk to the table after using it they point then handle to the edge. So, without the labels on the handle, the next person is forced to turn the carafe around to figure out what's in it. Much easier to use.

posted on Mon, 29 Oct 2007 at 08:17 | permanent link | 0 Comments

Imagine the social implications if, on every e-mail you sent, a random member of your addressbook was BCC'd. It would have to be a virus. I think it would be very entertaining to see how communication changed. People would probably just stop using e-mail. Anyone want to write this as a virus for the Blackberry?

posted on Fri, 12 Oct 2007 at 00:26 | permanent link | 0 Comments

There is a debate in congress on the role of security contractors in US policy. While I'm concerned at the use of contractors (almost doubling the US force in Iraq) I'm more concerned about the people who are those contractors.

I think that it is safe to say that the risk of PTSD is the same for enlisted military as contractors. Maybe even higher as the contractors haven't been through bootcamp. But, the support structure when they return home is entirely different. The military has the VA and the contractors have... well... money. The VA makes a tremendous effort to help those who have been at war reintegrate into society providing things like support groups and they are trained to look for things like PTSD. And the contractors have... nothing.

This will become a societal problem. As we have these contractors returning home they'll have the same problems that our military personnel have returning back to society, without support. We'll have a group of people trained in military techniques that are disenfranchised and can't reconnect with the support structures they have. It's likely that violence will ensue. They'll return to their training and back to the last times they felt like they were in control; when they were in Iraq.

I don't like to leave problems without some ideas of solutions, but I think that it might be too late for a reasonable solution. I think the right thing would have been to require the contractors to guarantee the same benefits as the military to their employees. I don't think we can do that retroactively. We need to either grandfather those people into benefits or deal with their problems as they happen.

posted on Thu, 11 Oct 2007 at 23:05 | permanent link | 0 Comments

In thinking more about the per-user filesystem that I proposed earlier I realized: Why should any process see files it doesn't need? If they aren't required, let's make them disappear. Then the question becomes: How do we know what files a program needs? The answer is: package management.

In Debian based Linux systems this is all handled by dpkg. Dpkg knows about every package, what files it contains, and which files it requires to be installed. Assuming all the packages are configured correctly, an application in a package shouldn't need any more files than those in it's package and it's requirements. So let's hide all the others.

The real question then becomes performance. For every program startup we would have to check which package the executable is in, find the files for it and all it's requirement, and then build a filesystem with only those files included. But, I think with caching and progressive loading those problems could be solved. The reality is that most applications rarely get directory listings. Most of the time programs ask for specific files that they've been compiled with like /lib/libmylib.so or /usr/share/myapp/icon.png. So the database would only need to be queried for specific files not all the files that the application could need.

Secuirty frameworks like SELinux and AppArmor try to achieve many of the same goals with files on the filesystem (they also do more with things like networking). But, for simplicity's sake many times the policies get grouped, so most applications can read anything in /lib. By involving package management we can ask the question: "Why should they?" and still keep coming up with the answer simple.

Though, this would probably be better implemented as a plug-able security module rather than a FUSE filesystem. Implementation decisions go to the person doing the implementation.

posted on Wed, 10 Oct 2007 at 14:12 | permanent link | 0 Comments

Here are some photos from our trip out to Boston. I was taking care of the kiddo, so I only took the little camera. Not the greatest pictures, but we had a good time.

       

Also, you can check out the pan-o-rama that I posted earlier

posted on Tue, 09 Oct 2007 at 02:03 | permanent link | 0 Comments

I'm thrilled to say that I'll be starting a new job at the end of this month working at Canonical. I'm happy to be leaving the proprietary software world behind, and starting to work in the open. The funniest part to me is when I tell people about the job, most comment on how great it would be to work at home, and I'm so much more excited to be working on Open Source. Different priorities I guess.

What will I be doing? Ubuntu desktop development. Basically making the Ubuntu desktop one of the most consistent and powerful desktop environments anywhere. It's hard work, but I'm excited to do it. The whole thing is summed up by this article in Good Magazine: "Better-than-it-has-to-be Design". We're hoping to make the Ubuntu desktop extraordinary.

posted on Tue, 09 Oct 2007 at 01:45 | permanent link | 0 Comments

Let's take a little trip along this thought experiment. A recent addition to the Linux Kernel (and now others) is FUSE, an interface that allows filesystems to exist in user space and have applications still use the kernel API to access them. What if we were to make a per-user filesystem, and make all of that user's processes chroot from it? A dynamic chroot jail.

This user filesystem could achieve a few things. It would provide additional security in that applications couldn't even see files that they shouldn't need. /etc simply doesn't exist. This problem should normally be solved by having reasonable permissions, but this would mean that an administrator accidentally going chmod 666 /etc/passwd couldn't result in any issues. /tmp could be mapped to a random directory for the user, something like /tmp/user-AF832BF, and so if a program had a temp file sharing vulnerability, it would be unexploitable.

We would also be able to simplify the filesystem such that things like /var and /etc and /sbin simply wouldn't exist to the user. We could also rearrange the filesystem some making a /Desktop and /Documents so that they're easier to find. (heck, Linspire could even call them My Desktop and My Documents)

I think another advantage would be to give network managers an easy way to move and configure user home directories. Instead of your home directory being /nfs/us/california/los_angeles/users/ted all of that would be hidden by the FUSE filesystem. Yeah, that can be done with symbolic links, but because different applications handle them differently (and many expand them) it still creates a confusion for users.

This would also give an easy way to start standardizing how things like local caches are handled. It is foolish that every application handles these themselves, and even crazier that they are saved in your home directory. For the NFS example that I gave above, why should your browser cache be synchronized across the network? Why shouldn't your e-mail image cache be shared with your browser image cache? A more universal handling could be achieved with this filesystem as things like "all caches are on local filesystems" could be configured.

I'm still not entirely convinced that this is a "good idea", it definitely has some strong points. It is a departure from the traditional UNIX filesystem structure that we all know and love. Every time you're departing from a long held standard you need to make sure that it's an upgrade. In many ways, this restructuring is similar to the way Apple's filesystem is presented to the user. Only, in this scenario the rest of the filesystem simply wouldn't exist to any user applications.

posted on Thu, 04 Oct 2007 at 01:53 | permanent link | 0 Comments

This weekend is the Google Summer of Code Mentor's summit. I'm going to represent Inkscape and I'm excited. I'm excited to meet up with lots of other Open Source hackers from a rather wide variety of projects. Plus, I get to see the Googleplex.

Inkscape had a very successful year with Summer of Code projects. I will blog about them more. The real key for us now is to roll them up into a release and get them out to users. I think users will be very shocked at all the new features in the upcoming 0.46 release.

If you're in or around Google drop me a line. I'm not there for very long; so I don't know if we'll be able to do anything, but let's try!

posted on Wed, 03 Oct 2007 at 13:53 | permanent link | 0 Comments