Pragmattica

October 21, 2009

Caffeine 1.0 Released!

Filed under: Uncategorized — bnsmith @ 8:04 am

It’s official. The “Caffeine for Linux” project has reached 1.0! Only a few short months ago, I was hacking away in secret on the initial 0.1 release of a clone of the original Caffeine for Mac. I had no idea if anyone would be interested in contributing to it, or even using it. I’m very pleased to say that the response has been terrific, and far beyond even my most optimistic predictions. I’m very glad that I took this project on, in part because I now have a version of Caffeine for my Linux box. But the best thing about this project has been having the opportunity to work with such incredibly talented and knowledgeable developers. I have learned so much, and I owe it all to you. Tommy and Isaiah, you’re the best!

But I think that I’ve spent quite long enough waxing nostalgic about the events of the last six months. Moving along…

What is “Caffeine for Linux”?

Caffeine keeps your computer awake! It’s a little coffee-cup applet that sits in the notification area:

pic1

When you click on it, the coffee-cup fills up and keeps your computer from going to sleep:

pic2

It also inhibits the screensaver.

Why is this Important?

Imagine that you’re giving a presentation. The room is illuminated only by the blue glow of the projector, displaying your slides on the screen behind you. You linger on a particularly crucial slide, carefully explaining the subtleties to your mesmerized audience. Several minutes pass, and just as you are about deliver the stunning conclusion, the projector goes dark, displaying only a tiny “No Signal” message in the bottom corner.

I expect that everyone reading this has seen some presentation or other where the display powered off or the screensaver came on halfway through. Don’t let this happen to you!

But That’s Not All!

There are a depressingly large number of fullscreen games available on Linux that don’t properly inhibit the screensaver. With Caffeine, you can fix this problem quite easily; no scripting required. It’s also handy for watching long flash videos without having to tap the Shift key every few minutes. In fact, the new 1.0 auto-activation features make these two things even easier than before.

There are three types of auto-activation that can be configured in the preferences:

pic3

You can configure Caffeine to automatically start preventing the screensaver and powersaving whenever a particular program is running. To set this up, just run the program that should inhibit the screensaver, right-click on the Caffeine applet, select “Preferences”, and then click “Add”. You should see a list of all running processes in the pop-up window. Click the name of the program that you started earlier and click “Add”. Close the preferences window. In about 30 seconds, you should see the coffee-cup applet spontaneously fill up.

If you want to set this up for a fullscreen application, just run the application, wait a minute or so and then quit. When you go into the Caffeine preferences to add a new auto-activation program, your fullscreen application should be listed under the “Recent Processes” tab.

Caffeine can also automatically prevent the screensaver and sleep mode when a flash video is playing in Firefox. This works for many popular flash video websites, most notably youtube.com. Unfortunately, there are also some websites for which this won’t work, like hulu.com (a workaround for this issue is available; see Isaiah’s post for details).

Finally, Caffeine can be configured to auto-activate whenever you play Quake Live, a version of Quake III that you can play for free right in your web browser.

Hopefully, these features will allow you to deal with any powersaving inhibition issues that you encounter on your Linux box. Once you get Caffeine configured, you should never have to think about it again.

Caffeine is also available in several new languages. In some cases, the translations are not totally complete, but are enough for typical day-to-day use.

Installation Instructions

At the moment, the easiest way to install Caffeine is through the project’s PPA. Just copy and paste the following three commands into a terminal:

sudo bash -c "echo 'deb http://ppa.launchpad.net/caffeine-developers/ppa/ubuntu jaunty main' >> /etc/apt/sources.list"
sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 569113AE
sudo apt-get update && sudo apt-get install caffeine

However, we do hope to get Caffeine 1.0 into the official repositories in the near future.

Where Do We Go From Here?

Caffeine 1.0 now has all of the features that I originally envisioned, and plenty more features on top of that. Still, now that 1.0 is here, I can see now that there is still room for improvement. The major task for the 2.0 release of Caffeine will be to make it easier to configure. We hope to do this through an online database of programs that have difficulty inhibiting powersaving on Linux. Our goal is to implement the capability for Caffeine to regularly download the online database of problematic programs, if the user explicitly enables it. There are some details that still need to be worked out, such as how to prevent a hostile individual from adding well-behaved programs to the database and thus draining people’s batteries unnecessarily. However, if we do manage to figure these things out, then it could become possible to fix all “powersaving-challenged” programs by simply installing Caffeine and enabling the database download feature.

Conclusion

I guess that’s it. If you have any ideas for new features, please post a comment or write a blueprint the project page. If you discover a bug, you can report it here. Finally, I’d like to say thanks to all the people who have contributed to Caffeine for Linux. Your hard work is helping to eliminate a major source of headaches for Linux users, and thus helping to push the whole Linux desktop experience forward.

March 19, 2009

What the Designers of Bank Vaults Should Learn from the Field of Computer Security

Filed under: Uncategorized — bnsmith @ 3:51 pm

I recently read this Wired article about a diamond heist that took place a few years ago. It’s a good read; I suggest you check it out.

Anyway, the article gives an excellent description of each of the security measures that the vault’s owners put in place, as well as the methods that the crooks used to circumvent the each measure. While reading, I continually marvelled at the ingenuity with which the thieves circumvented each system, which is, I suppose, the point of the article, and why it makes such great reading for geeks like myself. At the same time, I couldn’t help but feel a little uneasy about the approach taken by the owners of the building to secure their vault. It seemed like a shotgun approach: take one of every kind of sensor and locking mechanism available and stick it in their somewhere, and then keep the final resulting system secret, to make it more difficult for thieves to figure out which circumvention methods would be necessary to breach the vault.

In the realm of computers, there is a name for this strategy: security through obscurity. That got me thinking, is there a better way to secure physical property? I think that at this point, most knowledgeable computer people have given up on security through obscurity, and now recognize the importance of proper security. But physical security is a very different beast than computer security, isn’t it? I mean, if the current state of the art in vault-making is just security through obscurity, then what would proper security look like?

One of the primary principles of computer security is that it is open. Nothing is hidden or secret about encryption algorithms. The only secret is the secret key that a particular person uses to encrypt their data. As long as an attacker doesn’t know that secret key, their knowledge about the rest of the encryption algorithm doesn’t help them a bit. Would it be possible to do the same thing with a vault? Could you make a vault whose blueprints were completely open and available to anyone, but that was still secure, as long as the combination was unknown?

I thought about this question for a while, and it seemed to me that it should be possible, but no answer was forthcoming. The central problem is this: you can keep the control system for opening and closing the vault inside the vault itself, to protect it from tampering, but you still need some way to communicate with the control system in order to cause it to open the vault’s door. For example, if the control system inside the vault will only open the door for a particular numeric code, then you would need some kind of keypad on the outside of the vault, so that the vault’s owner could enter the code when they wished to enter. Then you would need some kind of connection between the keypad and the control system. The most obvious communication channel would be a simple wire, but then you would need to drill a hole through the vault’s outer wall for the wire to pass through. This hole then becomes a vulnerability. The attackers could rip off the keypad, pull out the wire and then snake a little endoscope-like robot through the hole to monkey with the control system directly. There are little additions that could be made to this system, but none that fully remove the vulnerability. If you make the hole through the vault wavy rather than straight, for example, then the little robot would have more difficulty snaking through, but a more flexible version of the robot could be built. Measures could be adopted to prevent the keypad from being ripped off, but they could all be circumvented by opening and hacking the keypad itself, which the attackers would have relatively easy access to.

If the vault’s walls were constructed of metal thick enough to withstand many hours of drilling, then it probably wouldn’t be possible to use any kind of wireless radio signal to communicate with the control system either. This was the thought that finally led me to the answer that I was looking for. If the vault’s walls were made of metal, then perhaps the walls themselves could conduct electricity well enough to allow a signal to be transmitted through.

Imagine this: a vault cast as a single piece of hardened metal, with walls several feet thick, able to withstand three days of non-stop drilling. The vault’s single opening would be protected by a door of the same thickness as the rest of the vault. The hinges for the door would attach on the inside of the vault. From the outside, the vault might appear as though it is just a solid block of metal, with only the thinnest seam visible where the door joins the rest of the structure. Also inside the vault would be the computer control system, perhaps powered by radioisotope battery. The computer would have paddles touching the outer wall that would be able to detect if the wall was conducting and electrical charge. If the computer detected the right pattern of on-off charges (communicating the secret key in binary), then it would open the door. To open the vault, the owner would roll some device up to the side of the vault, pressing paddles up against the vault’s walls. They would then enter their code, by a keypad or some other means, and it would be transmitted through the vault’s walls to the control system.

All that would remain would be the “brute-force” attack: drilling through the wall. Of course, there could still be some subtle vulnerability, but if the plans were published for review by the security community, that would definitely decrease the likelihood of such a thing. If nobody in the security community publishes an exploit for the vault over the course of, say, 50 years, then I think it would be safe to say that the chances of discovering a vulnerability in the next 50 years would be vanishingly small.

There are some possible problems with this. For instance, I don’t know how much electricity would be needed to generate a signal that could reach into the vault. Perhaps the owner would be risking electrocution every time they tried to open the door. Perhaps the vault would need to sit on insulated pillars, because of the electrical charges involved. I am not a vault designer (IANAVD), but it seems to me that something like this could be built.

Perhaps what I’m describing has already been invented, though a quick Google search didn’t turn up anything. If there’s anyone out there who knows anything about bank vaults and physical security, I’d love to hear what you think.

May 10, 2008

Why I Chose VI

Filed under: Uncategorized — bnsmith @ 8:21 am

Today, I finally made a decision. I will learn to use the vi text editor. Actually, that’s not quite correct; I plan to learn Vim, but you get the idea. Anyway, I have also decided to explain my reasons for this choice, in the hopes that it may be useful to other people who haven’t yet made a decision, just as I hadn’t, before today. I believe that I have made my decision on a rational basis, but that is for you to judge. Remember that I am new to both vi and Emacs. I haven’t invested several years of my life in mastering either one. On one hand, this means that I do not know enough about either to really judge based on their features. On the other hand, I believe this also leaves me largely unbiased. Until today, I would have been perfectly happy to select either one, had I encountered some incisive, knock-down argument in favor of one or the other. In the end, it was just a grab-bag of little things that finally pushed me over the edge. But first, perhaps it would be instructive to answer another, related question.

Why I Chose Nothing

A lot of you are probably wondering why it has taken me so long to pick one or the other. After all, vi and Emacs have been around for decades, and I’ve been a programming professionally for several years now. Well, it’s not as though I haven’t thought about it. Every time I encountered a co-worker who used one or the other, a little niggling doubt would pop into my head. What do they know that I don’t? What am I missing?

I gave the subject a great deal of thought, and decided that I should instead spend my time on languages rather than tools. Instead of learning a tool that makes it easy to add a lot of getters and setters to a Java class, for example, wouldn’t it be better to learn a language that doesn’t require getters and setters? I still feel this way, to some degree, and I certainly don’t regret my decision to learn about Python, Haskell and Scheme. Nonetheless, I now think that a little investment in vi will pay off in the long run.

Reason #1

I’m placing this reason first because it is the most immediate reason for me to learn vi. This is the reason why I am learning vi today rather than yesterday or tomorrow. Although I am still believe that learning more expressive languages is the better solution to repetitive editing tasks, I live in the real world. I am a working programmer, and it isn’t always reasonable to choose the exciting and obscure languages that I read about in my spare time. Beyond that, I have come to accept that there is more text out there than just raw code.

Today, I ran into a situation where I needed to edit a 20 MB data file. I tried to pop open gedit, but it wouldn’t open because of some null-bytes that appeared half-way through. Needless to say, this was not a problem in a real editor. I needed to cut this file down to isolate a bit of data that was causing problems. I wanted to search for a bit of text, and then delete everything above it to the start of the file. With vi, it is possible to hook an operation that you wish to perform to a selection command. To move to the start of a file, you can type ‘gg’. Therefore, to delete everything up to the start of a file, type ‘dgg’. Three characters is all that is required. If it had been a shorter file, I would have just held down the ‘Shift’ key and pressed ‘Page Up’ until I was at the top, then tapped ‘Delete’, and I wouldn’t be writing this post.

Reason #2

People often half-seriously suggest that Emacs isn’t an editor, it’s an operating system. The Emacs environment allows you to write programs, debug the programs you’ve written, check your mail, browse the web, play music, and a hundred other things, all without leaving the editor. The problem is, I already have an environment in which I can do those things: GNOME. I don’t feel the need to have another environment that runs entirely within a window on my GNOME desktop. Remember the Unix philosophy: write programs that do one thing and do it well.

Reason #3

This is probably going to be one of the more controversial reasons, given that I have so little to back it up, but I’ll mention it anyway, simply because I believe it and it has been a major factor in my decision. I believe that vi is currently more popular than Emacs. Linux Journal’s Readers’ Choice Awards for 2008 put vi in the top spot for text editors. Debian Administration also conducted a poll on the subject, though I admit that their numbers are probably unfairly skewed towards vi, given the site’s audience. There are a few bits and pieces of anecdotal evidence floating around, but the real clincher for me is the activity level. There just seems to be more going on with the vi community. There are multiple projects to bring vi-like features into Eclipse, as well as multiple GUI wrappers, including the intriguing Cream project.

Popularity isn’t everything, but it does matter, as I’ve described before in relation to programming languages.

Reason #4

I don’t want to get Emacs pinky. I do realize that it is possible to change the useless “Caps Lock” into a Ctrl key, and I have, in fact, done this previously. Still, based on what I have read, this improves the situation, but doesn’t eliminate it. I’d rather just avoid Emacs pinky entirely.

Conclusion

I’m not going to guarantee that I will spend the rest of my life becoming a master of Vim. I’m just going to make a point of learning some of the keys and using it regularly for a while. If it doesn’t stick, I’ll just move on to something else.

Blog at WordPress.com.