Posté par Alain-Pierre Perrin () le 21/05/2008 à 09:23. (lien). Évalué à 5.

"Deux jours à tuer", de Jean Becker avec Albert Dupontel, Marie-Josée Croze, Pierre Vaneck... Magistral, sobre, juste. Je suis allé le voir hier soir... Une sacrée claque. Je vous le recommande.

[ Répondre ]

Posté par Alain-Pierre Perrin () le 08/02/2008 à 13:43. (lien). Évalué à 4.

J'utilise également rdiff-backup et j'en suis très satisfait. En gros, il réplique dans un répertoire distant une arborescence locale et ajoute, dans ce répertoire distant, un répertoire spécial contenant tous les "incréments" permettant de "remonter le temps". En gros, si on veut récupérer la dernière sauvegarde, un bête scp suffit. Si on veut la version n-2, n-3, et au dela, on utilise rdiff-backup pour rapatrier les données.

Exemple : restaurer la version d'il y a 10 jours d'un fichier :

rdiff-backup --restore-as-of 10D toto@serveurdistant::/home/Backup/toto/fichier /home/toto/fichier

Autres avantages de rdiff-backup :
* Il ne stocke que les morceaux de fichiers qui changent. Un fichier de 600Mo qui change de 100ko tous les jours, c'est, sur le serveur de sauvegarde, 600Mo + n*100ko et non n*600Mo.
* Il sauvegarde tous les attributs étendus et ACLs des fichiers sources même si le filesystem de destination ne les gère pas nativement. Les liens "en dur" sont également préservés.

Un conseil pour finir : toujours soigneusement avoir la même version de rdiff-backup côté serveur et côté client... En pratique, j'ai constaté qu'une upgrade côté client non faite également côté serveur faisait que les sauvegardes plantaient (le client et le serveur se "prenant les pieds dans le tapis" pendant leur dialogue).

Tous les matins, avant de partir au boulot, je vérifie le log de ma sauvegarde nocturne pour vérifier qu'elle s'est déroulée sans encombre. Ben oui... parce que c'est bien beau d'automatiser tout ça, mais après, faut quand même garder un oeil pour voir si ça marche bien.

[ Répondre ]

Posté par Alain-Pierre Perrin () le 19/12/2007 à 07:58. (lien). Évalué à 1.

Quelqu'un a évoqué SystemRescueCD. On retrouve "Darik's boot and nuke" dessus. Au prompt boot: il suffit de taper dban et de se laisser guider. On peut aussi télécharger l'utilitaire tout seul sous forme d'une toute petite image (disquette ou CD) bootable sur la page http://dban.sourceforge.net/. Certes ça n'est pas la méthode la plus rapide (surtout pour de gros disques) ni la plus "défoulante" mais cet utilitaire a le mérite de la simplicité.

Bon, bien sûr, si le disque à effacer n'est plus accessible logiciellement et qu'il émet le "clac-clac-clac" tant redouté, on n'a plus qu'à le détruire physiquement. Du reste, le simple fait d'ouvrir un disque sans même toucher à ses plateaux doit déjà compromettre son intégrité. En effet, à moins de faire ça en salle blanche, la moindre poussière sur les plateaux ne sera pas appréciée par les têtes de lecture. Ça me fait d'ailleurs bien rire quand on voit des pubs montrant des disques ouverts. Dans cet état, comme dirait l'autre, ils vont marcher beaucoup moins bien, forcément.

Sur une note plus sérieuse, je suis un jour tombé, sur le net, sur un excellent article qui remettait en question la possibilité de récupérer des données sur un disque après ne serait-ce qu'une seule passe d'écriture de données aléatoires. Cet article expliquait en substance qu'un dd if=/dev/urandom of=/dev/hda était bien suffisant et que les utilitaires sophistiqués qui font 36 passes à écrire des motifs à chaque fois différents étaient en fait bien superflus.

[ Répondre ]

Posté par Alain-Pierre Perrin () le 17/08/2007 à 14:40. (lien). Évalué à 6.

Je me désole de ce que les efforts semblent se diluer. Xen a apporté sa pierre dans le domaine de la paravirtualisation... mais côté émulation de machines virtuelles complètes pour faire tourner l'OS sans modification, c'est la solution d'un qemu adapté qui a été retenue. Pour Virtualbox, ici encore on part sur une base de qemu qu'on peaufine et qu'on dote d'une belle interface graphique. Quant à KVM, qui, en soi, n'est qu'une extension du noyau, le seul émulateur s'appuyant dessus à ce jour c'est ? Un qemu patché... alors bien sûr le qemu "initial" profite petit à petit des évolutions de ses dérivés... mais trop lentement à mon goût. C'est sur lui qu'il faudrait travailler directement, plutôt que sur ses dérivés intégrés...

[ Répondre ]

Posté par Alain-Pierre Perrin () le 07/05/2007 à 05:09. (lien). Évalué à 10.

Je ne poste jamais dans les journaux politiques qui fleurissent à tout va sur ce site mais là... tout de même...

Cette citation, je suis désolé de le dire, ne s'applique en rien à notre pays ! Les électeurs s'y sont mobilisés comme rarement. J'aimerais bien que réponde à l'auteur de ce journal des personnes vivant dans un pays sous régime dictatorial. Leurs propos seraient plus cinglants et plus forts que les miens, sur le thème "Tu (toi, l'auteur de ce journal) te fous de nous ou quoi ???"

Bon, ok, j'ai nourri le troll. Mea culpa. 'me suis fait avoir.

[ Répondre ]

Posté par Alain-Pierre Perrin () le 06/02/2007 à 13:06. (lien). Évalué à 4.

Xen utilise un dérivé de qemu et ne permet actuellement l'exécution d'OS non modifiés que sur des architectures qui gèrent la virtualisation au niveau matériel. Je rêve d'un "Xen 4.0" intégrant un qemu 0.9 voire 1.0 et permettant enfin de faire tourner des OS non modifiés sans recourir nécessairement à des CPU super récents. Pour du recyclage de serveurs récents "mais pas assez pour gérer la virtualisation en hard", ce serait top...

[ Répondre ]

Posté par Alain-Pierre Perrin () le 16/01/2007 à 11:50. (lien). Évalué à 3.

Xen utilise actuellement, dès lors qu'il s'agit de faire tourner des OS non modifiés, une version de qemu adaptée pour utiliser les instructions d'aide à la virtualisation fournies par les derniers Intel (technologie "Intel VT") et AMD (technologie "pacifica"). J'ai testé cela sur du Xeon 5500 et les performances sont très correctes... Je regrette seulement que tous les OS un peu vieux ou exotiques ne puissent aussi bien s'installer et fonctionner que du Windows ou de l'Unix récent. Je pense notamment à du (pas taper) SCO Openserver.

À présent, j'aimerais bien que le qemu joint à Xen soit accompagné d'un module (GPL) de type kqemu afin que la virtualisation d'OS non modifiés soit également possible sur du matériel un peu plus ancien. Cela permettrait de recycler astucieusement des gros serveurs qui, bien que récents, ne disposent pas dans leurs processeurs d'instructions d'aide à la virtualisation... Je me demande d'ailleurs comment il se fait que Fabrice Bellard (qui dispose d'un potentiel de développement proprement ahurissant pour le commun des mortels) n'ait pas encore été embauché par une grosse boîte pour bosser la-dessus à plein temps. :)

Pour finir, y en a-t-il parmi vous utilisateurs de Xen qui auraient essayé les diverses "surcouches graphiques d'administration" actuellement existantes ? Pour "vendre" Xen c'est plus sympathique, surtout pour les collègues de culture Windowsienne qui sont allergiques à la console... Il faut bien avouer que les produits commerciaux concurrents (je pense notamment à VMware et ses déclinaisons "serveur") sont drôlement léchés, de ce côté...

[ Répondre ]

Posté par Alain-Pierre Perrin () le 25/12/2006 à 09:36. (lien). Évalué à 3.

Oui je veux bien payer la course, pas de problème.

Ce que je voulais dire, ironiquement, était que "les carottes n'étaient pas cuites" et qu'ils pouvaient se débrouiller pour venir quand même... ou alors c'est qu'ils n'avaient même pas de quoi payer la course ou que tous les taxis étaient indisponibles et que personne ne pouvait faire le trajet avec sa voiture dans un sens ou l'autre.

Sinon, dans l'absolu, c'est vrai que dans ces cas là je suis d'abord en colère contre le gréviste plutôt que contre son "maichant patron". :)

[ Répondre ]

Posté par Alain-Pierre Perrin () le 24/12/2006 à 19:32. (lien). Évalué à 5.

Les taxis.

[ Répondre ]

Posté par Alain-Pierre Perrin () le 21/12/2006 à 23:30. (lien). Évalué à 7.

C'est bien de ne pas utiliser un compte administrateur sur la machine qu'on utilise. C'est vrai... Si une application malveillante tourne sous notre compte, elle ne pourra pas (ou très peu) corrompre le fonctionnement de l'OS. Sur une machine hébergeant une foule d'utilisateurs, c'est évidemment d'autant plus important. Ce réflexe est un héritage de la culture Unix=OS multiutilisateurs. Ben oui mais quand on s'éloigne des mainframes pour se concentrer sur les petits PC des particuliers, ne pas être root ne signifie plus forcément "pas ou peu de dégats".

Sur une machine utilisée (au quotidien) par une seule personne, tout se relativise. Bien sûr, le vilain virus ne plantera pas le système. En revanche, tournant avec mon id, il pourra quand même... mine de rien... dégager tous mes fichiers (et là si j'ai pas de sauvegarde, ben je pleure). Une fois toutes mes données foutues, ça me fera une sacrée belle jambe de dire "Ouais mais mon OS il tourne encore".

A celui qui a commenté "Oh le beau FUD", je répondrai qu'il serait déraisonnable de considérer que nous autres linuxiens et autres "utilisateurs éclairés" sommes obligatoirement à l'abri de telles bestioles. Le système parfaitement sécurisé n'existe pas, à fortiori quand des personnes s'ingénient à créer des programmes sensés exploiter les "trous" dans la sécurité.

Tout cela nous amène à poser la question (hautement philosophique :) de savoir s'il vaut mieux passer du temps à créer des protections pour contrer les bêtises des "distraits" ou des novices ou bien s'il ne vaudrait mieux pas se concentrer sur l'é-du-ca-tion des utilisateurs... Vaste débat.

[ Répondre ]

Posté par Alain-Pierre Perrin () le 07/11/2006 à 10:25. (lien). Évalué à 1.

MacOS utilise le concept d'appdir qui veut que toute l'application soit contenue dans un répertoire et ce répertoire soit déplaçable à loisir sans empêcher l'application de fonctionner. Avec Gobolinux, une application est toute entière contenue dans un répertoire (exécutables, libs, docs). Supprimer le répertoire supprime bien toute trace de l'application. En revanche, déplacer ledit répertoire est susceptible de poser quelques problèmes...

En fait la force de Gobolinux est d'utiliser une arborescence repensée mais de continuer à offrir "en sous main" l'arborescence Unix standard (cachée par l'entremise d'un module (nommé "gobohide") du noyau), via une astucieuse série de liens logiques. Du coup, les applications comportant trop de références "en dur" ou "non relatives" à des fichiers systèmes ne sont pas dépaysées et n'ont pas besoin d'être retouchées dans leurs sources.

Ce que le site gobolinux ne m'a pas dit (mais peut-être n'ai-je pas tout bien lu), c'est comment les scripts de gestion/maintenance de tous ces liens logiques fonctionnent pour réparer ou supprimer les liens cassés et comment les dépendances sont gérées lors de l'installation d'une nouvelle application. En outre, est-il possible pour un utilisateur lambda d'installer une appli. dans le dossier /Programs ? Je n'ai pas encore de réponse...

En tout cas cette distribution a le grand mérite de remettre en question pas mal de choses, de manière intelligente et argumentée, en cherchant les bons compromis. Je crois que le mieux est d'aller lire la FAQ du site, de télécharger le LiveCD et d'essayer tout ça...

[ Répondre ]

Posté par Alain-Pierre Perrin () le 13/10/2006 à 05:06. (lien). Évalué à 2.

Curieusement personne n'évoque jamais qiv. Il est ultra-léger, sans fioritures inutiles... Dans le même genre, j'ai dernièrement vu fbida, qui lui fonctionne en mode "frame buffer", c'est à dire en mode console, sans recourir à X.

[ Répondre ]

Posté par Alain-Pierre Perrin () le 27/09/2006 à 10:05. (lien). Évalué à 1.

Les tests que j'ai pu faire jusqu'à présent montrent que le format 7zip est meilleur que rzip (lui même meilleur que bzip2 (lui même bien meilleur que gzip))... mais nom de nom : c'est looooong. Ah ça on sent que l'algo fignole sa compression. :)

Celui qui veut recompresser ses fichiers .gz, .bz2 ou .rz devrait se faire un petit script et le lancer avant d'aller au lit... C'est pas pour les pressés, p7zip. :)

[ Répondre ]

Posté par Alain-Pierre Perrin () le 26/09/2006 à 20:53. (lien). Évalué à 4.

Le format d'rzip est lui aussi adapté aux très gros fichiers car il va chercher les redondances très très loin. Son défaut en revanche est de ne pas gérer l'entrée standard et donc de ne pas être intégrable dans une chaîne de commandes. Quoi qu'il en soit il est meilleur que bzip2 pour les gros fichiers. Je vais tout de même faire un petit comparatif avec 7zip. Sait-on jamais... :)

[ Répondre ]

Posté par Alain-Pierre Perrin () le 15/09/2006 à 04:47. (lien). Évalué à 10.

Cet adjectif est tellement, tellement, tellllllllement galvaudé par le jargon publicitaire. C'en est fatigant. Inventez... je ne sais pas moi... un système de suppression de la gravité qu'on pourrait mettre en oeuvre dans tous les moyens de transports, une nouvelle méthode de production d'énergie énonomique et non polluante et *là*, on pourra enfin parler de quelque chose de vraiment *révolutionnaire*.

[ Répondre ]

Posté par Alain-Pierre Perrin () le 11/09/2006 à 12:40. (lien). Évalué à 6.

Fidèle à la tradition Unix consistant à ne pas réinventer la roue et faire cohabiter n petites appli. qui ne font qu'une seule chose (mais qui la font bien), mythtv sait dialoguer avec lirc, qui est un "écouteur générique de télécommandes".

En gros, on commence par installer lirc. On lui apprend à reconnaître notre télécommande en associant des noms "en clair" (PAUSE, STOP, LECTURE, etc...) aux codes envoyés par notre zapette. On peut alors lancer le process serveur lircd qui se met en écoute des émissions infrarouge par l'intermédiaire d'un capteur branché sur un port série, parallèle ou USB. Dans un second temps, dans notre profil utilisateur on décrit, dans un fichier utilisé par le process "lirc", une liste d'équivalences entre une touche de télécommande reçue et un évènement dans une application qui sait causer avec lirc.

Exemple : Que se passe-t-il quand j'appuie sur "pause" ? Détaillons la chaîne...
- Le process lircd (lancé au lancement du système) reçoit le code infrarouge de ma télécommande et traduit ça par "PAUSE".
- Le process lirc (lancé dans ma session utilisateur) reçoit de lircd "PAUSE". Dans sa configuration, il existe une équivalence "PAUSE" dans l'environnement "mythtv" = mettre le visionnage en pause". Il envoie donc un signal à mythtv.
- mythtv, qui est en écoute de ce que peut signaler le process "lirc" reçoit l'évènement "mettre le visionnage en pause" et agit en conséquence.

Certes ce côté modulaire fait qu'il faut paramétrer chaque maillon de la chaîne. Cela dit, une fois que, pour commencer, la télécommande est convenablement reconnue et que d'autre part on a paramétré une application pour utiliser lirc, on peut, par copier-coller, définir des configurations pour d'autres applications.

Au nombre des applications les plus connues qui savent "causer avec lirc" (et donc être pilotées par infrarouge), on trouve Mythtv d'une part mais aussi xmms et mplayer... Il est même possible, pour celles qui ne savent pas converser avec le process lirc, de "ruser" en définissant des séquences de touches à envoyer quand lirc reçoit un évènement émis par lircd.

[ Répondre ]

Posté par Alain-Pierre Perrin () le 11/09/2006 à 12:21. (lien). Évalué à 7.

Mythtv est très évolué mais souffre encore aujourd'hui de la tenace étiquette "pas de la tarte à paramétrer". Bien sûr, le fait que des packages binaires soient apparus pour nos distributions favorites a grandement facilité le boulot. Il est vrai aussi que des liveCD tels que KnoppMyth permettent sans trop d'effort d'évaluer que ce sait faire mythtv avant de l'installer "en dur"... mais (et là je m'adresse aux pros de Mythtv) existe-t-il d'autres projets ayant pour but de simplifier/automatiser son paramétrage initial ? On a beau être rompu à la ligne de commande et adooooorer potasser de longues docs, une application qu'on peux lancer directement après son installation, c'est pas mal.

[ Répondre ]

Posté par Alain-Pierre Perrin () le 03/09/2006 à 21:11. (lien). Évalué à 5.

Je m'étonne que personne encore n'ait mentionné nedit. Il est particulièrement léger et véloce. Son interface est sobre, voire austère (c'est du motif, donc indépendant des toolkits que sont GTK et QT) mais il intègre une foule de fonctionnalités. En outre il est porté sur de nombreux Unix. <mavie>En fait c'est par lui que j'ai découvert la puissance des expressions régulières, à l'époque où les autres "petits éditeurs de texte" (j'exclus les "frères ennemis" de la liste) n'implémentaient qu'un rechercher/remplacer basique.</mavie>

Kate, sous KDE, me semble assez prometteur lui aussi. Outre un look un peu plus "léché" (de par son intégration à KDE), il intègre comme nedit tout ce dont un développeur peut vouloir. Il gère notamment les "kioslaves" (les facilités de Konqueror à se connecter à des systèmes de fichiers distants (par ssh, ftp, samba, etc)) et un drag'n drop d'un fichier d'une fenêtre Konqueror affichant une arborescence accédée à distance par ssh ouvre le fichier sans souci. La sauvegarde est bien entendu gérée avec la même transparence. A l'usage c'est très pratique. Je suppose que ce système doit permettre de travailler sur un gestionnaire de versions quelconque (CVS ou autre) de manière également plus aisée et transparente... Je parlais plus haut de la recherche et du remplacement par le truchement d'expressions régulières. Pour ceux qui hésiteraient à s'attaquer à la syntaxe de ces dernières, Kate inclut un petit outil graphique pour "visuellement" construire une expression, pas à pas. Bien fichu.

Bref, pour ce qui me concerne, c'est nedit quand j'ai une édition rapide à faire. Quand je veux travailler sur du code, de plus en plus j'utilise kate pour son confort d'utilisation.

[ Répondre ]

Posté par Alain-Pierre Perrin () le 03/09/2006 à 20:52. (lien). Évalué à 3.

L'avantage de ScITE est qu'il est assez facilement regroupable dans un seul et même répertoire. Sous Windows, ça le rend particulièrement intéressant. Sa config étant uniquement dans des fichiers textes (rien dans la base de registres), on peut l'"installer" d'une machine à l'autre avec tout son paramétrage, par simple copie... et pour des besoins d'édition très ponctuels il existe même une version qui tient en un exécutable solitaire incluant un paramétrage par défaut ma foi convenable.

[ Répondre ]

Posté par Alain-Pierre Perrin () le 28/08/2006 à 09:08. (lien). Évalué à 1.

Ne pouvant corriger mon entrée précédente, je me réponds à moi-même pour une micro-correction. Vous aurez de vous-même corrigé la phrase :

"...que des données générées par un système A puissent être convenablement par un système B."

en

"...que des données générées par un système A puissent être convenablement exploitées par un système B."

[ Répondre ]