Je déplorais récemment la lenteur (au moins, la lenteur ressentie) de Linux. On m’a donné, et j’ai découvert, quelques pistes d’amélioration :
des alternatives à
initsont en développement : pinit (mais les commits sur le CVS semblent vieux de 3 ans) et InitNG (qui semble beaucoup plus actif). Elles devraient permettre le lancement en parallèle de plusieurs services, d’où, on peut l’espérer, un démarrage bien plus rapide ;Frederico Mena-Quintero du projet Gnome travaille à des améliorations de la rapidité de Gnome. Les résultats sont déjà visibles dans Gnome 2.14, et d’après les benchmarks, certains composants ont été grandement améliorés ! Voir aussi les transparents « Making Gnome Fast ».
J’ai fait quelques essais avec une station Sun Ultra 10 que j’ai récupérée. Comme ce n’est pas forcément évident lorsqu’on arrive du monde PC, voici quelques petites notes qui permettent de commencer…
Sur une Sun, le programme de démarrage s’appelle OpenBoot. Il énumère et teste le matériel, et passe la main au chargeur de l’OS. Au démarrage, OpenBoot ne se manifeste généralement pas. Il faut faire Stop-A pour rentrer dans OpenBoot, et pouvoir, en particulier, choisir le boot device et régler des paramètres de configuration de base. Attention, ça peut se transformer en Stop-Q, dans des conditions bizarres, sur clavier AZERTY.
Si la Sun met un temps fou à démarrer, avec les LED du clavier qui clignotent lentement, il est possible qu’elle soit configurée pour faire un long test matériel (appelé POST). Sous OpenBoot, vérifier alors la valeur de test-switch? (printenv test-switch?), et la modifier éventuellement avec setenv.
Par défaut, la Sun utilise une résolution d’écran élevée pour sa console (adaptée aux beaux moniteurs de chez Sun !). Pour une utilisation sur un petit écran LCD : setenv output-device screen:r1024x768x60. Sous Linux, on peut de même ajouter un paramètre video=atyfb:1024x768@60 lors du chargement du noyau.
Quelques liens :
Depuis quelques jours, j’essayais d’installer Subversion sur ma Gentoo : à chaque fois, après compilation, même erreur, un peu obscure, disant que l’installation ne peut se poursuivre à cause d’insecure RUNPATH’s. Le bug #81745 suit le problème, et après un peu de recherches, il semble qu’une partie des packages Gentoo soit actuellement cassés (ininstallables), sans que les mainteneurs aient le temps de résoudre le problème…
Le bug #124962 essaie d’apporter une réponse au problème, sous la forme d’un patch de /usr/lib/portage/bin/ebuild.sh, mais malheureusement, je n’ai pas réussi à l’appliquer, même après avoir réémergé Portage ! J’ai donc dû patcher à la main ce fichier, vers la ligne 1057 :
- #die "Insecure binaries detected"
+ echo "Auto fixing rpaths for ${f}"
+ TMPDIR={PORTAGE_BUILDDIR} scanelf -BXr ${f} -o /dev/null
C’est un peu sauvage, mais ça a le mérite de marcher…
J'ai récemment prétendu que le boot était considérablement plus lent sous Linux (Ubuntu) que sous Windows, du moins sur l'ordinateur où j'ai fait ces tests. Voici les mesures précises. Bien entendu, ces résultats sont à prendre avec des pincettes, car il faudrait effectuer les tests sur plusieurs ordinateurs, mais ça fait quand-même un peu peur...
Au quotidien, je n’utilise plus que pdflatex, et plus jamais latex. Ainsi, je peux inclure mes figures vectorielles sous forme de fichiers PDF, et les bitmaps directement en PNG ou JPEG.
Cependant, il arrive que des conférences exigent un fichier PostScript[1] : il faut donc dans ce cas impérativement utiliser latex, et importer toutes les images en EPS. La conversion des bitmaps en EPS se fait généralement bien avec ImageMagick, mais le problème, c’est que les fichiers EPS ont une fâcheuse tendance à l’embonpoint. Exemple : soit une image PNG de 670 x 304, 256 couleurs. Le fichier PNG fait 8,2 Ko. Après une bête conversion, on se retrouve avec un fichier EPS de 1,2 Mo ! J’ai trouvé un moyen de forcer la compression des images EPS :
convert **-compress zip** image.png **eps2:**image.eps
De cette façon, la taille de mon image est passé à 252 Ko. C’est toujours 30 fois plus que l’original en PNG, mais on limite les dégâts…
Notes
[1] quand ce n’est pas un fichier Word…
Après avoir mis à jour son fichier sieve-default, il ne faut pas oublier de l’envoyer sur le serveur car Sieve ne parcourt pas les répertoires utilisateurs… La commande : sieveshell -u username server, puis put, list, help, etc.
Ça y est, je suis touché… Pour éviter à Bruce les affres de la déréliction, il faudrait que j’énonce six vérités farfelues sur moi… Alors allons-y :
- vérité n°1 : moi non plus je n’ai pas d’idée précise sur le mot farfelu, et ce ne sont pas les explications de Florent qui m’ont beaucoup éclairé ! Farfelu, ça ressemble à chevelu, non ? Comment ? Rien à voir ? Ah bon… Tant pis alors…
- verité n°2 : j’aime le fromage ! Bleu, vert, blanc, chèvre, vache, brebis… Je n’admets aucune limite.
- verité n°3 : je hais par-dessus tout la malhonnêteté intellectuelle. Mes bêtes noires sont l’intox, le FUD, la propagande, le prêt-à-penser, les dogmes, la désinformation… Si je devais choisir une devise, je choisirais peut-être « sapere aude », « ose te servir de ton propre entendement » [1].
- vérité n°4 : gna ! gnî ! (qui a dit GNU ?) Dans ma tendre enfance, j’étais un spécialiste du [ɲ], que je rajoutais un peu partout. Exemple : la Garogne !
- vérité n°5 : j’ai un problème avec le temps. Il y a tant de choses qui m’intéressent que je n’arrive jamais à faire tout ce que j’aurais envie de faire ! Que la vie est dure… À quand la journée de 36 heures ?
- vérité n°6 : je suis un trainspotter. Je suis capable de rester planqué pendant plusieurs dizaines de minutes au détour d’une voie pour attendre le passage d’un improbable convoi et le mitrailler avec mon Minolta.
- vérité n°7 : ah ben c’est fini ! ouf ! :-)
Par principe, je n’aime pas les chaînes car elles sont en général basées sur de l’intox (cf. vérité n°3), mais celle-ci est bien gentillette, donc je tente de transmettre la chose à Laurent. Je ne pense pas connaître personnellement d’autres blogueurs, donc ça s’arrêtera là.
Notes
[1] Kant: Qu’est-ce que les Lumieres? (30 septembre 1784)
Voici un problème de Java qui a l’air insoluble : je veux faire une méthode qui me renvoie un tableau d’un type générique T, sachant que pour générer ledit tableau, j’utilise temporairement un ArrayList<T>. Problème : comment récupérer de façon type safe le tableau à partir de l’ArrayList<T>, sachant que je dispose d’une méthode toArray() qui renvoie un Object[] et toArray(T[]) qui renvoie un T[] ?
Première idée
public static <T> T[] truc(T a) {
List<T> liste = new ArrayList<T>();
liste.add(a);
return liste.toArray(new T[] {});
}
Ça ne compile pas, parce que Java ne peut pas instancier de tableaux du type paramètre T (en raison de l’erasure, i.e. la suppression des types paramètres lors de la compilation, la JVM ne saurait tout simplement pas quelle classe instancier[1]).
Deuxième idée
Étant incapable d’instancier un T[], je décide donc de me rabattre sur la méthode qui me renvoie un Object[], et caster vers T[] :
...
return (T[]) liste.toArray();
...
Sauf que le compilateur Java génère un warning « unchecked cast ». Ça compile et ça marche, mais on perd la type safety (qui n’est garantie que la compilation du projet entier ne génère aucun « unchecked cast »).
Des idées meilleures qu’un @SuppressWarnings("unchecked") ?
Notes
[1] Java interdit aussi l’instanciation de types génériques du genre List<String>[], mais c’est un autre problème, lié à la covariance des tableaux… Les deux problèmes sont très bien expliqués chez IBM.
Environ trois ans après avoir décidé de refaire mon site web, et notamment sa charte graphique, je me suis enfin décidé à le faire !
La structure du site n’a pas beaucoup changé, mais une nouvelle charte a été appliquée à la plupart des pages. Certaines des pages disposent de leur propre feuille de style : elles n’ont pas été basculées à la nouvelle charte. Elles le seront peut-être par la suite, mais pas systématiquement. D’ores et déjà, le site devrait déjà être beaucoup plus homogène.
J’ai commencé un thème Dotclear pour habiller le blog aux nouvelles couleurs du site web. Il n’est pas finalisé : il y a encore des imperfections d’affichage, mais je pense que l’essentiel y est.
J’ai testé la charte graphique avec Firefox, Opera, IE6 et IE7 beta : ça a l’air de fonctionner à peu près partout, mais tout commentaire est le bienvenu. Au passage, j’ai encore trouvé des bugs d’affichage vraiment très louches dans IE7 : le fond un div s’est mis à baver en-dessous, jusqu’à ce que je mette une largeur fixe pour le div… Allez comprendre…
Grâce à de nombreux retours, j’ai pu corriger des bugs dans Server Spy et proposer une version 0.1.1. Le reviewer du site Firefox Add-ons a été très réactif, mais lorsqu’il s’est agi de propager le nouveau fichier sur le FTP, il y a eu quelques minutes de retard, d’où l’angoisse d’un utilisateur !
Ceci me conduit à un début de liste de « trucs » pour le développement d’extensions à Mozilla:
- le livre « Creating Applications with Mozilla » (O’Reilly) est très bien. Même s’il date un peu (2002), il est en grande partie toujours d’actualité pour Firefox 1.5. Par contre, attention, il y a pas mal de typos (mauvaise capitalisation des noms de fonction notamment), donc il faut faire attention ;
- sur le web, developer.mozilla.org, XUL Planet ;
- l’extension FireBug est très pratique pour détecter les exceptions JavaScript levées par ses extensions ;
- il y a plein de bonnes choses dans l’Extension Developer Extension, notamment le très pratique « reload all chrome ». Ceci dit, cette fonction m’a créé quelques soucis (perte de contexte JavaScript) ;
- lorsqu’on teste une extension, penser à désactiver toutes les autres extensions. J’en étais ainsi venu à croire que Server Spy marchait correctement, alors que ce n’était pas le cas si une extension manquait (je n’ai même pas pu identifier laquelle…)
En parlant de développement, un geek de mes amis a publié des choses intéressantes : solveur de Sudoku en Java, logueur d’URL qui passent sur IRC en Perl.