Barnabé a écrit 701 commentaires

Je dirais pas grand chose, sinon le respect des standards.

Avoir un script configure, pas forcément issu des autotools, qui vérifie la présence des bibliothèques nécessaires et affiche clairement lesquelles manquent est un gros plus pour le packager.

Avoir un make qui ne fasse que compiler, et un make install qui ne fasse qu'installer est aussi une bonne base.

Sinon, un fichier INSTALL décrivant les éventuelles spécificités, un fichier LICENCE ou COPYING, un README contenant une description brève que le packager puisse pomper honteusement....

Kdelibs et grub sont deux exemples contestables

Kdelibs n'est compliqué que par ce que les mainteneurs Debian le fragmentent et l'adaptent. Tu peux faire un paquet des librairies KDE avec un fichier rules de 2 lignes, dont 1 générée par dh_make :
#!/usr/bin/make -f

include /usr/share/cdbs/1/rules/debhelper.mk
include /usr/share/cdbs/1/class/cmake.mk


Grub est l'exemple typique du paquet qui doit être maintenu par la distribution et pas par les développeurs upstream. Il est vital que son intégration avec le système soit très bien faite. De plus, le fichier rules de grub a l'air compliqué, mais il a été généré à partir du template des debhelpers, le packager ne l'a pas entièrement tapé à la main.

D'autre part, sur les exigences futures de Setup, tu verra assez vite que chacune d'elle augmente la complexité et la taille du code, et ralenti l'execution. Quand tu seras isofonctionnel avec les outils debian, tu te trouveras avec sensiblement les mêmes performances qu'eux, si tu codes aussi bien qu'eux.

Enfin, si tu veux faire des comparaisons de performance, apprend mieux à quoi servent les outils avec lesquels tu compare. Par exemple, setup search ne se compare pas à apt-cache, mais à dpkg -l, pour les exemples que tu donne.

Encore une incomprehension de l'écosystème.

Ce n'est pas le développeur de wormux qui fait les paquets, ce sont les packageurs des distributions.

Je ne savais pas trop où te situer, ton manque d'humilité m'aide à te placer :
Sur une échelle qui irait de Jayce à Linus, tu restes très près de Jayce, la folie en moins.

Seulement, quand les paquets deviennent un peu complexes (plusieurs binaires, bibliothèques, etc), ça devient plus difficile. Il faut adapter le Control pour que ça marche, le fichier Rules se complexifie, etc.
Si cette argument était étayé par des exemples, il en deviendrait plus persuasif.

Mon point est que même si faire un paquet debian satisfaisant les exigences de debian est difficile, faire un paquet debian au même niveau d'exigences que celui de logram est aisé.

Par exemple, on est pas obligé de faire quoi que ce soit de spécial pour un paquet contenant plusieurs binaires. C'est un choix de la distribution, pas du système de paquet, de les traiter différemment.

Mais pour une autre raison.

Il faut cesser de croire que créer des paquets est compliqué. Faire un .deb est moins compliqué que ce que j'ai pu lire ici : http://logram-project.org/wiki-setup-package.html

Je le prouve :

wget ftp://ftp.vim.org/pub/vim/unix/vim-7.2.tar.bz2
tar xf vim-7.2.tar.bz2
mv vim72 vim-7.2 # nom canonique du repertoire
dh_make -b --createorig # On utilise cdbs

rm debian/*ex debian/*EX # On supprime les exemples inutiles
emacs debian/changelog # On met son nom :)
emacs debian/control # on decrit le paquet

debuild

Ceci donne un paquet équivalent à ce qui est décrit dans la page d'exemple de Setup.

Trois choses rendent la création de paquets ardue :

1 - La connaissance des outils. Le problème est le même pour tous les gestionnaires de paquets, et la documentation est le point noir pour les debs, jusqu'à ce qu'on tombe sur cette page: http://build-common.alioth.debian.org/cdbs-doc.html

2 - La bonne qualité du code. Un logiciel avec un Makefile pourri rendra difficile la création d'un paquet, pour tous les systèmes, alors qu'un soft qui sait comprendre DESTDIR=/chemin make install la rendra facile.

3 - L'adaptation au système cible, c'est à dire la séparation en plusieurs paquets binaires d'un paquet source, la création et l'application de patches, le respect de standards précis sur la place de certains fichiers... Ceci n'est absolument pas nécessaire quand on se fait un paquet pour soi, et semble encore assez éloigné des buts de Logram

Les RPMs sont un peu plus difficiles à aborder, car la syntaxe des .spec est moins standard que les Makefiles utilisés par debian, mais une fois les idiosyncrasies comprises, les tâches sont fondamentalement les mêmes.

« un poste de travail Open Source c’est possible »

Faudrait expliquer ça aux dirigeants de Linagora.....

Tu veux dire le sens évoqué par la phrase « Ils distribuent des copies contrefaites de la GPL ? »

Ce n'est pas la GPL qui est piratée, c'est un projet sous GPL.

Je n'ai pas trouvé de lien vers le bug tracker depuis le site openvpn.net

Pour l'activité du projet, je persiste.


$ svn log http://svn.openvpn.net/projects/openvpn/trunk/openvpn | head -2 | tail -1
r1435 | james | 2006-11-08 02:08:55 +0100 (mer. 08 nov. 2006) | 3 lignes


Pour la future release, on se fait une bonne idée de l'activité avec

svn log --stop-on-copy http://svn.openvpn.net/projects/openvpn/branches/BETA21/open(...) | grep -A 1 -- --- | grep ^r


Je ne sais pas du tout ce que permettent les licences Microsoft, j'ai juste demandé si vous aviez vérifié.

Sinon, au cas visiblement improbable où l'une des licences interdirait la virtualisation, je pense que la bonne attitude est de respecter la licence. Si on n'accorde pas la même valeur à la licence d'un produit microsoft qu'à la GPL, alors on n'a pas bien compris comment fonctionne le logiciel libre.

C'est mon respect de la licence Microsoft qui fait que je n'utilise pas leurs produits.

Sinon, pour répondre à la question posée, j'utiliserais tinc.

Il a un gros avantage sur OpenVPN : il n'est pas centralisé. Il établit des liens automatiquement entre les membres du VPN et établit les routes dans le VPN, ce qui permet une redondance naturelle. Il est au choix de niveau 2 ou de niveau 3. Son défaut est une gestion des certificats trop jeune, mais cela ne pénalise pas un réseau dont tous les nœuds sont administrés par la même personne.

Pour le tutoriel : http://www.linux.com/archive/feature/131343

OpenVPN est mourant.

Je ne confierais pas une partie aussi sensible d'une infrastructure à un projet dont la dernière release stable date de 2006, dont la release suivante est codée par un gars tout seul, et dont le bug tracker est introuvable.

Avez vous vérifié que les licences des produits Microsoft utilisés vous permettent ce type d'intégration ?

Et quand tu cherches Google dans Wikipedia, ca marche aussi ?

« Pour le moment, le libre n'a pas encore su démontrer qu'il pouvait faire un jeu de cette qualité »

Pour le moment, le propriétaire n'a pas su démontrer qu'il était compatible avec mon éthique.

Et le super installeur d'Ubuntu, il ne permet pas de configurer les accents ?

«Ubuntu devient le maitre étalon.»

D'accord, mais très talon alors.

Bon, maintenant, tu peux m'expliquer l'intérêt de OneSwarm? Je veux dire, il te sert à quoi?

- à échanger des fichiers légalement? ...
- à échanger des fichiers illégalement? ...

Cela ressemble un peu trop pour moi à l'argument classique : « Le flicage ne gène que les gens qui ont des choses à cacher »

Tu oublies l'utilité principale dans ton énumération : OneSwarm sert à protéger la vie privée des utilisateurs.

D'autre part, si tu pense que les libristes ne se sont opposés à HADOPI qu'à cause du spyware proprio, tu as raté un gros morceau du problème. Beaucoup pensent que la préservation des droits des artistes ne justifient pas l'espionnage des citoyens proposé par HADOPI.

Pourquoi ne sont elles pas disponibles ?

« Je vis très bien avec un GSM et un wifi. »

Il y a à peine 100 ans, on vivait très bien en se soignant au radium. Et puis des scientifiques se sont dit « on fait peut-être une connerie », et puis des usagers sont morts, et puis il y a eu des procès, environ 30 ans après sa découverte.

Pour l'amiante, on a maintenu pendant à peu près 100 ans qu'elle n'était pas dangereuse, et encore aujourd'hui, des canadiens se ravagent les poumons par ce qu' « ils vivent très bien avec l'amiante »

Ce n'est pas par ce que tu ignores les risques que tu cours que tu n'en cours aucun.

Tu n'as pas les moyens de savoir si tu es ou pas pas en train de te fabriquer une belle tumeur cérébrale, ou une autre saloperie qui te fera dire dans dix ans « on était pas au courant. »

Et si le premier africain dans l'espace avait été un noir affreux, issu d'une famille enrichie par la décolonisation et la corruption (cliché grossier, mais assumé), ça aurait été mieux ou moins bien que MS ? Et les métis, ils ont pas le droit de voler ?

« faire la distinction entre la couleur de peau » n'est pas faire preuve de racisme, dire qu'un noir est plus africain qu'un blanc, ou bien réduire un individu à sa seule couleur de peau, l'est. Quelle que soit la définition.

Le malentendu est dissipé :
la phrase « un africain blanc dans l'espace n'a rien de formidable, par rapport à si ça avait été un africain noir. » est fondamentalement raciste.
Ce qui fait un africain, ce n'est pas la couleur de sa peau, c'est l'Afrique.

Si ton proxy est sur le même LAN que ton poste client, alors cette optimisation n'apporte pas grand chose, car la communication sur le LAN est de l'ordre de 1000 fois plus rapide sur ton LAN que sur le réseau internet.

Dit d'une autre manière, le temps que tu vas gagner, c'est juste le temps que met un fichier html à aller de ton proxy à ton poste client, il est négligeable par rapport au temps de téléchargement du même fichier sur internet.

Sur debian, /bin/sh est bash. Sur ubuntu, c'est dash.
Je ne connais pas subprocess, mais a priori il forke le shell par défaut pour exécuter la commande, et dash ne permet pas les mêmes redirections que bash.

L'inconvenient de cette methode est que la compression de plein de petits fichiers est moins efficace que la compression d'un gros fichier les contenant tous.

Ma solution serait d'adjoindre à l'archive compressée un index du contenu. Ca se fait en 3 scripts basiques (un pour archiver, un autre pour lister et le troisieme pour extraire) ou bien en un script a peine plus chiadé qui devra gerer les options en ligne de commande et appeler tar.

Ceci dit, la lenteur de tar sur le listage d'un gros fichier ne m'a pas souvent géné.

Je ne suis pas plus fan de tar que des autres outils UNIX qui me permettent d'être beaucoup plus efficace que n'importe quel clicquodrome.