Sysmic.org

Aller au contenu | Aller au menu | Aller à la recherche

vendredi, avril 16 2010

Connect to Bluetooth Access Point using Bluez framework

Bluez is packaged with a set very useful scripts. Exemple to connect to a Bluetooth access point:

$ /usr/share/doc/bluez/examples/test-discovery       
[ 00:22:FD:35:3D:74 ]
   Name = Nokia 5310 XpressMusic
   Paired = 0
   LegacyPairing = 1
   Alias = Nokia 5310 XpressMusic
   Address = 00:22:FC:38:3F:79
   RSSI = -63
   Class = 0x5a0204
   Icon = phone
$ /usr/share/doc/bluez/examples/test-device create 00:22:FC:38:3F:79
/org/bluez/1104/hci0/dev_00_22_FC_38_3F_79
$ /usr/share/doc/bluez/examples/test-network 00:22:FC:38:3F:79 NAP &
Connected /org/bluez/1104/hci0/dev_00_22_FC_38_3F_79 to 00:22:FC:38:3F:79
Press CTRL-C to disconnect
$ sudo dhclient bnep0
[...]

(Tested on Kubuntu 10.4beta2)

jeudi, avril 8 2010

Convertir un fichier binaire en structure C en une ligne de shell

L'option -ede hexdump permet de formater la sortie à la mode printf:

$ hexdump -e '16/1 "0x%02X, " "\n"' < file
0x02, 0xB0, 0x2A, 0x00, 0x01, 0xF9, 0x00, 0x00, 0xE0, 0xC8, 0xF0, 0x13, 0x09, 0x11, 0x01, 0x00,
0xE0, 0x67, 0x00, 0x8C, 0xFF, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01, 0x00, 0x21, 0x02,
0xE0, 0xC8, 0xF0, 0x00, 0x04, 0xE0, 0xC9, 0xF0, 0x00, 0x85, 0xC5, 0xE7, 0xDC, 0x  , 0x  , 0x  ,

16/1 Indique que l'on doit répéter le formatage suivant 16 fois et que l'on fait des pas de 1 octet. "0x%02X, " spécifie le format. Lorsque hexdump a terminé le premier format, il passe au suivant. Ici on affiche un saut de ligne. Hexdump boucle sur ce formatge jusqu'à la fin de l'entrée.

On peut remplacer \n par quelque chose d'un peu plus attrayant et ajouter une indentation:

$ hexdump -e '"\t" 16/1 "0x%02X, " " // %.7_ax\n"'  < file
        0x02, 0xB0, 0x2A, 0x00, 0x01, 0xF9, 0x00, 0x00, 0xE0, 0xC8, 0xF0, 0x13, 0x09, 0x11, 0x01, 0x00, // 0000000
        0xE0, 0x67, 0x00, 0x8C, 0xFF, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01, 0x00, 0x21, 0x02, // 0000010
        0xE0, 0xC8, 0xF0, 0x00, 0x04, 0xE0, 0xC9, 0xF0, 0x00, 0x85, 0xC5, 0xE7, 0xDC, 0x  , 0x  , 0x  , // 0000020

Bon, il faut encore retirer les crottes à la fin de la sortie manuellement, mais le plus gros est fait.

mercredi, mars 24 2010

Convert keys between GnuPG, OpenSsh and OpenSSL

OpenSSH to OpenSSL

OpenSSH private keys are directly understable by OpenSSL. You can test for example:

openssl rsa -in ~/.ssh/id_rsa -text
openssl dsa -in ~/.ssh/id_dsa -text

So, you can directly use it to create a certification request:

openssl req -new -key ~/.ssh/id_dsa -out myid.csr

You can also use your ssh key to create a sef-signed certificate:

openssl x509 -req -days 3650 -in myid.csr -signkey ~/.ssh/id_rsa -out myid.crt

Notice I have not found how to manipulate ssh public key with OpenSSL

OpenSSL to OpenSSH

Private keys format is same between OpenSSL and OpenSSH. So you just a have to rename your OpenSSL key:

 cp myid.key id_rsa

In OpenSSL, there is no specific file for public key (public keys are generally embeded in certificates). However, you extract public key from private key file:

ssh-keygen -y -f  myid.key > id_rsa.pub

GnuPG to OpenSSH

The best way is to use openpgp2ssh tool distributed in with monkeyshpere project:

  gpg --export-options export-reset-subkey-passwd,export-minimal,no-export-attributes --export-secret-keys --no-armor 0x01234567! | openpgp2ssh 01234567 > id_rsa

Notice 0x01234567 must be a RSA key (or subkey).

You can now extract ssh public key using:

ssh-keygen -y -f id_rsa > id_rsa.pub

GnuPG to OpenSSL

We already saw all steps. Extract key as for ssh:

  gpg --export-options export-reset-subkey-passwd,export-minimal,no-export-attributes --export-secret-keys --no-armor 0x01234567! | openpgp2ssh 01234567 > myid.key

You can create a certification request:

openssl req -new -key myid.key -out myid.csr

You can create a sef-signed certificate:

openssl x509 -req -days 3650 -in myid.csr -signkey myid.key -out myid.crt

GnuPG S/MIME to OpenSSL

Gpgsm utility can exports keys and certificate in PCSC12:

 gpgsm -o  secret-gpg-key.p12 --export-secret-key-p12 0xXXXXXXXX

You have to extract Key and Certificates separatly:

openssl pkcs12 -in secret-gpg-key.p12 -nocerts -out gpg-key.pem
openssl pkcs12 -in secret-gpg-key.p12 -nokeys -out gpg-certs.pem

You can now use it in OpenSSL.

You can also do similar thing with GnuPG public keys. There will be only certificates output.

OpenSSL to GnuPG S/MIME

Invert process:

 openssl pkcs12 -export -in gpg-certs.pem -inkey gpg-key.pem -out gpg-key.p12
 gpgsm --import gpg-key.p12

GnuPG S/MIME to OpenSSH

Now, chain processes:

  gpgsm -o  secret-gpg-key.p12 --export-secret-key-p12 0xXXXXXXXX
  openssl pkcs12 -in secret-gpg-key.p12 -nocerts -out gpg-key.pem

We need to protect key, else ssh refuse it.

 chmod 600 gpg-key.pem
 cp gpg-key.pem ~/.ssh/id_rsa
 ssh-keygen -y -f gpg-key.pem > ~/.ssh/id_rsa.pub

OpenSSH to GnuPG S/MIME

First we need to create a certificate (self-signed) for our ssh key:

openssl req -new -x509 -key ~/.ssh/id_rsa -out ssh-cert.pem

We can now import it in GnuPG

openssl pkcs12 -export -in ssh-certs.pem -inkey ~/.ssh/id_rsa -out ssh-key.p12
gpgsm --import ssh-key.p12

Notice you cannot import/export DSA ssh keys to/from GnuPG

mardi, février 16 2010

KDE Tip: universal text filter

KDE SC 4.4 has a Plasma widget allowing to pate output of some commands.

Using xclip, I can get content of current clipboard. So it is possible to add a macro to sort current selected text:

 %{exec(bash -c "xclip -o | sort")}

Better, I can ask to user what command he wants to apply:

 %{exec(bash -c "xclip -o | $(kdialog --inputbox 'Command?' 'wc -c')")}

Now, I can filter text in any applications: Firefox, OpenOffice, Kmail....

Only one problem, I can yet assign a shortcut to this action.

mercredi, février 3 2010

Le support d'Android droppé du mainstream

Le noyau a dû supprimer le support d'Androïd du mainstream Greg K.H. annonce que c'est un coup dur pour Linux. Un résume, voici le problème:

Google a publié son patch, sous GPL, et l'a envoyé au mainstream du kernel. Le kernel a donc placé la contribution dans staging/. La contribution aurait du y rester pendant quelques versions avant d'être officiellement supportée. Néanmoins, en l'absence de support de la part de Google, le code à été supprimé et ne passera jamais en stable (c'est ce qui risque aussi d'arriver au driver Hyper-V de Microsoft). Jusque là, rien d'anormal. Cela fait partie du quotidien du développeur kernel de suivre des branches parallèles.

Là où ca se complique, c'est que le patch Android n'inclut pas simplement quelques drivers. Il touche aux mécanismes internes du noyau. Donc, si il n'est pas intégré dans le mainstream, beaucoup d'entreprises ne pourront pas non plus intégrer leur driver développé pour Android (ou bien cela demandera plus de travail).

vendredi, janvier 29 2010

Coroutine en C

J'entends beaucoup parler des coroutines ces derniers temps. On me le présente comme quelque chose de formidable, "des threads coopératives, sans les problèmes de concurrence". Lua semble avoir porté cette mode.

Les coroutines ne sont finalement que des threads non-préemptives. Tous le monde se souvient du formidable scheduler de Windows 3.1.

Je suis tombé sur des articles horribles (disons plutôt incomplets) sur les coroutines en C qui me font pensé qu'on petit rappel des syscall Posix s'impose.

Un petit tour sur la documentation de l'appel système makecontext nous permet de faire des choses assez lisible:

      #include <ucontext.h>
      #include <stdio.h>
      #include <stdlib.h>
      
      static ucontext_t uctx_main, uctx_func1, uctx_func2;
      
      #define handle_error(msg) \
          do { perror(msg); exit(EXIT_FAILURE); } while (0)
       
      static void func1(void)
      {
          printf("func1: started\n");
          printf("func1: swapcontext(&uctx_func1, &uctx_func2)\n");
          if (swapcontext(&uctx_func1, &uctx_func2) == -1)
              handle_error("swapcontext");
          printf("func1: returning\n");
      }
       
      static void func2(void)
      {
          printf("func2: started\n");
          printf("func2: swapcontext(&uctx_func2, &uctx_func1)\n");
          if (swapcontext(&uctx_func2, &uctx_func1) == -1)
              handle_error("swapcontext");
          printf("func2: returning\n");
      }
       
      int main(int argc, char *argv)
      {
          char func1_stack[16384];
          char func2_stack[16384];
          
          if (getcontext(&uctx_func1) == -1)
              handle_error("getcontext");
          uctx_func1.uc_stack.ss_sp = func1_stack;
          uctx_func1.uc_stack.ss_size = sizeof(func1_stack);
          uctx_func1.uc_link = &uctx_main;
          makecontext(&uctx_func1, func1, 0);
         
          if (getcontext(&uctx_func2) == -1)
              handle_error("getcontext");
          uctx_func2.uc_stack.ss_sp = func2_stack;
          uctx_func2.uc_stack.ss_size = sizeof(func2_stack);
          /* Successor context is f1(), unless argc > 1 */
          uctx_func2.uc_link = (argc > 1) ? NULL : &uctx_func1;
          makecontext(&uctx_func2, func2, 0);
         
          printf("main: swapcontext(&uctx_main, &uctx_func2)\n");
          if (swapcontext(&uctx_main, &uctx_func2) == -1)
              handle_error("swapcontext");
          
          printf("main: exiting\n");
          exit(EXIT_SUCCESS);
      }

dimanche, janvier 17 2010

for (;;);

Un de mes stagiaire à été surpris de lire sur la ligne for (;;); dans mon code. Cette ligne de code produit une boucle infinie. C'est quelque chose que l'on ne trouve que lorsqu'on travaille sur des OS. C'est alors la meilleure chose à faire quand plus rien n'est récupérable (un assert coté OS en gros). Cela permet de brancher un debuggeur (software ou hardware) et d'étudier la pile d'appel.

Cette instruction est très utile lorsque vous devez étudier l'exécution d'un morceau de code avec les moyen du bord. C'est le breakpoint du pauvre. C'est simple de la convertir en assembleur (b 0 ou jre 0) ou en opcode. Placez le dans votre code. Dès que le CPU passera dessus, il se stoppera. Incrémentez PC pour continuer.

mercredi, décembre 23 2009

Le support de Hyper V pourrait être droppé

Greg KH, mainteneur des versions stables du noyau, indique que les contributeurs du driver Hyper V ne semble plus répondre. Je rappelle que le driver Hyper V est la première et unique contribution de Microsoft au noyau Linux.

Le driver Hyper V est actuellement en staging. Cela signifie que si les développeurs ne se manifestent pas, il pourrait ne jamais sortir de la branche staging et être supprimé dans la version 2.6.35.

dimanche, décembre 20 2009

Histoire d'un bug

On me demande souvent comment se gère la qualité des releases du noyau Linux. Voici une étude de cas:

Thu, 10 Dec 2009 10:10:41 +0100: Jens Axboe rapporte sur la LKML une régression sur son système contenant un "Nehalem-EX" (le processeur octo-core d'Intel actuellement en développement). Son système ne démarre plus.

Jens entreprend d'effectuer une "bisection". git bisect permet d'automatiser partiellement ou totalement la recherche d'une régression. Pour cela, on présente à git-bisect un espace de révisions à analyser. On sait que la révision la plus ancienne fonctionne et que la plus récente ne fonctionne pas. git-bisect va alors effectuer une recherche par dichotomie sur l'ensemble des patchs. A chaque étape, git-bisect présentera la version du noyau correspondante. Optionnellement, on peut automatiser le test de la régression. Classiquement, dans le cas de Jens, il pourra compiler le noyau, l'installer sur la cible et redémarrer la cible automatiquement. Il devra ensuite indiquer manuellement à git bisect si le noyau démarre ou pas. La recherche dichotomique permet de réduire le nombre de test à log(nb_patchs). Ainsi, il faut 10 test pour rechercher une régression sur plus de 1000 patchs. De plus, git-bisect gèrera automatiquement les cas ou le kernel ne compile pas.

Thu 10 Dec 2009 11:39:45 +0100: Résultats des tests pour Jens. Le coupable est b24c2a925a9837cccf54d50aeac22ba0cbc15455. Jens ajoute que le kernel fonctionne bien si on retire le commit et propose donc de le reverser. Pour faire ce test, Jens à utilisé git revert. git-revert permet retirer un commit de l'historique. Pour cela, il se place juste avant le commit et réapplique l'historique sans le commit fautif. Cette approche permet de supprimer des commit introduits il y a très longtemps.

A l'aide de git show, on peut avoir des information sur le patch problématique. Remontons dans le passé:


Tue 24 Nov 2009 02:48:18 -0800: Yinghai Lu a écrit le patch b24c2a925a9837cccf54d50aeac22ba0cbc15455. Ce patch est intégré dans le repository de l'architecture x86, maintenu par Ingo Molnar.

Thu, 3 Dec 2009 22:02:46 +0100: Nous sommes dans la fenêtre de merge pour la version 2.6.33. Cela signifie que Linus Torvald permet aux contributeurs (plus particulièrement aux mainteneurs des sous-systèmes) d'intégrer des patchs dans la future version stable du noyau. Ingo Molnar envoie un mail sur la Linux Kernel Mailing List demandant à Linus "to pull" la version de son sous-systeme qu'il a préparé pour la version 2.6.33.

Tue, 8 Dec 2009 13:27:33 -0800: Dans le commit e33c01972239fee4696679ae5f7d1f340f424999, Linus Torvalds "pull" la branche x86-mm-for-linus du repository de l'architecture x86.

Revenons à notre bug.


Thu, 10 Dec 2009 17:06:40 +0100: Réaction d'Ingo, le maintener du sous-système concerné: On peut reverter le commit de la branche stable du kernel. Cela signifie que le patch sera surement corrigé et soumit plus tard (2.6.34, par exemple).

Thu, 10 Dec 2009 09:26:45 -0800: Réaction de Yinghai, le commiter. D'après les traces, il voit d'où vient le problème, même si c'est un peu cryptique: "mptable mpc is [12 - f011]. what a BIOS !".

Thu, 10 Dec 2009 10:41:42 -0800: Réaction de Roland Dreier. Il est en relation directe avec les développeur du BIOS en question. Il demande quelques détails.

Thu, 10 Dec 2009 10:42:00 -0800: Yinghai propose un patch, sans succès.

Thu, 10 Dec 2009 13:07:22 -0800: Yinghai fait une seconde tentative.

Fri, 11 Dec 2009 09:19:02 +0100: Réponse de Jens sur le patch de Yinghai: Ca marche.

Fri, 11 Dec 2009 09:32:07 +0100: Remerciement de Ingo Molnar. Le patch sera bientôt intégré au repository de Linus. 74h après le pull, 24h après l'alerte, le problème est réglé.

En parallèle, Roland gère le problème avec le équipe de développement du Bios.

jeudi, novembre 19 2009

Innovations de Windows 7

Voici un billet intéressant sur les "optimisations" innovantes de Windows 7

Je vous en retranscrit une partie:

Microsoft a remarqué [1] que 15% des plantages sont dû à de la mémoire désallouée trop tôt. Pour "régler" le problème, Windows identifie les applications ayant planté dans le passé et ne désalloue pas la mémoire instantanément comme cela devrait être le cas.

Microsoft montre une fois de plus sa capacité a masquer les problèmes. Ce type de solution est a peu près équivalent à donner un coup de peinture sur un mur délabré avant de vendre l'appartement.

Notes

[1] Comme quoi, les rapports de bug de Dr. Watson ne sont pas inutiles

lundi, juin 15 2009

Ajout du support 2.6.28 sur EB8541

Untitled post of 2009-09-20T10:35:53ZLa société Odyssée Système m'a demandé de porter le noyau 2.6.28 sur la carte EB8541, à base de PowerPC 8541 éditée par la société Kontron. Il y a pas mal de travail en perspective:
  • Ajout de la gestion d'un FPGA spécifique intégrant:
    • Gestionnaire d'interruption,
    • Watchdog
    • Quelques gpio
    • Bus i2c
    • Description de la carte accessible par le bus i2c
  • Ajout de la gestion d'un bootloader encore non supporté par le noyau: NetBootLoader
  • 4 ports ethernet avec le support de MDIO (2x100Mbps + 2x1Gbps)
  • Gestion d'une mémoire Flash
  • Ajout de la gestion d'un second bus i2c et sur celui-ci:
    • une DRAM
    • une sonde de température
    • un RTC
  • Gestion d'un bus PCI
  • 6 ports RS232
  • Gestion d'une interface IDE (lecteur de cartes compact flash)

lundi, mai 25 2009

Utilisation d'apt-get dans un environnement multi-architecture

Je recherchais un outil capable de facilement récupérer des paquets (binaires ou sources) Debian provenant de dépôts multiples (architectures ou distributions). Il me semblait qu'il n'y avait rien capable de me satisfaire aujourd'hui. Puis, je me suis rappelé de la puissance des fichiers de configuration d'apt. Finalement, apt répond parfaitement à mes besoins.

Il est possible de spécifier des options de configuration sur la ligne de commande. Il suffit de modifier Dir pour que apt utilise un autre répertoire comme racine. L'option Dir::State::status est particulière car c'est un chemin absolu. Nous devons la modifier aussi:

apt-get -o Dir=/tmp/woody-ppc -o Dir::State::status=/tmp/woody-ppc/dpkg_lib/status update

Vu que je ne souhaite pas avoir une arborescence complète, j'ai aussi modifier les autres chemins afin d'avoir une arborescence moins profonde:

apt-get -o Dir=/tmp/woody-ppc -o Dir::State::status=/tmp/woody-ppc/dpkg-lib/status Dir::Etc=etc -o Dir::State=apt-lib -o Dir::Cache=apt-cache update

Apt ne fonctionnera pas si les répertoires n'existent pas:

mkdir -p /tmp/woody-ppc/etc
mkdir -p /tmp/woody-ppc/apt_lib/lists/partial
mkdir -p /tmp/woody-ppc/apt_cache/archives/partial
mkdir -p /tmp/woody-ppc/dpkg_lib
touch /tmp/woody-ppc/dpkg_lib/status

Et bien entendu, il nous faut un fichier /tmp/woody-ppc/etc/sources.list valable:

cat << EOF > /tmp/woody-ppc/etc/sources.list
deb http://archive.debian.org/debian/ woody contrib main non-free
deb http://archive.debian.org/debian/ woody contrib main non-free
EOF

Enfin, l'option APT::Architecture nous permet d'obtenir les paquets d'une autre architecture:

apt-get -o Dir=/tmp/woody-ppc -o Dir::State::status=/tmp/woody-ppc/dpkg_lib/status Dir::Etc=etc -o Dir::State=apt_lib -o Dir::Cache=apt_cache -o APT::Architecture=ppc update

J'ai créé un fichier de configuration pour abréger cette ligne. Il me suffit maintenant de faire:

apt-get -c woody-ppc.conf update

Pour résumer, pour gérer un nouveau repository, je fais:

mkdir -p /tmp/woody-ppc/etc
mkdir -p /tmp/woody-ppc/apt-lib/lists/partial
mkdir -p /tmp/woody-ppc/apt-cache/archives/partial
mkdir -p /tmp/woody-ppc/dpkg-lib
touch /tmp/woody-ppc/dpkg-lib/status
cat << EOF > woody-ppc.conf
APT::Architecture "ppc"; 
Dir "/tmp/woody-ppc/";
Dir::Etc "etc/";
Dir::State "apt_lib/";
Dir::Cache "apt_cache/";
# We need absolute path there
Dir::State::status "/tmp/woody-ppc/dpkg_lib/status";
EOF
cat << EOF > /tmp/woody-ppc/etc/sources.list
deb http://archive.debian.org/debian/ woody contrib main non-free
deb http://archive.debian.org/debian/ woody contrib main non-free
EOF

puis,

# Vérifier la configuration
apt-config -c woody-ppc.conf dump
# Mettre à jour la liste de paquets
apt-get -c woody-ppc.conf update
# Quelle version de bash y avait-il en woody?
apt-cache -c woody-ppc.conf show bash
# Recupération d'une binaire de bash pour ppc
apt-get -c woody-ppc.conf install --download-only bash
apt-get -c woody-ppc.conf install --print-uris bash
# Bon départ pour porter le bash de woody sur une autre distribution
apt-get -c woody-ppc.conf source bash

lundi, mai 18 2009

Le téléphone portable comme machine de bureau

AdamW décrit sur son blog un nouveau périphérique pouvant s'apparenter à une carte graphique (et son écran) sur USB. C'est le chainon manquant que l'on attendait. Il y avait les claviers USB, les périphériques de stockage USB, les ports ethernet sur USB, les cartes son sur USB, il ne manquait que la carte vidéo. Avec la puissance des système embarqués qui ne cessent de grimper, bientôt, je pourrais brancher toute la tripaille de périphériques USB sur mon téléphone portable et m'en servir de machine de bureau.

samedi, mai 16 2009

Packager son noyau

Lorsque l'on touche au noyau, on se trouve rapidement confronté au problème de la distribution du noyau et de ses modules additionnels.

Je propose d'expliquer comment j'ai empaqueté le noyau 2.6.28.9 pour la société Substantiel. Il s'agit d'un cas complet avec des patch et des modules externes.

Lire la suite...

samedi, avril 18 2009

Non aux drivers binaires

Je commence à véritablement détester les drivers propriétaires. Il y a toujours les arguments classiques: "C'est pas libre", "L'équipe kernel ne vous apportera aucune aide si vous avez un kernel "tainted"", etc ...

De mon point de vue, c'est surtout une catastrophe pour porter ces drivers d'une version à l'autre du noyau. Pas la peine de demander de l'aide à l'entreprise originaire du driver. Réponse classique: "On ne supporte que la version 2.6.4/gcc2.95 du noyau" [1]. Pire, parfois, vous n'avez qu'un .ko. Dans ce cas, il n'est mais pas envisageable de choisir un autre compilateur ou une autre version du kernel (ni certaines options de compilation). Evidement, rapidement, vous vous retrouvez sur votre système avec un driver qui ne fonctionne que en 2.6.8 et un autre que en 2.6.30. Il faut bien en porter un des deux. C'est généralement là que les choses se gâtent. On se rend compte que les auteurs ont gardé le code fermé, non pas pour préserver un soi-disant secret de fabrication, mais pour éviter qu'on les prennent pour des codeurs du dimanche [2]. Bref, porter un driver ça n'est pas forcément évident. Si il est mal codé, c'est pire: on risque de faire apparaitre des bugs "latents". Et si il vous n'avez ni les sources, ni les spécifications du matériel, ça devient un véritable casse-tête de comprendre les problèmes.



Par conséquent, pour avoir retarder le développement de certains de mes projets, je délationne : Fglrx, Nvidia (bien que le suivis du mainstream soit suffisament proche pour qu'il y ait peu de problèmes), DVS (fabriquant de cartes d'acquisition vidéo), Intel Poulsbo (Libre, mais personne n'est capable de comprendre ce qu'il fait), TrueFFS (Disk On Chip), etc...

Notes

[1] Oui, bien souvent les versions sont hors d'age

[2] Je suis sûr que parfois, ce sont les stagiaires qui développent les drivers

mercredi, mars 18 2009

EmDebian

Je me dis toujours qu'il faudrait un système de paquet pour les systèmes embarqués. Builtroot est trop monolithique et reste une suite de binaires. Il y a bien le système OpenEmbedded avec ipkg, mais il reste très monolithique dans sa manière de gérer les sources. Une Debian cross-compilée (avec scratchbox par exemple) donne un excellent système, mais même une installation minimale utilise plusieurs dizaines de mégas.

Pour bien faire, il faudrait partir d'une Debian. Le plus important serait de supprimer les dépendances avec perl et ne laisser que busybox comme interpréteur. Il faudrait avoir la possibilité d'utiliser µlibc. Lorsque l'on (corss-)compile, les paquets -dev, -doc, -dbg doivent être produit pour l'architecture hôte. Il faudrait aussi que le répertoire /use/share/doc soit supprimé. Et enfin, il faudrait pouvoir désinstaller apt/dpkg lors de la mise en production du système.

J'en rêvais, emDebian l'a fait. L'uniformité et la QA de Debian appliqué à l'embarqué... Formidable!

Bref, un projet à suivre de près.

vendredi, mars 13 2009

Add quick calculator to zsh

How to add this kind of behavior to zsh:

 $ = 2 +4
 2 + 4 = 6

First, we need a command to do calculus. Personnaly, I love qalc command, so I use it as calculator. Nevertheless, it is not a standard command, so it is usefull to have a fallback. Zsh arithmetic expansion is great, we could use it:

function myCalculator() {
  echo $(($*))
}

Now, we need to add an alias to = command. But, alias doesn't accept syntax alias ==myCalculator. So we have to edit manualy aliases has table:

 $ # Be sure zsh/parameter module is loaded
 $ zmodload zsh/parameter
 $ aliases[=]=myCalculator

To use it, don't forget you need to type a space between = and your expression

Currently, I havn't find any solution for bash

dimanche, décembre 30 2007

XDMCP couplé à un VPN

J'ai lu récemment cet article sur eyeOS. Ca me donne une impression de déjà vu. Vous ne souvenez pas de ce bon vieux serveur X distant? Je pense que l'on sous-estime sa puissance. Je vous rappelle ses avantages:

  • pas de récriture des applications
  • simplicité de mise en oeuvre du serveur
  • technologie éprouvée
  • portable sous Windows, Mac, Linux, BSD, SGI, etc... (Je rappelle les problèmes de portabilité entre les différentes machines virtuelles (autrefois, on avait des navigateurs) auxquels est confronté eyeOS)
  • nécessite seulement un client léger
  • parfaitement adapté aux environnement réseaux complexes

Lire la suite...

mardi, août 22 2006

Tricky shell

Je viens de m'apercevoir que la syntaxe suivante fonctionnait parfaitement en shell :

true && foo() { echo ok; } || foo() { echo ko; }

Je ne sais pas si je dois trouver ça beau ou pas. Ca a un arrière goût de fonctionnel, mais pas assez pour que ça soit utilisable.

lundi, août 7 2006

Nom de domaine en UTF8

Une expérience intéressante de jd. Néanmoins, je ne suis pas d'accord avec les résultats de son expérience. Tout d'abord, http://www.domainsite.com[1] est compatible IDN. Ensuite, la compatibilité IDN se fait au niveau client et non au niveau des serveurs (cela poserait trop de problème d'encodage)[2]. Il suffit d'enregistrer un nom directement en Punycode pour que cela fonctionne avec n'importe quel domain register.

PS pour Julien: Un cercle surscrit (tel que Å) s'appelle un "rond en chef"

Notes

[1] Un petit whois sur ®.com (Notez au passage que la commande whois supporte bien l'IDN) permet de voir que domainsite.com est le domain register

[2] On remarque au passage que Mozilla gère bien l'IDN, mais pas Konqueror

- page 1 de 2