Emile “iMil” Heitor ’s home

Pour notre anniversaire de mariage, madame m’a offert un joujou dont je lui cause depuis un moment sans parvenir à me décider à l’acheter, le Samsung NC10. Ce netbook, je l’avais repéré à cause de son clavier qui, contrairement aux autres claviers de netbooks, est simplement parfait. Pas de disposition pourrie des touches de fonction, une touche “Enter” digne de ce nom, une frappe sublime et des touches assez grandes pour ne pas chopper des crampes.

Après avoir consciencieusement refusé les conditions d’utilisation de l’”os” moisi livré par defaut et préparé ma lettre de demande de remboursement de la license de cette vermine qui polluait la machine, je me lançais dans l’installation d’une Debian Lenny sur la première partie du disque de 160Go, la seconde étant evidemment dédiée à un NetBSD 5.0.

L’installation via une clé USB fut une banale formalité, et 15 minutes plus tard, le NC10 bootait sur un kernel 2.6.26.

Et là, vous vous attendez à 10 pages de fixes et autres bidouilles pour faire fonctionner les divers periphériques de la bête. Eh bah non. Ok, j’ai du me fendre d’un module-assistant install madwifi pour des raisons evidentes, mais mis à part cela, _tout_ fonctionne out-of-the-box.

Cerise sur le gateau, Xen, qui lorsque je bootais mon X31 sur un hyperviseur/noyau-xen faisait s’emballer la température de la machine, ne provoque pratiquement aucune surchauffe (1 à 2 degrés de plus que sur un noyau classique).

Il est tout à fait regrettable que cette merveille ne se vende pas par defaut avec un OS convenable, car rien n’aurait rebuté le GENS, pas même la caméra integrée qui semble parfaitement fonctionner.

Cet après midi, j’ai eu une mauvaise surprise. Je fus en effet étonné de constater qu’en compilant pkgin sous GNU/Linux, les appels du type :

snprintf(a, size, "unechaine/%s", a);

tronquaient a avec uniquement unechaine.

Evidemment, mon premier reflexe fut de blâmer GNU/Linux puisque ce code passait sans aucun soucis sur NetBSD, DragonFly BSD et même Solaris. Et pourtant. C’est gl qui m’informa que ce document issu de l’ISO et l’IEC explique clairement que le fait d’appeler snprintf() de la sorte rendait le résultat “imprévisible”. Dont acte.

Ainsi, j’ai imaginé la parade suivante :

Faire renvoyer le resultat malloc‘é du format string

char *
safe_snprintf(int size, const char *fmt, ...)
{
    char *p;
    va_list ap;

    XMALLOC(p, size * sizeof(char));
    va_start(ap, fmt);
    (void) vsnprintf(p, size, fmt, ap);
    va_end(ap);

    return p;
}

Puis simuler le précédent appel à snprintf via un define qui s’occuppera de libérer la destination et la faire pointer vers la chaine allouée précédemment renvoyée par safe_printf().

#define XSNPRINTF(dst, size, fmt...)            \
    do {                                        \
        char *pdst;                             \
        pdst = safe_snprintf(size, fmt);        \
        XFREE(dst);                             \
        dst = pdst;                             \
} while (/* CONSTCOND */ 0)

Je teste ce workaround en ce moment, et le résultat semble probant.

<spoil>

imil@temple:~/src/pkgin$ ./pkgin -v
pkgin 0.2.1 for SunOS-5.11 i386

imil@temple:~/src/pkgin$ ./pkgin ls|wc -l
      43

</spoil>

Et une de plus.

Oui je sais, je parle que de ça. Mais c’est comme ça, je suis un obsessionnel. Pkgin, vous l’avez peut-être vu sur GCU, a fait son entrée dans pkgsrc-wip. Depuis mon dernier post, beaucoup de fixes sont venus corriger des problèmes avérés ou potentiels, en majeure partie grace à mes testeurs chevronnés. Je pense que la version de ce soir, 20090517, marque une nouvelle étape dans l’évolution de mon apt wanabee, je commence enfin à m’attaquer à des aspects d’ordre “usability”, comme par exemple le fait de ne pas recharger la base si le mtime du pkg_summary(5) distant n’a pas changé, et m’assurer que l’outil est réellement utilisable sur des machines vierges.

Si tout se passe comme je le souhaite, je pense faire entrer pkgin dans pkgsrc d’ici une semaine ou deux, le temps de vérifier qu’aucun cas particulier qui viendrait tout foutre par terre ne se présente. Moyennant quoi, j’espère qu’il sera au moins disponible dans pkgsrc-2009Q2, et si assez de développeurs soutiennent le projet, peut être meme mieux que ça.

Aujourd’hui, mon stress-o-meter a été mis à rude épreuve. Après plusieurs semaines de développement, j’ai fini par soumettre le résultat de mes travaux aux autres développeurs NetBSD. Et le résultat fut probant. J’ai fatalement reçu pas mal de feedback, d’idées et des pistes pour le futur de mon apt-like, mais tous étaient unanimes sur un point: pkg_dry, comme nom, ça craint.

Je n’étais moi-même pas bien satisfait de ce nom que j’avais trouvé un peu par dépit, constatant que l’idée initiale, pkg_get était déja prise.

Alors on a brainstormé avec les copains de NetBSDfr, avec en arrière plan l’idée que je voulais rendre hommage à l’un des carburateurs de ce projet, ma boisson de prédilection. Et finalement, stacktic lâche :

17:22 < stacktic|sh> pkgin histoire de garder le gin

Et ce fût plié. Tout le monde a adoré, ça dit tout, ça se dit bien, et c’est mignon. Ainsi soit-il ! “pkg_dry est mort, VIVE pkgin !”

Il parait qu’y'a un tool là, pour NetBSD, qui essaierait de mimer apt(8). Le gars il doute de rien, il a même pondu une page expliquant le projet. Je suis dubitatif.

Bon, blague à part, je pense que pkg_dry commence à être utilisable. Il reste encore quelques petites choses à ajouter, probablement un tas de vilains bugs et des ajustements divers, mais dans les grandes lignes, on y est.

Si donc vous vous sentez l’âme d’un testeur et que vous avez sous la main une machine / VM sous NetBSD ou DragonFlyBSD (voir ici pour ce dernier), je serais ravi de recevoir vos feedbacks.