Luca's meaningless thoughts  

The LANGUAGE environment variable can accept multiple fallback languages (at least if your commands are using gettext), so if your main LANG is, say, es, but you also speak fr, then you can use LANGUAGE=es:fr.

But what happens when you main LANG is en, so for example your LANGUAGE looks like en:es:de? You'll notice some message that used to be in perfect English before using the multi-language fallback now seem to be shown randomly in es or de.

Well, it is not random. The thing is, since English tends to be the de-facto language for the original strings in a program, it looks like almost nobody provides an en translation, so when fallback is active, almost no programs will show messages in English.

For example, this is my Debian testing system with roughly 3.5K packages installed:

$ dpkg -l |wc -l
3522
$ ls /usr/share/locale/en/LC_MESSAGES/ | wc -l
12

Only 12 packages have a plain English locale. en_GB does a bit better:

$ ls /usr/share/locale/en_GB/LC_MESSAGES/ | wc -l
732

732 packages. This is still lower than both en and de:

$ ls /usr/share/locale/es/LC_MESSAGES/ | wc -l
821
$ ls /usr/share/locale/de/LC_MESSAGES/ | wc -l
820

The weird thing is packages as basic as psmisc (providing, for example, killall) and coreutils (providing, for example, ls) don't have an en locale, and psmisc doesn't provide es. This is why at some point it seemed like a random locale was being used. I had something like LANGUAGE=en_GB:en_US:en:es:de and I use KDE as my desktop environment. KDE seems to be correctly translated to en_GB, so I was seeing most of my desktop in English as expected, but when using killall, I got errors in German, and when using ls, I got errors in Spanish.

If you don't provide other fallback languages, gettext will automatically fall back to the C locale, which is the original strings embedded in the source code, which are usually in English, and this is why if you don't provide fallback languages (other than English at least), all will work in English as expected. Of course if you use C in your fallback languages, before any non-English language, then they will be ignored as the C locale should always be present, so that's not an option.

I find it very curious that this issue has almost zero visibility. At least my searches for the issue didn't throw any useful results. I had to figure it all out by myself like in the good old pre-stackoverflow times...

Fuck! I bought this extremely nice ultrabook, the Toshiba Satellite Z830-10J, about an year ago, and I've been experiencing some problems with CPU frequency scaling.

At one point I looked and looked for kernel bugs without much success. I went through several kernel updates in the hope of this being fixed, but never happened.

It seemed that the problem wasn't so bad after all, because I only got the CPU frequency locked down to the minimum when using the ondemand scaling governor, but the conservative was working apparently OK.

Just a little more latency I thought, is not that bad.

Recently I received an update on a related bug and I thought about giving it another shot. This mentioned something about booting with processor.ignore_ppc=1 to ignore some BIOS warning about temperature to overcome some faulty BIOS, so I thought on trying that.

But before doing, if this were a real BIOS problem, I thought about looking for some BIOS update. And there was one. The European Toshiba website offered only a Windows program to do the update though, but fortunately I found in a forum a suggestion about using the non-European BIOS upgrade instead, which was provided also as an ISO image. The problem is I don't have a CD-ROM, but that shouldn't stop me, I still have USB sticks and hard-drives, how hard could it be? I failed with UNetbootin but quickly found a nice article explaining how to boot an ISO image directly with grub.

BIOS upgraded, problem not fixed. So I was a about to try the kernel parameter when I remembered I saw some other article when googling desperately for answers suggesting changing some BIOS options to fix a similar problem.

So I though about messing with the BIOS first instead. The first option I saw that looked a little suspicious was in:

PowerManagement
   -> BIOS Power Management
      -> Battery Save Mode (using custom settings)
         -> Processor Speed
            <Low>

That is supposed to be only for non-ACPI capable OS, so I thought it shouldn't be a problem, but I tried with <High> instead.

WOW!!!

I start noticing the notebook booting much faster, but I thought maybe it was all in my mind...

But no, then my session opened way faster too, and everything was extremely faster. I think maybe about twice as fast. Everything feels a lot more responsive too. I can't believe I spend almost an year with this performance penalty. FUCKING FAULTY BIOS. I didn't make any battery life comparisons yet, but my guess is everything will go well, because it should still consume very little power when idle.

Anyway, lesson learned:

Less blaming to the kernel, more blaming to the hardware manufacturers.

But I still want to clarify that I love this notebook. I found it a perfect combination between features, weight and battery life, and now that it runs twice as fast (at least in my brain), is even better.

Hope this is useful for someone.

OK, after I recovered my phone without needing to reflash once, I was even much closer to do it again because of a new problem.

After missing an appointment and arriving at work about 3 hours late, I realized my phone stopped reproducing sound and vibrating when an alarm was fired. At first I thought I put the alarm incorrectly but then I verified that the alarm was not working. I still got a popup with the alarm message, but no sound or vibration.

So... Time to debug the problem. After searching a lot, I couldn't find anybody with my same problem, I found similar, but not the same, so I decided to report a bug. I got a very fast but useless response. Great!

Making long story short, I finally found some IRC channels and mailing lists where I could find a more opensourceish support that the one provided in the forums and bugzilla. So I'm happy I finally found a place where you can talk to actual developers.

I commented my problem and just after a very trivial but extremely useful suggestion (installing syslogd), I could trace the origin or the problem and fix it (I just love you strace!).

I also had another problem, suddenly the skype calls stopped working. Again the syslog helped a lot. Unfortunately I didn't save the exact syslog error message, but it was something like:

GStreamer - Could not convert static caps "!`phmcadion/x-rtp,
media=(string)video, payload=(int)[ 96, 127 ], clock-rate=(int)[ 1,
2147483647 ], encoding-name=(string)MP4V-ES"

As the MIME TYPE looked like garbage, I just grep(1)ed the filesystem searching for that string, and I found some binary file at /home/user/.gstreamer-0.10/registry.arm.bin. I backed up the file, remove it, and everything started working again (the file was recreated but with a very different content).

I have no idea how the symlink or the gstreamer file got broken, except maybe because of the unexpected reboot because of the broken batterypatch, but still, is really strange.

Anyway... Lessons learned:

• Maemo (Nokia) bugzilla is useless for getting help
• Install syslogd to debug Nokia N900 problems
• The maemo developers mailing list is your friend

Conclusion: Reflash my ass!

I bought a Nokia N900 recently, a great toy if you like to have a phone with a Linux distribution that uses dpkg as package manager :)

Of course you can use it as an end user, and never find out, but as the geek I am, I had to hack it, and use the devel package repositories. Of course, with that comes the problems (and the fun! :D).

The last update of the batterypatch package came with a weird feature. The device rebooted itself each time it starts, leaving it in a restart loop that rendered the device unusable.

Searching for valuable information was not easy (thanks forums! You SUCK at organizing information... I miss mailing lists).

Anyway, I hope I can save some work to someone if you get in a similar situation, so you don't have to waste ours searching the Maemo Forums.

First you will need a tool to flash the phone (it can do other things besides flashing it, I used the maemo_flasher-3.5_2.5.2.2_i386.deb file). You can also check some instructions on how to load a (very) basic rescue image (from Meego). The good thing is this image is an initrd that's loaded in MEMORY, so you don't loose anything if you tried, the device goes to it's previous state (broken in my case :P) after a reboot.

What this image can do is put the device in USB mass storage mode (the embedded MMC -eMMC- and the external MMC). I've done this to backup my eMMC data, which holds the MyDocs vfat partition and the 2 GiB ext3 partition used to install optional software. You can also put the device in USB networking mode, you can get a shell console (and reboot/power off the device), but I found that pretty useless (because you don't have any useful tools, the backlit is not turned on, so is really hard to see anything, and because the kayboard doesn't have the function key mapped, so you can't even write a "/").

The bad thing about this image, is you can't access to the root filesystem (wich is stored in another NAND 256MiB memory). I wanted to access it for 2 reasons. First, I wanted to edit some files that the batterypatch program created to see if that fixed the rebooting problem. And if now, I wanted to make a backup of the rootfs so I didn't loose most of my customizations and installed software.

I first found that a way to access the rootfs was to install Meego in a uSD memory, but for that I needed a 4GiB uSD. Also it looked like too much work, it has to be something battery and easier to just mount the rootfs and play around.

And I finally found it. It was the hardest thing to found, that's why I not only passing you the original link, I'm also hosting my own copy because I have the feeling it can disappear any time! :P

This image let's you do all the same the other image can, but it turns on the backlit, it has better support for the keyboard (you can type a "/") and it can mount the UBI root filesystem. Even more, it comes with a telnet daemon, so you can even do the rescue work remotely using USB networking ;)

You can see the instructions for some of the tasks, but here is how I did to be able to log in using telnet, which is not documented elsewhere that I know off. Once you have your image loaded:

1. You have to activate the USB networking in the device: /rescueOS/usbnetworking-enable.sh

2. Configure your host PC to assign an IP to usb0: sudo ip a add 192.168.2.14/24 dev usb0 && sudo ip link set usb0 up

3. Start the telnet daemon in the device: telnetd

4. I couldn't find out the root password, and since the initrd root filesystem is read-only, so I did this to change the root password:

   cp -a /etc /run/
   mount --bind /run/etc /etc
   passwd
   

   Now type the new root password.

5. That's it, log in via telnet from the host PC: telnet 192.168.2.15 and have fun!

With this I just could edit the broken files and saved the device without even needing to reflash it, but if you're not so lucky, you can just backup the root filesystem and reflash using this instructions (I didn't tested them, but seems pretty official).

Now I should probably have to try the recovery-boot package, if it works well it might be even easier to rescue the phone using that ;)

Estoy demasiado lazy como hacer posts con contenido propio, así que sencillamente, como vengo acostumbrando, me voy a limitar a copiar algo que hizo otra persona:

Buenas comunidad.

Hoy tengo la alegría de contarles que ya está oficialmente disponible

sequreisp, que es un completísimo software para gestión de ISPs made in

Argentina.

Si bien el proyecto esta en github desde hace unos meses recién ahora lo

estamos dando a conocer públicamente, una vez que superamos una fase de

prueba y feedback entre conocidos.

Para los que no saben que es sequreisp les cuento que es un soft escrito en

Ruby On Rails que permite montar un server de ISP para manejar multiples

proveedores con balanceo y failover, control de ancho de banda, priorizado

entre muchas otras cosas, todo muy comodamente desde una interfaz web.

Esta pensado para pequeños y medianos ISP o WISPs, desde unos pocos clientes

hasta 3000 mil o más que son los setups más grandes que tenemos actualmente

en un single server, pero creemos que se puede escalar aún más. Respecto al

balanceo hemos llegado a balancear 32 ADSL en un sólo servidor. La solución

es muy estable, actualmente la están usando alrededor de unos 40 ISPs/WISPs

de argentina y latinoamérica y el número va creciendo.

Si bien sequreisp es un producto comercial se eligió liberar su core bajo

AGPLv3 para devolver a la comunidad todo lo que siempre nos da y sigue dando,

sin el kernel de linux, iptables, tc, mysql, ruby y un largo etc. sequreisp

no existiría.

Existe también una versión comercial(de algo hay que vivir =) que agrega

funcionalidades mediante módulos, y es la que usan nuestros clientes, ya que

además incluye soporte, asesoramiento, backups online y otros servicios.

Agradecemos la difusión del proyecto e invitamos a toda a la comunidad

a usarlo y participar del mismo, git-hub facilita enormemente esto último.

Tickets, bugs reports, sugerencias y sobre todo pull-request son más que

bienvenidos.

Les dejo las urls.

Sitio oficial:

http://www.sequreisp.com/

Codigo fuente:

https://github.com/sequre/sequreisp

Foro:

http://forum.sequreisp.com/

--

Luciano Ruete

lruete at sequre.com.ar

Gracias Lucho por compartir :)

Yaii! My beep will be back in the next kernel release :)

This is a note to let you know that I've just added the patch titled

    ALSA: hda - Add PC-beep whitelist for an Intel board

to the 2.6.35-stable tree which can be found at:
    http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
    ../tmp/alsa-hda-add-pc-beep-whitelist-for-an-intel-board.patch
and it can be found in the queue-2.6.35 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@kernel.org> know about it.


>From e096c8e6d5ed965f346d94befbbec2275dde3621 Mon Sep 17 00:00:00 2001
From: Takashi Iwai <tiwai@suse.de>
Date: Tue, 3 Aug 2010 17:20:35 +0200
Subject: ALSA: hda - Add PC-beep whitelist for an Intel board

From: Takashi Iwai <tiwai@suse.de>

commit e096c8e6d5ed965f346d94befbbec2275dde3621 upstream.

An Intel board needs a white-list entry to enable PC-beep.
Otherwise the driver misdetects (due to bogus BIOS info) and ignores
the PC-beep on 2.6.35.

Reported-and-tested-by: Leandro Lucarella <luca@llucax.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 sound/pci/hda/patch_realtek.c |    1 +
 1 file changed, 1 insertion(+)

--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -5183,6 +5183,7 @@ static void fillup_priv_adc_nids(struct

 static struct snd_pci_quirk beep_white_list[] = {
        SND_PCI_QUIRK(0x1043, 0x829f, "ASUS", 1),
+       SND_PCI_QUIRK(0x8086, 0xd613, "Intel", 1),
        {}
 };



Patches currently in stable-queue which might be from tiwai@suse.de are

queue-2.6.35/alsa-hda-add-pc-beep-whitelist-for-an-intel-board.patch

If you feel it should not be added to the stable tree, and let <stable@kernel.org> know about it, I kill you!.

This is mostly a reminder to myself, since I'm throwing away the blister and I want to be able to identify this little gadget in case I have to buy another one in the future.

The is a very cheap USB Bluetooth adapter. It's made in China and don't even have a brand name, the blister just says Bluetooth USB Adapter ES-388. Linux report it as:

Bus 004 Device 003: ID 1131:1001 Integrated System Solution Corp. KY-BT100
Bluetooth Adapter

And it works very well using a stock Linux kernel; just plug it and enjoy!

Here is what the blister looks like:

In Argentina you can buy it for as low as ARS 10 (USD 3) so I guess in another coutries they are practically given away for free =P

Definition by Wikipedia:

A plug computer is a small form factor network-attached server for use in the home. It is a lower cost and lower power alternative to a PC-based home server. In effect, a plug computer is a network appliance that is fully enclosed in an AC power plug or AC adapter.

Look at this little bastard (up to 2Ghz CPU, 512MB of RAM + 512MB of flash memory, 1.8" hard drive, gigabit ethernet, SD reader, USB, Wi-fi, Bluetooth, under USD100):

Runs Linux and it's supposed to be fully open source.

I want one! =)

Lessfs is an open source data deduplication filesystem:

Data deduplication (often called "intelligent compression" or "single-instance storage") is a method of reducing storage needs by eliminating redundant data. [...] lessfs can determine if data is redundant by calculating an unique (192 bit) tiger hash of each block of data that is written. When lessfs has determined that a block of data needs to be stored it first compresses the block with LZO or QUICKLZ compression. The combination of these two techniques results in a very high overall compression rate for many types of data.