Vous trouverez sur cette page un petit simulateur en javascript qui permet de calculer les résultats du second tour en fonction de votre estimation personnelle des participations et reports de voix des candidats du premier tour.
Archives de la catégorie ‘Intérêts divers’
Voilà, c’est sûr, mon vieux ZX-81 ne fonctionne plus…
ZX-81, imprimante et extension 16ko
J’ai voulu en avoir le cœur net, et j’ai tenté de le remettre en marche pour fêter le trentième anniversaire de son acquisition. En vain, il n’y a aucun signe de fonctionnement – bien que l’alimentation soit toujours correcte. En outre le câble plat qui reliait le clavier à la carte à microprocesseur à mal supporté l’usure du temps et s’est cassé net en plusieurs endroits ce qui me paraît difficilement réparable.
Tant pis, il ne se rallumera pas, mais cela ne m’empêchera aucunement de le conserver sur une étagère avec un certain nombre d’autres rescapés de la même époque. J’éprouve une affection particulière pour ce petit ordinateur sur lequel j’ai découvert la programmation en basic et en assembleur.
Pour ceux qui n’ont pas connu le ZX-81 (TS-1000 dans sa version américaine), il faut savoir que c’était le premier ordinateur vraiment grand public, et que les choix économiques rigoureux faits par son concepteur (Sir Clive Sinclair) en rendait l’utilisation assez… particulière. Tout d’abord le gros défaut de cet ordinateur était le manque de fiabilité des connexions sur le bus d’extension (où l’on branchait entre autre le bloc d’extension mémoire) ce qui provoquait des coupures inopinées d’alimentation en cas de mouvement de l’unité centrale, avec toutes les pertes de données que l’on peut imaginer.
Le système reposait sur un processeur huit bits, le Zilog Z-80-A, cadencé à 3.5 MHz, et sur une mémoire RAM de 1 kilo-octet extensible à 16ko, voire 64ko pour les plus fortunés. Et aussi étonnant que cela puisse paraître, nous disposions de nombreux programmes (jeux, utilitaires, programmation, etc.) qui tenaient dans ces dimensions réduites de mémoire. La sauvegarde de la mémoire se faisait sur des cassettes audios par l’intermédiaire d’un magnétophone externe, le chargement d’un programme de quelques kilo-octets pouvant durer plusieurs longues minutes avec une fiabilité plutôt aléatoire.
Dès la mise sous tension, l’utilisateur disposait d’un prompt permettant de saisir des lignes de codes dans une version simplifiée du langage BASIC. Deux instructions, PEEK et POKE, permettaient de lire ou d’écrire des octets directement dans la mémoire et la fonction USR autorisait l’exécution d’un code à une adresse quelconque, généralement après y avoir inséré du code assembleur personnel.
3D Monster Maze
Les capacités vidéo étaient très limitées : 32 x 24 caractères monochromes. 16 caractères spéciaux étaitent constitués d’une matrice de quatre petits carrés, qui pouvaient se combiner pour offrir des graphiques avec la résolution de 64×48 pixels ! L’ingéniosité des programmeurs permettait de disposer quand même de jeux graphiques, comme le fameux « 3D Monster Maze » dans lequel le joueur se trouvait plongé dans un labyrinthe chassé par un tyrannosaure. J’ai pu en prendre la copie d’écran ci-contre sur un émulateur en-ligne. Mes jeux favoris étaient également « Space Invaders » et « Flight Simulation » (copie d’écran ci-dessous) ainsi que tous les programmes que l’on trouvait sous forme de listing dans les revues de l’époque.
Flight Simulation
J’ai appris sur cet ordinateur la programmation en BASIC, en écrivant notamment quelques outils de calculs pour l’astronomie (à usage personnel), et la programmation assembleur pour des jeux – inspirés de Pac-man ou Centipède – qui n’ont à ma connaissance jamais été diffusés en dehors d’un cercle très restreint d’amis possesseurs de la même machine.
Il faut souligner la pédagogie du manuel (en français) du ZX-81 qui permettait de découvrir progressivement les principes de la programmation, et la bonne qualité des livres – disponibles en français également – pour approfondir l’étude de l’assembleur par exemple.
Même s’il ne redémarre pas, ce petit ordinateur continuera à trôner sur une étagère de mon bureau, attirant les regards surpris, amusés et parfois nostalgiques des visiteurs qui l’aperçoivent.
J’ai eu la chance d’assister vendredi dernier à un excellent spectacle musical nommé « La face cachée de la Lune » que je conseille sans la moindre hésitation à tous les fans des Pink Floyd si d’autres dates sont programmées.
L’équipe de Thierry Balasse reconstruit en direct devant nous l’album mythique des Floyd, dans ses moindres détails, y compris (et surtout) les bruitages, les vocalises, et les parties instrumentales aux synthétiseurs analogiques. Il ne s’agit pas d’un concert habituel où l’on joue une version de l’album arrangée pour la scène, mais bien de la reconstruction de la version studio.
Pour être bien clair : aucune bande pré-enregistrée n’est utilisée, tout est joué ou créé sur place. Les voix et les pas de course de « On the Run » , les carillons de « Time » , ou la caisse enregistreuse de « Money » sont sur scène. Pas moins de dix musiciens sont présents pour la re-création de cet album, avec des moments de grâce absolue (comme la partition vocale de « The Great Gig in the Sky » !). Des petites parenthèses en provenance de l’album « Meddle » sont adroitement intercalées (« One of these Days » , « Echoes » …). J’ai été particulièrement sensible à la présence des synthétiseurs analogiques d’époque (Minimoog, VCS3, etc.).
Un spectacle qui, je l’espère, se poursuivra avec succès.
Kernel panic – not syncing: No init found.
J’indiquais dans un article précédent (à la fin de « Construire son système personnel pour Pandaboard – 1« ) que ce message était pour moi une excellente nouvelle, car il indiquait que le noyau avait correctement démarré, identifié les périphériques et trouvé son système de fichiers initial. Une excellente nouvelle lorsqu’on construit un système embarqué. Pas lorsque le message se présente sur mon poste de travail principal ! Voici donc une mésaventure qui m’est arrivé cette semaine.
Circonstances
Après une longue journée de développement logiciel, de rédaction d’un chapitre de mon prochain livre, et de configuration d’un système live Gnu/Linux dont je vous reparlerai prochainement, j’allais lancer la sauvegarde quotidienne de mon répertoire personnel sur le serveur lorsqu’un popup attire mon regard, indiquant que des mises à jour étaient disponibles pour quelques dizaines de packages de la Fedora 15 que j’utilise. Je valide alors naturellement le téléchargement et la mise à jour de ces packages, tout en fermant mes dernières applications. Le système de mise à jour m’a demandé la confirmation pour l’installation d’une nouvelle version du kernel Linux, ce que j’ai accepté.
Puis, j’ai quitté l’écran des yeux pendant quelques instants, pour préparer la synchronisation de mon répertoire personnel sur un ordinateur portable. J’ignore quelle était exactement la tâche de mise à jour en cours lorsque j’ai aperçu l’écran de mon poste de travail s’éteindre. Ce dernier allait apparemment redémarrer tout seul, ce qui m’a légèrement surpris, mais la mise à jour du noyau nécessite évidemment un reboot du système.
Sauf que ce reboot s’est mal terminé ! Le message classique du « kernel panic » indiquant qu’il ne pouvait charger le programme init est apparu. J’ai donc essayé successivement un reboot à froid – ordinateur totalement éteint puis rallumé – puis un redémarrage sur les versions précédentes du noyau (dans le menu de choix de Grub), rien n’y fit le système restait incapable de trouver son programme init. J’ai tenté de redémarrer en mode mono-utilisateur en ajoutant (avec le menu Grub) sur la ligne de commande du kernel l’option « single« .
Le fichier /sbin/init (qui correspond sur les Fedora 15 à un lien symbolique vers /bin/systemd) aurait pu être endommagé, aussi ai-je tenté sans grande conviction d’ajouter l’option init=/bin/sh sur la ligne de démarrage du kernel. En vain.
Diagnostic
Arrivé à ce point, une touche d’angoisse commençait à poindre. Ce poste de travail ne comporte que deux partitions : la première contient le système Linux Fedora proprement dit et la seconde mon répertoire de travail personnel. Je ne pouvais m’empêcher d’imaginer la sauvegarde pénible du contenu de cette partition à l’aide d’un outil de récupération plus ou moins convivial, suivi d’une réinstallation du système.
En analysant la situation, on peut quand même déduire quelques éléments :
- Le bootloader fonctionne correctement et charge le noyau, ce n’est donc pas un problème de disque ou de partition.
- Le noyau démarre a priori normalement et ne panique qu’au moment de lancer le processus init. Le comportement est le même pour les deux versions précécentes du kernel, ce n’est donc pas lié au noyau Linux lui-même.
- Le processus
/sbin/initne démarre pas, non plus que/bin/sh. Il y a très peu de chances que ces deux exécutables aient été endommagés simultanément. Dans le doute je pourrais toujours essayer ultérieurement avec d’autres commandes comme/bin/ls, etc.
Mes soupçons se portèrent alors sur les bibliothèques. Il suffit que la bibliothèque C par exemple soit endommagée pour qu’aucun exécutable ne fonctionnent hormis ceux dont l’édition des liens a été réalisée de manière statique, mais il n’y en a pratiquement plus dans les distributions classiques actuelles. Pour vérifier cela, il faut déjà accéder à la partition système incriminée.
J’ai démarré sur un CD-Rom Fedora 15 live que j’avais gravé il y a quelques temps pour mettre mon système à jour. Je conseille vivement de toujours disposer d’un CD live relativement récent pour ce genre de situation où la tension nerveuse aidant on n’a aucune envie de devoir télécharger et graver une nouvelle image dans l’urgence.
Une fois le système live en fonctionnement, j’ai monté manuellement les deux partitions de mon disque dur sur deux répertoires temporaires. J’ai examiné rapidement le contenu des répertoires /bin, /sbin, /etc, et /lib avec la commande « ls -lrt » qui présente le contenu des répertoires classé par ordre chronologique. Les derniers fichiers listés sont les plus récemment modifiés. L’erreur est apparue rapidement :
# cd /mnt/sda1/lib # ls -lrt [...] -rwxr-xr-x. 1 root root 0 3 juin 16:52 libgcc_s-4.6.0-20110603.so.1 lrwxrwxrwx. 1 root root 28 4 août 05:25 libgcc_s.so.1 -> libgcc_s-4.6.0-20110603.so.1 # ls -l libgcc* -rwxr-xr-x. 1 root root 115328 30 mai 20:48 libgcc_s-4.6.0-20110530.so.1 -rwxr-xr-x. 1 root root 0 3 juin 16:52 libgcc_s-4.6.0-20110603.so.1 lrwxrwxrwx. 1 root root 28 4 août 05:25 libgcc_s.so.1 -> libgcc_s-4.6.0-20110603.so.1 #
Visiblement la mise à jour de la bibiothèque libgcc ayant échoué, le fichier visé par le lien symbolique est vide. Ceci explique que le démarrage des exécutables soit impossible.
Récupération
On peut déjà corriger partiellement le problème en redirigeant le lien symbolique vers la version précédente.
# ln -sf libgcc_s-4.6.0-20110530.so.1 libgcc_s.so.1
Puis, pour vérifier le fonctionnement, je tentai un déplacement chroot vers ma partition système.
# chroot /mnt/sda1 #
Ceci fonctionna et les utilitaires classique (ls, df, rpm) marchèrent correctement.
Toutefois, le problème étant survenu lors d’une mise à jour du système, la base de données des packages devait probablement être en mauvais état. J’ai dû exécuter successivement (de mémoire, je n’ai pas pu faire de capture d’écran).
# yum check
qui m’indiqua qu’il restait une transaction de mise à jour non terminée. Je la complétai donc avec
# yum-complete-transaction
toutefois, des erreurs persistaient et je dus effectuer les opérations suivantes (chacune m’indiquant la suivante à lancer)
# package-cleanup --problems # package-cleanup --dupes # rpm -Va --nofiles --nodigest
Enfin, certains conflits persistant entre packages de même nom et de numéros de version différents, je dus terminer le nettoyage avec une série de :
# yum erase nom-du-package
Après retrait du CD live et redémarrage, tout fonctionna à nouveau comme avant. Ouf !
Conclusion
Cette petite mésaventure, heureusement sans conséquences autres qu’un peu de temps perdu, m’a permis de tirer quelques remarques que je présenterai sous forme de conseils :
- Ne jamais paniquer, ne jamais se précipiter et surtout ne jamais tenter de réinstaller quoique ce soit avant d’avoir tout essayé. Il est extrèmement rare qu’un incident logiciel (je ne parle pas de la mort physique d’un disque) bloque irrémédiablement un système Linux. Tant qu’il n’y a pas de fumée ou d’odeur bizarre, il y a un bon espoir de pouvoir remettre tout le système en marche comme précédemment.
- Disposer d’un CD-Rom bootable live de préférence de la même distribution (même version majeure) que votre poste de travail. Il n’est pas très agréable de devoir courir après un CD vierge et un poste libre pour télécharger et graver la version de sauvetage alors que votre poste de travail est apparemment moribond.
- Éviter les mises à jour du système en étant connecté en mode graphique avec plusieurs applications en cours d’utilisation. Et éviter avant-tout de faire une mise à jour du système si les données utilisateur qu’il contient n’ont pas été entièrement sauvegardées. C’est une règle simple, mais rarement respectée d’autant que bon nombre d’environnements de travail nous présentent une fenêtre « 50 mises à jour disponibles » alors que nous venons de commencer notre travail depuis quelques dizaines de minutes…
En respectant ces conseils, et avec un peu de patience et de réflexion, on doit pouvoir redémarrer un système Linux quelque soit le plantage survenu.
Voici quelques jours que j’ai installé la distribution Fedora 15 sur mon poste de travail principal. L’évolution la plus visible de cette version Fedora est l’adoption de Gnome 3.0. Hors cette interface graphique, il existe d’autres nouveautés et évolutions dans cette nouvelle version de la Fedora, comme la généralisation de systemd pour la configuration du boot, ou le nommage persistant des interfaces ethernet : les interfaces se trouvant sur la carte mère sont nommées em1, em2, etc (em pour embedded) et les interfaces supplémentaires s’appellent désormais pci<numero slot>#<numero port>.
Gnome 3.0 modifie les concepts habituels d’interface utilisateur graphique. Fini les menus Applications, Raccourcis et Système en haut de l’écran et les sous-menus Accessoires, Bureautique, etc. Disparus la barre des tâches et le changeur de bureau au bas de l’écran.
Plutôt que de proposer à l’utilisateur un choix d’applications à lancer, l’interface vise à se concentrer plutôt sur les activités de l’utilisateur. Souhaite-t-il rédiger un courrier ? un document ? naviguer sur le web ? lire ses mails ? En fait on s’intéresse, du moins me semble-t-il, plus à la tâche à réaliser qu’à l’outil à employer. Cette perspective se rapproche de celle des tablettes et smartphones : l’environnement Gnome-Shell est visiblement prêt pour une interface tactile à la manière des tablettes.
Plus précisément, l’interaction avec le Gnome-Shell est sollicitée par le survol à la souris de l’angle supérieur gauche de l’écran. Apparaissent alors deux docks regroupant, pour celui de gauche les applications favorites, et pour celui de droite les bureaux virtuels actifs. Le nombre de ces bureaux virtuels augmente ou diminue dynamiquement. En outre deux boutons « Fenêtres » et « Applications » apparaissent dans la partie supérieure de l’écran : le premier présente une mosaïque des fenêtres ouvertes (rafraichies en permanence) et le second propose toutes les applications disponibles avec une présentation qui rappelle furieusement les smartphones actuels.
Certains éléments de configuration de Gnome 3.0 ne sont pas évidents. J’ai listé ci-dessous quelques-unes de solutions que j’ai trouvées.
Configuration de l’aspect des fenêtres
Gnome 3.0 n’offre pas beaucoup d’éléments visuels directement configurables par l’utilisateur. Même l’aspect des fenêtres (barre de titres, boutons système, etc.) n’est pas modifiable avec les outils de configuration de base. Il faut commencer par installer un utilitaire supplémentaire : Gnome-Tweak-Tool.
[~]# yum install -y gnome-tweak-tool
On peut choisir dans son menu Shell les boutons système à afficher (maximiser, minimiser, fermer) et dans le menu Windows le thème à appliquer aux fenêtres. Toutefois celui-ci n’est pris en compte qu’à la reconnexion de l’utilisateur. Voici donc un aperçu des thèmes disponibles avec l’installation standard (cliquez sur l’image ci-dessous pour voir les styles de fenêtres).
Taille du texte sous les icônes des applications
Je trouve que le texte indiquant les noms des applications sous leurs icônes est trop petit. Il nécessite un effort visuel. Pour corriger ceci, il faut éditer le fichier /usr/share/gnome-shell/theme/gnome-shell.css et chercher l’emplacement des lignes suivantes :
.app-well-app > .overview-icon,
.remove-favorite > .overview-icon,
.search-result-content > .overview-icon {
border-radius: 4px;
padding: 3px;
border: 1px rgba(0,0,0,0);
font-size: 7.5pt;
color: white;
transition-duration: 100;
text-align: center;
}
et remplacer la valeur font-size par celle de votre choix (9.5 pour ma part).
Lancer une application à la connexion
J’avais l’habitude, sous Gnome 2 de voir l’utilitaire GkrellM démarrer automatiquement et se coller le long du bord droit de mon écran. Pour réaliser la même chose avec Gnome 3, c’est un peu plus compliqué que précédemment. Il faut aller dans le répertoire ~/.config/autostart/ et y créer un fichier correspondant à l’application à lancer avec le suffixe .desktop. Ensuite on remplira les champs suivants :
[autostart]$ cd ~/.config/autostart/ [autostart]$ cat gkrellm.desktop [Desktop Entry] Type=Application Name=GkrellM Exec=/usr/bin/gkrellm Hidden=false X-GNOME-Autostart-enabled=true Comment=Gnome Krell Monitor [autostart]$
Des extensions pour configurer le Gnome-Shell
Il existe déjà quelques extensions pour le Gnome Shell, entre autres celles du projet Gnome Shell frippery qui modifie sensiblement certains éléments, en reprenant des comportements plus proches de Gnome 2. J’ai installé l’ensemble de l’archive (à l’aide du RPM fourni), puis conservé seulement les extensions : Bottom Panel et Panel Favorites. Pour supprimer les autres après installation du RPM, il suffit de supprimer (ou déplacer) les répertoires correspondants de /usr/share/gnome-shell/extensions/.
Conclusion
En conclusion, après quelques jours d’utilisation, cette nouvelle interface est plutôt agréable, et offre un renouveau notable dans le monde des interfaces-utilisateur graphiques. Toutefois, il y a un gros défaut pour Gnome-Shell : une fuite mémoire qui le rend inutilisable au bout de deux ou trois jours sans déconnexions. Il s’agit d’un bug connu, qui je l’espère pourra être corrigé rapidement. Le paliatif proposé par le site web recensant les bugs Fedora (se déconnecter et se reconnecter quotidiennement) est efficace mais pas très satisfaisant si des applications au long cours doivent s’exécuter.