or any 10' netbook, actually...

There s a new extension called Meerkat that squeezes the icons and menu from firefox in a more compact space, that and auto-hiding the status bar when it is not used, allowing for 60 vertical pixels to be regained.

Full screen capture: FF3 with Meerkat extension - and Green Guitar Persona

Short of hitting F11 (ie full screen mode) this is a very nice way to make firefox more usable.

(via http://www.notebooks.com/2009/08/06/make-firefox-fit-your-netbook-in-30-...)

F.

This weekend's Gdium hackathon in Paris attracted hackers and enthusiasts to Bellinux in Paris 20th Arrdt  (the location had to be changed at the last minute).

During the weekend they compiled and packaged a few applications, such as tuxtyping or guten (a first for some of the participants) or tackled ambitious re-compilations (such as the latest version of Wesnoth, QT4.5, Webkit or Midori).

We should see the results soon (some of those builds need more than a couple of days, even when using an external harddrive for storage).

Thanks to Norbert (our Host), Vincent, Natacha, Aurelien, Benoit, Paul, Emmanuel and everyone else.

See you next time !

Some hackers at work

Compilation row.

Just for kicks, I urpmi'd telnet and went to check the old animated Starwars movie at towel.blinkelights.nl

It's working, and it's still great in its monochrome glory.

who needs flash anyway :)

cheers,

Fab

This is an explanation why Gkey images should not exceed 14.8 GB (Giga bytes=1024^3)

for a "16GB" flash key, the theoretical number of stored bytes is 17 179 869 184 bytes

However the NAND flash manufacturer does specify that the guaranteed usable capacity - when the key is new - is 93% of nominal capacity (keeping 7% for spare blocks and controller data).

Which turns out to be 15,977,278,341 byte ie: 14,88 GB

Even though the previous gkey images were stlightly larger (closer to 16GB), we're now making the gkey images at around 14.4 GB (we're still experimenting a bit around this as this is related to wear and the capacity of the controller to replace faulty blocks by healthy ones from the spares).

Fabrice.

Hi I've described this method in the forum already but I put it here so it can be more visible.

The problem with PMON choosing to boot from various USB devices that can be connected to the gdium instead of the system partition on the gkey has mutliple sources. In particular if the usb device is mass storage (usb key or harddrive) pmon may mount it earlier than the gkey. At the moment pmon is trying to boot from /dev/sda2, so if /dev/sda2 has been assigned to the external device it can be a problem.

The method to fix the problem is to ensure that:

1) the partition to boot from is correctly labelled as "mips" (this is default in glinux images, and you can do it on your own image by using the command e2label)

2) the karg variable in PMON is correctly set, for this follow the method below:

Get into PMON at boot time by hitting the DEL (Suppr) key during the "G" splash screen.

Be aware that (as described in the Wiki) PMON thinks you have a US keyboard so double-check what you input !

anyway, you can check the karg variable with the env command

it will dispay the karg variable (among others) which contain

root=/dev/sda2

Then you can edit the karg environment variable by using
eset karg

(use arrows to move on the line, then hit return)

then replace the root=/dev/sda2 with root=LABEL=mips

hit enter, then use the command reboot.

It should now boot on the gkey regardless of what is inserted in the other USB ports.

Disclaimer: beware this may not work as expected, but it can be reverted in the same way.

As usual I cannot take responsibility if the gdium is broken or turned into a pile of smoldering ashes :-)

Fab