Whole new world

First of all, EFI is not something just can just “enable”. Even if your kernel has support for EFI, that won’t make a difference unless you boot it through EFI, and you can’t seamlessly boot through EFI unless you create a boot entry, which is done with efibootmgr, which only works once you are in EFI mode. So it’s a bit of a chicken-and-egg problem.

So how do you enter this world in the first place? First of all, you would need a shell. Some BIOSes come with one, but otherwise you would need to install one, and you can find public links on this wiki page.

But where to put this “shell”? Well, the EFI system partition–yes, you need a dedicated partition (more info here). This partition should be formatted using FAT32, and marked in a special way, so the EFI BIOS would be able to identify it, and use it’s contents.

You copy the shell to this partition on /shellx64.efi (I tried UEFI Shell 2.0 (Beta), but it didn’t work for me, so I used the old one).

Your BIOS should now be able to boot this shell… Somehow. It took me a long time to figure out that in my BIOS, that’s a hidden option on the exit menu, where you can “exit” into a shell.

Congratulations, now you are in EFI mode, and probably type some commands, like in the old DOS days, but not be able to do anything really (unless you have some EFI version of Prince of Persia).

The bootloader

There are a few EFI bootloaders out there, like ELILO, and efilinux, but I decided to go with the safest and familiar choice: GRUB2 (well GRUB was familiar, GRUB2 not so much). Arch Linux’s wiki describes in great detail how to setup GRUB2 for EFI, so I’ll just mention that you need to use a different command (‘grub_efi_x86_64-install’ in the case of Arch Linux), and the files need to be installed in the aforementioned EFI system partition.

You would end up with a file /efi/arch/grubx64.efi, and this is an EFI binary that you can use in the shell. Theoretically you should be able to enter the command “\efi\arch\grubx64.efi”, but for some reason that didn’t work for me, so I had to “cd \efi\arch”, and then “grubx64.efi”. Of course, you first need to choose the right partition, but the shell makes it easier by having aliases to the EFI system partitions, so you first type “fs0:” (or something like that), like I said; very similar to DOS.

Directly, please

But going into the shell and typing those commands every time you boot is cumbersome, which is why you would want to add a boot entry. So, once you have been able to boot Linux through EFI, you should be able to load the ‘efivars’ module, and thus access ‘/sys/firmware/efi/vars/’, which is what ‘efibootmgr’ needs.

Then you can do something like:

efibootmgr --create --gpt --disk /dev/sdX --part Y --write-signature --label "Arch Linux (GRUB2)" --loader '\efi\arch\grubx64.efi'

WARNING: You shouldn’t use this on Mac’s, there’s a different process for those.

In your BIOS you should see the option of booting into “Arch Linux (GRUB2)”, like you have the option of booting into a CD-ROM, and then you can choose that as the first one in the boot order

Stub

But wait a second, that starts to look like two bootloaders: the BIOS has a boot entry, and so does GRUB. Why not boot directly into Linux?

A couple of patches from Matt Fleming enable just that. They should be in version 3.3. Enable CONFIG_EFI_STUB, and copy bzImage to /efi/linux/linux.efi.

So now you can boot directly from the BIOS into Linux (or Windows) with no bootloader at all

GPT

While you are on that, why not enable this new partitioning scheme? It’s more EFI friendly, and you can’t actually install a version of Windows that works with EFI without it. For Windows 7 it’s either EFI and GPT, or non-EFI and MBR; you can’t mix them (don’t ask me why).

Fortunately it’s very easy to switch from MBR to GPT; just run gdisk (from a rescue disk, of course). It’s also easy to switch back, as long ad you haven’t used more than four partitions.

During this discussions the dynamic and static power management were described and discussed at length, and there was a bit of talk about Maemo(MeeGo) vs Android approaches to power management, but there was so much more than that.

Some people have problems with the battery on Android devices, for some people it’s just fine, some people have problems with the Maemo, other don’t, so in general; your mileage might vary. But given the extremely different approaches, it’s easy to see in which cases you would have better luck with Maemo, and in which with Android–Although I do think it’s obvious which approach is superior, but I am biased.

An interesting achievement was shared by Thiago Maciera, who managed to get ‘5 days and a couple of minutes‘ out of the Nokia N9 while traveling, and actually using it–and let’s remember this is a 1450 mAh battery. Some Android users might have trouble believing this, but hopefully this blog post would explain what’s going on.

So lets go ahead and explore the two approaches.

Dynamic Power Management

Perhaps the simplest way to imagine dynamic power management, is the gears of a manual transmission car. You go up and down depending on how much power does the system actually needs.

In some hardware, such as OMAP chips, it’s possible to have quite a lot of fine control on the power states of quite a lot of devices, plus different operating power points on the different cores. For example, it might be possible to have some devices, such as the display on, and active, some other devices partially off, like speaker, and other completely off, like USB. And based on the status of the whole system, whole blocks can be powered off, other with low voltage levels, etc.

Linux has a framework to deal properly with this kind of hardware, the runtime power management, that originally came from the embedded world, and a lot from OMAP development, but is now available to everyone.

The idea is very simple; devices should sleep as much as possible. This means that if you have a sound device that needs chunks of 100ms, and the system is not doing anything else but playing sound, then most of the devices go to sleep, even the CPU, and the CPU is only waken up when it needs to write data for the audio device. Even better is to configure the sound device for chunks of 1 second, so the system can sleep even more.

Obviously, some co-operation between kernel and user-space is needed. Say, if you have an instant messenger program that needs to do work every minute, and a mail program that is configured to check mail every 10 minutes, you would want them to do work at the same time when they align at every 10 minutes. This is sometimes called IP heartbeat; the system wakes up for a beat, and then immediately goes back to sleep. And there are kernel facilities as well, such as range timers.

All this is possible thanks to very small latencies required for devices to go to sleep and wakeup, and have intermediary modes (e.g. on, inactive, retention, off), so, for example a device might be able to go to inactive mode in 1ms, retention in 2ms, and off in 5ms (totally invented numbers). Again, the more sleep, the better. Obviously, this is impossible on x86 chips, which have huge latencies–at least right now, and it’s something Intel is probably trying to improve effusively. All these latencies are known by the runtime pm framework in the kernel, and based on that it and the usage, it figures out what is the lowest power state possible without breaking things.

Note I’m not a power management expert, but you cant watch a colleague of mine explain the OMAP 3 power-managment on this video:

Advanced Power Management for OMAP3

And there’s plenty of more resources.

Update: That was the wrong link, here are the resources.

Static Power Management

Static power management has two modes: on and off. That’s it.

OK, that’s not exactly the case in general, but it is in the Android context; the system is either suspended, or active, and it’s easy to know in which mode you are; if the screen is on, it’s active, and if it’s off; it’ is suspended (ideally).

There’s really not much more than that. The complexity comes from the problem of when to suspend; you might have turned off the display, but there might be a system service that still needs to do work, so this service grabs a suspend blocker which, as the name suggests, prevents the system from suspending (until the lock is released). This introduces a problem; a rouge program might grab a ‘suspend blocker’ and never release it, which means your phone will never suspend, and thus the battery would drain rather quickly. So, some security mechanisms are introduced to grant permissions selectively to use suspend blockers.

And moreover, Android developers found race conditions in the suspend sequences in certain situations that were rather nasty (e.g. the system tries to suspend at the same time the user clicks a button, and the system never wakes up again), and these were acknowledged as real issues that would happen on all systems (including PC’s and servers, albeit rarely, because they don’t suspend so often), and got fixed (or at least they tried).

Versus

First of all, it’s important to know that if you have dynamic pm working perfectly, you reach exactly the same voltage usage than static pm, so in ideal cases they both behave exactly the same.

The problem is that it’s really hard for dynamic pm to reach that ideal case, in reality systems are able to sleep for certain periods of time, after which they are woken up, often times unnecessarily, and as I already explained; that’s not good. So the goal of a dynamic pm system is to increase those periods of time as much as possible, thus maximizing battery life. But there’s a point of diminished returns (read this or this for expert explanations), so, if the system manages to sleep 1s in average, there’s really not much more to gain if it sleeps 2s, or even 10s. These goals were quite difficult to achieve in the past (not these, I invented those numbers), but not so much any more thanks to several mechanisms that have been introduced and implemented through the years. So it’s fair to say that the sweet spot of dynamic pm has been achieved.

This means that today a system that has been fine-tuned for dynamic pm can reach reach a decent battery life compared to one that uses static pm in most circumstances. But for some use-cases, say, you leave your phone on your desk and you don’t use it at all, static pm would allow it to stay alive for weeks, or even months, while dynamic pm can’t possibly achieve that any time soon. Hopefully you would agree, that nobody cares about those use-cases were you are not actually using the device.

And of course, you only need one application behaving badly and waking up the system constantly, and the battery life is screwed. So in essence, dynamic pm is hard to achieve.

Android developers argued that was one of the main reasons to go for static pm; it’s easier to achieve, specially if you want to support a lot of third party applications (Android Market) without compromising battery life. While this makes sense, I wasn’t convinced by this argument; you still can have one application that is behaving badly (grabbing suspend blockers the whole time), and while permissions should help, the application might still request the permission, and the user grant it (who reads incomprehensible warnings before clicking ‘Yes’ anyway?).

So, both can get screwed by bad apps (although it’s likely that it’s harder in the static pm case, albeit not that much).

But actually, you can have both static and dynamic power management, and in fact, Android does. But that doesn’t mean Android automatically wins, as I explained, the system needs to be fine-tuned for dynamic pm, and that has never been a focus of Android (there’s no API’s or frameworks for that, etc.). So, for example, a Nokia N9 phone might be able to sleep 1s in average, while an Android phone 100ms (when not suspended). This means when you are actually using the device (the screen is on), chances are, a system fine-tuned for dynamic pm (Nokia N9) would consume less battery, than an Android device.

That is the main difference between the two. tl;dr: dynamic pm is better for active usage.

So, if Android developers want to improve the battery usage while on active usage (which I assume is what the users want), they need to fine-tune the system for dynamic pm, and thus sleep as much as possible, hopefully reaching the sweet spot. But wait a second… If Android is using dynamic pm anyway, and they tune the system to the point of diminishing returns; there is not need for static pm. Right? Well, that’s my thinking, but I didn’t manage to make Android developers realize that in the discussion.

Plus, there’s a bunch of other reasons while static pm is not palatable for non-Android systems (aka. typical Linux systems), but I won’t go into those details.

Nokia’s bet was on dynamic, Google’s bet was on static, and in the end we agreed to disagree, but I think it’s clear from the outcome in real-world situations who was right–N9 users experiencing more than one day of normal usage, and even more than two. Sadly, only Nokia N9 users would manage to experience dynamic pm in full glory (at the moment).

Upstream

But not all is lost, and this in my opinion is the most important aspect. Dynamic pm lives on the Linux kernel mainline through the runtime power management API. This is not a Nokia invention that will die with the Nokia N9; it’s a collaborative effort where Nokia, TI, and other companies worked together, and now not only benefits OMAP, but other embedded chips, and even non-embedded ones. Being upstream means it’s good, and it has been blessed by many parties, and has gone through many iterations, and finally it probably doesn’t look like the original OMAP SRF code at all. Sooner or later your phone (if you don’t have an N9) will benefit from this effort, and it might even be an Android phone, your netbook (if not already benefiting in some way), and even your PC.

Android’s suspend blockers are not upstream, and it’s quite unlikely that they will ever be, or that you would see them used in any system other than Android, and there’s good reasons for that. Matthew Garrett did an excellent job of summarizing what went wrong with the story of suspend blockers on his presentation ‘Android/Linux kernel: Lessons learned’, but unfortunately the Linux foundation seems to be doing a poor job of providing those videos (I cannot watch them any more, even though I registered, and they haven’t been helpful through email conversations).

Update: I managed to get the video from the Linux Foundation and pushed it to YouTube:

Here is part of the discussion on LKML, if you want to read it for some strange reason. WARNING; it’s huge.

Keycodes

So, first things first. I recently had an issue with a PS/2 keyboard on my PC, so I had an idea how to debug this, and the first thing I did was to run keycode, which shows messages like these:

keycode  30 press
keycode  30 release
keycode  30 press
keycode  30 release
keycode  29 press

Then these keys are supposed to be converted to real characters somehow through a key map, and apparently X has a map of its own.

However, I saw keycodes being pressed when I clicked ‘shift’, so I concluded that neither hardware, nor input driver was the problem, could it be the mapping? The MeeGo project provided a mapping file that I have been using for some time, and it clearly shows “keycode 42 = Shift”, and I was getting keycode 42, so the mapping seemed correct, but was it being applied properly? I found out this can be checked by using dumpkeys, and indeed, the mapping was correct.

Everything was fine up to this level. Next.

Note: all these tools (showkey, loadkeys, and dumpkeys) are provided by the ‘kbd’ package.

Virtual terminal

Now I stumbled into a problem; I’ve no idea what it is that I am interacting with on the framebuffer console (I’m not using X). So, I try fill that gap in my knowledge by going to the ##linux IRC channel in freenode.net, and ask the question: what is it that converts they keycodes to characters in a framebuffer console? As it’s typical when I ask these sorts of tricky questions, I get useless responses, like, ‘what distribution are you using?’ I knew that didn’t matter, so I set out to investigate myself.

I thought, well, what is this thing that I have to add in my inittab to get the console working? 1:2345:respawn:/sbin/getty 9600 tty1. I tried to read documentation about getty and try different options, like try to specify vt100 as an argument, but to no avail.

Maybe it’s done in the kernel? I thought. So I quickly went through my kernel config, and I find this gem:

CONFIG_VT

If you say Y here, you will get support for terminal devices with
display and keyboard devices. These are called "virtual" because you
can run several virtual terminals (also called virtual consoles) on
one physical terminal. This is rather useful, for example one
virtual terminal can collect system messages and warnings, another
one can be used for a text-mode user session, and a third could run
an X session, all in parallel. Switching between virtual terminals
is done with certain key combinations, usually Alt-.

The setterm command ("man setterm") can be used to change the
properties (such as colors or beeping) of a virtual terminal. The
man page console_codes(4) ("man console_codes") contains the special
character sequences that can be used to change those properties
directly. The fonts used on virtual terminals can be changed with
the setfont ("man setfont") command and the key bindings are defined
with the loadkeys ("man loadkeys") command.

You need at least one virtual terminal device in order to make use
of your keyboard and monitor. Therefore, only people configuring an
embedded system would want to say N here in order to save some
memory; the only way to log into such a system is then via a serial
or network connection.

If unsure, say Y, or else you won't be able to do much with your new
shiny Linux system  

That makes sense, now we are getting somewhere. So, in the past, there was this notion of ‘terminals’, which are specialized pieces of hardware that send and receive ASCII (or some codes), so they are the ones that have all the needed stuff to control they keyboard, screen, and so on. I never had the need to use one of these terminals, therefore I never really knew what a “virtual” terminal was. So a virtual terminal does the job of a real terminal; it needs an input driver, and a display driver, and really puts them to do something useful.

Interesting theory, but is it true? I quickly looked at the code inside drivers/tty/vt, and I found code to control the keyboard, screen, and also that contains the keyboard mappings. Excellent! So we found the thing that uses these keyboard mappings. Now what?

Before moving on, the fact that this code resides in tty is also helpful, basically, serial console, virtual terminals (framebuffer console), and real terminals all operate through tty’s (teleprinter), which are means of communication between hosts and these “devices”. So, getty really gets a tty to be used by any of these.

All right, so now the knowledge gap seems to be filled, what next? Well, clearly there’s something wrong with this virtual terminal, but what? I immediately started looking at the code at drivers/tty/vt/keyboard.c, and I noticed something interesting: kbdmode can have different values, like RAW, and this mode, certain things are not handled, like ‘shift’. That looked promising, but how to change that mode?

I looked for tools to control the virtual terminal, I found an interesting one, setterm, which was not available in my minimal system, I couldn’t find how to get it, and anyway didn’t have any option that I wanted. terminfo and such looked interesting, but it didn’t seem like anything relevant to the issue at hand. Then I found kbd_mode, which obviously did what I wanted, and I already had it . I couldn’t even type mbd_mode on my keyboard, so I had to write shortcuts on my PC (kbda, kbdb, etc.). Unfortunately, I found out that initially the mode was set to ‘unicode’, which seemed Ok, and changing to ‘ascii’ didn’t change anything.

So, it didn’t seem to be a user-space configuration of any sort. Next.

Getting our hands dirty

Time to actually type some code. I modified the code in ‘drivers/tty/vt/keyboard.c’, specially in kbd_keycode() to find out the true kbdmode, the keycodes coming down, and how they were being interpreted.

I quickly found out that they keycodes and mode were indeed correct, but each and every key press was immediately followed by a key release, so shift+a was interpreted as shift, a. Now we are getting somewhere; the problem has to be on the input driver.

Maybe I chose the wrong one, or maybe I’m missing some configurations. I see some CONFIG_KEYBOARD_GPIO, and CONFIG_KEYBOARD_TWL4030, and it looks like I should be using TWL4030, as that’s the chip the Nokia N900 has, but I’m not sure, so time to look at the N900 schematics. Well, it seemed like TWL4030 is indeed the right one, and there’s nothing to it; either you have it or not.

Maybe some recent change broke it… But there’s nothing recent that I can see that could do that. So it’s time to take a look at the actual code: drivers/input/keyboard/twl4030_keypad.c. After adding a few prints here and there I realize the problem starts with this code ret = twl4030_kpread(kp, &reg, KEYP_ISR1, 1) which returns 0 after a key press (that returns 1). So, time to read the TRM.

It took me some time to find the right document, and then understand what all the configuration options were actually doing (more or less), and then play around with them. After making a lot of more or less random changes I notice no difference in this particular problem of getting an extra ’0′. So I think to myself; maybe the problem is the interrupt.

So I abandon the configuration of the keyboard, and look at the code to request the interrupt:
request_threaded_irq(kp->irq, NULL, do_kp_irq, 0, pdev->name, kp);

I had some interrupt issues before (in fact on this very keyboard), so I knew a few hacks I could try, like specifying the IRQF_ONESHOT flag. That didn’t help, so I tried to do that in the parent interrupt on ‘drivers/mfd/twl4030-irq.c’, because I saw a patch from Neil Brown on the linux-omap mailing list that fixed another issue, but that didn’t help either. Then I realized I saw one patch that affected this interrupt request (see here). So I revert the patch, and voilà, no more 0′s afterwards, and the keyboard works properly.

However, there’s a nasty warning about interrupts being enabled, which is probably the reason why the original patch happened, so I try a few random things to get rid of it, but nothing helps. So then I wonder, maybe the reason the keyboard driver worked before that patch is just pure luck, and these extra interrupts were not being detected properly.

Enough fooling around

Since I really want to fix this issue properly, I push myself to really understand what’s going on in the driver. So I slowly read all the documentation, and all the registers, and try to set different values to see what’s going on. While doing that, I noticed one function was calculating the times wrongly, and was telling the driver to use values twice as big as originally intended. It took me some time to figure out why the author chose 31 << (x + 1) instead of 2 << (x + 1) * 31, which is what a direct function conversion would return, until I realized that a shift basically means multiplying by two, and x << 1 is basically the same as (2 << 0) * x, but the author missed that x = ptv + 1, and so it should be 31 << (ptv + 2). Anyway, after being confident of these timeout values, I could set big timeouts on the range of seconds without overflowing the registers and see exactly what they were doing in timescales I could notice.

So yeah, these registers were doing what I thought they should be doing. Nice try.

Time to go back to the interrupt handling. After reading the code of the twl4030-irq, which is supposed to fire the irqs that the keyboard driver eventually gets, and then reading some kernel core code as well, it was not really clear to me how these were all weaved together, so I added some printfs.

Before going forward I’ll briefly explain a bit what TWL4030 is. To my understanding it’s basically an integrated circuit that has many functions, one of them is having a keyboard controller. So there is no dedicated IRQ for the keyboard interrupt, but TWL4030 has a level interrupt, and then the right module IRQ is demultiplexed. OK.

I was hoping there was a chain of actions like pih -> sih (from twl-core) -> keyboard, but no, there was only one action in the chain. Fortunately when I reverted the patch I got a warning with a backtrace where I could see something like twl4030_irq_thread->generic_handle_irq->handle_simple_irq. It was really straight-forward, but I couldn’t see why. There was a lot of code in twl403o-irq for a “secondary interrupt handler” but it didn’t seem to be called at all, and I didn’t see how generic_handle_irq was calling handle_simple_irq.

Time to step back for a second. I remembered a patch from Neil Brown trying to fix something regarding how this sih stuff was called (here) because it was not called at all, but these patches are supposed to be fixes for other patches that are not applied at this point, so they really wouldn’t help.

At this point I’m pretty much stuck, as I’ve no idea how all this code is connected, you might think that all this is way over my head, and it might be, even if just a little, but that has never deterred me. I know that as long as I have the code, and I have a way to run it, I can figure out how it works, so I just keep trying.

After reading the code more carefully, I noticed that only some twl “modules” had a sih setup, and the keyboard was not one of them, so that explained the sih part. And then I noticed a part of the irq handling that dealt with “chips”, and one interesting function that setup the chip’s “handler”. Wait a second… So there’s a chip handler, and a client handler, a few keystrokes after and I find this gem irq_set_chip_and_handler(i, &twl4030_irq_chip, handle_simple_irq). Finally! So I can now see the whole chain of events, but alas, I still have no idea why things are failing.

I thought maybe some states where miscalculated, so I find a function that is used to print everything related to an irq, but it was hidden in some internal code, so I had to do a few tricks to use it in the keyboard driver. All the states seemed to be OK, except one… the irq count, which showed something like 0, 0, 0, 1, 2, 2, 3 where it should have shown 0, 0, 1, 1, 2, 2. I looked at all the places where this counter is modified, and I found an interesting function: handle_nested_irq, so I replaced handle_simple_irq just for fun, and…

BAM!

Everything worked perfectly.

Why, Why, Why

So, now I found a fix, but why does it work? If I want to fix this in a way that other people will not get bitten, I have to find the proper fix, so “This seems to make things work here” usually doesn’t convince many kernel hackers.

Using handle_nested_irq makes the compiler throw a warning right away, because the number of arguments is different, so I looked at how other people use this function, and it’s indeed very different, it looks like people are calling handle_nested_irq directly, instead of generic_handle_irq, which would eventually handle handle_simple_irq, because that’s the chip’s configured handler. It all boils down to the difference between handle_nested_irq and handle_simple_irq, and looking at them it’s clear that handle_nested_irq does much less, specifically, it calls directly the action->thread_fn() callback, which is the keyboard interrupt handler, rather than waking up the thread, which is the same function (but in a specialized thread).

And this finally shines some light; the reason why the interrupt counter is wrong, is that the thread is waked after the irq has been processed, so the code that is supposed to clear the interrupt hasn’t been called yet, and a second interrupt is generated which is spurious. The relevant code is supposed to read a register, and the hardware clear the interrupt on a read (or write) operation. The reason handle_nested_irq works is because it doesn’t bother with the interrupt thread at all, it calls the function right away on the same thread, and thus the interrupt is marked as handled at the right time (after it has been really handled).

And this also explains why other people call handle_nested_irq instead of generic_handle_irq; you are supposed to call it inside an interrupt thread (which is configured with request_threaded_irq), but there’s a thread lying around that nobody uses. Indeed, Neil Brown noticed the same (here), so irq_set_nested_thread() will make sure that no extra thread is created.

So both irq handlers must be threaded, the one for the twl-core, and the one for the keyboard, not just the one for the keyboard like right now. Fortunately Felipe Balbi already fixed that (see this patch series), but that broke things badly, and then Neil Brown fixed them (see this). Interestingly enough, I had already tested those patches for other reasons, but at this point I wasn’t sure if they would fix the keyboard problems, I just assumed the would anyway.

Good good, it looks like we finally have the whole picture, but the job’s not done yet.

Getting it “done”

Now the question is: how to fix this? One limitation of the ‘stable’ kernel trees (at least AFAIK), is that the patches should be in the latest Linus’s tree, so whatever solution is found, should be in the main tree.

Ideally, all the stack of irq’s should be reorganized to use the nested/threaded API, or none at all. So this patch, should have been applied only after this patch series, and not two years beforehand. I pondered for quite some time whether a middle-ground could be found, either by workarounds in the core irq handler, or in the keyboard one, eventually I came to the conclusion that since the core is supposed to set irq_set_nested_thread() anyway (just trust me), the keyboard one is the one that should check if it’s nested or not, and either set the thread handler, or a normal one, and this code should work before and after the patches applied for 3.2. Unfortunately, the ‘nested’ flag is supposed to be internal to the kernel’s thread handling code.

So there’s really no way around it, either the original patch is reverted (and other possible similar ones for other twl modules), or all the twl core irq handler gets the new code for 3.2 backported, and that code isn’t even fixed yet (as of v3.2-rc5) (and maybe it will not be the way things are progressing).

Then the question arises; is all that new code on v3.2 working properly? I went ahead and tried it, and lo and behold; the keyboard works as expected. I then backported all those patches to v3.1, and they all worked too.

But does it really make sense to apply all those patches to all the kernels after v2.6.33? Or does it make sense to revert a few of them? That’s not for me to decide, so I ask the community, after I did all that work on this mail.

Sometimes the result of a week’s work ends up being a one line patch, sometimes it’s just one character, and in this case, there was no patch (at least from me), but at least the issue is clearly identified, as well as the fixes. And that means nobody has to do this work again.

Well, the fun is not over… We still need to synchronize the maintainers, so the right patches land on Linus’ tree for v3.2, and they are back-ported to the relevant linux-stable trees.

Kernel development is hard, let’s go shopping

What are you talking about? This isn’t even kernel development, it’s just some legwork I’m going to be Topper for a second and say “That’s nothing!”, there’s way more complicated and challenging issues kernel developers confront all the time. I thought this was interesting because of all the steps I had to do, and because it involved things I had no idea about.

Was this worth my time? Well, I learned what is actually a virtual terminal for real, and not some vague notion, like when common people say “My browser? Yeah, I use Google… No?”. I also learned a bit more about the IRQ handling API in the Linux kernel, and BTW, all this threaded interrupt API started because of real issues, and the removal of IRQF_DISABLED (nice LWN article about it here), and that thread was fun to read years ago, even when I didn’t understand most of it, maybe it’s time to read it again

For me, the best is the satisfaction of knowing that I really “got it”. I mean, I really understand what causes the problem, many of the possible solutions, including hacky and proper ones, and exactly what to do if I get bitten by a similar problem regarding threaded IRQ’s.

And now that the keyboard is fixed, on with the next problem on the N900 (which I stopped working on, because I though a functional keyboard would help to debug it, as opposed to shut down, remove the MMC, plug it into a PC, write a script with the commands I want to run, unmount, plug it back, and boot [I can't use USB networking for this issue to appear]).

Linus Torvalds:

The biggest thing any program can do is not the technical details of the program itself; it’s how useful the program is to users.

So any time any program (like the kernel or any other project), breaks the user experience, to me, that’s the absolute worst failure that a software project can make.

No project is more important than the users of the project.

Alan Cox:

If you want to understand the importance of not suddenly changing your users’ experience.
I would go and take a look at GNOME 3.0.
[Laughter]
Irrespective of whether it is a good user interface design or not.
It’s a demonstrattion of why you don’t suddenly change everything on people who rely on what you were doing.

If you look at it from the point of view of the people producing the hardware and technology. Then there’s always a pressure from them to get every new feature and every new thing enabled.

But if you talk to the users of these systems, most of them are primarily concerned that what used to work continues to work and in the same way.

You can see the whole video to get a sense of how important it is for Linux developers not to break user experience. Also, how to don’t break the API while still moving forward, and not increasing code complexity. Or breaking API without users noticing.

This should be common sense, but some people don’t agree and there are various arguments I have heard over the years.

Developers vs. Users

According to some people, it doesn’t matter what the users want, only what developers want, because at the end of the day, it’s the developers that will implement it. This mentality even lead to the term Free Software User Entitlement Syndrome; the idea that somehow users have a say in what happens in the project is dismissed with passion by some people.

This kind of thinking ignores a very basic fact; there’s no such thing as a user/developer divide. We were not branded at the moment of birth; “you shall be a developer”. No, developers were mere users at some point in time. Maybe they were not so good at programming when they started, but they eventually learned all the tricks. Or maybe they already were good programmers, but didn’t want to contribute right away until they saw the software was actually useful, saw an area of opportunity, and had enough time.

Moreover, there are all kinds of developers; the ones that contribute only one patch, the ones that contribute a series of patches they did in one weekend, the ones that contribute sporadically, the ones that contribute often (but are not part of the core team), and the core team. There is no natural division either; it’s a continuum, and people often move back and forth in it as time and motivation permits.

In fact, this continuum of developers follows a power law distribution, also referred to as the long tail. It is hard to see in the following image, but the total area from the right (yellow) is the same as the left (green), that’s why the term long tail is used to point out that one should not dismiss certain people that might be labeled as outsiders, or not part of the “core”:

Here is a graph of all the contributors to the git project ordered by the number of commits, which is plotted on the y axis:

It’s not easy to see, but there’s a long tail there. Here it’s plotted in logarithmic scale, and with a graph of a pareto function:

This means that 70% of the people contributing to git have only provided less than 6 patches, and 37% only one patch. Sure, one patch might not look like a lot, but as Clay Shirky points out; what if it’s a patch for a buffer overflow? what if it’s the difference between a malevolent hacker being able to exploit your system or not? Traditional companies can’t make use of people like Zack Brown who contribute only one patch to the project, but open source organizations can, so lets make use of them.

And lets not forget that this continuum is not static; people often move up (and down) in the ladder. Good projects would exploit this long tail by not dividing groups of developers, and making things easy for newcomers. Junio C Hamano, the maintainer of git, points out:

During the entire history leading to 1.6.6, 710 authors contributed code
and documentation. The changes since 1.6.5 were made by 99 authors, among
which 17 are the new contributors to the project.

Source.

And of course, this long tail graph doesn’t even take into account the thousands of users, many which are potential contributors. Plus you have people like Ingo Molnar, who is a very active Linux kernel developer, but has only committed 6 patches to the git project, does that mean he is not a “developer”?

Lets get rid of this idea that there is a division between users and developers; in open source projects, this division just exists in people’s imagination.

Lack of resources

As Linus and other developers pointed out in the video above, you can find ways to provide both the old, and the new behavior. Often this is not difficult at all, but requires some imagination.

Unfortunately, some people disagree and just drop features without any way to use the previous behavior and they rationalize the decision using the “lack of resources” card. Sometimes they don’t even try it, but sometimes it’s true that it’s difficult to implement something while keeping the old behavior. However, something being difficult is not an excuse not to do it; it might take more time, but it’s still doable.

This is the point that is often ignored; they don’t want to spend more time.

But there’s another important point; perhaps the lack of developers is due to the amount of features dropped. Think about it. As I explained, all developers were users at some point, and dropping features means dropping users (current and potential), which inevitably means dropping potential developers. The harder you try to keep you users (through keeping features), the more confidence these users would have that they will be using your project in the future, and the more they will see contributing as an investment.

This is one of the reasons Linux is so popular (as I explained in another post; it’s the most important software project in history) everybody that has been using it for years knows (s)he will still be using it in the years to come, as they are not going to suddenly break everything. It’s a contract between users and developers that builds trust. With this trust it’s easy to gather more and more users, and thus, more and more developers.

This also applies the other way; not only about not dropping features, but adding unpopular ones. It is possible to add features not everybody will use, and still keep them isolated from the main experience–although this requires time, and resources.

Imagine a developer that uses project X, which works pretty well from him, but he wants to add a feature. He might be reluctant to do so because a) there’s no guarantee that they will not drop it in the future, and b) they might reject it right away because they don’t want it in their main experience. Until there is a project like Linux that incorporates all the needs of all the people, this developer would have to either fork project X, or stay in apathy.

So, don’t drop any feature, and incorporate all the features; it’s difficult, but this this is the only sure way of being as successful as Linux, and avoid forks.

Users don’t know what they want

While there is some truth to this claim, it’s a very crude oversimplification of reality. For example, users didn’t know they wanted a touch screen before the iPhone, that is true, but after that, they knew they wanted it, and if you were say Nokia, you couldn’t say “oh, users don’t know what they want” and stay with non-touch interfaces; sometimes they do know. Plus, what they definitely know is what they don’t want; like an application that crashes constantly.

This argument is often used as a rationalization when features are removed and users complain. Some developers bring this argument in a patronized way, implying that they know better. Sometimes they do know better, but this should not be used as an excuse to stop listening the complaints.

Conclusion

So, there you have it, it’s really simple; try really hard not to break your user’s experience, because unlike what some people like to think; it’s the users that make a project successful. The user-base is from where all the contributors come from, and the publicity. If you do break user experience, try to do it in a way that can be reverted if your users complain, or even better, provide both an old and new way of doing things; eventually the new way would be as good as the old, and everybody would move eventually.

Appreciate your users, listen to them, and never threat them as expendable, or even worst; a nuisance. Basic stuff that many big projects forget.

However, that hasn’t prevented me to cooperate in their bugzilla, I have filed bug reports, participated in discussions, also fixed bugs, and I even maintain one component; gst-openmax. You can check yourself here, or for a few interesting ones: 629349, 640859, 640665, 650724, 655361, 480858, 623473, 630910, 598771, 535074, 534975, 548776, 340375.

Yet, because of a couple of comments in bug #629161 (Support voting in GNOME Bugzilla), and without any warning, I got banned. But of course, they deleted the evidence, so you can’t see it.

The official response

Anyway, let’s leave the ban pending, and concentrate on the real issue: why are votes not enabled? This is what you can find from GNOME’s site:

Voting would give the impression that your vote would make someone fix the bug faster. That is almost always not the case. As this gives a false impression, voting usually creates a lot of extra comments because of that (eg ‘this bug has XXX amounts of votes and still not fixed’) and just frustates users.

A better way to get a bug fixed faster is to either:

• Provide a patch, or
• Look, review and test the patches provided by other contributors. Especially the reviewing part takes a lot of time and developers will really appreciate people who say if a patch does or does not fix the bug for them. Reviewing the patch (looking for potential problems / good code style / etc) is even better.

Note: If you want to express interest in a bug, just CC yourself (and leave the comment field empty). The developer can easily see if a lot of people have cc’ed themselves, without causing the bad voting side-effects.

Voting would give the impression that your vote would make someone fix the bug faster.

No, it wouldn’t. That’s a miss-conception, there’s plenty of evidence to the contrary, as Tim Janik pointed in his blog post, both GitHub and Google Code offer voting methods, but not only that, Mozilla Firefox, KDE, Mediawiki, WineHQ do too.

Let’s take a quick look at the most voted bugs in some projects: Chromium Issue 60101: webRequest extension API (2264 stars), Wine Bug 421 – Implement a DIB engine (161 votes). Do you see anybody having the impression that the bug should be fixed fast as GNOME people suggest? No.

That’s because it’s not true, people assume that a bug with a lot of votes should have a high priority, that’s a completely different thing; speed != priority.

As this gives a false impression, voting usually creates a lot of extra comments because of that (eg ‘this bug has XXX amounts of votes and still not fixed’) and just frustates users.

Again not true, and backed up by a lot of evidence. People don’t complain if a bug is not fixed in a timely manner, they complain if it affects many people, and developers give to it no importance. But if they did their job properly, that would not happen, in my experience, just setting the right priority but explaining that it’s not that easy to implement is enough. Additionally, I set milestones based important bugs fixed, this way users know that 1.2 won’t be released until the bug they care about is fixed, so they know there’s no point in raising attention to it.

But even assuming what they said was true, the amount of annoyance the complains would generate is overcome by the value provided by knowing which bugs are really important.

If you want to express interest in a bug, just CC yourself (and leave the comment field empty)

That’s not what the CC field is for, therefore people would not use it for that, defeating the purpose. Plus, you can’t sort bugs by number of people in CC.

That’s it. It was easy to debunk wasn’t it?

The bug

Let’s go now to the bug in question; bug #629161. A bunch of GNOME developers (Tim Janik, Jürg Billeter, Sandy Armstrong, Travis Reitter, Javier Jardón, Gabriel Burt) made it clear that they would want this for their components, yet nothing happens. There’s basically only arguments in favor, nobody is arguing against.

So, now you have refuted arguments from their official position, and an enhancement request to allow voting in some components. Why wouldn’t they just allow it, if anything, just to see how things go? At the end of the day it’s the maintainers of the components that would decide if voting has been beneficial, or not. One can only speculate, but I assume the reason is political; if you enable voting for some components, people would automatically assume that the other components don’t want to hear feedback from users (which might very well be the case).

In anyway, it won’t happen–not for certain components, not as a trial, not ever. There’s no real reasons against, and it doesn’t matter how many arguments are put forward. Strange, huh?

The ban

These comments were deleted, so I’m providing them in full so you can judge by yourself, also, because there’s no public hearing or any way one can defend itself against arbitrary bans.

--- Comment 14 Felipe Contreras 2011-09-08 23:24:33 UTC

(In reply to comment #5)
> Google's star approach is nice because the user does not see how many other
> folks starred the issue (or if they do, it's not nearly as visible as something
> like "votes").

Wrong.

http://code.google.com/p/chromium/issues/detail?id=60101

2273 people starred this issue and may be notified of changes.

(In reply to comment #12)
> The argument that users will be disappointed that bugs with high numbers of
> votes are not being fixed has been raised here, and also previously on Bug
> 390454.  My counter-argument to this is: so what?  Every other bug tracker I
> use (KDE, Novell, SeaMonkey, OpenOffice.org, MediaWiki) allows users to both
> make and view votes.  Yes, occasionally some users complain that bugs haven't
> been fixed.  No, this hasn't resulted in planes falling out of the sky, all
> development work ceasing, etc.  Such unhelpful comments are thankfully rare,
> and either get ignored, or else someone politely reminds the poster of bug
> tracker and free software development etiquette.

Exactly. The value of the information gathered by this outweighs tremendously
against the small possible annoyances. In my experience however adding voting
does not lead to annoying comments.

In my own project hosted in Google code I always make it clear when a feature
is extremely popular but it's difficult to implement, I just say that, and the
users seem to understand, that if it's not fixed in a certain period of time,
it doesn't mean that nobody cares, it just means it's not that easy.

Now, if this was actually *tried* for some period of time, and *then* it turned
out that there was indeed too many of these comments I would understand, but
that's not the case.

The decision is based on pure speculation.

I say something is not true, and I provide evidence that shows that’s the case. Then I say the decision is based on speculation, which is true, and the only way to know for sure is to give it a try. Is that too bad? According to Olav is it bad enough to warrant a ban:

--- Comment 15 Olav Vitters [bugzilla.gnome.org developer] 2011-09-10 03:46:00 UTC

(In reply to comment #14)
> The decision is based on pure speculation.

Please just stop the way you're acting. Just because I see things differently
doesn't make it ok to behave like this on Google Plus, desktop-devel-list,
here, etc.

Olav says I should stop with the way I’m acting, without specifying what is that “way”. First of all, notice that there’s no threat of a ban at this point. Also, notice that I don’t know what exactly I’m supposed to stop doing. So…

--- Comment 16 Felipe Contreras 2011-09-10 12:34:24 UTC

(In reply to comment #15)
> (In reply to comment #14)
> > The decision is based on pure speculation.
>
> Please just stop the way you're acting. Just because I see things differently
> doesn't make it ok to behave like this on Google Plus, desktop-devel-list,
> here, etc.

I'm not acting in any way. Here's the definition of speculation:

 * to think, meditate or reflect on a subject; to deliberate or cogitate
 * to make an inference based on inconclusive evidence; to surmise or
conjecture

That is what you are doing. If you don't like how it sounds, then don't do it.

The only way you can know for sure what would happen if you enable voting, is
to enable voting, and see.

Right? If somebody is speculating, what’s wrong with saying “you are speculating”, if you want people to say you are speculating, then don’t speculate. Like a cheater that is complaining about people calling him cheater.

--- Comment 17 Olav Vitters [bugzilla.gnome.org developer] 2011-09-10 13:22:55 UTC

To put it in other words: I don't like the way you're behaving.

For example:

(In reply to comment #16)
> That is what you are doing. If you don't like how it sounds, then don't do it.

Stating things in above way, just don't. I'm not talking about arguments you're
trying to make. It is about the way you phrase them.

More concretely: My objection is not about not like "speculation", it is the
tone of your messages and the way you phrase those things. To more it comes
acrosss as trying to "tick me off". This is the last I'll say on this matter on
this bug, getting offtopic.

Oh! So it’s the tone? Well, we could debate whether there’s a nicer way to transmit the message I want to convey, but why linger on such lowly things? Olav certainly seems to have moved on and don’t want to discuss about this.

Note that at this point there’s still no warning about what would happen if I continue this behavior, that until the last comment wasn’t clarified, and in my opinion, it should never be an issue in the discussion.

--- Comment 18 Felipe Contreras 2011-09-10 14:06:06 UTC

(In reply to comment #17)
> This is the last I'll say on this matter on this bug, getting offtopic.

Exactly, this has nothing to do with the subject.

And complaining about "tone" is not precisely considered a sophisticated way to
engage in a discussion:

http://www.paulgraham.com/disagree.html

http://upload.wikimedia.org/wikipedia/commons/7/7c/Graham%27s_Hierarchy_of_Disagreement.svg

According to Paul Graham responding to tone is “a weak form of disagreement”, so I try to make it more delicate by saying it’s “not precisely a sophisticated way to engage in a discussion”.

BANG. Without any other comment or notification, I got banned. I didn’t notice until weeks later when I couldn’t login to GNOME bugzilla with this message:

Bug 629161 -- continue behaviour after various requests to change it
If you believe your account should be restored, please send email to bugmaster@gnome.org explaining why.

What? I go to that bug report and I don’t see anything (my comments were deleted), so I ask personally Andre Klappler to fetch the comments for me, and at the same time I contact the bugmasters.

After I got the comments and analyzed them I proceeded to build my defense (attached at the end); I actually never used a wrong tone. Olav’s problem was not with the tone, but with what I was actually saying, which was not flattering for him or GNOME, but actually true. I went into detail through those comments, and there was not nicer way of saying it.

In fact, I even proposed a compromise, I would not make any comment that criticizes GNOME, because apparently, that’s not allowed.

But, not surprisingly I got no response, except from Andre Klapper, who said he didn’t even read my defense:

On Fri, Sep 23, 2011 at 3:35 PM, Andre Klapper wrote:
> On Fri, 2011-09-23 at 15:20 +0300, Felipe Contreras wrote:
>> Of course not, you are only interested in patting each other in the
>> back, and self-congratulate yourselves. You are not interested in a
>> fair trial.
>
> It's exactly this style that makes me not interested in discussing
> anything with you currently.
> I stopped reading here, not interested in the rest.

So, no fair trial, banned with no warning, with reasons that are not true. That’s justice in GNOME’s world.

So that’s why

Perhaps it should be clear now why is it that the GNOME project doesn’t listen to it’s users, doesn’t allow voting in bugzilla, doesn’t allow a user survey (I’ll explain that in another blog post), ideastorm, or anything that gives the user masses the ability to speak.

GNOME is an autocratic oligarchy; it’s a club of like-minded people which only allows like-minded people. It a group that is both pompous and self-congratulatory; patting each other on the back is an obligation. You should not rock the boat, criticize the status quo, be confrontational, or deviate from the norm. They are never wrong, or do lowly things, and their design is dogma.

As I found out, to suggest that a GNOME member is speculating is such an extreme offense, that one should be shunned forever, never to poison GNOME’s precious ears, regardless of years of contributions (in my case since 2005).

Good riddance.

Defense

Since not Olav, nor anybody else presented any case, I'm going to
infer it from this:
---
Bug 629161 -- continue behaviour after various requests to change it
---

What is that behavior? Using phrasing and tone that are not in the
liking of Olav. How many instances? Presumably two, comment #14, and
comment #16. How many requests were done to change it? Presumably two,
comment #15, and comment #17.

First of all, at this point it should be clear, that in no point in
time any ban warning was issued. In fact, at no point in  time any
repercussions where stated. Having participated in countless online
discussions, I thought saying "I don't like your tone" meant only
that. Many people dislike the tone of other people, but most people
don't have the power, or the indecency, to block somebody's comments
just because they don't like them.

Now, did the accused change his tone after the second request to
change it? Well, lets look at comment #18.

What is the tone of this comment? How could this comment transmit the
same idea, but with a tone in the liking of Olav?

If you go to the page http://www.paulgraham.com/disagree.html, on the
section "Responding to Tone", the description is "this is still a weak
form of disagreement". So, stating that the site says so, is merely
stating a fact, not engaging in any form of inflammatory rhetoric. But
instead, I tried to choose more "subtle words", and changed "a weak
form of disagreement" to "not precisely sophisticated".

So no, there's nothing wrong with the tone of this comment. What Olav
didn't seem to like, was the content of the message which diminished
his position. There is no way I could have made that point in a way
that Olav would have lied it. So his "request" in comment #17 doesn't
apply, thus the "second warning" was never enforced.

Not to mention that at this point it seems more that Olav doesn't want
to discuss the merits of tone, and thus he is willing to let go of his
request. A person who was willing to improve discussions would have
been willing to continue the discussion about merits of tone in a
private manner. Or at the very least Olav should have made it clear
that regardless of the importance, it's something that is not
tolerated and warrant a ban. He didn't do any of such things.

But if you look closely at comment #17:

This is not a second request, it's a *clarification* on the first request.

And it points out to a line in comment #16:
---
That is what you are doing. If you don't like how it sounds, then don't do it.
---

Is this tone bad? What could be done to this message to improve the
tone? The point being made is that things are what things are;
speculating is speculating, and there's nothing wrong with pointing
out what is happening, instead, one should focus on avoiding doing it,
rather than preventing people from pointing it out.

So, there's really not much that can be done to change the tone of
this message without changing its meaning as well.

So, again, Olav was not concerned with the tone as he claimed, but he
was concerned about what was being said.

And finally, the line that started everything in comment #12:
---
The decision is based on pure speculation.
---

We ask again, is this tone bad? How can you say the same thing in a
better tone? There are not many ways.

So, yet again, Olav was concerned about what was being said, not the tone.

In conclusion:

1) There was no law, no warning, effectively no way in which I could
know what was going to happen.
2) There were no various requests to change the behavior, only one,
explained in two parts, because the first one was not clear enough.
3) The complaint about tone is unsubstantiated, the real problem is
pointing out things that put GNOME in a bad light.

This first video is from Cafe Tacuba, IMO the best band from Mexico, although I’m not sure what kind of style it is, it’s certainly awesome (I couldn’t find a better video quality)

The rest of the videos are of what I consider Son Jarocho in the right setting; small room, 3 guys; jarana jarocha (small guitar), requinto jarocho (even smaller guitar), and more importantly; arpa jarocha (a special harp). It’s a mixture of different styles from different continents, and the lyrics are often funny and sometimes improvised to make fun of something, or somebody. BTW, jarocho means from Veracruz, one of the 31 states of Mexico.

La Bamba is the most famous one, but I couldn’t find one video worthy of highlighting, so I just put the best one I could find. And before you ask, yes, the high pitch and loud voices in the chorus are intended, also, wait for the solos

This is what you most likely would expericence; a group wandering around restaurants, improvising and making jokes.

This one seems professionally recorded. Just for measure.

For more more about Mexican music and culture, check this previous post.

If you are not familiar with it, this package will see what music you are listening on Maemo devices, and scrobble to your favorite service, either last.fm, libre.fm, or both.

I already explained the features in an earlier blog entry, along with an explanation of how to make use of the “love” feature.

But now I also managed to port this to Harmattan, and it works perfectly on my Nokia N9. Interestingly enough, the new UI has a “favorite” feature directly integrated, it took me some time, as it’s not publicly documented, but I finally managed to hook into it, so everything works seamlessly

I was rather impressed by how easy it was to port it, I was able to leave all the GLib bits intact, even libsoup is still supported, and libconio, so I only had to make changes regarding the new qmafw. Thanks to the Qt guys for using the GLib’s mainloop by default, it certainly made things easier for me

Update

You can find a debian package here: maemo-scrobbler 2.0-2.

Then, you would need to create a file ~/.config/scrobbler like this:

[lastfm]
username=foo
password=bar

[librefm]
username=foo
password=bar

That’s it

Update: apparently this is not present in the images distributed with the Nokia N950′s, it was introduced after 25-3.

If you open ~/.config/mcompositor/mcompsitor.conf, you’ll see a bunch of swipe-action-foo configs, all of them set to “away” (by default).

You can, however, change them to something like:
swipe-action-up: switcher
swipe-action-down: close
swipe-action-left: events
swipe-action-right: launcher

And voilà! Now depending on which direction you swipe, is the action that would happen. You need to kill mcompositor for them to become active (or send SIGTERM/SIGINT, I don’t remember which one).

This was possible because I got fed up arguing about the benefits of swiping down to close applications, and decided to implement the thing by myself. While doing that, I also decided to implement an idea that was flying around, which was to do something different depending on the direction of the swipe. It took me about two days to do, including making it configurable, mostly trying to familiarize myself with the code that was split into multiple packages, and wrapping myself around C++, which I have avoided as much as possible. That was much less time than the time spent discussing before and after I implemented the patches. Fortunately, after seeing the thing in action, many people jumped into the wagon, and at least swipe down to close is available to the masses, which people seem to like. Guerrilla design

However, after a lot of though, I realized the configuration I mentioned above is ideal. And this is my rationale:

Rationale

The current design is inconsistent; when you swipe away, you never know in which desktop view you are going to end up, specially if you just unlocked the device. You might end up in ‘switcher’, or ‘launcher’, or ‘events’. Same action, different behaviour equals inconsistency.

There’s a simple solution; utilize the simple mental model required to navigate the desktop views.

In this way, it’s easy to know exactly what would happen when swiping on each direction, decreasing the amount of actions needed from the user. The same action always produces the same behavior.

It is unclear if this mode is ever going to be officially supported on the device, despite the fact that I think it’s obviously superior (and Ed Page seems to agree, as he came with the exact same idea by himself), maybe some people are worried about updating manuals and what not, but at least it’s trivial to activate, and anybody can create a 3rd party app for that

BTW. This is yet another reason why I distrust people telling me I’m a “geek”, and “designers” know better when it comes to design. In the words of Elaine Morgan; yes, they can all be wrong, history is strung with occasions when they all got it wrong.

Enjoy

This is a normal maintenance release mostly to fix reliability on
authentication, and offline messaging fixes.

Felipe Contreras (19):
      build: use makensis
      win32: update README with full instructions
      gitignore: update
      build: trivial cleanup
      build: remove redundant -ansi specifier
      pn_util: remove clang warnings
      auth: properly cleanup pending request
      Improvements from clang analyzer
      Trivial cleanups from clang analysis
      pn_util: trivial improvement in pn_html_unescape
      http: fix crash when connecting from another location
      sync: fix gression in LST command
      msn: send messages offline when invisible
      notification: properly update the status on CHG
      node: extra check for open signal handler
      auth: fix a few memory leaks
      node: fix trivial warning
      build: use GIO by default
      win32: tag 0.1.3

Download from the (usual place).

Do you really think Average Joe will listen when you say your Samsung Galaxy S II has a 1.2Ghz dual-core processor? No, he will ask his friend, Geek Mike, which phone he should buy.

Seth Godin, marketing guru, explains it perfectly:

He explains the TV industrial complex is gone, the golden years of the 60′s when all companies had to do is flood the TV with ads is now history. There’s too many choices, and way less time. Nowadays there’s complex networks of information, and everybody knows where and how to get recommendations of services and products, which probably will only be noticed if they are remarkable.

How do you explain that Google became such a big company without advertisement? You make a good product, and people talk about it. First the hard-core geeks, then normal geeks, there’s normal people, and eventually, even grandmas and grandpas. They started with doing one thing, but very well, and that made them remarkable. That’s why today even though Google+ as 74% males and 25% engineers (reference), they will spread the word, and eventually everybody will be there.

That is the viral effect of social networks. If you want something to spread through the network, you have to target the nodes that are more tightly connected, the ones at the center of the network. These would obviously be geek bloggers, many of which have thousands of followers, each of which will spread it to more and more people, until eventually you get to the masses. Google, Twitter, Facebook, the iPhone, they all seemed to be targeting only a small niche of technical people, but what many people didn’t consider, is that these geeks would find the value, and spread the message.

This should be obvious, but for some people it’s not. Some people say “oh, the geeks don’t like this, but it’s OK, they are not our target market” (Nokia comes to mind), which completely misses the point that if geeks don’t spread the message, you already lost.

And that is why GNOME 3, for example, already lost. They are ignoring the huge backlash from existing users telling them “we don’t care about you, you are a tiny minority”.

In this hugely interconnected world, you should not disregard the tiny minority that loves you, to seek the huge majority that doesn’t care about you, that is not only dangerous, but doomed to fail. Moreover, I would go even further and say, this tiny minority can actually tell you what you should do to reach the big majority better.