A speech about cryptography and linux.

This speech is about:

• crypted email with gnupg
• crypted file system avaible under linux, an overview and a comparison of loop-AES , cryptoloop, dm-crypt, bestcrypt
• creation of a full crypted file-system, root included. The most interesting feature is system’s boot sequence, which uses a usb token for authenticating users

After three days of LWE, I'm both happy that it's over and I don't have to talk anymore and can just sit here at the gate waiting for the flight home, and sort-of sad that it's over, that it was so short and we couldn't talk to more people. openSUSE as a project doesn't immediately excite all people, but after explaining what it is about, everybody I talked to seemed to really like the idea.

Here's a list of the frequently asked questions at LWE, and my answers. Please note that this is by no means an official FAQ, but as I told everything written below in public already I can just as well blog it:

So, tell me about openSUSE!

The openSUSE project is where the development of the SUSE Linux distribution will happen from now on. We've had for a long time one common code tree on which we worked internally, and from which all our products, like SuSE Linux Professional or the enterprise offerings were branched at a certain point in time. All our developers and packagers are working on that tree, and will continue to do so, but now every change is visible immediately to the world so that people outside can download the latest versions, test and contribute to them.

Right now people can only download and test the beta builds and latest packages and report the bugs they find (we've opened up our Bugzilla for that). In the future, we want to offer a platform where people can upload code and RPM specfiles and have their packages built on our infrastructure, and rebuilt automatically whenever something in the distribution changes.

This way you can be sure that you always have a working rpm you can distribute to your users, and be notified when it doesn't compile cleanly any more because something you depend on changed - some library, the compiler, anything. This might not seem much at first glance, but in our experience this kind of automated build system is a great help in developing and maintaining any non-trivial application, and we want to offer our knowledge, our infrastructure and the necessary tools to people and projects in the open source community.

The distribution that is developed in the openSUSE project will be called SUSE Linux. Packages maintained by people from the outside may or may not end up on the distribution - we actually want to encourage people to also use our infrastructure for exotic or experimental stuff.

Is this like Sourcefourge?

No. We do not want to duplicate anything that already exists. The core functionality of sourceforge and similar sites is to host project development. Our core goal is to provide an infrastructure to make working RPM packages from code developed elsewhere, and to offer the advantages of automated distribution builds to developers.

Is this like rpmfind?

Yes and no. No, because rpmfind does not provide the infrastructure we're planning. Yes, because we hope that we attract people to build their packages on our servers, resulting in many more packages available to users than the ones we work on ourselves (which, by the way, are quite a few already).

Is this like Fedora?

Similar (there's no point in denying that), but not the same.

First, we want to be more open than we perceive the Fedora project to be towards contributions from the world. We will need to have the packages which make up our core distribution closely reviewed and under our control, just because the will eventually end up in our business products and have to be maintained and supported (by us).

But for packages that are not in this core set we can yield much of this control to package maintainers which are not employees, so we want the openSUSE project to be more flexible regarding new packages or experimental versions of existing ones.

Second, we still make a retail product from it, targeted at end users and developers alike.

* * *

Other frequent questions were about the relationship to other products, the motivation of Novell to start the project at all, and many practical ones, like how to get involved and become a beta tester and whether one needs to register or not. This entry is long enough already, so I'll spare you the remainder of my sermons ;-)

Oh, and the chamaeleon printed on the DVD is definitely very, very cool.

Ok, you've got me. I'm blogging now as well. Welcome ;-)

Several people have asked for a little standalone app that uses ipod-sharp, since not everyone uses Muine and keeps all of their music on their PC. So this weekend I wrote Dopi.

You simply DnD folders/files onto the song list there to add stuff. The delete key deletes (surprise!). To try it, you’ll need the latest ipod-sharp. It has been moved into Mono’s SVN, so if you have the stuff from baz, that is out-of-date. Also, ipod-sharp depends on libipoddevice in GNOME CVS, so you’ll need that too. And lastly, Dopi itself is in my baz archive, here.

I worked some more on the muine-burn plugin. It should be far more stable now. So if you tried the last one and had problems, give this a shot. Tarballs are here and here.

I fixed up fer‘s muine-burn plugin recently. It now works with the latest muine, and recent libnautilus-burn. Surprisingly little was needed to get it into working condition again. AFAIK, the plugin wasn’t checked into version control anywhere, so I committed the changes into my baz archive. I also put up a tarball here.

I was in Utah last week for work. It was good to see people, put some faces with names, etc. Working from home has benefits, but it’s nice to do things in person sometimes. I was in the SuperLab, testing ZENworks (of course). It was pretty cool, and I’m quite sure I’ve never seen more computers in a single place before.

Haven’t done any hacking on Muine lately. Partially, because it won’t even run for me currently (some kind of lame gtk-sharp exception). One thing I was thinking of doing, is resurrecting fer’s CD burning plugin. I don’t usually take the iPod with me in the car on short trips, and I’ve wanted an easy way to burn stuff on a CD to use there.

Enjoyed reading GUADEC-goers blogs. Maybe one of these days I’ll be able to go. If there’s another Boston summit, I should definitely try to make it to that.

Like everyone else, I am totally stoked about the new Nokia 770. The hardware looks sweet, but the fact that it is coupled with a sane open development platform just makes it ridiculously attractive. Especially considering it’s based on a platform we all know relatively well :)

The screenshots look really great. One thing I wonder about, though, is how well the included apps deal with an unreliable network. I mean, if I stroll out of range from my wifi, will all kinds of errors and stuff show up, or will it deal gracefully? The development site mentions some things about getting events like “low battery” over dbus. Hopefully “network is down” is the same kind of thing, and apps can just go into offline mode or whatever.

It would be really fabulous to get mono running on this thing. I wonder if something like a “compact edition” of it would be needed.

Martin Palma has gone to the work of packaging muine-ipod and ipod-sharp for Ubuntu hoary. You can get them here.

Work progresses. I’ve still been getting used to bazaar, which I’m using for version control. Overall I really like it. I want to start learning some of the more advanced features, though.

The latest muine-ipod snapshot has support for optionally syncing only the current playlist to the iPod. I’ve been told this works pretty well for shuffle users. I still think we need some way to individually mark songs in the library for syncing (similar to what iTunes does I think?). iPod Mini users would especially benefit from this, since they probably can’t sync their entire library — and composing a playlist would just be a bit ridiculous (6gb of music in a playlist!).

Also, I sent a patch to muine-list this week that added a plugin for inotify support. It simply monitors the directories you’ve added to muine, and if something gets added/removed/changed it takes the appropriate action on the song library. I’ve wanted this kind of behavior in a music player for years, and now that inotify has come along it’s finally possible. I’ve been using rml’s inotify kernel for SuSE 9.3, and it’s working quite well. You can get the patch + plugin here.

A while ago I started working on a plugin for Muine that syncs your library with an iPod. I worked on it a bit more lately and it seems to be coming along, so I’m trying to get people to test it. You need this and this, to start.

Right now there is no HAL integration, as I’m having an incredibly difficult time figuring out the correct way to integrate with that stuff. What it will do, however, is mount/umount your iPod assuming it is setup correctly in fstab (correct device, ‘user’ option, etc). It defaults to /media/ipod for the mount point, but that is configurable through a gconf key (/apps/muine/ipod/mount_path).

I’ve been using it for the last few days with no serious problems. I do suggest you backup your iTunesDB file before giving it a shot, though, as corrupting that is the worst thing that can happen. You can find it at /media/ipod/iPod_Control/iTunes/iTunesDB. If you encounter problems, feel free to email me.

Update: You will need muine 0.8.3 or greater to use this plugin, as previous versions lack the necessary interface.

Another Update: I’ve checked ipod-sharp and muine-ipod into arch at http://www.snorp.net/bazaar.