ErrTu a écrit 108 commentaires

Non, la sécurité n'est pas meilleure en paravirtualisé (en pratique, pas en théorie).

Le paravirtualisé, c'est pratique, ça apporte des fonctionnalités intéressantes, ça fait économiser de l'argent, ça fait consommer moins d'électricité et ça sauve des ours.

Mais si jamais un des OS virtualisés est infecté, alors il est possible que l'hyperviseur se fasse infecté lui-aussi. Et là, c'est la catastrophe car depuis l'hyperviseur on peut modifier toutes les OS virtualisés et ces-derniers ne peuvent s'en prémunir. Même si l'OS virtualisé est une forteresse imprenable, il tombera quand même si sa mémoire est modifiée par l'hyperviseur.

Mais il restera toujours une poignée d'irréductibles utilisateurs soucieux de leurs libertés - et tous les développeurs d'OpenBSD - pour faire avancer le projet. Ceux-là ne nagent pas pour gagner, ils ne perdront jamais.

La licence BSD est une licence libre très simple à comprendre (en 3 lignes on fait difficilement mieux), utilisée principalement par des personnes bien plus intéressées par la technique et l'élégance du code source (sans oublier leur liberté personnelle) que par les discussions interminables sur les licences ; que le code puisse être réutilisé dans un programme propriétaire importe peu. La licence BSD propose la liberté de partager avec _tout le monde_, ce qui est dans les objectifs d'au moins un des systèmes d'exploitation *BSD.

Il est vrai que du code sous licence BSD est utilisé par des sociétés pour faire du propriétaire, mais beaucoup d'entre-elles (bien plus que ce que l'on pourrait croire) jouent le jeu et contribuent en retour.

Du moment qu'il y a des standards pour communiquer et de la documentation pour écrire des pilotes, tout va pour le mieux dans le meilleur des mondes. Chacun est libre de choisir sa voie ; celle que la FSF montre n'est pas la seule à mériter l'intérêt des développeurs du libre.

Sachant que rien ne sera reversé aux logiciels libres de ce pack, c'est sûr, ça fait cher la pré-installation.

c'est vrai que ce n'est pas à "linux" ou à ses ayants droit de donner de telles directives (mais s'ils le rappellaient et qu'ils s'engagaient dans ce processus cela ferait peut-être avancer les choses), pourtant dans freeBSD, qui gère tout le système en "userland" de A à Z, c'est le même foutoir, tous les logiciels ont leurs fichiers de config dans le ~/ et c'est super pénible, d'autant plus que tous les logiciels ne gèrent pas pareil l'affichage de ces fichiers : certains les cachent par défaut, d'autres pas, bref, là aussi cela pourrait être normalisé.

Les ports (ou packages) fournit avec les *BSD ne sont que des logiciels tiers dont le but n'est pas forcément d'avoir une intégration parfaite. Ces logiciels ne sont pas dans les dépôts de développement de ces systèmes d'exploitation. Ils ne sont pas ou très peu audités par les développeur *BSD comme l'est le système de base.
En revanche, tout ce qui se trouve dans les dépôts sont quand à eux très bien intégrés. C'est tout à fait comparable aux systèmes de paquets des distributions linux excepté qu'à la base il n'y a ni le noyau linux, ni GNU (enfin si gcc et quelques autres...).

Donc pour tout normaliser, il faudrait créer des patches pour une bonne partie de ces ports (et ensuite les faire adopter en upstream), ce qui est quand même un boulot assez considérable. De plus les distributions linux peuvent parfaitement en faire de même pour leurs paquets.


Personnellement avoir tous les fichiers de configuration directement dans ~/ ne me dérange plus. Étant donné que d'une part, dans mon utilisation courante, je n'affiche pas ces fichiers donc je ne les vois pas (eh eh logique) et ils sont très bien là où ils sont. Limite les recommandation de freedesktop me gène plus qu'autre chose. Oui, il est plus rapide de faire "vi .mplayer/config" ou "vi .vimrc" que de faire "vi .config/openbox/rc.xml".

Pour ceux qui comme moi sont assez allergiques au site voyages-sncf.com, je vous conseille d'aller voir le site de la Deutsche Bahn qui est autrement plus léger (pas de flash, pas trop de pubs, pas trop de javascript à outrance, ...) et est pratiquement en HTML valide.

http://reiseauskunft.bahn.de/bin/query.exe/fn

Bon ce n'est que pour consulter les horraires puisque l'on ne peut pas réserver sur les trains français à partir de ce site mais à part ça, il fait bien son boulot.

Au niveau de la commande de connexion, l'ordre des paramètres est tel qu'il est pour des raisons "historiques" ; elle est en fait calquée sur celle qui existe actuellement dans irssi pour se connecter à un serveur irc. Il faudra que je me penche sur la question pour refaire une commande de connexion adaptée à jabber. Par exemple spécifier le serveur en plus de celui qui est dans le JID est une information redondante qu'il n'est pas forcément nécessaire de spécifier plusieurs fois. De plus le port devrait être une information non obligatoire puisqu'il est courant d'utiliser le port par défaut.
Quelque chose comme me l'avait suggéré David Ammouial serait beaucoup plus approprié :
/connect [-ssl] -xmppnet <network> <jid> <password> [<servfer>[:<port>]]
Enfin la commande /connect est bien ancrée dans irssi, donc ça me demandera pas mal de boulot de recherche pour savoir comment je peux la modifier en profondeur. Mais c'est bon, ça ne me décourage pas, au contraire :)
À la limite, on pourrait imaginer une nouvelle commande autre que /connect ou /server spécialement dédiée à la connexion à des serveurs jabber, comme /xmppconnect, ...

Au niveau d'autotools, je n'ai pas pris le temps et je ne le prendrais sûrement pas pour faire un beau configure. La méthode actuelle avec un simple Makefile marche pas mal (en tout cas moi ça me convient). Mais je suis ouvert à toute personne souhaitant adapter à un quelconque système de compilation du moment que ça reste relativement simple et que ça ne rajoute pas de nouvelles dépendances non nécessaires.

Ça fait plaisir d'avoir des encouragements :)

J'ai mis en place un page un peu plus clair pour résumer le projet :
http://cybione.org/src/irssi-xmpp/

Le module est maintenant en partie hébergé chez gna! qui fournit un dépôt CVS, un bug tracker, un task manager et une mailing-list. Tous les détails sont sur la page citée plus haut.

J'ai oublié de le mentionner mais pour les utilisateurs d'openSUSE, des paquets[1] sont (ou seront) disponibles sur le dépôt Guru[2].

[1] http://linux01.gwdg.de/~pbleser/rpm-navigation.php?cat=/Netw(...)
[2] http://opensuse-community.org/Guru

Bon, je continue dans mon monologue pour vous annoncer irssi-xmpp 0.13. Cette version intègre la gestion des contacts donc à partir de maintenant le module supporte toutes les fonctionnalités de bases pour l'utiliser en tant que client jabber.

Donc au programme :
- La gestion des contacts et des autorisations
- L'option de conf "roster_add_send_subscribe" pour envoyer automatiquement une requête subscribe lorsque l'on ajoute un contact au roster.
- L'option de conf "xmpp_priority" pour spécifier la priorité de la connexion. Il faudra se reconnecter après avoir modifié cette variable.
- La commande /CONNECT vérifie correctement ses paramètres.
- Et enfin une petite modification dans les Makefiles pour que le module compile chez ceux qui n'ont pas les commandes "lorder" et "tsort".

Le fichier README contient une documentation beaucoup plus complète où pratiquement tout est décrit.

La commandes /ROSTER se voit dotée de 2 jeux de commandes. Le premier pour gérer les contacts dans la liste et l'autre pour gérer le autorisation.

Ainsi pour gérer les contacts, on a pour ajouter un contact :

/ROSTER ADD «jid»

Pour supprimer un contact (et toutes ses autorisations) :

/ROSTER REMOVE «jid»

Pour renommer un contact :

/ROSTER NAME «jid» «name»

À savoir que même si on peut spécifier un nom, il n'apparaîtra que dans la liste des contacts et si l'on souhaite faire un /QUERY sur un contact, il faut toujours passer par le JID et non par le nom.
Enfin pour changer un contact de groupe :

/ROSTER GROUP «jid» «group»

Au niveau des autorisations, on peut demander à voir la présence d'un contact avec :

/ROSTER SUBSCRIBE «jid»

Si on souhaite ne plus voir sa présence, il suffit de faire :

/ROSTER UNSUBSCRIBE «jid»

Lorsque l'on reçoit une demande d'autorisation, pour qu'un contact puisse voir votre présence, on peut accepter cette demande avec :

/ROSTER ACCEPT «jid»

Et enfin si on ne veut plus qu'un contact puisse voir votre présence ;

/ROSTER DENY «jid»

C'en est tout pour cette version 0.13. Pour la prochaine version, on devrait voir arriver la sauvegarde des sessions pour pouvoir automatiquement se reconnecter lorsqu'une connexion est rompue, la possibilité de voir les informations concernant un contact (globalement sa vCard) et quelques améliorations par ci par là. Ainsi la prochaine grosse étape sera le support des MUC.

uh uh uh une dépêche pour présenter le module :)

Voici venir la version 0.12 : http://cybione.org/src/irssi-xmpp/irssi-xmpp-0.12.tar.gz

Au programme :
- Le support de la connexion SSL : pour en profiter, il faut rajouter "-ssl" à la commande "/connect", où "use_ssl = "yes";" dans votre section "servers" de votre fichier de conf. (pour le moment, si la connection n'abouti pas, la connection se retrouve bloquée, alors ne vous trompez pas !)
- La complétion des JID et des ressources est maintenant complète
- Si on ouvre une fenêtre de discussion avec "/query jid" sans spécifier la ressource, cela ouvrira la fenêtre avec la ressource la plus élevée du jid (s'il y en a de connecté biensûr)
- Des petites choses de modifiées dans la liste des contacts (on affiche le niveau de subscription s'il n'est pas à "both", on n'affiche plus les groupes vides, on peut changer le nom du groupe par défaut)
- Et enfin l'ajout de la variable de configuration "xmpp_default_away_mode" que l'on peut mettre à "away", "xa", "dnd" ou "chat" pour choisir le mode de disponibilité que l'on veut lorsque l'on ne le spécifie pas avec la commande /away. Par défaut elle est fixée à "away". (par exemple : "/set xmpp_default_away_mode xa", "/away plus là" équivaut à "/away xa plus là")

À venir probablement pour la prochaine version : la gestion des contacts et des groupes.

Exactement, c'est lié aux ressources. Chaque ressource est en fait une connection sur un même compte jabber. Ainsi si une personne se connecte de plusieurs endroits à la fois, plusieurs ressources apparaitront.

Le comportement par défaut de /query ne prend pas en compte les ressources si on ne les spécifies pas. Dans la prochaine version, si l'utilisateur est connecté et que l'on fait /q xy@z cela ouvrira une fenêtre de query sur sa ressource qui a la priorité la plus élevée. Donc on n'aura plus ce phénomène. En revanche si l'utilisateur n'est pas connecté, on n'en tiendra pas compte (évidement puisqu'il n'y aura aucune ressource de disponnible).

http://cybione.org/src/irssi-xmpp/irssi-xmpp-0.11.tar.gz

Voilà irssi-xmpp version 0.11. Au programme, les petites choses que tu avais demandé Landry et quelques corrections de bugs :

- L'autocomplétion des JID et aussi des ressources. La complétion des ressources n'est pas encore complète, pour l'avoir faut taper un truc du genre : /q foo@bar.bar/«TAB» (où «TAB» est l'appui sur la touche tabulation biensûr).

- La possibilité de n'afficher que les contacts connectés avec : /SET roster_show_offline OFF

- La possibilité de ne pas envoyer les informations sur la version du client avec : /SET xmpp_send_version OFF
À l'occasion, le nom du système d'exploitation renvoyé est bien celui que vous utilisez.

- Le roster trie les contacts correctement.

Arg, Templeet m'a mangé tout les "<", ">" et ce qu'il y avait dedans. Pourtant quand j'ai rédigé le message, je les avais remplacés par des "&lt;" et "&gt;" mais visiblement ça n'a pas suffi.

Donc en fait, pour se connecter, il fallait lire :
/server -xmppnet <network> <server> <port> <password> <username>

Et pour les commandes de changement d'état (dans l'ordre) :
/away <message>
/away chat <message>
/away dnd <message>
/away xa <message>
/away

Je suis on ne peut plus d'accord avec toi, c'est d'ailleurs ce qui fait l'une des forces du logiciel libre.

Ça fait un petit moment que je voulais faire évoluer la prise en charge de jabber dans irssi et comme j'ai eu récement un peu plus de temps et de motivation à y consacrer, j'ai décidé de mettre les mains dans le camboui.

Seulement ça me paraissait impossible de contribuer à irssi-jabber pensant ne pas avoir les compétences pour. Donc j'ai commencé à bricoler dans mon coin pour comprendre comment fonctionne les modules irssi et le protocole XMPP. Sans m'en rendre compte j'avais obtenu une bonne base et quelques heures de boulot supplémentaires on suffit pour faire voir le jour à irssi-xmpp.

À mon niveau actuel de compréhension je pourrais contribuer sans trop de problème à irssi-jabber mais comme irssi-xmpp en est pratiquement au même stade de fonctionnalités, l'interêt n'y est plus.

Maintenant techniquement, les deux modules sont assez différent puisque irssi-jabber intrègre son propre parser XML et utilise les sockets d'irssi alors qu'irssi-xmpp se base entièrement sur loudmouth. Personnellement je trouve irssi-xmpp plus facile à maintenir car il n'intrègre pas toute la brique bas niveau de communication avec le protocole XMPP.

les posts se suivent et se complètent .....

Çool ?

non.

Oh, ça fait plaisir de découvrir un tel projet. Moi qui ne peut se séparer d'irssi, j'utilise bitlbee pour me connecter à jabber (et uniquement jabber).

Jabber directement dans irssi sans proxy ni quoi que ce soit, il faut que j'aille essayer ça.

Mplayer est capable de lire et d'interpréter une grosse partie du format ASS avec sa libass. Peut-être que l'on peut l'utiliser pour encoder avec Mencoder.
Sinon dans la version de développement d'Avidemux, ils ont ajouté le support de la libass de mplayer. Tu devrais aller jetter un coup d'oeil sur leur svn.

Il y a deux ans, j'ai entendu parlé sur le forum tt-hardware d'un tout petit importateur en allemagne. Celui-ci achetait par dix des protables directement chez le producteur à Taïwan. Il s'appelait getbestmobile.de mais il a du changer de nom à cause d'un conflit avec getmobile.de, il devrait s'appeler notebookbuilder.de maintenant mais le site ne correspond pas dutout. Donc je suppose qu'il a fermé.

C'était un peu un pari mais j'ai commandé là-bas un Compal CL56 sans OS à un prix vraiment attractif par rapport à ce qu'il se vendait en france. Je ne suis vraiment pas déçu de l'avoir acheté.

Effectivement, il y a des prises électriques dans certains TER. Le hic c'est qu'elles ne fonctionnent que quand le train roule (s'il est en gare, c'est rapé).

Ensuite je ne sais pas si c'est à cause de ça mais je n'ai jamais réussis à refaire marcher mon boitier de disque dur après l'avoir branché sur une de ces prises.

À noter que la version 0.2 de warsow vient tout juste de sortir. Au programme un nouveau netcode (avec antilag), une amélioration du gameplay, des cartes et de nombreux bugs corrigés. Le changelog complet : http://www.warsow.net/changelog.txt

C'est un excellent fps qui vaut le coup d'½il. D'ailleurs il me tarde de tester cette nouvelle version avec ma radeon 9250 (et ses pilotes libres).

Soit c'est moi, soit le paquet gstreamer-plugins-base-0.10-dev est mysterieusement apparu dans l'archive debian. Enfin bref, ça compile parfaitement maintenant.

Après l'abandon de sabbu par son développeur (chez moi sabbu n'arrête pas de retourner des erreurs de ségmentations, il me semble que c'était depuis un apt-get update/upgrade qui a mis à jour la glibc), ça fait plaisir de voir arriver un autre logiciel de ce genre sous gnu/linux. À force, on va bien finir par avoir une plateforme de sous-titrage amateur assez performante sous notre os favori.

Pour parler plus précisément de subtitleeditor, je trouve se logiciel fort sympathique et prometteur. Le format ASS a l'air d'être très bien supporté et j'aime beaucoup le fait de pouvoir afficher ou non les colonnes associées aux fonctions des lignes de sous-titres ASS, ça permet de gagner en place et clarté sur ces lignes virant les colonnes qui ne sont pas necessaires.
Il a la possibilité de charger un grand nombre de fichiers audio et vidéo. Ça fait plaisir de pouvoir ouvrir une bande son en Flac.
Il possède quelques fonctions classiques pour la manipulation des sous-titres tel qu'ajuster les temps d'affichage des sous-titres avec les fps. Par contre j'ai un gros doute sur le fait qu'il soit capable de déplacer les temps d'affichage dans le cas où l'on change de bande son pour une qui n'a pas de publicité au milieu (par exemple).

Ce qui manque vraiment c'est qu'il ne soit pas assez "optimisé" niveau synchronisation des sous-titres avec l'audio.
Tout d'abord il y a le carré noir où est censé apparaitre la vidéo mais je n'ai jamais réussi à afficher quoique ce soit dedans. Chez moi, mplayer s'ouvre dans une fenêtre à côté. Et comme de toute façon la vidéo n'est pas interessante pour faire une synchronisation brute à partir de l'audio, ça me bloque une partie de l'écran. Il serait bien qu'on puisse masquer ce carré pour pouvoir laisser plus de place à la waveform.
Ensuite il y a un manque cruel de fonctions, raccourcis et boutons permettant de simplifier et de rendre plus rapide la synchronisation, par exemple : lire les cinquante dernières millisecondes de la sélection, ...
Si toutes les fonctions pouvaient être associées à des raccourcis claviers (pourquoi pas personnalisables), ça pourrait être encore plus pratique.
Et le dernier point, il manque la possibilité de personnaliser les couleurs de la waveform car je trouve que celles par défaut ne sont pas les plus claires possibles. Par contre j'ai la forte impression que la waveform pixelise beaucoup (trop) lorsque l'on diminue le zoom et qu'on augmente le scale.

Voilà, j'ai à peu près fait le tour ^^

Sinon je galère un peu à le compiler sous Debian car il semblerai que gstreamer-plugins-base-0.10 n'existe pas avec pkg-config sous Debian et il n'arrive pas à trouver la librairie aspell. J'arrive quand même à lancer la compilation (avec gcc 4.1.2) en bricolant dans le configure.in (c'est à dire en virant gstreamer-plugins-base-0.10 et en changeant les instructions pour détecter aspell) mais il doit bien me manquer un paquet de développement car il n'apprecie pas trop et je me retrouve avec l'erreur suivante :
TimingSystem.cc:40:37: error: gst/interfaces/xoverlay.h: No such file or directory
TimingSystem.cc:41:41: error: gst/interfaces/colorbalance.h: No such file or directory

Tu essayes de charger un modules compilé avec une version de gcc différente de celle utilisée pour compiler le noyau donc ça coince.
Pour en savoir un peu plus, regarde les derniers messages de log avec : dmesg