J'avais promis une réponse à Rémi Grossmann, suite à la publication d'un de ses billets qui m'avait passablement énervé. Il m'aura fallu quelques temps... mais finalement, je tente de passer l'épreuve de la modération, pour publier le premier commentaire sur ce, peut être, futur grand blog politique en Suisse.
Le sens du sacrifice... tout un programme, n'est-ce pas ? Après une énième relecture, je me décide finalement à poster une réponse. Après tout, j'avais dit que je le ferais ;-) . Ça arrive juste un peu plus tard que prévu.
Le premier point abordé, ou plutôt survolé, dans la première partie de ce billet, est bien sur celui qui me dérange le plus, et de très loin. Car après tout, une arme est une arme. J'ai du mal à faire la différence entre un fusil d'assaut et une mine anti-personnelle. Vraiment.
Les deux peuvent tuer, blesser, mutiler, au choix. Le problème de la mine étant qu'elle mutile trop souvent. Donc pour faire semblant de se donner bonne conscience, les "pays qui respectent les droits de l'homme", certaines armes à caractère mutilant ne sont plus produites dans certains pays, selon les termes d'accords dont je ne connais pas le contenu exact. Par exemple, la France, pour ne pas parler que des territoires neutres, ne fabrique plus de mines anti-personnelles. Les guerres doivent être propres pour que TF1 puisse les couvrir pendant le JT de 20h.
Pourtant une arme reste une arme. Là où les fusils et les chars que la Suisse vend vont prendre des vies, les mines les détruiraient. Je ne vois pas en quoi la mort est plus louable. Les deux sont, à mon avis, aussi grave, aussi condamnable. La mort ne fait partie du respect ni de l'homme, ni du citoyen.
Le respect des droits de l'homme passe peut être pour toi par le refus de vendre des armes à des pays en guerre. Pourtant, des nuances existent. Sur les conflits internes, par exemple. Et sur les garantie qu'en acheteur donnera de ne pas revendre le matériel à des nations ou groupuscules aux velléités moins louable que la simple protection du territoire. Tu auras du mal à me faire croire que la Suisse a les moyens de contrôler la destination finale des armements vendus. Notamment parce que des dérives semblent avoir eu lieu par le passé.
Car les armes produites en les contrées helvètes sont, finalement, vendues. Et que rien ne garantit qu'elle ne finiront pas dans les mains de terroristes/rebelles/braqueurs de banques/mafioso. Une arme, ça se vole. Un stock d'arme, ça se détourne.
Effectivement, nous parlons ici d'arguments moraux, là où tu nous opposes clairement des arguments pratiques : l'arrêt de la production d'armes serait catastrophique économiquement. Et pourtant...
Tu parles de dizaines de milliers d'emplois supprimés. Il semblerait (source à vérifier, cependant, l'article où j'ai obtenu le chiffre ne cite pas ses sources) que les opposants à l'arrêt de la vente d'arme à l'étranger, lors de la dernière votation, évaluait le nombre de ces emplois à 10 000. On change d'échelle, déjà. Mais j'admets que 10 000 vies mises à mal de cette façon, ça me trouble.
Cependant... nous parlons bien d'un pays prospère économiquement, n'est-ce pas ? Je tiens à être sûr... La Suisse, à mon avis, a tout à fait les moyens de créer la richesse d'innovation nécessaire au retour de ces 10 000 emplois. Des défis technologiques d'ampleur sont là, et doivent être soutenus. Certains ont même des dimensions morales. D'ailleurs, je pense que la structure étatique de la Suisse, par son découpage en cantons, est adaptée à l'éclosion de startups performantes, grâce à des encadrements ciblés et efficaces.
Tu opposes les objectifs moraux (ou philosophiques, les deux choses sont pourtant différents, mais admettons que je les ai plus ou moins amalgamés ici) et pratiques, économiques. Je soutiens que les défis que posent les réflexions philosophiques ou morales permettent de construire des projets ambitieux, car ils soulèvent des buts autrement plus nobles, autrement plus soutenables que la simple vénalité.
L'économie ne peut pas tout justifier. Sinon, autant vendre ses enfants au marché...
16/07/2010
zypper est surpuissant...
Pour les gens qui ne seraient pas au courant, openSUSE 11.3 est sortie tout récemment. Et contrairement à mes habitudes, je ne l'ai pas installée de suite, ma machine personnelle étant actuellement ma machine de boulot...
Pas grave, me dis-je : j'ai voulu profiter de la bande passante phénoménale de l'école qui m'emploie en ce moment. 2 Go de mise à jour, normalement, fait en une demi-heure... donc début d'installation à 17h. Et hop, zypper dup.
À 17h50, je quitte le bureau... et la mise à jour n'était pas finie (merci latex...). Je dois donc débrancher le câble réseau, en faisant le pari :
"Zypper va y arriver..."
Arrivé chez moi, je sors la machine de sa veille... et plus de clavier. Arrêt brutal de la machine, il me manque à peu près 300 paquets, dans le lot... Donc redémarrage. Je retrouve mon clavier, mais pas d'interface graphique (KDE était pas content... étrange :-p ). Console virtuelle, deuxième zypper dup...
Au fur et à mesure de l'installation, j'ai commencé à retrouver des fonctionnalités. Après installation propre de kdm, j'ai pu accéder à un bureau, puis à firefox. Et à la fin, redémarrage... et tadam, j'y suis. Je roule sur une 11.3 toute fraîche.
Donc dans l'histoire, zypper a réussi à reprendre un upgrade (pas une simple mise à jour, hein, un upgrade) après une mise en veille ratée et un redémarrage.
Chapeau.
Pas grave, me dis-je : j'ai voulu profiter de la bande passante phénoménale de l'école qui m'emploie en ce moment. 2 Go de mise à jour, normalement, fait en une demi-heure... donc début d'installation à 17h. Et hop, zypper dup.
À 17h50, je quitte le bureau... et la mise à jour n'était pas finie (merci latex...). Je dois donc débrancher le câble réseau, en faisant le pari :
"Zypper va y arriver..."
Arrivé chez moi, je sors la machine de sa veille... et plus de clavier. Arrêt brutal de la machine, il me manque à peu près 300 paquets, dans le lot... Donc redémarrage. Je retrouve mon clavier, mais pas d'interface graphique (KDE était pas content... étrange :-p ). Console virtuelle, deuxième zypper dup...
Au fur et à mesure de l'installation, j'ai commencé à retrouver des fonctionnalités. Après installation propre de kdm, j'ai pu accéder à un bureau, puis à firefox. Et à la fin, redémarrage... et tadam, j'y suis. Je roule sur une 11.3 toute fraîche.
Donc dans l'histoire, zypper a réussi à reprendre un upgrade (pas une simple mise à jour, hein, un upgrade) après une mise en veille ratée et un redémarrage.
Chapeau.
08/06/2010
Reverse engineering
Je suis, en ce moment, plongé assez profondément dans l'étude des codes d'un logiciel complexe. L'objectif est d'extraire un bout de librairie pour travailler aussi bien, mais en codant moins. Je vous rassure, c'est un logiciel libre, il s'appelle BEAM. Et c'est pour inclure dans un autre logiciel libre, donc ça va ;-)
Le problème, dans ce petit exercice, c'est la taille des codes... J'ai un peu plus de 1700 classes (sans compter les classes de test, d'ailleurs), au total. Et c'est pas forcément évident de comprendre les liens entre les classes et package. Bref, il me fallait un logiciel de reverse engineering performant, pour pouvoir faire de l'UML vite et gagner du temps.
J'ai cur pouvoir compter sur ArgoUML. Et ben non. face à la taille de la tâche, ce cher logiciel me claquait dans les pattes. Il commençait par passer une bonne demi-heure à mouliner (et pourtant mon dual-core ne fait pas semblant de compter, en général... :-p ), et à la fin, il n'était plus franchement utilisable. Après, c'est peut être de ma faute, mais bon...
Du coup, changement de plan, je cherche un suppléant. Et je tombe sur BOUML. J'étais plutôt sceptique, au début, l'expérience précédente m'avait refroidie. D'autant que le logiciel, écrit en C, s'appuie sur qt3, et que c'est pas forcément très courant sur ma machine. Mais je me dégonfle pas, je le cherche dans mes dépôts. Et je l'installe, ni une ni deux.
Après un peu de prise en main, je trouve une bonne méthode pour faire l'import des classes qui m'intéressent intelligemment. Je commence par spécifier l'ensemble du jdk comme bibliothèque de base. Pas d'objections. Puis j'ajoute les dossiers contenant les sources en omettant juste les classes de test. Toujours pas d'objections. Je lance l'opération... et en cinq minutes c'était fait.
Je me retrouve donc avec un logiciel libre (j'ai du oublier de le dire avant ^_^ ) hyper efficace. Mes classes sont toutes là, liées entre elles et avec les classes du jdk. Les imports sont hyper rapides, et le logiciel sait résoudre les dépendances sur plusieurs niveaux. Tout petit bémol : au-delà d'une centaine de classes affichées simultanémént, il commence à ramer un peu... mais un diagramme de classe avec autant de monde, c'est pas super rationnel :-p
En clair, c'est un très bon logiciel. Pour les gens qui ont besoin de ce genre de choses... il vaut le coup :-)
Le problème, dans ce petit exercice, c'est la taille des codes... J'ai un peu plus de 1700 classes (sans compter les classes de test, d'ailleurs), au total. Et c'est pas forcément évident de comprendre les liens entre les classes et package. Bref, il me fallait un logiciel de reverse engineering performant, pour pouvoir faire de l'UML vite et gagner du temps.
J'ai cur pouvoir compter sur ArgoUML. Et ben non. face à la taille de la tâche, ce cher logiciel me claquait dans les pattes. Il commençait par passer une bonne demi-heure à mouliner (et pourtant mon dual-core ne fait pas semblant de compter, en général... :-p ), et à la fin, il n'était plus franchement utilisable. Après, c'est peut être de ma faute, mais bon...
Du coup, changement de plan, je cherche un suppléant. Et je tombe sur BOUML. J'étais plutôt sceptique, au début, l'expérience précédente m'avait refroidie. D'autant que le logiciel, écrit en C, s'appuie sur qt3, et que c'est pas forcément très courant sur ma machine. Mais je me dégonfle pas, je le cherche dans mes dépôts. Et je l'installe, ni une ni deux.
Après un peu de prise en main, je trouve une bonne méthode pour faire l'import des classes qui m'intéressent intelligemment. Je commence par spécifier l'ensemble du jdk comme bibliothèque de base. Pas d'objections. Puis j'ajoute les dossiers contenant les sources en omettant juste les classes de test. Toujours pas d'objections. Je lance l'opération... et en cinq minutes c'était fait.
Je me retrouve donc avec un logiciel libre (j'ai du oublier de le dire avant ^_^ ) hyper efficace. Mes classes sont toutes là, liées entre elles et avec les classes du jdk. Les imports sont hyper rapides, et le logiciel sait résoudre les dépendances sur plusieurs niveaux. Tout petit bémol : au-delà d'une centaine de classes affichées simultanémént, il commence à ramer un peu... mais un diagramme de classe avec autant de monde, c'est pas super rationnel :-p
En clair, c'est un très bon logiciel. Pour les gens qui ont besoin de ce genre de choses... il vaut le coup :-)
26/05/2010
MPD, MPC, Intel et openSUSE...
Sacré quartet évoqué dans le titre. Petits rappels. Pour les deux premiers, au moins. MPD, pour Music Player Daemon, est comme son nom l'indique une programme tournant en tâche de fond, qui permet d'émettre de la musique vers une sortie choisie. On peut même l'utiliser comme base pour faire de la diffusion par le réseau. Non, ne partez pas, c'est pas le but, ici.
Pour contrôler MPD, on peut utiliser un logiciel adéquat. certains sont graphiques, pas celui que j'utilise. L'objectif estt de libérer de la mémoire, afin d'être vraiment à l'aise en utilisant Eclipse, OpenOffice, Firefox, ArgoUML, Kate, tous avec pleins de trucs d'ouverts... Donc j'économise sur le lecteur audio. Même au niveau de l'interface. Mpc est donc fait pour moi :-).
Je vais d'abord vous montrer comment j'ai fait marcher le machin, chez moi, sur une carte son Intel. J'ai du tatonné un peu, ça m'arrivera pas deux fois ;-) . Et vous l'aurez compris, je vais présenter les manip's sur une openSUSE, avec des opérations tout à fait typiques de cette magnifique (et VERDOYANTE) distribution GNU/Linux. Pour les autres, vous pourrez aussi trouver quelques petites choses utiles à la fin. Peut être.
La partie facile : l'installation des deux logiciels. Un simple
et le tour est joué, zypper est incroyable.
Pour la suite... MPD s'appuie sur une base de données où il garde les infos sur votr base de données. Il va donc falloir qu'il soit capable de trouver le fichier où est la base, et d'écrire dedans. D'ailleurs ce sera pas le seul fichier utile.
Créez un répertoire .mpd dans votre dossier personnel, et ajoutez-y des fichiers nommés
Pour créer un fichire vide, par exemple database, faites
Ajoutez enfin un répertoire nommé playslists. Pour tous ces éléments, une petite modification s'impose encore. Placez vous dans le répertoire .mpd
Nous alons changer les droits sur les fichiers créés avant. mpd sera lancé par l'utilisateur mpd, qui appartient au groupe audio. Donc on modifie les droits d'accès en conséquence :
La suite est un peu sale. L'utilisateur et le groupe doivent avoir accès en lecture et écriture. Donc
Et il faut pouvoir rentrer dans le dossier. Donc
Et on arrête de donner des droits d'accès à tort et à travers (parceque c'est pas optimal. Mais y a mieux, et j'ai pas cherché ;-) )
La chose n'est toujours pas prête. On va devoir modifier le fichier de configurattion de MPD, qui se situe dans /etc. Avec nano pour moi, ce que vous voulez pour vous, mais il faut être root ;-) :
vous allez modifier les valeurs suivantes :
music_directory : l'endroit où est votre musique, sur votre disque.
playlist_directory : Vous devez pointer le répertoire playlist créé précédemment. Donc a priori :
db_file :
log_file :
state_file :
J'ai laissé la variable pid par défaut, à savoir "/var/lib/mpd/mpd.pid", mais j'ai du créer le fichier qui va bien, je crois. dans le doute :
user : laissez "mpd", on a fait les modifs pour ;)
Pour les utilisateurs d'une carte son Intel de type ICH9 (ou plus généralement celle qui utilisent le module snd_hda_intel), la section audio output devra ressembler à ça :
audio_output {
type "alsa"
name "Intel G45 DEVCTG"
# device "hw:0,0" # optional
format "44100:16:2" # optional
mixer_device "default" # optional
mixer_control "Master" # optional
mixer_index "0" # optional
}
Je sais, c'est étrange de virer la section device. Mais chez mois ça marche comme ça :-) .
À ce stade, la chose est prête à être lancée. Dans une console root :
devrait passer sans problème. On crée ensuite la collection :
Enfin, quelques petits trucs. J'aime bien être efficace, donc les deux scripts suivants peuvent être tout à fait pratique :
ce script, que j'ai magnifiquement appelé pause, met en pause la lecture si mpc lit un fichier, et la remet en marche si mpc est en pause.
De même, ce programme (que j'ai nommé random) active ou désactive la lecture aléatoire.
Placez les deux scripts dans /home/votrelogin/bin . et rendez les exécutables avec un chmod u+x, aussi ;-) . L'avantage de les mettre dans ~/bin, c'est que vous pourrez les appeler très vite. Sous KDE, vous pourrez même utiliser le lanceur d'applications. Bref, la vie est belle :)
Enfin, j'ai aussi quelques petits alias (qui ne sont utilisables que depuis une console où vous êtes loggés en votre nom ). À mettre dans .bashrc (qui peut être créé pour l'occasion). :
Une dernière chose pour la route : mpd est un démon, il peut être lanccé automatiquement au démarrage. Pour les gens de chez suse, passez par YaST, trouvez le module qui gère les niveaux d'exécution, passez en mode expert, et cochez les cases 3 et 5 pour mpd. Prudence, cependant, si le démon est arrêté alors qu'une lecture est en cours, elle sera reprise automatiquement au démarrage suivant. Donc pour la discrétion... ;-)
Amusez-vous !
Pour contrôler MPD, on peut utiliser un logiciel adéquat. certains sont graphiques, pas celui que j'utilise. L'objectif estt de libérer de la mémoire, afin d'être vraiment à l'aise en utilisant Eclipse, OpenOffice, Firefox, ArgoUML, Kate, tous avec pleins de trucs d'ouverts... Donc j'économise sur le lecteur audio. Même au niveau de l'interface. Mpc est donc fait pour moi :-).
Je vais d'abord vous montrer comment j'ai fait marcher le machin, chez moi, sur une carte son Intel. J'ai du tatonné un peu, ça m'arrivera pas deux fois ;-) . Et vous l'aurez compris, je vais présenter les manip's sur une openSUSE, avec des opérations tout à fait typiques de cette magnifique (et VERDOYANTE) distribution GNU/Linux. Pour les autres, vous pourrez aussi trouver quelques petites choses utiles à la fin. Peut être.
La partie facile : l'installation des deux logiciels. Un simple
zypper in mpc mpdet le tour est joué, zypper est incroyable.
Pour la suite... MPD s'appuie sur une base de données où il garde les infos sur votr base de données. Il va donc falloir qu'il soit capable de trouver le fichier où est la base, et d'écrire dedans. D'ailleurs ce sera pas le seul fichier utile.
Créez un répertoire .mpd dans votre dossier personnel, et ajoutez-y des fichiers nommés
database errors.log log mpd.log state tag_cachePour créer un fichire vide, par exemple database, faites
touch databaseAjoutez enfin un répertoire nommé playslists. Pour tous ces éléments, une petite modification s'impose encore. Placez vous dans le répertoire .mpd
cd ~/.mpdNous alons changer les droits sur les fichiers créés avant. mpd sera lancé par l'utilisateur mpd, qui appartient au groupe audio. Donc on modifie les droits d'accès en conséquence :
chown mpd:audio *La suite est un peu sale. L'utilisateur et le groupe doivent avoir accès en lecture et écriture. Donc
chmod ug+rw *Et il faut pouvoir rentrer dans le dossier. Donc
chmod a+x playlistEt on arrête de donner des droits d'accès à tort et à travers (parceque c'est pas optimal. Mais y a mieux, et j'ai pas cherché ;-) )
La chose n'est toujours pas prête. On va devoir modifier le fichier de configurattion de MPD, qui se situe dans /etc. Avec nano pour moi, ce que vous voulez pour vous, mais il faut être root ;-) :
nano /etc/mpd.confvous allez modifier les valeurs suivantes :
music_directory : l'endroit où est votre musique, sur votre disque.
playlist_directory : Vous devez pointer le répertoire playlist créé précédemment. Donc a priori :
"/home/votrelogin/.mpd/playlist/"db_file :
"/home/votrelogin/.mpd/database"log_file :
"/home/votrelogin/.mpd/log"state_file :
"/home/votrelogin/.mpd/state"J'ai laissé la variable pid par défaut, à savoir "/var/lib/mpd/mpd.pid", mais j'ai du créer le fichier qui va bien, je crois. dans le doute :
touch /var/lib/mpd/mpd.piduser : laissez "mpd", on a fait les modifs pour ;)
Pour les utilisateurs d'une carte son Intel de type ICH9 (ou plus généralement celle qui utilisent le module snd_hda_intel), la section audio output devra ressembler à ça :
audio_output {
type "alsa"
name "Intel G45 DEVCTG"
# device "hw:0,0" # optional
format "44100:16:2" # optional
mixer_device "default" # optional
mixer_control "Master" # optional
mixer_index "0" # optional
}
Je sais, c'est étrange de virer la section device. Mais chez mois ça marche comme ça :-) .
À ce stade, la chose est prête à être lancée. Dans une console root :
mpd --create-db
rcmpd startdevrait passer sans problème. On crée ensuite la collection :
mpc updateEnfin, quelques petits trucs. J'aime bien être efficace, donc les deux scripts suivants peuvent être tout à fait pratique :
#!/bin/bash
if mpc |grep -q paused
then
mpc play
else
mpc pause
fi
ce script, que j'ai magnifiquement appelé pause, met en pause la lecture si mpc lit un fichier, et la remet en marche si mpc est en pause.
#!/bin/bash
if mpc|grep -q 'random: off'
then
mpc random on
else
mpc random off
fiDe même, ce programme (que j'ai nommé random) active ou désactive la lecture aléatoire.
Placez les deux scripts dans /home/votrelogin/bin . et rendez les exécutables avec un chmod u+x, aussi ;-) . L'avantage de les mettre dans ~/bin, c'est que vous pourrez les appeler très vite. Sous KDE, vous pourrez même utiliser le lanceur d'applications. Bref, la vie est belle :)
Enfin, j'ai aussi quelques petits alias (qui ne sont utilisables que depuis une console où vous êtes loggés en votre nom ). À mettre dans .bashrc (qui peut être créé pour l'occasion). :
alias next='mpc next'
alias stop='mpc stop'
alias play='mpc play'
Une dernière chose pour la route : mpd est un démon, il peut être lanccé automatiquement au démarrage. Pour les gens de chez suse, passez par YaST, trouvez le module qui gère les niveaux d'exécution, passez en mode expert, et cochez les cases 3 et 5 pour mpd. Prudence, cependant, si le démon est arrêté alors qu'une lecture est en cours, elle sera reprise automatiquement au démarrage suivant. Donc pour la discrétion... ;-)
Amusez-vous !
08/05/2010
Montage automatique d'un périphérique... depuis la console.
Y a des jours où c'est pas facile... quand il s'agit de faire de l'aide sur IRC, en général, ça va, quand les gens ont un minimum de connaissance... mais parfois... et allez expliquer comment monter simplement un périphérique, avec un utilisateur qui n'est pas capable de trouver le nom du disque en question, et encore moins l'identifiant des partitions qu'il contient...
Du coup, après plus d'une heure perdue, ou presque, à essayer de glaner des infos pour lui faire faire les bonnes manip' avec mount, j'ai fini par me demander quel outil simple existait pour remplacer les gestionnaires d'évènements HAL présents dans KDE ou Gnome.
Un petit tour... sur IRC :D et je trouve une réponse satisfaisante (en moins de trente secondes, efficacité raisonnable :p )
On va utiliser un script Python, nommé halmount. Faut l'installer, d'abord, il est dans le paquet ivman :
Ensuite...
nous liste les possibilités,
monte toutes les choses non montées et montables automatiquement
Amusez vous !
Du coup, après plus d'une heure perdue, ou presque, à essayer de glaner des infos pour lui faire faire les bonnes manip' avec mount, j'ai fini par me demander quel outil simple existait pour remplacer les gestionnaires d'évènements HAL présents dans KDE ou Gnome.
Un petit tour... sur IRC :D et je trouve une réponse satisfaisante (en moins de trente secondes, efficacité raisonnable :p )
On va utiliser un script Python, nommé halmount. Faut l'installer, d'abord, il est dans le paquet ivman :
zypper in ivmanEnsuite...
man halmount nous donne des informations utiles. Notamment si on veut, ce qui est le cas de mon utilisateur débutant, monter tous les machins présents automatiquement.halmountnous liste les possibilités,
halmount -a monte toutes les choses non montées et montables automatiquement
Amusez vous !
15/04/2010
Lancer une application graphique par SSH
Chose assez inhabituelle pour moi, j'ai deux machines qui tournent bien à disposition. Donc je peux m'amuser un peu avec... Question du jour : comment lancer une application graphique au travers de SSH, sans VNC ou autre outils de ce genre... Le but étant... euh... bon, y a pas vraiment de but. Mais je suis sur que ça peut servir.
Première chose : je pars du principe que vous savez activer sshd correctement sur la machine serveur, et ce avec ouverture du pare-feu. Pour les utilisateurs d'openSUSE, c'est assez simple : dans YaST, Pare-Feu, Services autorisés, ajouter SSH dans la zone externe. Et configurer votre interface réseau pour qu'elle soit dans la zone externe (ce qui est bien plus sûr, en passant... ;-) )
Une fois la chose faite, sshd et X11 démarrés sur le serveur, placez vous sur la machine cliente, ouvrez un terminal, et lancez la connection ssh :
Je pars du principe que user a les sur X11... Notez le "-X" dans la commande qui va permettre d'importer les variables relatives à l'environnement graphique.
Jusque là, ça va... Nous allons maintenant devoir autoriser les directives allant vers le serveur X à être prises en copte depuis notre machine. Supposons que notre machine s'appelle patate . À travers la connexion SSH, nous autorisons patate à lancer des commandes faisant intervenir X11 :
Nous supposons ici que le serveur connaît le nom de notre machine. Si ce n'est pas le cas, utilisez une adresse IP, par exemple :
Ce n'est pas fini, cependant... les variables X11 actuelles sont relatives à la machine cliente... il va donc falloir changer un peu les choses en corrigeant la variable DISPLAY :
Et normalement, c'est bon... :-) pour tester, lancez xterm depuis la machine cliente :
Mieux, xdg -open marche tout à fait convenablement de cette façon :-)
Amusez vous !
Première chose : je pars du principe que vous savez activer sshd correctement sur la machine serveur, et ce avec ouverture du pare-feu. Pour les utilisateurs d'openSUSE, c'est assez simple : dans YaST, Pare-Feu, Services autorisés, ajouter SSH dans la zone externe. Et configurer votre interface réseau pour qu'elle soit dans la zone externe (ce qui est bien plus sûr, en passant... ;-) )
Une fois la chose faite, sshd et X11 démarrés sur le serveur, placez vous sur la machine cliente, ouvrez un terminal, et lancez la connection ssh :
ssh -X user@machineJe pars du principe que user a les sur X11... Notez le "-X" dans la commande qui va permettre d'importer les variables relatives à l'environnement graphique.
Jusque là, ça va... Nous allons maintenant devoir autoriser les directives allant vers le serveur X à être prises en copte depuis notre machine. Supposons que notre machine s'appelle patate . À travers la connexion SSH, nous autorisons patate à lancer des commandes faisant intervenir X11 :
xhost +patateNous supposons ici que le serveur connaît le nom de notre machine. Si ce n'est pas le cas, utilisez une adresse IP, par exemple :
xhost +192.168.0.10Ce n'est pas fini, cependant... les variables X11 actuelles sont relatives à la machine cliente... il va donc falloir changer un peu les choses en corrigeant la variable DISPLAY :
export DISPLAY=:0.0Et normalement, c'est bon... :-) pour tester, lancez xterm depuis la machine cliente :
xtermMieux, xdg -open marche tout à fait convenablement de cette façon :-)
Amusez vous !
09/04/2010
Installation d'awesome pour openSUSE 11.2
En traînant sur des blogs, je suis tombé sur la page d'awesome, un bureau qui se présente comme étant un gestionnaire de fenêtres hautement configurable hautement novateur, et particulièrement adapté pour les développeurs. Comme j'aime bien me faire chi** à configurer ce genre de choses, je décide de l'installer. Coup de chance, il est dans mes dépôts, donc un
a suffi. Pour ceux qui n'ont pas cette veine, passez par ce site pour la recherche de paquets. Ou ajoutez le dépôt X11, et faites l'install avec zypper.
Et là, problème : utilisateur de KDE, je ferme ma session, me retrouve dans KDM, et pas de traces d'awesome... erf. Du coup, je fouine un peu, et je me retrouve à rajouter un fichier dans
C'est le répertoire où KDE va regarder, pour savoir quels sont les environnements de bureaux installés. Pour chaque bureau, un fichier .desktop. Donc on rajoute un fichier
et on met les choses suivantes dedans :
Et o ntrouve enfin awesome dans la liste des bureaux disponibles. Pour la suite (l'utilisation) reportez vous aux manuels divers. Mais je confirme : ça a l'air hautement cool :)
Amusez-vous!
zypper in awesomea suffi. Pour ceux qui n'ont pas cette veine, passez par ce site pour la recherche de paquets. Ou ajoutez le dépôt X11, et faites l'install avec zypper.
Et là, problème : utilisateur de KDE, je ferme ma session, me retrouve dans KDM, et pas de traces d'awesome... erf. Du coup, je fouine un peu, et je me retrouve à rajouter un fichier dans
/usr/share/kde4/apps/kdm/sessions/C'est le répertoire où KDE va regarder, pour savoir quels sont les environnements de bureaux installés. Pour chaque bureau, un fichier .desktop. Donc on rajoute un fichier
awesome.desktopet on met les choses suivantes dedans :
[Desktop Entry]
Encoding=UTF-8
Name=awesome
Comment=awesome
Exec=awesome
Type=XSession
TryExec=awesomeEt o ntrouve enfin awesome dans la liste des bureaux disponibles. Pour la suite (l'utilisation) reportez vous aux manuels divers. Mais je confirme : ça a l'air hautement cool :)
Amusez-vous!
Interactions de communautés.
Petite mise en contexte
De nombreux remous ont agité la communauté Alionet à la fin de l'année 2009. À l'époque, la communauté Kaméléon-Facile (KF) s'est dissoute. KF hébergeait une documentation très importante, qui servait officiellement de documentation à Alionet. Du jour au lendemain, la communauté Alionet s'est donc retrouvée sans site pour sa documentation. Nous avons donc envisagé plusieurs solutions, et sommes tombés d'accord avec l'équipe qui assure l'organisation du projet Linuxpedia . Et nous avons alors commencé la migration, dont la description des étapes n'est pas le but de ce billet.
Cet état de fait a provoqué l'apparition d'un problème original. Nous partons de deux communautés a priori distinctes : on a des utilisateurs d'openSUSE réunis au sein d'un forum, et des utilisateurs de systèmes libres qui alimentent un wiki très vaste (plus de 2500 pages... ). Bien sur, on compte quelques personnes qui jouent sur les deux tableaux, qui contribuent à la fois au forum et au wiki... mais elles sont assez peu nombreuses, en fait. La problématique suivante est donc apparue. Les membres des deux communautés cherchent à répondre à leur besoin d'informations auprès de l'outil de leur choix, ici un forum d'une part, et un wiki d'autre part. Les attentes sotn donc propres, même si elles peuvent avoir des points commun.
De plus, Linuxpedia a un statut un peu particulier : il s'agit d'une documentation traitant de problèmes très différents. Il faut donc réussir à inclure une documentation pour une distribution spécifique, ici openSUSE, dans un cadre très général. Point positif, l'expérience n'est pas la première du genre pour Linuxpedia, qui abrite par exemple la documentation de la distribution Nutyx. Point négatif : il est nécessaire de repenser la structure de la documentation qui était proposée par Kaméléon-Facile...
Une situation à démêler...
Que ce soit pour Linuxpedia ou pour Alionet, les projets à mener sont toujours le fruit de l'attente, puis de la mise en oeuvre, de la communauté. Malheureusement, dans notre cas, la situation est extrêmement complexe. En effet, les pages à étudier sur l'ancienne documentation sont nombreuses, et doivent être mises en ligne au sein de Linuxpedia. Malheureusement, aucune architecture n'est prévue pour ce genre d'entreprise, il est donc nécessaire de tout reconstruire. De plus, Linuxpedia possède ses propres règles, qu'il serait impensable pour la communauté Alionet de ne pas suivre. L'association entre les deux communautés doit être pérennes, sans quoi le projet mourra. Et si le projet est intéressant pour Alionet, puisqu'il permet une remise en ligne et un renouveau de la documentation, il l'est également pour Linuxpedia. En effet, cette intégration permet l'apport de nouvelles connaissances, et un partage de ressources entre les commaunutés. Il est tout à fait naturel d'envisager un transfert de compétences d'une communauté à l'autre, de façon tout à fait transparente.
Dans le cadre ainsi présenté, comment réaliser la migration? Bien entendu, les communautés sont maîtresses de la chose. Cependant, il est plus qu'indispensable de réussir à transmettre les informations clairement, surtout lors des premières phases de reconstruction : la construction de l'architecture, et le transfert des documentations les plus importantes vers la nouvelle ossature. À ce niveau d'interactions, je pense qu'il est plus habile de faire communiquer des représentants de la communauté en cercle restreint, plutôt que la communauté dans son ensemble. Cela permet de limiter les problèmes de communication, et de simplifier les processus de décision.
Attention cependant, il faut toujours garder à l'esprit la règle suivante : une décision ne peut jamais être prise par une seul personne, sans consentement des autres, et de préférence avec un large soutient. Dans notre cas, la communication a connu deux niveaux distincts, peut être trois. D'une part, l'équipe d'administration d'Alionet a construit peu à peu une architecture d'accueil, qui a longtemps été débattue avant d'arriver à un résultat satisfaisant tout le monde. D'autre part, nous avons été, et sommes toujours, engagé dans un dialogue étroit avec le staff de Linuxpedia. Ceux-ci ont ainsi pu émettre des critiques vis-à-vis du résultat que nous proposions, et améliorions peu à peu.
En choisissant cette approche, nous avons effectué l'hypothèse suivante : nous pensons être capable d'effectuer un travail qui sera satisfaisant pour la communauté. Cette hypothèse est dangereuse, car elle nous impose une très grande prudence. En effet, on peut très rapidement s'éloigner de ses objectifs, oublier quel est l'intérêt du travail que nous accomplissons, et imposer finalement un résultat décevant, sans être plus capable de comprendre pourquoi les membres sont déçus.
Et les membres de la communauté dans tout ça...
Le pari était risqué. Nous serons bientôt fixé sur la qualité de notre travail, il est très proche de la mise en ligne, la plupart des phases de migration subissent des finitions ces jours-ci. Nous avons fait le choix discutable de parler au nom de la communauté, tout en sachant que nous ne pouvons pas la représenter pleinement.
Car après tout, ces différents projets appartiennent tous aux diverses commautés. De même que Linuxpedia ne pourrait continuer son aventure sans la contribution de ses rédacteurs, Alionet mourrait sans les interventions prolifiques de certains de ses membres, toujours prompts à défendre la carte graphique veuve et le chipset wifi orphelin.
Le travail des équipe d'administration n'est qu'une simplification pour les utilisateurs. Il permet de résoudre de façon à peu près transparente les interférences qui secouent naturellement les mouvements de ce genre de projets. Transparente pour les utilisateurs. Suite à une discussion avec un membre de l'équipe technique de Linuxpedia, ce soir (enfin, hier soir, mais bon... ), il est ressorti qu'après tout, nous ne sommes que des membres de ces communautés. Même en étant administrateurs, nous sommes aussi de simples contributeurs. Avec une contrainte supplémentaire : ce que nous faisons peut rendre la vie de la communauté plus simple. Mais ça peut aussi la détruire.
De nombreux remous ont agité la communauté Alionet à la fin de l'année 2009. À l'époque, la communauté Kaméléon-Facile (KF) s'est dissoute. KF hébergeait une documentation très importante, qui servait officiellement de documentation à Alionet. Du jour au lendemain, la communauté Alionet s'est donc retrouvée sans site pour sa documentation. Nous avons donc envisagé plusieurs solutions, et sommes tombés d'accord avec l'équipe qui assure l'organisation du projet Linuxpedia . Et nous avons alors commencé la migration, dont la description des étapes n'est pas le but de ce billet.
Cet état de fait a provoqué l'apparition d'un problème original. Nous partons de deux communautés a priori distinctes : on a des utilisateurs d'openSUSE réunis au sein d'un forum, et des utilisateurs de systèmes libres qui alimentent un wiki très vaste (plus de 2500 pages... ). Bien sur, on compte quelques personnes qui jouent sur les deux tableaux, qui contribuent à la fois au forum et au wiki... mais elles sont assez peu nombreuses, en fait. La problématique suivante est donc apparue. Les membres des deux communautés cherchent à répondre à leur besoin d'informations auprès de l'outil de leur choix, ici un forum d'une part, et un wiki d'autre part. Les attentes sotn donc propres, même si elles peuvent avoir des points commun.
De plus, Linuxpedia a un statut un peu particulier : il s'agit d'une documentation traitant de problèmes très différents. Il faut donc réussir à inclure une documentation pour une distribution spécifique, ici openSUSE, dans un cadre très général. Point positif, l'expérience n'est pas la première du genre pour Linuxpedia, qui abrite par exemple la documentation de la distribution Nutyx. Point négatif : il est nécessaire de repenser la structure de la documentation qui était proposée par Kaméléon-Facile...
Une situation à démêler...
Que ce soit pour Linuxpedia ou pour Alionet, les projets à mener sont toujours le fruit de l'attente, puis de la mise en oeuvre, de la communauté. Malheureusement, dans notre cas, la situation est extrêmement complexe. En effet, les pages à étudier sur l'ancienne documentation sont nombreuses, et doivent être mises en ligne au sein de Linuxpedia. Malheureusement, aucune architecture n'est prévue pour ce genre d'entreprise, il est donc nécessaire de tout reconstruire. De plus, Linuxpedia possède ses propres règles, qu'il serait impensable pour la communauté Alionet de ne pas suivre. L'association entre les deux communautés doit être pérennes, sans quoi le projet mourra. Et si le projet est intéressant pour Alionet, puisqu'il permet une remise en ligne et un renouveau de la documentation, il l'est également pour Linuxpedia. En effet, cette intégration permet l'apport de nouvelles connaissances, et un partage de ressources entre les commaunutés. Il est tout à fait naturel d'envisager un transfert de compétences d'une communauté à l'autre, de façon tout à fait transparente.
Dans le cadre ainsi présenté, comment réaliser la migration? Bien entendu, les communautés sont maîtresses de la chose. Cependant, il est plus qu'indispensable de réussir à transmettre les informations clairement, surtout lors des premières phases de reconstruction : la construction de l'architecture, et le transfert des documentations les plus importantes vers la nouvelle ossature. À ce niveau d'interactions, je pense qu'il est plus habile de faire communiquer des représentants de la communauté en cercle restreint, plutôt que la communauté dans son ensemble. Cela permet de limiter les problèmes de communication, et de simplifier les processus de décision.
Attention cependant, il faut toujours garder à l'esprit la règle suivante : une décision ne peut jamais être prise par une seul personne, sans consentement des autres, et de préférence avec un large soutient. Dans notre cas, la communication a connu deux niveaux distincts, peut être trois. D'une part, l'équipe d'administration d'Alionet a construit peu à peu une architecture d'accueil, qui a longtemps été débattue avant d'arriver à un résultat satisfaisant tout le monde. D'autre part, nous avons été, et sommes toujours, engagé dans un dialogue étroit avec le staff de Linuxpedia. Ceux-ci ont ainsi pu émettre des critiques vis-à-vis du résultat que nous proposions, et améliorions peu à peu.
En choisissant cette approche, nous avons effectué l'hypothèse suivante : nous pensons être capable d'effectuer un travail qui sera satisfaisant pour la communauté. Cette hypothèse est dangereuse, car elle nous impose une très grande prudence. En effet, on peut très rapidement s'éloigner de ses objectifs, oublier quel est l'intérêt du travail que nous accomplissons, et imposer finalement un résultat décevant, sans être plus capable de comprendre pourquoi les membres sont déçus.
Et les membres de la communauté dans tout ça...
Le pari était risqué. Nous serons bientôt fixé sur la qualité de notre travail, il est très proche de la mise en ligne, la plupart des phases de migration subissent des finitions ces jours-ci. Nous avons fait le choix discutable de parler au nom de la communauté, tout en sachant que nous ne pouvons pas la représenter pleinement.
Car après tout, ces différents projets appartiennent tous aux diverses commautés. De même que Linuxpedia ne pourrait continuer son aventure sans la contribution de ses rédacteurs, Alionet mourrait sans les interventions prolifiques de certains de ses membres, toujours prompts à défendre la carte graphique veuve et le chipset wifi orphelin.
Le travail des équipe d'administration n'est qu'une simplification pour les utilisateurs. Il permet de résoudre de façon à peu près transparente les interférences qui secouent naturellement les mouvements de ce genre de projets. Transparente pour les utilisateurs. Suite à une discussion avec un membre de l'équipe technique de Linuxpedia, ce soir (enfin, hier soir, mais bon... ), il est ressorti qu'après tout, nous ne sommes que des membres de ces communautés. Même en étant administrateurs, nous sommes aussi de simples contributeurs. Avec une contrainte supplémentaire : ce que nous faisons peut rendre la vie de la communauté plus simple. Mais ça peut aussi la détruire.
07/04/2010
Retrouver les paquets orphelins sur openSUSE
Certaines questions reviennent régulièrement. Et on n'a pas forcément de réponse, en plus. Genre "comment je connais les paquets, sur mon système, qui ont été installés comme dépendances d'autres paquets, mais pas enlevés lors de la désinstallation ? ". Je crois que j'ai trouvé une réponse, autre que "en vérifiant tous les paquets à la main"...
Pour pouvoir faire cette vérification, il va falloir... installer un paquet. Ben oui, c'est pas un tour de magie que je vais proposer. Et comme il semble que la fonctionnalité ne soit pas part intégrante de zypper ou de rpm... Donc on installe rpmorphan. Comme ça :
Déjà on est content, y a un nouveau logiciel sur la machine, c'est cool :) . Au delà de ça... on va aussi pouvoir l'utiliser. Rien de plus simple :
va vous sortir une liste de paquets orphelins. Plus précisément, rpmorphan va lister tous les paquets qui ne sont pas dépendance d'un autre paquet.
Attention toutefois : savoir qu'un paquet n'est pas dépendance d'un autre paquet, ça veut pas dire qu'il faut le supprimer... Il peut être une dépendance "aveugle", dans le sens où un paquet aura été mal construit. Donc les dépendances mal renseignées, en l'occurrence. Et un paquet peut ne pas être une dépendance, mais être "fortement conseillé" pour un logiciel. Genre libdvdcss, pour plein de monde. Il apparaît dans ma sortie de liborphan. Et j'ai pas l'intention de le dégager, j'aime pouvoir lire des DVD sous Linux ;)
À utiliser avec prudence et intelligence, donc ;)
Amusez vous!
Pour pouvoir faire cette vérification, il va falloir... installer un paquet. Ben oui, c'est pas un tour de magie que je vais proposer. Et comme il semble que la fonctionnalité ne soit pas part intégrante de zypper ou de rpm... Donc on installe rpmorphan. Comme ça :
zypper in rpmorphanDéjà on est content, y a un nouveau logiciel sur la machine, c'est cool :) . Au delà de ça... on va aussi pouvoir l'utiliser. Rien de plus simple :
rpmorphanva vous sortir une liste de paquets orphelins. Plus précisément, rpmorphan va lister tous les paquets qui ne sont pas dépendance d'un autre paquet.
Attention toutefois : savoir qu'un paquet n'est pas dépendance d'un autre paquet, ça veut pas dire qu'il faut le supprimer... Il peut être une dépendance "aveugle", dans le sens où un paquet aura été mal construit. Donc les dépendances mal renseignées, en l'occurrence. Et un paquet peut ne pas être une dépendance, mais être "fortement conseillé" pour un logiciel. Genre libdvdcss, pour plein de monde. Il apparaît dans ma sortie de liborphan. Et j'ai pas l'intention de le dégager, j'aime pouvoir lire des DVD sous Linux ;)
À utiliser avec prudence et intelligence, donc ;)
Amusez vous!
Il faut toujours se méfier des utilisateurs...
Les utilisateurs sont capables de tout. Du meilleur. Mais pas souvent. Alors que pour faire le pire, ils sont toujours fichus de déployer des trésors d'ingéniosité. Et quand je dis des trésors, je pèse mes mots...
Dernier exemple en date, un collector. Légèrement désoeuvré en fin de soirée, je décide de m'occuper en faisant du openSUSE-SAV sur un chan IRC officiel. Plutôt de bonne humeur, j'ai trouvé de la bonne musique dans ma médiathèque préférée. Ça part donc plutôt bien...
Arrive un utilisateur, avec une question magique. Problème classique, il se bat un peu avec ses pilotes vidéos. Jusque là, rien de mal. Il a une carte ATi, ça part mal. Et il a réussi à installer les pilotes pour cartes nVidia sur sa machine.
En toute franchise, j'ai cru à un canular. Vraiment. Un gars qui vient là pour tester la réaction des intervenants du canal. Un autre désoeuvré, mais dans un esprit légèrement moins coopératif que le mien. Sauf que non, vu les réponses du gars, ça a l'air sérieux. Il l'a vraiment fait.
C'est dans des moments comme ça que je me souviens pourquoi j'interviens dans ce genre de situations... Eh oui... c'est débile, hein. Souvent je me dis de toutes façons, si les gens lisaient le manuel, ils s'en sortiraient seuls. Ils ont qu'à se démerder, zut... Si seulement c'était si simple...
Il y a des gens, dont j'espère faire partie dans une mesure raisonnable, qui s'en sorte bien face à un ordinateur. Avec un système correct, un manuel à eu près clair, et un peu de temps, ils s'en sortent pas trop mal. Y a aussi des gens qui prennent le temps, après d'expliquer.
Mais à côté de ça... y a leur équivalents, leur pendant, ces gens qui sont là pour assurer l'équilibre naturel de notre univers. Qui ne comprennent rien à l'univers de l'informatique. Mais ils en ont besoin, que ce soient pour des raisons de productivité (les gens au travail, nda) ou pour des raisons de philosophie (les libristes non-geeks, nda). Et il faut bien les aider, y a pas de raisons.
C'est pour ça que j'essaie d'intervenir. Je trouve que c'est une bonne raison. Mais parfois, faut s'accrocher pour pas le balancer le clavier.... :p
PS : je me bats encore avec l'utilisateur. Ce serait plus simple s'il était pas obligé de rebooter toutes les minutes pour passer de son live cd à son système en dur. Le pire c'est qu'il a l'air d'avoir vraiment cassé son système, ce con... :D
Dernier exemple en date, un collector. Légèrement désoeuvré en fin de soirée, je décide de m'occuper en faisant du openSUSE-SAV sur un chan IRC officiel. Plutôt de bonne humeur, j'ai trouvé de la bonne musique dans ma médiathèque préférée. Ça part donc plutôt bien...
Arrive un utilisateur, avec une question magique. Problème classique, il se bat un peu avec ses pilotes vidéos. Jusque là, rien de mal. Il a une carte ATi, ça part mal. Et il a réussi à installer les pilotes pour cartes nVidia sur sa machine.
En toute franchise, j'ai cru à un canular. Vraiment. Un gars qui vient là pour tester la réaction des intervenants du canal. Un autre désoeuvré, mais dans un esprit légèrement moins coopératif que le mien. Sauf que non, vu les réponses du gars, ça a l'air sérieux. Il l'a vraiment fait.
C'est dans des moments comme ça que je me souviens pourquoi j'interviens dans ce genre de situations... Eh oui... c'est débile, hein. Souvent je me dis de toutes façons, si les gens lisaient le manuel, ils s'en sortiraient seuls. Ils ont qu'à se démerder, zut... Si seulement c'était si simple...
Il y a des gens, dont j'espère faire partie dans une mesure raisonnable, qui s'en sorte bien face à un ordinateur. Avec un système correct, un manuel à eu près clair, et un peu de temps, ils s'en sortent pas trop mal. Y a aussi des gens qui prennent le temps, après d'expliquer.
Mais à côté de ça... y a leur équivalents, leur pendant, ces gens qui sont là pour assurer l'équilibre naturel de notre univers. Qui ne comprennent rien à l'univers de l'informatique. Mais ils en ont besoin, que ce soient pour des raisons de productivité (les gens au travail, nda) ou pour des raisons de philosophie (les libristes non-geeks, nda). Et il faut bien les aider, y a pas de raisons.
C'est pour ça que j'essaie d'intervenir. Je trouve que c'est une bonne raison. Mais parfois, faut s'accrocher pour pas le balancer le clavier.... :p
PS : je me bats encore avec l'utilisateur. Ce serait plus simple s'il était pas obligé de rebooter toutes les minutes pour passer de son live cd à son système en dur. Le pire c'est qu'il a l'air d'avoir vraiment cassé son système, ce con... :D
05/04/2010
Quand on n'a pas de tête....
...on se sert de ses logiciels pour remplacer. Par exemple, je fais une mise à jour, elle casse un bout de mon installation (ça part mal). Je veux revenir en arrière, mais j'ai pas été rigoureux... erf. Je peux démarrer, me logguer en root, rpm et zypper marchent. Le contraire serait étonnant. Pas de panique, on va pouvoir récupérer les derniers paquets installés sur le système. La formule magique est la suivante :
rpm alimente une base de données, que nous alimentons chaque fois que nous l'utilisons, directement ou par le biais de zypper, pour installer un paquet. Cette base de données contient, entre autres, la date de dernière installation des paquets présents dans le système. Donc on interroge rpm (c'est le -q) sur toute l'installation (c'est le -a), on classe en mettant le dernier installé en premier (c'est le --last), et on filtre avec une redirection de flux.
Ici je filtre avec un head, arbitrairement, on peut faire mieux avec un grep en précisant la date d'installation.
Amusez-vous!
rpm -q -a --last|head -20rpm alimente une base de données, que nous alimentons chaque fois que nous l'utilisons, directement ou par le biais de zypper, pour installer un paquet. Cette base de données contient, entre autres, la date de dernière installation des paquets présents dans le système. Donc on interroge rpm (c'est le -q) sur toute l'installation (c'est le -a), on classe en mettant le dernier installé en premier (c'est le --last), et on filtre avec une redirection de flux.
Ici je filtre avec un head, arbitrairement, on peut faire mieux avec un grep en précisant la date d'installation.
Amusez-vous!
04/04/2010
Imposer la version d'un logiciel avec zypper
Hé oui, encore un post pour les utilisateurs d'openSUSE (ou d'ark linux, il me semble qu'ils utilisent zypper ;) ). Et aussi pour me servir de pense bête. J'aime bien faire d'une pierre deux coups :p
Problème du jour : imposer la version d'un logiciel depuis la ligne de commande. Je me suis légèrement battu pour faire marcher baskets, aujourd'hui. C'est passé, non sans une petite lecture du manuel de zypper ;)
Donc permière chose, je fais une recherche avec zypper, sur baskets :
Moi je veux le paquet qui est en haut de la ligne. Pour que ça marche. Parceque je suis sous KDE4.4 .
Du coup, on va forcer la version, sur l'appel de zypper, en respectant la syntaxe
Du coup pour moi ça donne ça :
et à la fin, on a bien :
Et basket marche. Donc je suis content :)
Problème du jour : imposer la version d'un logiciel depuis la ligne de commande. Je me suis légèrement battu pour faire marcher baskets, aujourd'hui. C'est passé, non sans une petite lecture du manuel de zypper ;)
Donc permière chose, je fais une recherche avec zypper, sur baskets :
zypper se -s baskets Chargement des données du dépôt... Lecture des paquets installés... S | Nom | Type | Version | Arch | Dépot --+--------------------+---------------+---------------------+--------+-------------------- v | basket | paquet | 1.80-4.5 | x86_64 | KDE4.4Community v | basket | paquet | 1.0svn20091126-1.81 | x86_64 | KDE4.4Playground v | basket | paquet | 1.80-4.5 | i586 | KDE4.4Community v | basket | paquet | 1.0svn20091126-1.81 | i586 | KDE4.4Playground i | basket | paquet | 1.0.3.1-9.5 | x86_64 | openSUSE-11.2-Oss v | basket | paquet | 1.0.3.1-9.5 | i586 | openSUSE-11.2-Oss | basket | paquet source | 1.80-4.5 | noarch | KDE4.4Community | basket | paquet source | 1.0svn20091126-1.81 | noarch | KDE4.4Playground(je vous épargne une partie de la sortie, c'est pas forcément toujours utile)
Moi je veux le paquet qui est en haut de la ligne. Pour que ça marche. Parceque je suis sous KDE4.4 .
Du coup, on va forcer la version, sur l'appel de zypper, en respectant la syntaxe
zypper in paquet=versionDu coup pour moi ça donne ça :
zypper in basket=1.80-4.5et à la fin, on a bien :
Chargement des données du dépôt... Lecture des paquets installés... S | Nom | Type | Version | Arch | Dépot --+--------------------+---------------+---------------------+--------+-------------------- i | basket | paquet | 1.80-4.5 | x86_64 | KDE4.4Community v | basket | paquet | 1.0svn20091126-1.81 | x86_64 | KDE4.4Playground v | basket | paquet | 1.80-4.5 | i586 | KDE4.4Community v | basket | paquet | 1.0svn20091126-1.81 | i586 | KDE4.4Playground v | basket | paquet | 1.0.3.1-9.5 | x86_64 | openSUSE-11.2-Oss v | basket | paquet | 1.0.3.1-9.5 | i586 | openSUSE-11.2-Oss | basket | paquet source | 1.80-4.5 | noarch | KDE4.4Community | basket | paquet source | 1.0svn20091126-1.81 | noarch | KDE4.4Playground
Et basket marche. Donc je suis content :)
31/03/2010
Eclipse et openSUSE
En bon développeur Java (ça va quand même arriver à toute vitesse, là...) j'utilise un EDI qui va bien. Eclipse, en l'occurence. Et, petit rappel pour ceux au fond qui ne suivent pas, j'utilise aussi openSUSE. Et comme je suis sous KDE, qu'Eclipse se sert de GTk, et qu'en plus les conf GTk sont faites pour windows, y a eu des petits problèmes...
En fait, certains boutons deviennent inaccessibles. Certaines parties des fenêtres sont soudainement insensibles aux clics de souris. Restent la touche tabulation et les raccourcis clavier... Ou alors, on fouine un peu, et on passe par les manip's que je décris ici. Ça marche pas torp mal...
Deux choses sont à régler. La première (en fait y a pas d'ordre, mais mettons que ce soit la première), choisir un thème gtk pour KDE. Dans certaines versions de KDE4, aucun choix n'est fait par défaut, c'est un peu gênant... donc, dans la "Configuration du système" de KDE4, allez dans apparence, styles et polices gtk, et choisissez un thème GTk, par exemple Clearlooks (qui marche très bien)... On a réglé le problème de l'absence de configuration GTk.
Passons au problème de compatibilité avec les options GTk pour Windows. C'est un peu plus compliqué. Il va falloir ouvrir un terminal, se logguer en root, et aller modifier le fichier /usr/bin/eclipse . Comme pour la plupart des logiciels, il s'agit d'un script de lancement pour passer les bons paramètres au binaire.
On va ajouter des choses au début du fichier, histoire d'assurer que tous les boutons sont accessibles. On a besoin de ces trois lignes :
Surtout de la première, en fait, les autres devraient déjà être présentes. C'est un appel pour préciser le comportement des éléments GTk.
A priori, ça devrait marcher mieux ;)
Amusez vous!
En fait, certains boutons deviennent inaccessibles. Certaines parties des fenêtres sont soudainement insensibles aux clics de souris. Restent la touche tabulation et les raccourcis clavier... Ou alors, on fouine un peu, et on passe par les manip's que je décris ici. Ça marche pas torp mal...
Deux choses sont à régler. La première (en fait y a pas d'ordre, mais mettons que ce soit la première), choisir un thème gtk pour KDE. Dans certaines versions de KDE4, aucun choix n'est fait par défaut, c'est un peu gênant... donc, dans la "Configuration du système" de KDE4, allez dans apparence, styles et polices gtk, et choisissez un thème GTk, par exemple Clearlooks (qui marche très bien)... On a réglé le problème de l'absence de configuration GTk.
Passons au problème de compatibilité avec les options GTk pour Windows. C'est un peu plus compliqué. Il va falloir ouvrir un terminal, se logguer en root, et aller modifier le fichier /usr/bin/eclipse . Comme pour la plupart des logiciels, il s'agit d'un script de lancement pour passer les bons paramètres au binaire.
On va ajouter des choses au début du fichier, histoire d'assurer que tous les boutons sont accessibles. On a besoin de ces trois lignes :
export GDK_NATIVE_WINDOWS=1
ECLIPSE_OPTS=""
VM_OPTS=""Surtout de la première, en fait, les autres devraient déjà être présentes. C'est un appel pour préciser le comportement des éléments GTk.
A priori, ça devrait marcher mieux ;)
Amusez vous!
24/03/2010
Installation de la carte BCM4312 sous openSUSE 11.2
Avoir une carte wifi, c'est bien, pouvoir la faire marcher, c'est encore mieux... de préférence sur le système qui nous intéresse. Dans mon cas, je suis censé travailler avec une carte de chez Broadcomm, et comme très souvent avec ces cartes, c'est un peu compliqué... mais bon, vous allez voir, on va s'en sortir avec openSUSE, bon gré mal gré.
Installation sur le noyau de base
Première approche : Broadcomm, contre toute attente, fournit un pilote pour le noyau par défaut de SUSE. Bonne nouvelle, donc, qui s'accompagne de deux mauvaises nouvelles : le pilote est fermé (pouah pouah pouah) et nécessite de changer de noyau. Donc on perd les optimisations desktop du noyau par défaut.
Attention ça va aller très vite :
Ajoutez le dépôt Packman, présent dans les dépôts communautaires.
Cherchez le paquet broadcomm-wl, ou installez le directement avec
Le solveur de dépendances va vous proposer d'installer d'autres paquets, notamment un kernel-debug, dans la bonne architecture. Faites, redémarrez sur le noyau débug qui s'est automatiquement ajouté dans le grub, et c'est à peu près tout...
Vous aurez peut-être à blacklister deux pilotes : ssb et b43. Pas de chance si vous avez besoin de ssb pour votre carte ethernet, donc, ce sera soit l'une, soit l'autre...
Vous aurez peut être besoin de blacklister des choses... a priori ça se fait tout seul, sinon, ça se passe dans
dans le mien on trouvera des choses genre :
Installation avec un nouveau noyau
Ça vous a plu? Ben c'est pas fini... Comme dit plus haut, wl, c'est pas libre, bouh! et surtout, le pilote ne permet pas de passer la carte en mode Moniteur, indsipensable notamment pour fiare un peu d'audit wifi. Qu'à cela ne tienne, on va changer de noyau, pour avoir un pilote qui va bien. C'est aussi possible de patcher celui qu'on utilise actuellement, mais c'est moins intéressant, moins formateur, et beaucoup trop rapide.
Changement de noyau, donc... permière chose, récupérer des sources. Pour ça, il nous faut un dépôt qui va bien, en l'occurence, le dépôt
Ca peut bien entendu se faire par yast, ou par zypper avec
Après, il faut récupérer les sources du kernel qui nous intéresse, genre un 2.6.33 (ou une rc d'un 2.6.34, mais c'est un peu plus risqué, c'est une rc ;) ) en l'installant par yast (par zypper c'est un peu plus long, faut être précis et attentif ;) )
Compilation, donc, je vais passer très vite...
Là vous êtes dans la partie chiante de la manipulation. Vous allez devoir sélectionner les bouts du kernel que vous voulez intégrer ... ça comprend des pilotes, mais aussi des bouts indispensables, genre les couches réseau... prenez bien le temps de lire les docs, l'utilisation de l'interface ncurses est assez simple. Comptez une bonne heure de lecture, et peut être une ou deux tentatives pour que le kernel tourne ;)
avant de pouvoir l'utiliser, après avoir sauvé le fichier .config ;) il reste à compiler et installer la chose. Donc
De ce que j'ai pu voir, pas besoin de modifier de fichier pour le grub, un reboot et ça repart... choisissez le bon kernel, si ça passe c'est bon. J'espère que vous n'avez pas oublié ssb et b43 dans la config sinon faudra recommencer...
Reste donc à récupérer un firmware qui va bien :
s'occupe de ça pour vous.
Ensuite, un petit
suivi d'un
Amusez vous!
Installation sur le noyau de base
Première approche : Broadcomm, contre toute attente, fournit un pilote pour le noyau par défaut de SUSE. Bonne nouvelle, donc, qui s'accompagne de deux mauvaises nouvelles : le pilote est fermé (pouah pouah pouah) et nécessite de changer de noyau. Donc on perd les optimisations desktop du noyau par défaut.
Attention ça va aller très vite :
Ajoutez le dépôt Packman, présent dans les dépôts communautaires.
Cherchez le paquet broadcomm-wl, ou installez le directement avec
zypper in broadcomm-wlLe solveur de dépendances va vous proposer d'installer d'autres paquets, notamment un kernel-debug, dans la bonne architecture. Faites, redémarrez sur le noyau débug qui s'est automatiquement ajouté dans le grub, et c'est à peu près tout...
Vous aurez peut-être à blacklister deux pilotes : ssb et b43. Pas de chance si vous avez besoin de ssb pour votre carte ethernet, donc, ce sera soit l'une, soit l'autre...
Vous aurez peut être besoin de blacklister des choses... a priori ça se fait tout seul, sinon, ça se passe dans
50-broadcom-wl-blacklist.confdans le mien on trouvera des choses genre :
# modules blacklisted for broadcom-wl
blacklist bcm43xx
blacklist ssb
blacklist b43
blacklist ndiswrapperInstallation avec un nouveau noyau
Ça vous a plu? Ben c'est pas fini... Comme dit plus haut, wl, c'est pas libre, bouh! et surtout, le pilote ne permet pas de passer la carte en mode Moniteur, indsipensable notamment pour fiare un peu d'audit wifi. Qu'à cela ne tienne, on va changer de noyau, pour avoir un pilote qui va bien. C'est aussi possible de patcher celui qu'on utilise actuellement, mais c'est moins intéressant, moins formateur, et beaucoup trop rapide.
Changement de noyau, donc... permière chose, récupérer des sources. Pour ça, il nous faut un dépôt qui va bien, en l'occurence, le dépôt
http://download.opensuse.org/repositories/Kernel:/HEAD/openSUSE_11.2/Ca peut bien entendu se faire par yast, ou par zypper avec
zypper ar http://download.opensuse.org/repositories/Kernel:/HEAD/openSUSE_11.2/Après, il faut récupérer les sources du kernel qui nous intéresse, genre un 2.6.33 (ou une rc d'un 2.6.34, mais c'est un peu plus risqué, c'est une rc ;) ) en l'installant par yast (par zypper c'est un peu plus long, faut être précis et attentif ;) )
Compilation, donc, je vais passer très vite...
cd /usr/src/linux2.6.****/
make clean
make mrproper
make menuconfig
Là vous êtes dans la partie chiante de la manipulation. Vous allez devoir sélectionner les bouts du kernel que vous voulez intégrer ... ça comprend des pilotes, mais aussi des bouts indispensables, genre les couches réseau... prenez bien le temps de lire les docs, l'utilisation de l'interface ncurses est assez simple. Comptez une bonne heure de lecture, et peut être une ou deux tentatives pour que le kernel tourne ;)
avant de pouvoir l'utiliser, après avoir sauvé le fichier .config ;) il reste à compiler et installer la chose. Donc
make
make modules_install
make installDe ce que j'ai pu voir, pas besoin de modifier de fichier pour le grub, un reboot et ça repart... choisissez le bon kernel, si ça passe c'est bon. J'espère que vous n'avez pas oublié ssb et b43 dans la config sinon faudra recommencer...
Reste donc à récupérer un firmware qui va bien :
install_bcm43xx_firmwares'occupe de ça pour vous.
Ensuite, un petit
rmmod b43
rmmod ssb
modprobe b43suivi d'un
iwlist scan devrait vous donner de bonnes nouvelles.Amusez vous!
07/02/2010
abcde, utilisation un peu plus avancée.
Vous vous souvenez certainement d'abcde (pour another basic cd encoder) évoqué ici. Là, ce qu'il fait ne me va pas trop : par défaut, il encode les ogg avec un niveau de qualité à 3 (la qualité en ogg est mesurée de -1 à 10. Plus c'est élevé, mieux c'est). En gros, ça fait du 120kbps. Un peu trop bas. Donc j'aimerais un qualité 5, pour être aux environs de 192kbps. Reste à trouver comment le lui dire...
Pour ça, j'ai du chercher un peu :
Nous donnes les infos importantes. En utilisant l'option
C'est déjà plus satisfaisant.
Pour ça, j'ai du chercher un peu :
man abcdeman oggencNous donnes les infos importantes. En utilisant l'option
-o vorbis d'abcde, je peux passer des options à oggenc, qui est utilisé par abcde. genre une "-q 5", parceque ça me fait plaisir. A la fin, ça donne ça:abcde -o vorbis:"-q 5"C'est déjà plus satisfaisant.
Amarok, petit retour d'expérience.
Je suis tombé par hasard sur le site d'amarok, mon lecteur audio favori... quelle ne fut pas ma surprise de constater que j'avais quelques versions de retard... mais que font les packageurs d'openSUSE???
En fait, c'est la configuration de mes dépots qui laisse à désirer... Qu'à cela ne tienne, je fais la mise à jour, le paquet étant dans mes dépôts habituels. Pas de problèmes, heureusement. Du moins pendant la mise à jour. (En fait si, un léger problème de dépendance. Zypper m'a presque déçu, y'avait une solution simple. Comme toujours c'est de ma faute, c'est moi qui l'empêche de changer de fournisseur pour un paquet sans me prévenir. Faudrait que je revoie ça :p )
C'eut été trop beau que tout se passe sans casse. Je lance la version mise à jour... et celle-ci fout le bordel dans la base de données sqlite existante, qui référence ma collection. Pas grave. Je m'y attendais, en fait... du coup, un petit
dégage le tout. Plus de préférences amarok, tout oublié, on repart sur des bases saines. Deuxième surprise : amarok va me chercher les dossiers cachés, maintenant :(. Donc je précise un peu mieux les fichiers à traiter, et ça passe... (en fait, c'est aussi un peu de ma faute. On n'a pas idée de faire des liens symboliques sur des dossiers cachés... )
C'est enfin utilisable... Et là, surprise : je retrouve enfin les sensations d'utilisations que j'avais avec la version... 1.4. Le développement d'amarok 2 touche au but sacro-sain de l'utilisabilité. C'est finalement arrivé. On retrouve une interface agréable, fluide, intuitive, et puissante. L'esthétisme est de nouveau au rendez vous. On récupère le play-back pour les cd audios...
D'autres améliorations en vrac : la récupération des jaquettes est plus performante, c'est nettement mieux. Les panneaux principaux d'amarok sont bien mieux agencés. Et on retrouve enfin des boutons utiles directement dans l'interface. Plus besoin de passer par les menus et sous-menus pour provoquer une lecture aléatoire de la playlist, par exemple...
En bref, donc, que du bonheur :)
En fait, c'est la configuration de mes dépots qui laisse à désirer... Qu'à cela ne tienne, je fais la mise à jour, le paquet étant dans mes dépôts habituels. Pas de problèmes, heureusement. Du moins pendant la mise à jour. (En fait si, un léger problème de dépendance. Zypper m'a presque déçu, y'avait une solution simple. Comme toujours c'est de ma faute, c'est moi qui l'empêche de changer de fournisseur pour un paquet sans me prévenir. Faudrait que je revoie ça :p )
C'eut été trop beau que tout se passe sans casse. Je lance la version mise à jour... et celle-ci fout le bordel dans la base de données sqlite existante, qui référence ma collection. Pas grave. Je m'y attendais, en fait... du coup, un petit
rm -r ~/.kde4/share/apps/amarokdégage le tout. Plus de préférences amarok, tout oublié, on repart sur des bases saines. Deuxième surprise : amarok va me chercher les dossiers cachés, maintenant :(. Donc je précise un peu mieux les fichiers à traiter, et ça passe... (en fait, c'est aussi un peu de ma faute. On n'a pas idée de faire des liens symboliques sur des dossiers cachés... )
C'est enfin utilisable... Et là, surprise : je retrouve enfin les sensations d'utilisations que j'avais avec la version... 1.4. Le développement d'amarok 2 touche au but sacro-sain de l'utilisabilité. C'est finalement arrivé. On retrouve une interface agréable, fluide, intuitive, et puissante. L'esthétisme est de nouveau au rendez vous. On récupère le play-back pour les cd audios...
D'autres améliorations en vrac : la récupération des jaquettes est plus performante, c'est nettement mieux. Les panneaux principaux d'amarok sont bien mieux agencés. Et on retrouve enfin des boutons utiles directement dans l'interface. Plus besoin de passer par les menus et sous-menus pour provoquer une lecture aléatoire de la playlist, par exemple...
En bref, donc, que du bonheur :)
29/01/2010
Ouverture de fichiers depuis la ligne de commande.
A force de côtoyer un mac-user légèrement vindicatif, j'apprends de plus en plus de choses... sur le système que, moi, j'utilise. En l'occurence, openSUSE. Dernier épisode en date, M. Winandy se plaignait de ne pas pouvoir, sous GNU/Linux, avoir recours à une commande du type open, sous Mac, qui permet, depuis la ligne de commande, d'ouvrir un fichier en utilisant le logiciel associé dans les préférences utilisateurs...
Petite recherche, rapide, pour trouver un équivalent sous Linux. Je tombe, très rapidement (deuxième requête Google, premier résultat) sur un des incontournables pour les informaticiens : stackoverflow. Le résultat est sans appel : utilisez xdg-open
Par exemple,
Par ailleurs, on peut aussi ouvrir des urls :
Bref, la vie est belle... Le fait d'avoir un partenaire de travail au courant et chambreur me permet de connaître encore mieux les outils à ma disposition. Je suis pas à plaindre, donc :)
PS : petites réflexions annexes. les commandes de type xdg communiquent avec l'interface graphique en cours d'utilisation. celle-ci doit donc être capable de communiquer un résultat à xdg... faudra que je la tente sous fluxbox, un jour, voir si ça passe aussi bien que sous KDE ;)
Petite recherche, rapide, pour trouver un équivalent sous Linux. Je tombe, très rapidement (deuxième requête Google, premier résultat) sur un des incontournables pour les informaticiens : stackoverflow. Le résultat est sans appel : utilisez xdg-open
Par exemple,
xdg-open /chemin/vers/monfichier.pdf ouvrira monfichier.pdf (dans mon cas avec okular)Par ailleurs, on peut aussi ouvrir des urls :
xdg-open http://www.alionet.orgBref, la vie est belle... Le fait d'avoir un partenaire de travail au courant et chambreur me permet de connaître encore mieux les outils à ma disposition. Je suis pas à plaindre, donc :)
PS : petites réflexions annexes. les commandes de type xdg communiquent avec l'interface graphique en cours d'utilisation. celle-ci doit donc être capable de communiquer un résultat à xdg... faudra que je la tente sous fluxbox, un jour, voir si ça passe aussi bien que sous KDE ;)
27/01/2010
Canonical et Mozilla, une alliance à peu d'intérêts.
On m'a gentiment pointé un lien vers ce post sur le framablog
Je trouve personnellement que l'auteur accorde une trop grande force à Ubuntu, ou plutôt à Canonical. Cette entreprise est faible, à mes yeux, elle est issue du mécénat, pas d'une croissance folle initiée par le support de produits open source. Je ne dis pas que sa raison d'être est mauvaise, que créer une entreprise pour le bien de la communauté, c'est mal. Seulement, cette entreprise n'a pas de recours, que ce soit pour créer un produit aussi performant que ce qu'on peut attendre d'un OS Google, surtout si l'OS est basé sur du connu, genre Linux, surtout si le navigateur, présenté comme le centre névralgique de la machine, est archi testé et hyper performant.
D'ailleurs, les évolutions du navigateur made in Mozilla seront certainement révélatrices dans les prochains mois. Si la version 3.6 apporte effectivement des fonctionnalités et progrès intéressants, bien que parfois légers, là non plus je ne pense pas que ça soit suffisant. Mais contrairement à Canonical, Mozilla a plein de ressources, car il ne s'agit plus ici d'une entreprise privée, mais d'une entité à but non-lucratif... Cette entité fait vaciller le géant Microsoft jour après jour un peu plus, et, mieux, a trouver la force, un jour, de relancer une guerre des navigateurs que tout le monde croyait terminée. De permettre l'entrée de nouveaux venus, Chrome et, dans une moindre mesure, Safari.
Enfin, malheureusement, oui, je pense que ce que Google essaie de produire correspond à une évolution. Je ne veux pas dire que l'idée d'un OS hyper web me réjouisse. C'est pas franchement le cas. Mais le fait d'être capable de réaliser un OS et un navigateur de qualité, basé sur du Linux (je ne connais pas l'OS de Google, approximation possible ), et surtout de l'introduire de façon convaincante pourra avoir de nombreux effets collatéraux, qui se détacheront peut être de la simple peur de Google.
Je ne crois pas franchement aux vertus du capitalisme, en général. Mais si je me souviens, les théoriciens de notre système économique préféré suppose que le marché doit être juste, notamment en permettant l'arrivée facile de nouveaux entrants. D'une certaine façon, Mozilla a provoqué cette révolution chez les navigateurs. Pensez à ceux cités plus haut, mais aussi à Konqueror, ReKonq, Epiphany... ca fait du monde, pas toujours visible, certes, mais là. Et il n'est pas forcément bien vu de parler d'IE. Pourrait-ce être la même chose pour cet OS? Google aura-t-il la force de percer la carapace hégémonique protégeant le système actuellement majoritaire? Allez savoir... De toutes façons, ni Novell, ni Red Hat, et encore moins Canonical, ne pourraient le faire.
PS : ou alors, cette alliance, ce serait aussi efficace que la fusion dans dragon Ball Z. Mais bon. Je suis sceptique.
Je trouve personnellement que l'auteur accorde une trop grande force à Ubuntu, ou plutôt à Canonical. Cette entreprise est faible, à mes yeux, elle est issue du mécénat, pas d'une croissance folle initiée par le support de produits open source. Je ne dis pas que sa raison d'être est mauvaise, que créer une entreprise pour le bien de la communauté, c'est mal. Seulement, cette entreprise n'a pas de recours, que ce soit pour créer un produit aussi performant que ce qu'on peut attendre d'un OS Google, surtout si l'OS est basé sur du connu, genre Linux, surtout si le navigateur, présenté comme le centre névralgique de la machine, est archi testé et hyper performant.
D'ailleurs, les évolutions du navigateur made in Mozilla seront certainement révélatrices dans les prochains mois. Si la version 3.6 apporte effectivement des fonctionnalités et progrès intéressants, bien que parfois légers, là non plus je ne pense pas que ça soit suffisant. Mais contrairement à Canonical, Mozilla a plein de ressources, car il ne s'agit plus ici d'une entreprise privée, mais d'une entité à but non-lucratif... Cette entité fait vaciller le géant Microsoft jour après jour un peu plus, et, mieux, a trouver la force, un jour, de relancer une guerre des navigateurs que tout le monde croyait terminée. De permettre l'entrée de nouveaux venus, Chrome et, dans une moindre mesure, Safari.
Enfin, malheureusement, oui, je pense que ce que Google essaie de produire correspond à une évolution. Je ne veux pas dire que l'idée d'un OS hyper web me réjouisse. C'est pas franchement le cas. Mais le fait d'être capable de réaliser un OS et un navigateur de qualité, basé sur du Linux (je ne connais pas l'OS de Google, approximation possible ), et surtout de l'introduire de façon convaincante pourra avoir de nombreux effets collatéraux, qui se détacheront peut être de la simple peur de Google.
Je ne crois pas franchement aux vertus du capitalisme, en général. Mais si je me souviens, les théoriciens de notre système économique préféré suppose que le marché doit être juste, notamment en permettant l'arrivée facile de nouveaux entrants. D'une certaine façon, Mozilla a provoqué cette révolution chez les navigateurs. Pensez à ceux cités plus haut, mais aussi à Konqueror, ReKonq, Epiphany... ca fait du monde, pas toujours visible, certes, mais là. Et il n'est pas forcément bien vu de parler d'IE. Pourrait-ce être la même chose pour cet OS? Google aura-t-il la force de percer la carapace hégémonique protégeant le système actuellement majoritaire? Allez savoir... De toutes façons, ni Novell, ni Red Hat, et encore moins Canonical, ne pourraient le faire.
PS : ou alors, cette alliance, ce serait aussi efficace que la fusion dans dragon Ball Z. Mais bon. Je suis sceptique.
25/01/2010
Ligne de commande et presse papier.
Ce message est une réponse (informative) au poste de Jonathan Winandy, parlant de la communication entre pbcopy et pbpaste, et le presse papier de Mac OS X. Ce post m'a donné envie de chercher quelque chose du genre sous Linux... et j'étais un peu dubitatif...
Voilà voilà... Dites, vous connaissez xclip? xclip est un utilitaire capable d'assurer la communication entre le presse papier de X11 et la ligne de commande. Son utilisation est on ne peut plus simple... Il suffit juste de s'appuyer sur la redirection des flux anonymes dont dispose tout Unix bien construit.... Mais une petite illustration, avant, pour toi, public :
va vous afficher le contenu du presse papier dans la ligne de commande. Cool, mais ce n'est pas tout. Si le contenu change (quelle que soit la politique de X11 en la matière, je pense), la valeur renvoyée par xclip changera, évidemment.
Continuons. Dans l'autre sens, maintenant... pour que ça marche, on va devoir se farcir de la redirection de flux. Rien de bien grave, hein. Je veux dire : sur un forum, on me demande la fin de mon dmesg (exemple idiot, j'aime pas les commandes pour rien). Par habitude, je fait
Là je veux balancer direct sur le presse papier, pour gagner du temps :
Et en théorie, c'est bon :)
Notes : Je ne maîtrise pas totalement la communication, notamment avec klipper, le machin de KDE...
Par ailleurs, on peut choisir directement le contexte graphique avec lequel on communique. Enfin je crois. Je sais pas trop me servir de ça. (a priori en se servant des annonces de Displays, comme d'habitude. Qui se sert de ça? Peut être pour faire remonter des infos par ssh, mais de façon tordue :p )
La chose est plus ancienne que ce machin prétendumment construit exprès avec COCOA, sous Mac... Comme quoi, tout ne vient pas forcément de là, n'en déplaise à certains ;)
Enfin, pour installer la chose sous openSUSE, parcequ'elle ne l'est pas (mais elle est dans les dépots de base, genre essentiels, genre tu les as pas tu meurs...) :
Oh, une dernière chose : xclip ne fait pas de pornographie ;)
Voilà voilà... Dites, vous connaissez xclip? xclip est un utilitaire capable d'assurer la communication entre le presse papier de X11 et la ligne de commande. Son utilisation est on ne peut plus simple... Il suffit juste de s'appuyer sur la redirection des flux anonymes dont dispose tout Unix bien construit.... Mais une petite illustration, avant, pour toi, public :
xclip -outva vous afficher le contenu du presse papier dans la ligne de commande. Cool, mais ce n'est pas tout. Si le contenu change (quelle que soit la politique de X11 en la matière, je pense), la valeur renvoyée par xclip changera, évidemment.
Continuons. Dans l'autre sens, maintenant... pour que ça marche, on va devoir se farcir de la redirection de flux. Rien de bien grave, hein. Je veux dire : sur un forum, on me demande la fin de mon dmesg (exemple idiot, j'aime pas les commandes pour rien). Par habitude, je fait
dmesg | tailLà je veux balancer direct sur le presse papier, pour gagner du temps :
dmesg | tail | xclip -inEt en théorie, c'est bon :)
Notes : Je ne maîtrise pas totalement la communication, notamment avec klipper, le machin de KDE...
Par ailleurs, on peut choisir directement le contexte graphique avec lequel on communique. Enfin je crois. Je sais pas trop me servir de ça. (a priori en se servant des annonces de Displays, comme d'habitude. Qui se sert de ça? Peut être pour faire remonter des infos par ssh, mais de façon tordue :p )
La chose est plus ancienne que ce machin prétendumment construit exprès avec COCOA, sous Mac... Comme quoi, tout ne vient pas forcément de là, n'en déplaise à certains ;)
Enfin, pour installer la chose sous openSUSE, parcequ'elle ne l'est pas (mais elle est dans les dépots de base, genre essentiels, genre tu les as pas tu meurs...) :
zypper in xclipOh, une dernière chose : xclip ne fait pas de pornographie ;)
18/01/2010
Disponibilité
Actuellement, la documentation de la communauté Alionet, entretenue par feu la communauté Kameleon-Facile, est en restructuration en vue d'une installation dans linuxpedia.fr. Cette migration apporte plusieurs changements au sein de l'équipe Alionet...
Tout d'abord, pour la nouvelle équipe d'administration, il s'agit du premier projet digne de ce nom à mener. Discrétement, nous essayons donc de faire de la gestion de projet, en utilisant les outils les mieux adaptés, que ce soit pour la conception ou pour la communication, en passant par la représentation provisoire du wiki dans un endroit peu visible du reste du monde, pour pouvoir faire les choses tranquillement.
Le problème, aujourd'hui, c'est que toute l'ancienne documentation, celle de Kameleon-Facile, est hébergée (en attendant) sur linuxpedia.fr... et le site est down, malheureusement.
Tout d'abord, pour la nouvelle équipe d'administration, il s'agit du premier projet digne de ce nom à mener. Discrétement, nous essayons donc de faire de la gestion de projet, en utilisant les outils les mieux adaptés, que ce soit pour la conception ou pour la communication, en passant par la représentation provisoire du wiki dans un endroit peu visible du reste du monde, pour pouvoir faire les choses tranquillement.
Le problème, aujourd'hui, c'est que toute l'ancienne documentation, celle de Kameleon-Facile, est hébergée (en attendant) sur linuxpedia.fr... et le site est down, malheureusement.
15/01/2010
Lecteur optique et ligne de commande
A priori, quand on veut se servir d'un lecteur de cd, on a tendance à passer par les interfaces graphiques... Et pourtant... la ligne de commande est toujours là pour nous! Quelques exemples...
Je suis sous linux, mon lecteur n'éjecte plus le disque (ou le rack, quand il est vide). Pas de panique. Un petit
et c'est reparti.
Mon interface graphique est plantée ou inexistante, et j'ai besoin de graver une image iso présente sur le disque dur. Là encore, c'est possible :
où vous mettez le chemin vers votre lecteur après -dev= ;)
Enfin, pour encoder un cd audio sans s'embêter, un petit
fera la chose pour vous, en vous récupérant même les infos CDDB, pour peu que vous soyez connecté à Internet!
Je suis sous linux, mon lecteur n'éjecte plus le disque (ou le rack, quand il est vide). Pas de panique. Un petit
ejectet c'est reparti.
Mon interface graphique est plantée ou inexistante, et j'ai besoin de graver une image iso présente sur le disque dur. Là encore, c'est possible :
cdrecord -v -dev=’/dev/scd0′ kubuntu-9.10-alternate-i386.isooù vous mettez le chemin vers votre lecteur après -dev= ;)
Enfin, pour encoder un cd audio sans s'embêter, un petit
abcdefera la chose pour vous, en vous récupérant même les infos CDDB, pour peu que vous soyez connecté à Internet!
14/01/2010
Ark et les pdf
J'ai beau utiliser KDE4, et plus généralement GNU/Linux, depuis quelques temps déjà, je trouve toujours le temps de découvrir des fonctionnalités sympas ou étonnantes... genre, là, par hasard, je viens d'ouvrir un pdf dans une archive zip, en sachant à peine si j'allais pas me faire gueuler dessus. Rien de tout ça. Mieux, plutôt que de m'ouvrir une fenêtre supplémentaire, ark est allé chercher Okular, mon lecteur de pdf favori, et a réalisé un affichage intégré dans sa propre fenêtre. C'est pas optimisé pour tous les cas de figure. Mais là ça me fait bien plaisir :)
08/01/2010
La vente liée, c'est pas seulement mal...
A force de fouiner doucement à droite à gauche, je suis tombé sur ce post sur le blog FSF . De bonnes nouvelles dedans... notamment, les utilisateurs vont pouvoir choisir leur navigateur internet dès l'installation de Windows... merci l'Europe, qu'on ne me dise plus qu'elle ne sert à rien ;) . L'auteur continue, embraie sur la vente liée et les abus de position dominante de Microsoft...
Juste une remarque... Certes cette situation est très mauvaise, pour pleins de raisons. Le jour où les vendeurs de PC arrêteront ça, il faudra toujours qu'ils préparent leurs machines. Parcequ'un utilsiateur avec une machine nue, il change de fournisseur... ^_^
Juste une remarque... Certes cette situation est très mauvaise, pour pleins de raisons. Le jour où les vendeurs de PC arrêteront ça, il faudra toujours qu'ils préparent leurs machines. Parcequ'un utilsiateur avec une machine nue, il change de fournisseur... ^_^
Inscription à :
Articles (Atom)
