Posts about arch linux

2010-04-10 14:51

Android on x86: report

Since I expect Android on tablets to be a big thing in 2010, I am experimenting with the closest thing I can get: Android in my eee 701 Surf 4G:


I got the testing Android 2.0 image from I had the 1.6 "stable" one but it was... well, it worked awful (half the key combos or menu options caused it to crash, reboot or otherwise autocombust).

So... how is it working? Slow, but it has potential!

The bad:

  • It boots quite fast... but my tricked full Arch Linux install boots faster.

  • It works sloooooow, you can see individual letters when you type in the search gadget. I read this is a temporary problem, though.

  • I am getting a "castrated" experience because the open android app stores are not as well stocked as the official android marketplace (and come on, why the heck can't I get free apps from there???)

    I see obvious holes in the app landscape that I suppose are well covered in the market (like, is there a RadioTray replacement?)

    No text editor?

    No semi-decent word processor? Not even one that generates HTML?

  • The web browser is pathetic. It may be nice for a phone, but for a "real" system? It's awful. You get the mobile versions of all sites (obviously) and many don't let you switch to the real ones! (even google does that, for Google Reader), and of course, no flash.

  • The email app is terrible. You can't not-top-post!!!! "In-Reply-To" is off-spec!

  • The WiFi settings are way too hidden. They should pop if you click on the wifi icon.

The good:

  • It shuts down incredibly fast.
  • Some apps are quite nice, specially the Aldiko book reader is awesome (and I can share the ePub books with fbReader on the arch linux side.
  • The included SSH client has great ideas.
  • I love the "all your data is in the SD" approach. I do the same thing with Linux. In fact, I have the same exact data organization now on both OSs :-)
  • The home screen with the sliding app drawer: nice
  • The "grabbable" system notifications on the top bar: very nice
  • The "use the menu key to get the menu" thing? genius ;-)
  • The "everything fullscreen all the time", thing? works on this screen.
  • App installation is a solved problem here.
  • I know I will be able to get Qt working native... can't wait!

I am not sold yet, Arch is just so much faster right now, and it can do so much more, but...

  • I am getting a touchscreen for it, so I can experience it more the way it's meant to be experienced.
  • I am using it a lot to read at night in bed (Just finished Makers, read it, it's cool!).
  • I am using it for casual mail reading (I refuse to reply with that broken app).
  • It's a pretty nice alarm clock, so it's becoming my bedside OS.

I'll write another report once I have the touch screen or a new (hopefully faster!) version running.

2010-02-11 14:00

Packaging and shipping is HARD

I have worked really hard on Marave, a full screen editor in the style of ommwriter, DarkRoom, WriteRoom, pyRoom, etc. I have worked very hard and I want users to use it.

Or not even that, I want them to have a chance of using it.

That means I want it to work on Windows (and maybe OSX some day, too, if someone helps me). Which means, I have to pakage it for windows.

Let's do a quick comparison here from the points of view of the user and the developer.

The User, In Linux

This is in Arch Linux, which is what I use, in other Linux variants it will be pretty much the same once Marave is a bit more well known.

yaourt -S marave-svn --noconfirm

That gets the code from SVN (right now it's the best way, later I will package releases, too), all required dependencies, builds and installs. It takes all of 15 seconds in my notebook.

After that, you have a fully working Marave.

In case it's not packaged for your distro, just install PyQt (which surely is) and run this command:

easy_install marave

The User, in Windows

You go to, click on "Marave-0.5.win32.exe" (Not linked yet, it's not finished), then download a 10MB program. That is a 10MB program because windows doesn't believe in packages and dependencies. On Linux, a Marave package could be under 1MB (most of it images), and not be executable, just data.

Of course nowadays web browsers don't actually run programs on download, so... let's see it as a gallery!


Yes, save it.


Double click to open it


Yes, I agree


Sure, whatever




Good to hear!

Now, this Marave that just got installed may or may not currently work because of a missing MSVCR90.DLL but that's for the next section...

The Developer, in Linux

First, here's the biggest problem a Linux packager can have:

Since Marave is a new app, and I develop it in the rather cutting-edge Arch Linux, it uses some newish features only available in recent versions of Qt. In fact, it doesn't work with PyQt < 4.6, which is not available in some slow distros, like Debian, or even in a not-latest Ubuntu.

Solution? Well, I could just ignore it, but what the heck, let's fix it instead!

Thanks to PyInstaller it's not even hard to do, here's the spec file:

a = Analysis([os.path.join(HOMEPATH,'support/'), os.path.join(HOMEPATH,'support/'), 'marave/'],

pyz = PYZ(a.pure)
exe = EXE(pyz,
        name=os.path.join('build/pyi.linux2/main', 'marave.exe'),
        console=0 )

coll = COLLECT( exe,
            name=os.path.join('dist', 'marave'))

Use this, and PyInstaller will produce a nice folder full of everything Marave needs to run on any Linux.

OTOH, if you can rely on a recent PyQt being available, it's also simple. Here's a packaging configuration for a similar package in Arch Linux (I must confess not having done one for Marave yet). For other distributions it should be about as simple, if more verbose, and someone else probably does it for you:

# Contributor: Roberto Alsina <[email protected]>
pkgdesc="Create PDFs from simple text markup, no LaTeX required."
arch=('i686' 'x86_64')
depends=('python' 'setuptools' 'docutils' 'pygments' 'python-reportlab' 'python-simplejson' 'pil')
source=($pkgver.tar.gz LICENSE.txt)
optdepends=('uniconvertor: vector images support'
            'python-svglib: SVG support'
            'python-wordaxe: hyphenation'
            'pythonmagick: PDF images support')
build() {
cd $startdir/src/rst2pdf-$pkgver
python install --root=$startdir/pkg || return 1
install -D ../LICENSE.txt $startdir/pkg/usr/share/licenses/python-rst2pdf/COPYING
install -D doc/rst2pdf.1 $startdir/pkg/usr/share/man/man1/rst2pdf.1

And that's all you need to know about the process of packaging your app for Linux. It's easy to do, and most of the time, easy to do right!

Now, let's go to our final section...

Windows for the developer

First, remember that of relying on the system's version of Qt? Forget it, there is no system version available. And no python either. And noone is going to install it or your app, so it's "ship everything yourself" mode, or nothing.

But anyway, PyInstaller works for Windows too! So, using the same spec file, it works. Right?

Well, no beause of two problems.

Problem 1: You need an installer

Users are not going to open a zip somewhere, then do a shortcut to the binary on Windows, so you need to do some operations, and that means an installer.

Here's what I came up with to use NSIS, a free installer creator for Windows:

;Include Modern UI

!include "MUI2.nsh"


;Name and file
Name "Marave"
OutFile "Marave-0.5.win32.exe"

;Default installation folder
InstallDir "$LOCALAPPDATA\Marave"

;Get installation folder from registry if available
InstallDirRegKey HKCU "Software\Marave" ""

;Request application privileges for Windows Vista
RequestExecutionLevel user

;Interface Settings






!insertmacro MUI_LANGUAGE "English"

;Installer Sections

Section "Install"

SetOutPath "$INSTDIR"
File /r "dist\marave"

;Store installation folder
WriteRegStr HKCU "Software\Marave" "" $INSTDIR

;Create uninstaller
WriteUninstaller "$INSTDIR\Uninstall.exe"

;Create shortcuts
CreateDirectory $SMPROGRAMS\Marave
CreateShortCut "$SMPROGRAMS\Marave\Marave.lnk" "$INSTDIR\marave\marave.exe" ; use defaults for parameters, icon, etc.
CreateShortCut "$SMPROGRAMS\Marave\Uninstall Marave.lnk" "$INSTDIR\Uninstall.exe" ; use defaults for parameters, icon, etc.


;Uninstaller Section

Section "Uninstall"

Delete "$INSTDIR\Uninstall.exe"

DeleteRegKey /ifempty HKCU "Software\Marave"


It's comparable to the effort of building a packaging file, really, except every time you want to test it... you install it. There is no way (AFAICS) to see what's inside the installer except running it!

When things fail, you get no error messages, at least not the kind that is useful for a developer, the guy that needs to know what went wrong.

And after it's finished, you may end with a non-working program because of...

Problem 2: system libraries don't exist

Python 2.6 binaries are built using Visual Studio. That means they require the Visual Studio Runtime, specifically MSVCR90.DLL. That contains what on Linux would be considered part of libc. (linux guy: imagine apps that depend on a specific libc... hard to do!)

On Linux that's part of the system. Further, if you wanted, you can redistribute it. On Windows... well, it's a bit different.

  1. It's part of the "Visual C++ redistributables"

  2. Installing that doesn't guarantee it will work (yes, I have tried)

  3. The license for those 'redistributables' says you can't make them available for download.

    I have been told that including that in your installer is fine and dandy, but how is that not making them available for download?

So what can you do when you need a library and can't ship it and the user won't install it?

Well, that's why there is no Windows binary of Marave yet. Of course if anyone can help, I'd be really, really happy!

2009-10-20 21:31

Simple KDE Trick #2: using remote desktops with avahi, krfb and krdc

Most people nowadays have more than one computer. Often, you are using one, and would like to do something in another. In this video, I will explain how trivial it is to do that without leaving your seat in a modern Linux using KDE.

We will use the following:

  • Avahi, a zeroconf implementation to let you find your computers in your network without worrying about IP addresses, DNS, etc.
  • krfb, the KDE Remote Frame Buffer. This is a program to share your desktop over the network.
  • krdc, the KDE Remote Desktop Client, a VNC, RDP client, which is what you use to see a desktop shared via krfb.

I am sure users of other operating systems or desktop environments will say they can do it just as easily. In that case, feel free to do your own videos ;-)

Keep in mind that accessing remote desktops over the internet is a whole different beast, and this solution is not meant for that case.

As usual, this video was recorded using qt-recordmydesktop. There was minor editing using mencoder.

The computer used is the original Asus eee PC 701 4G, so you can see this is not exactly a hardware-intensive operation. I find the eee's small screen is great for this kind of full-screen demo, because it's not big enough to drown the important parts.

2009-06-21 05:35

About 80% of what's wrong with Linux users, all in a post

My post about Arch Linux from yesterday got posted at tuxmachines and there was a comment there.

I can't reply at the site because:

  • It requires login.
  • I can't find a place to get an account.
  • It has freaking google ads popups

So I reply here because:

  • Hey, it's my own blog, so I can do whatever I want.

Here's the comment by hussam with my (admittedly ranty) response:

I've been using ArchLinux as my only distribution/operating system since early 2006. It is really a good distribution but lately there have been a lot of really bad choices which I call bad compromises:

1. Too many ArchLinux users think gnome/kde are bloat and instead install some half developed window manager and some terminal emulator and call it a "minimalist" desktop.

Why is that any of your business? And what "compromise" is there?

2. Optional dependencies are the worst idea ever. If a package is linked against then libsomething should be a dependency not an optional dependency. Making libsomething an optional dependency just because "minimalist" users don't want to install dependencies is plain stupid.

That's not what optional dependencies are for. For example, consider the example I mentioned, rst2pdf. It can use pythonmagick. It can also not use it. You will lose one small feature that AFAIK only one person ever used. If you need that feature, the manual tells you what to do: install pythonmagick.

Maybe there should be a pacman option "install optdepends" which turns optional dependencies into regular ones. That would make you happy and keep others happy too.

3. Bad leadership. Aaron is fantastic guy but I know at least two ArchLinux developers who can do a much better job.

That's just stupid and mean.

4. Too many ArchLinux users now like badly automation scripts like yaourt or whatever it is called.

Parse error. And then again: yaourt is great. You don't like it? Act as if it doesn't exist and be happy. You seem to have a big problem ignoring people who disagree with you. That's a really, really serious personal flaw. I suggest you grow up.

5. Too many noobs who do dumb things like people adding their users to hal, disk and dbus groups.

Sure, they should add themselves to optical and storage. So what? It's a simple problem and it has a simple solution.

Then again, the adduser scripts probably should do that for regular user accounts. After all, who wants to create a regular user that can't use removable storage? And if said use case exists, that should be doable by removing the user, and not viceversa!

On the other hand, I don't give a damn, because I can fix it trivially.

The main reason why I don't think I will switch to another distribution soon is that creating Archlinux packages from scratch is very easy and the initscript system is really fantastic.

All in all, ArchLinux is a really strong distribution now and it's constantly growing.

I expect you, like most elitist poseurs, will run away when you feel Arch is too popular and accessible to "too many noobs" or some similar nonsense.

Which, like the title says, is why you are a big part of what's wrong with Linux users.

2009-06-20 13:06

Why I STILL use Arch Linux

Yesterday I had one of those moments where I feel very happy about my distro of choice, Arch Linux. Since the last time I posted about Arch seems to have been over two years ago (time flies when you are having fun!), I think it's time to explain it.

I wanted to test rst2pdf against reportlab from SVN, wordaxe from SVN and docutils from SVN, and I wanted it to be simple.

Solution: I just packaged them in AUR!

Now, whenever I need to check rst2pdf agains wordaxe trunk, I just need to yaourt -S python-wordaxe-svn and I can go back to stable wordaxe with yaourt -S python-wordaxe.

The svn package will always be the current trunk without any modifications, and I can switch back and forth in about 45 seconds, without messing up my system's packages.

Also, I can keep my installed SVN packages updated by doing yaourt -Su --devel every now and then.

How would I have done that using Debian or a RPM distro? I suppose by going around the packaging system (which I hate) or by doing a private repo (which is so ... lame?) or by doing a public repo (which is freaking work).

Really, if you are a coder, I can't think of a Linux distro that makes life easier than Arch. Pretty much everything is there (12K packages in unsupported!) and if it isn't, it's a 5-minute job to slap it into AUR and help the community.

Suppose you are doing a KDE app. On most distros you need to install your own from-source copy of kdelibs to have the latest and make sure it's not screwed by distro-specific patches.

On Arch? Patching upstream is frowned upon. Not having the latest version is frowned upon. So it's pretty much the ideal environment to develop against KDE, or GNOME, or PyQt or whatever.

If my life was not 150% committed already, I would try to become an Arch developer, or at least a TU (Trusted User). Maybe next life!

Contents © 2000-2019 Roberto Alsina