Barnabé a écrit 682 commentaires

Le problème de la différence entre le Passe Navigo et la version découverte est complètement anecdotique.

La vraie question est plutôt :
- En quoi la RATP a-t-elle besoin de conserver des informations nominatives sur les trajets des abonnés ?

Le passe découverte est une mauvaise réponse à ce problème. La bonne serait à mon sens l'interdiction pure et simple du fichier.

Ceci dit, j'ai un passe découverte, je le recharge tous les mois en liquide.

Je ne fais jamais d'autres trajets que domicile-travail-domicile, mais c'est ma vie, et je refuse de faciliter le travail de ceux qui veulent la mettre en fiches.

Encore faut-il avoir eu conscience du problème avant que ton patron ne reçoive cette photo de toi tout nu debout sur le bar.

Tu parles de bisounours, et tu ne vois pas que tes photos ne sont privées que tant que Google le désire...

Il suffit d'un changement unilatéral des conditions d'utilisation de Picasa, (changement que tu as déjà accepté, même si il n'est pas encore fait) pour que subitement les photos que tu croyais privées ne le soient plus.

Il ne fait pas ses keynotes le Vendredi...

Elle est inacceptable pour moi.

Il revient à chacun de la lire et de faire son choix.

Pour ce qui me gène, il y en a pas mal. Par exemple, ceux d'entre vous qui ont installé Chrome ont donné à Google l'autorisation d'aller désinstaller du logiciel de leur machine (article 20).

Dans le même genre, accepter cette licence revient à accepter les versions futures, sans être prévenus des changements (article 18).

L'article 7, appliqué à un navigateur WEB, autorise Google à « pré-visualiser, réviser, marquer, filtrer, modifier, refuser ou retirer » tout le contenu généré à l'aide du navigateur.

L'article 3 est manifestement illégal en France.

Et plus généralement, le coté complètement déséquilibré de ce genre de contrat, ou les devoirs sont pour l'utilisateur et les droits pour l'éditeur.

La différence principale est que la licence d'utilisation de Chrome est inacceptable.

Lisez la bien.

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. »