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 :

man abcde

man oggenc

Nous 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
rm -r ~/.kde4/share/apps/amarok
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 :)

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,
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.org
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 ;)

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.

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 :

xclip -out
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
dmesg | tail
Là je veux balancer direct sur le presse papier, pour gagner du temps :
dmesg | tail | xclip -in
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...) :
zypper in xclip

Oh, une dernière chose : xclip ne fait pas de pornographie ;)

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.

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
eject
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 :
cdrecord -v -dev=’/dev/scd0′ kubuntu-9.10-alternate-i386.iso
où vous mettez le chemin vers votre lecteur après -dev= ;)
Enfin, pour encoder un cd audio sans s'embêter, un petit
abcde
fera la chose pour vous, en vous récupérant même les infos CDDB, pour peu que vous soyez connecté à Internet!