LXDE in Archlinux

LXDE (screenshots) is a great desktop environment. I felt in love for it in a few days, exactly when I discovered it.

It is based on Openbox, which is my favourite WM except for tiling ones. It includes PCManFM, which is by far the best file manager I’ve ever seen on a Linux environment, after KDE4’s Dolphin/Konqueror: I’ve been waiting for the multicolumn mode from OpenStep under Linux for years. I’ll talk with LXDE’s developers about it. LXAppearance provides an easy way to choose the GTK theme, icon theme and font. It is, AFAIK, the only graphical alternative to Gnome’s tool for those features. LXPanel works great, it provides exactly what I’m looking for and is light, still easy to configure. To name a few, icon-only window list, keyboard LEDs indicators (did you remember I use a EEEPC?), launchers you can manage just by selecting .desktop files (sooo better than Xfce). The session manager permits me to shutdown/reboot/suspend/etc., without using any display manager (I use x:5:respawn:/bin/su - gcarrier /usr/bin/startx). And it doesn’t depend on many libs: GTK2, DBus, HAL, FAM. There’s a simple NetworkManager alternative which is work-in-progress. For now, it only works with Debian-based systems (as it uses ifup/down scripts), but I got SVN commit access and will improve this very soon. Anyway, it will never follow the NetworkManager way and any advanced stuff should be done through a shell. But it manages ASCII/hexadecimal WEP keys, parts of WPA and is very easy to extend by customizing shell scripts. What really astonished me was LXLauncher, an enhanced replica of EEEPC’s default tabbed desktop launcher. Considering it, I could really provide LXDE to my grandma.

I wrote PKGBUILDs for everything today. For now, various TU maintain parts of it; I’d like to entirely maintain it as I’ll follow the developers very closely. And provide a lxde group to make it easier to install. You might want to use lxsession-lite instead of lxsession which is buggy. Last but not least, the Subversion repository contains nice apps to come.

Packages signing in pacman, Archlinux getting secured?

Introduction

This post title is such a troll… Archlinux is my favorite Linux-based distribution, it’s already secured, blah blah blah, you got the point. Here’s the story. Questions come next.

Signing? How awesome is that!?

Security is one of my big concerns. So I started to work on packages signing, which might be the biggest lack in Archlinux for now. Thanks to toofishes, who is totally mentoring me on this, we went to a point where a nearly complete design is available. The implementation is far from finished, but it’s now possible to see where we’re going, if we keep this way. And I think it perfectly suits the Arch philosophy.

The place to start with

We started working on makepkg. Basically, we added an option in the BUILDENV array (defined in /etc/makepkg.conf) named sign, which causes makepkg to sign the package it builds using gpg, creating a binary 72 bytes detached signature file.

That’s one small step for add-repo…

Then, we need the signature to be available on the repos. Using a 72 bytes file for each package would be overkill considering the number of mirrors. So we wanted to include the signature in the repo database (this .db.tar.gz file you might have opened if you understand a few words in this post). A whole file path in the tarball for every signature would be overkill too, plus it is uncompressed in /var/lib/pacman/sync/ and each signature could take something like 8kb (depending on your fs and its options, btw) as a separate file! But for each package, there’s a desc file with fields in it. Our idea is to put the signature in it. As it is plain text, we can’t put the binary signature directly. base64 is here! With a tool to (de)code it in coreutils, it definitely was the way to go. Now we have a new field which looks like:

%GPGSIG%
iEYEABECAAYFAkhDcqcACgkQj8OreK3cj9eStwCeIjf9AWQcPE9hH+t7iQ2pVCychxwAoKBcIiYph4RzVISP6bklppdOwmkF

It’s a long line, but it is still plain ASCII and won’t interfere with the file format as there can’t be any % in it. So we tweaked repo-add. That was a one line patch in the code. Did I tell you it’s a true story?

What’s the point?

Now that everything is here to generate repos with signed packages, maybe pacman could use this brand new information…

It could embed muuuch code from GnuPG. OK, what else? It could use gpgme, which would rely on gnupg itself, but is supposed to make things easier. Here, we just have to check a signature. We can work like git! Basically, we just need to popen something like gpg --keyring $keyringfile --no-default-keyring --verify - $pkgfilename and write the binary key to it. Then check for return code 0.

That’s where the biggest design choice come. How pacman should know whether a package can be trusted or not? Let’s use (a) keyring(s)!

I’ll let the gnupg users who learnt their lesson tell you that to trust Archlinux’s packages, you need to meet Aaron Griffin himself (omg omg! RMS would be so jealous!), or someone who met him, or someone who met someone who met him, etc. as long as it seems at least a lot more than reasonable to you. And please do the same for [archlinuxfr], [eee], etc. Web of trust is a good concept.

Irrelevant throughts: Now let’s suppose you install Archlinux via FTP: you launch your installer from the USB key you’ll give to Grand’ma at her birthday next week, and you have configure gpg before installing packages. Well, I don’t know for you, but when I install a system, I want this done fast. Meaning at least a prompt to start tweaking within minutes. Dealing with a keyring like you would do for e-mails or chat sessions with your buddies at the NSA is not really adapted. Anyway, you will be able to work that way with our system!

We could have a keyring per repository in pacman.conf. I think it doesn’t make much sense: if I trust a developer to provide me binaries it seems I want to use, I don’t really care whether it’s init or vim (but I care whether it’s not emacs or still not). And I care even less if it’s in [core] or [community], because I love TUs. Did I tell you TUs are beautiful and smart young men and women who need care and love?

Now that you’re convinced pacman’s keyring should be system-wide, it would be convenient to deal with the various packagers of the repos you use. Here’s a hypothetical story:

I wake up at 10AM. I take my breakfast, a shower, and go to school. My girlfriend (yes, hypothetical) kisses my math teacher… Let’s be realistic. A year later, I install Archlinux on my brand new laptop. In [core], I keep archlinux-keyring. I add the [archlinuxfr] repository to /etc/pacman.conf, pacman -S archlinuxfr-keyring. I confirm the installation even if this package is not signed. I change Keyring /etc/pacman.d/archlinux.gpg to Keyring /etc/pacman.d/belovedlaptop.gpg, and run gpg-merge-keyrings archlinux.gpg archlinuxfr.gpg belovedlaptop.gpg. Then I add the [kdemod] repository, install its keyring and run gpg-add-keyring kdemod.gpg belovedlaptop.gpg.

Questions as promised

Why don’t the thousands of people who visit this blog put at least a dozen of comments on it? Do you think I should stop replying to my replies to my patches on pacman[dash]dev[at]archlinux[dot]org? Is packages signatures something you actually want? Do we do it completely wrong or just wrong?

Python on your Twintact

Here comes the first experimental release! Jean-Christophe is focusing on his exams and I don’t have much time either, but we’d love to get feedback and help.

You just need to download one archive and extract it on your micro SD card root, as a “twinthon” directory.

It comes in many flavours: tar.bz2 (12M), tar.gz (16M), zip (17M).

The (small) port system, with (inexistant) documentation and examples (for now, an example script with its shebang) is available on github.

Twinthon’s coming! Twinthon arrive !

Here we are: Twinthon! Python on the Twintact… Yes, that’s a little bit nerd. More to come in the next days.
On y est : Twinthon ! Python sur le Twintact… Oui, c’est un peu nerd. Plus à venir dans les prochains jours.
/mnt/fat/python
Linux (none) 2.4.20_mvlcee31-omap730_gsm_gprs #1 Wed Mar 5 15:30:00 CST 2008 armv5EJl unknown
Python 2.5 (r25:51908, May 26 2008, 18:59:45)
[GCC 3.3.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> print "Hello Twintact! I'm Python!"
Hello Twintact! I'm Python!
>>>
Ça pourrait intéresser les gars de chez OpenTwin…

Ideas for Arora: forms autofill, or “Think different”.

Do we need a password manager? I don’t think so.

Is it a good idea to bother the user about whether the form he just submitted should be stored locally or not? I don’t think so!

I think it should be easy to remember any form value easily. I want to control that from the keyboard or the mouse in seconds. This choice is field-related. That’s why it should be simply available from the contextual menu (so, simply using the Menu key on anyone’s modern PC keyboard).

Three states could be useful (I didn’t think a lot about the naming issue):

• Don’t remember (default)
• Remember on this page
• Remember on the whole website/domain

But contextual menu is not visible by default, and this choice should always be visible to the user and intuitive. That’s why I suggest extending the input widgets. Widgets extensions rock, just see how useful and easy it is to resize a multiline input field using drap and drop… Some rounded icon at the right of the field, like the one on the adress bar. Grey by default, which means nothing is stored. Grey when the field value is stored for the page, blue when it is stored for the website. You just have to click it to change this state.

BTW, a central place to control which form items are stored, and forget some would be necessary. It could look like some sort of browser, with a two-pane view.

No mockups for now, but I’m working on it!

Edit: here’s a mockup for the forms autofill values manager (please find a name; and BTW, the lines headers are stupid, there should be 2 columns):

Ideas for Arora: the download location

I would like some intuitive way of choosing the download location in Arora.

From what I’ve seen:

• A lot of people just always use the desktop. Maybe just because it’s their browser default setting, but they adapted their behaviours to it. They want all their downloads to go straight to it.
• Some people use some “Downloads” directory the same way as the desktop. They don’t want to be worried about the download location each time but want to choose it once.
• A fairly small amout of users prefer choosing the download location each time.

I propose a Arora design that will suit all those people by staying, IMHO, intuitive.

If no default location is chosen, this dialog is shown (I have no idea if it’s easy to extend the QFileDialog to get something like that; otherwise, we might open some simple dialog after it for the first download):

By default, the “Always here” checkbox is unchecked, except for the first download (as it is the behaviour most people will expect).

The preferences pane would be changed to this (I’ll skip the handmade draft for a real mockup this time; you can thank me):

Edit: Here’s a new version, as some think that a checkbox is counter-intuitive. Please give your opinion in comments!

Edit 2: As Arora’s developers prefer to keep the native file dialogs (under Windows and Mac OS X), there are no hooks to implement the first download checkbox. Another (maybe better) solution could be to use this kind of dialog on the first download then:

It would be better to default to “Yes”, I guess.

EEEPC = revolution

I won’t write a lot of thoughts on this weblog, but this one might become related to my work, as I just contacted MSI to spend time on their Wind netbook.

I got really interested in the EEEPC concept during last summer. The buzz around it seems to make logic to me, and I’m happy to participate to it.

I were an early adopter and turned into an impatient child until I received mine from Taipei. And it met my expectations, thanks to toofishes and his marvelous EEE repository.

I won’t spend time on the choice of not using Microsoft Windows. People who might contest it might also want to leave this place…

The EEEPC has some defaults, indeed. From the beginning, I wanted a 9 or 10 inches screen, at least 1024×600. Too bad it didn’t came out soon. I expected it to be completely Intel-based, and was disapointed by the Ethernet and Wifi drivers issues. I also was worried about its CPU. As I use it as my main computer for interaction (I mostly use its keyboard, trackpad and screen, and a X server on it for everything), I suffer from all those limitations on a daily basis. Flash is great, but 4GB became small when I started contributing to various OSS projects. Add its plastic design, relatively low battery (as most notebooks) and you should understand why I’m waiting for the next generation.

But my next computer will not a EEEPC 900 because 64 bits is the future, and I’d love Intel VT (not sure the Wind Atom model will support it, though). Not a EEEPC 901 either because this keyboard is a real pain in my *ss. Flash is lovely, but I’d rather get a 80GB harddrive that I can easily replace by something bigger. And I want way more battery life.

I will try to keep my EEEPC alive for years to come. This model will belong to museums someday.

Arora static builds for Archlinux

I just wrote a PKGBUILD for Arora, using Qt snapshot (static build). It makes the binary 19MiB, but will permit nsplugins (meaning Flash and Java) support very soon and permits you to keep the full-featured Archlinux Qt 4.3. Everything is again available on my server. And again, it’s highly experimental work.

Desktop integration: look and feel

As a Unix system user, I get sick of listening to same reproch again and again: apps look and act different.

Except for their references (neither Microsoft, with default Windows apps GUI looking completely different than Windows Live Apps to name some, or Apple, with the Carbon/Cocoa stuff and a pretty strange policy for iLife), I understand those persons who want a unified look. Because I do so.

I don’t know any solution for all X11 apps. I don’t know much about the “feel” part. The solution I use only deals with GTK1, GTK2, Qt3 and Qt4 apps look. And it’s far from perfect, but hey, who wants to work on “good” font support hack for Gtk 1.2?
This solution is named QtCurve, and it happily happens to be perfectly packaged under Archlinux. There’s even a group. Now, you just have to:

# pacman -S qtcurve gtk-theme-switch gtk-theme-switch2
:: group qtcurve (including ignored packages):
    qtcurve-gtk1  qtcurve-gtk2  qtcurve-kde3  qtcurve-kde4

And then use qtconfig, qtconfig3, switch and switch2.

KDE’s control center is supposed to permit detailed customization of the themes. As I use dwm on a EEEPC, I didn’t try it. But please add comments if you think it is worse the pain. And thanks for the tip, slubman.

Try arora on Archlinux!

This is my new “daily” browser for now. It is based on Qt’s WebKit new integration and started as a demo. Still pretty limited, it doesn’t include support for Flash or Java, nor any plugins/extensions (which is a feature in my case, as I prefer launching another browser whenever I really want it).

It depends on Qt 4.4. As the qt44 PKGBUILD has been removed from AUR, I decided to provide binary packages for both. Arora itself is available as arora-git on AUR (I use it). I compiled them for x86_64 and i686. As this only makes 4 packages and I don’t want to “officially” maintain them, I didn’t make a repository.

You can find everything on my server, and install them with pacman -U. Please notice qt is less patched than Archlinux’s version, and doesn’t include support for any DB except sqlite.

BTW, use at your own risk! But feel free to report any problem.

Edit: I am now working on the integration of nsplugins, which would mean support for flash and java.
Edit 2: Qt 4.4 is now available in [testing]. Local packages deleted, and AUR PKGBUILD marked deprecated. arora-git moved to [community].