willoblog

J’ai acheté un Packard Bell EasyNote BG46-P-018 à Noël 2007, et présenté ici.

Après un an d’utilisation, on peut le dire : cet ordinateur avait le seul intérêt à l’époque d’être vraiment pas cher pour un 12 pouces. C’est un Packard Bell, et comme tous les Packard Bell il est assez mal conçu. En particulier, il chauffe beaucoup et son ventilateur, bruyant, est en marche en permanence.

Un certain nombre de problèmes se posaient, et il fallait un peu lutter avec Ubuntu Gutsy (7.10).

Deux ans plus tard, de grands progrès ont été faits :

• l’affichage en 16/10 fonctionne de suite
• l’affichage sur un écran externe (j’ai un HP 19 pouces en format 5/4) fonctionne de suite, après un passage dans Préférences/Affichage pour l’activer
• le son fonctionne de suite
• la webcam fonctionne de suite et apparaît dans le bon sens (elle apparaissait à l’envers avant)
• compiz ne pose plus de problème, et le processeur ne tourne pas pour rien même avec l’écran supplémentaire.

Seule ombre au tableau, les boutons « wifi » et « éco » qui des fois s’éteignent. Mais la connexion wifi est pourtant toujours active. Il me semble même qu’elle est plus stable qu’avant.

À noter, pour la webcam, que cela est dû à une modification des drivers. Nombreuses sont les webcams « montées à l’envers » sur les ordinateurs portables. Les fabricants le savent et fabriquent des drivers pour windows qui retournent automatiquement l’image. Sous Linux, il faut que quelqu’un tombe sur le modèle posant problème, le dise aux personnes compétentes pour modifier la liste des webcams concernées dans la librairie correspondante (v4l).
Si un logiciel comme cheese affiche l’image de la webcam à l’endroit, alors c’est gagné. Mais si en essayant avec VLC (souvent avec la commande vlc v4l2:///dev/video0) ou skype l’image est encore à l’envers, vous devez simplement faire précéder systématiquement la commande de LD_PRELOAD=/usr/lib/libv4l/v4l1compat.so, sur la même ligne. Pour skype par exemple, c’est facile à automatiser. Il suffit de créer un fichier /usr/local/bin/skype contenant

#!/bin/bash
 
LD_PRELOAD=/usr/lib/libv4l/v4l1compat.so /usr/bin/skype

(tapez gksudo gedit /usr/local/bin/skype dans un terminal, collez-y ce qui précède, enregistrez, et rendez le fichier exécutable en tapant sudo chmod +x /usr/local/bin/skype dans le terminal)
Il sera utilisé à chaque fois que la commande skype sera lancée.

Ubuntu Karmic is to be released on thursday, and the release candidate is available since a few days. So I tried to install it on a laptop that I don’t really use daily. I installed from scratch, with the live CD, desktop version.

This is a laptop I bought in May 2004, an Asus M2400n. It almost worked…
First, you have to specify on the live CD boot : acpi=off and nolapic by hiting F6. Then, you have no sound but it will work at the end. Installation works fine, as usual. To first boot after installation, you have to hit shift and escape when Loading GRUB is displayed (it’s very quick), then «e» to edit the first menu item and add the same boot options on the kernel line.

There are three things to do to make the release candidate work (hope this will be fix this week). One on Grub to boot properly, and two big issues with the display.

Modify Grub boot options

New in Karmic : Grub2 is finally used, and the famous /etc/boot/grub/menu.lst doesn’t exist anymore. Some explanations are available within the Internet. All you need to know is that you have to modify /etc/default/grub, and particularly the GRUB_CMDLINE_LINUX_DEFAULT variable to add nolapic. Do not add acpi=off, or you will never ear any sound.
After any modification of /etc/default/grub, you have to do sudo update-grub in order to modifiy the Grub intern files.

Kernel issue

The new kernel display handling (Kernel mode-setting, KMS) may be a little buggy… Anyway, with this method and with Intel graphic chipset like the i855GM in this laptop, it makes Xvideo not available (which results in a very buggy display, CPU high load, and unespected reboot with some softwares or websites). To deactivate KMS, you have to add nomodeset] to the boot options in /etc/default/grub.

This two issues can be simply solved by

sudo sed -i '/GRUB_CMDLINE_LINUX_DEFAULT/s/^\(.*\)"$/\1 nolapic nomodeset"/' /etc/default/grub
sudo update-grub

Intel driver issue

The current Intel driver has also some bugs. With this driver, the display freezes sometimes, very quickly after login, even before. It’s only a display freeze, not a system crash at all (computer is still pingable and ssh-ing still works).
I hope most of these bugs will be quickly solved, but till then we can use the vesa generic driver. It’s not as simple as before, because Xorg has also changed, and the famous /etc/X11/xorg.conf no longer exists… But you can write a new minimalist one, only containing what you want to modify. You can this way write in /etc/X11/xorg.conf:

Section "Device"
  Identifier      "Configured Video Device"
  Driver 	  "vesa"
EndSection

Section "Monitor"
  Identifier      "Configured Monitor"
EndSection

Section "Screen"
  Identifier      "Default Screen"
  Monitor         "Configured Monitor"
  Device          "Configured Video Device"
EndSection

Nothing else to do, the configuration file is automatically read as soon as the system reboots or Xorg restarts.

This way, presently my Asus M2400n works fine. Hope this helps.

SyntaxHighlighter : présentation

J'ai découvert il y a quelques semaines un (gros) bout de code génial. Comme le dit le site dédié, il s'agit d'un code de surlignage syntaxique, ou comment rendre des bouts de codes déjà lisibles encore plus lisibles.

L'utiliser n'est pas très compliqué, puisqu'il suffit de télécharger le dernier .zip, de le dézipper et de regarder ce qu'on trouve. Un répertoire scripts contenant en particulier shCore.js qui est le cœur de la machinerie, ainsi que plein de shBrush*.js, qui contiennent les définitions des syntaxes pour différents langages. Personnellement, je n'ai pas besoin de tout, donc je n'ai choisi de garder que ce qui m'intéresse : Bash, Php, Plain que j'utiliserai souvent, Css, JScript et Sql un peu moins, et puis aussi au cas où Diff, Perl, Python, Xml. Un dossier styles contient lui les fichiers de mise en page css, parmis lesquels shCore.css est obligatoire et ensuite shThemeDefault.css correspond au seul thème écrit en noir sur blanc (les autres font du blanc sur noir, je déteste ça). Sans oublier les trois icônes qui seront affichées dans la toolbar et l'icône de retour à la ligne.

Donc on prend tous ces fichiers, on met tout ça dans un répertoire, appelé par exemple syntaxhighlighter, à la racine du site. Il ne reste plus qu'à modifier les pages web en ayant besoin. Il faut rajouter dans l'entête html :

[html]
  <script type="text/javascript" src="/syntaxhighlighter/shCore.js"></script>
  <link type="text/css" rel="stylesheet" href="/syntaxhighlighter/shCore.css"/>
  <link type="text/css" rel="stylesheet" href="/syntaxhighlighter/shThemeDefault.css"/>
  <script type="text/javascript" src="/syntaxhighlighter/shBrushPlain.js"></script>
  <script type="text/javascript" src="/syntaxhighlighter/shBrushBash.js"></script>
  <script type="text/javascript">
    SyntaxHighlighter.all();
  </script>

Ensuite, tous les paragraphes de type <pre> seront analysés, pour peu qu'on dise à quel langage ils correspondent, en ajustant la classe :

[html]
<pre class="brush: bash">

par exemple. J'ajoute aussi, pour éviter la numérotation des lignes quand il s'agit d'une simple ligne de commande :

[html]
<pre class="brush: plain; gutter: false">

Mais il y a encore deux trois détails à gérer. Petits trucs et astuces pour pouvoir afficher des scripts bash comme cela est réalisé sur mon site.

Pour le transcript, deux problèmes

Balises malgré elles

SyntaxHighlighter transforme tous les chevrons « < » et « > » en entités html correspondantes, respectivement « &lt; » (less than) et « &gt; » (greater than). Ce ne serait pas grave s'il ne le faisait pas seulement pour presque tous les chevrons... Or il cherche à détecter automatiquement les balises (ce qui n'est pas très malin dans du code bash d'ailleurs, ce qui fait que mon adresse mail par exemple était comprise comme une balise, dégradant quelque peu la suite de l'affichage. Total : il faut le faire pour lui.
Au départ, j'avais choisi d'utiliser readline en php, à savoir

[php]
<pre class="brush: bash">
<?PHP  @readline('compil'); ?>
</pre>

Mais transformer les chevrons à l'avance n'est pas beaucoup plus compliqué :

[php]
<pre class="brush: bash">
<?PHP  echo str_replace('<','&lt;',str_replace('>','&gt;',file_get_contents('compil'))); ?>
</pre>

Vous aurez remarqué que du coup, dès que le fichier est modifié, c'est le code de la dernière version qui s'affiche. Zéro maintenance (le fichier compil est un lien symbolique vers /usr/local/bin/compil sur mon serveur).

Décidément, ces chevrons...

Et c'est à ce moment que l'on relit un peu ce qui s'affiche à l'écran, et qu'on se rend compte que plein de chevrons (mais pas tous) sont restés à l'état d'entités html. Alors qu'en enlevant l'influence de SyntaxHighlighter, on obtient bien le résultat attendu. Il m'aura fallu quelques minutes pour me souvenir que lt et gt, sont des mots-clés en bash, justement pour des tests numériques plus grand/plus petit (ouais, tout est lié). Un grand dilemme se pose alors. Soit on laisse comme ça, et le code affiché est faux. Soit on s'arrange pour ne jamais avoir de chevrons (ce qui est impossible quand on a besoin de redirections). Soit on commente les mots-clés gt et lt dans le fichier de définition shBrushBash.js, et tant pis pour leurs rares apparences en tant que tests, où ils ne seront pas colorés comme il faut. J'ai choisi cette dernière solution.

Pour l'aide

Ah, là ça se corse. Au départ j'avais recopié telle quelle la réponse de compil -h. Je me suis dit alors « mais si t'as une coquille dans l'aide ou que tu la modifies, il faudra revenir ici... au secours ». Alors j'ai trouvé un moyen. Après plusieurs tâtonnements et hésitations sur la meilleure fonction php entre exec, system et passthru, j'ai opté pour

[php]
<pre class="aide">
$ compil -h

<?PHP 
exec('[ ! -e compil.help -o compil -nt compil.help ] && compil -h | tr -d "\033" | sed -e "s/\[1m/<b>/g" -e "s/\[0m/<\/b>/g" > compil.help');
@readfile('compil.help'); ?>
</pre>

Explication : la dernière commande lit et affiche un fichier compil.help. On va donc y mettre l'aide. Problème, j'utilise un formatage à base de caractères bizarres qui permettent de mettre en gras du texte en console. On prend donc le résultat de compil -h, on en vire donc le caractère bizarre (grâce à la commande tr -d), puis on identifie le début et la fin des mises en gras, que l'on remplace de façon moche mais fonctionnelle par des balises de formatage html.
Le début est un test, qui permet d'exécuter la commande seulement si compil.help n'existe pas ou est plus ancien que compil. Cela semble fonctionner à peu près correctement.

Petite astuce latex que j'ai découverte hier : l'espace qui est systématiquement insérée derrière une virgule, y compris en mode mathématique, est supprimable. Cette espace me gênait beaucoup, juste parce que c'est moche. C'est un format anglais, et c'est typographiquement incorrect en français.

Après quelques recherche, on trouve plusieurs solutions :

• rajouter des accolades autour de chaque virgule dans les formules mathématiques. Problème, il faut le faire pour chaque virgule concernée. Moi, mes 135 pages sont déjà écrites, c'est impensable.
• rajouter une macro des packages de traduction, \nombre{}, autour de chaque formule mathématique. Même problème (même si c'est un peu plus simple à gérer en ligne de commande via sed par exemple).
• simplement utiliser le package icomma. Intérêt : une seule ligne à changer, et après recompilation toutes les espaces indésirables auront disparu !

Pour ceux qui ont du mal à suivre, plus en détail :

• Disposer du fichier icomma.sty. Sous Ubuntu par exemple, il suffit d'installer le bon paquet, si ce n'est déjà fait : sudo aptitude install texlive-latex-extra
• dans le préambule de vos sources latex, insérer \usepackage{icomma}

Je viens de trouver la solution d'un problème qui me turlupinait depuis environ 1 an (au moins...).

Mes pdf produits par latex étaient jolis, vus de loin. En se rapprochant de l'écran, pas génial, mais ce n'est pas très grave, les pdf c'est fait pour être imprimé. Plus gênant, beaucoup plus gênant, la sélection de texte étant une vraie plaie, pour ne pas dire que ça faisait n'importe quoi. Dans Evince et dans l'Acrobat Reader d'Adobe, rien à faire. Et je ne parle pas de la recherche de texte... Et le meilleur venait de l'impression : si Acroread n'avait pas grand problème, Evince ramait tellement qu'il en attaquait la plage : saturation du processeur pendant plus de 10 secondes par page, et rendu vraiment abominable sur toutes les imprimantes laser à ma disposition, à peine lisible pour le texte, mais parfait pour les formules et les images. Bref, la fête.

J'ai essayé plein de méthodes pour générer différemment mes pdf. J'utilise couramment ce formidable logiciel qu'est Lyx, avec la compilation via latex+latex+dvips+ps2pdf. La première idée était de changer l'option PDFSETTINGS de ps2pdf, comme indiqué dans la documentation. J'ai réussi à améliorer la qualité des images en réglant cette option à printer, mais rien sur les fontes et l'impression par Evince... Je me suis dit à un moment que c'était Lyx. Depuis, j'ai l'occasion maintenant d'utiliser beaucoup plus du « vrai » latex, avec plein de petits bouts de macros dedans (je m'amuse comme un fou en ce moment :) ), vraiment compilé à la main, et pareil... Au cas où le fautif serait ps2pdf, j'ai essayé pdflatex (que je n'ai pas encore adopté parce que j'ai toutes mes images en ps, fabriquées par le très « original » logiciel de dessin Xfig et l'excellent script fig2ps, qui permet d'avoir simplement des figures avec du texte et des formules latex dedans...). Même résultat.

J'ai donc trouvé la cause de tous ces problèmes. J'imagine que je suis pas le seul à qui ça arrive, mes fichiers tex n'ont rien de particulier, et mes documents lyx sont d'un commun tout juste compensé par la haute valeur ajoutée du contenu scientifique qu'ils contiennent. L'installation d'Ubuntu est récente sur cette machine et sans grande modification. J'ai pourtant mis du temps à trouver. J'espère que des personnes faisant la recherche sur « latex pdf evince impression » ou « latex pdf ubuntu affichage » ou « latex pdf sélection texte » pourront tomber ici...

Le problème venait visiblement de texlive, devenue la distribution latex « officielle » sous Ubuntu depuis Gutsy (tout pile un an), remplaçant petit à petit l'ancienne distribution tetex. Les polices ne sont visiblement pas gérées de la même façon et maintenant (je ne peux pas vérifier comment c'était avant), les lettres sont transformées en images bitmap, à la fois pixellisées (donc moche) et lourdes (donc qui prennent du temps à être envoyées à l'imprimante et de la place sur le disque dur). Deux possibilités pour arranger cela :

• installer le paquet cm-super, via par exemple sudo aptitude install cm-super. Besoin de rien modifier dans le fichier tex|lyx, les polices moches bitmap utilisées avant (« cm ») seront remplacées automatiquement à la prochaine compilation. Un problème : si dans trois ans vous changez de machine et que vous oubliez que vous aviez installé cm-super, rebelote...
• rajouter dans le préambule de votre fichier tex l'utilisation du package des polices latin modern : \usepackage{lmodern}. L'inconvénient étant certes qu'il faille modifier vos fichiers actuels, mais l'avantage est qu'ils seront compilés partout pareil. De plus, il paraît (j'y connais rien, c'est ce que j'ai lu) que cette police est un peu plus fidèle aux anciennes polices bitmap que cm-super...

Ce qui est bien, c'est que j'ai un mémoire un peu plus présentable maintenant... :)

J’ai acheté un nouveau portable pour Noël (pas pour moi, pour Amélie en fait). Il s’agit d’un ultraportable. Le choix est restreint sur ce segment, sachant qu’on voulait un portable à la fois léger (2kg max) et puissant (processeur Intel Core 2 Duo T7100 minimum), et le tout sans mettre plus de 1300€.

Hier, un collègue me demande pourquoi est-ce que, quand il utilise aptitude, il voit des paquets avec marqué 'id' en début de ligne. Après une recherche dans Google, impossible d'avoir un embryon de réponse. En fait, il faut lire le fichier /usr/share/doc/aptitude/html/index.html (dans Firefox par exemple). On y trouve, en plein milieu, que ce 'd' signifie que le paquet est vu par aptitude comme devant être bientôt supprimé (mais le paquet est bien installé et fonctionnel). Ce n'est donc pas gênant, puisque tout fonctionne normalement, mais c'est juste un peu moche...

La solution, elle est indiquée dans le même fichier, elle consiste à taper pour chaque paquet

sudo aptitude install nom_du_paquet:

Mais dans le cas de mon collègue, c'est assez usant, il y a au moins 40 paquets concernés... Alors là je lui dis "pas de problème, je te le fais en une ligne", et je fais mon malin :

• voir tous les paquets de votre système (attention, c'est très long) :

sudo aptitude search "~A"

• voir seulement les lignes commençant par 'id' ('i' = paquet installé)

sudo aptitude search "~A" | grep -e "^id"

• sur chaque ligne choisie, ne garder que le nom des paquets

sudo aptitude search "~A" | grep -e "^id" | sed 's/^[idA]*[ ]*\([a-z0-9.+-]*\)[ ]*.*$/\1/'

• ne garder que le nom des paquets, mais y ajouter à chacun deux points

sudo aptitude search "~A" | grep -e "^id" | sed 's/^[idA]*[ ]*\([a-z0-9.+-]*\)[ ]*.*$/\1:/'

• enfin, passer tout ça à sudo aptitude install

sudo aptitude install `sudo aptitude search "~A" | grep -e "^id" | sed 's/^[idA]*[ ]*\([a-z0-9.+-]*\)[ ]*.*$/\1:/'`

(Attention, les trois types de guillemets sont utilisés, et ici ne sont pas interchangeables...)