Moi, j'avais une étiquette « non merci » que j'étais aller demander à l'accueil de mon magasin Géant (sur leurs brochures de pub, c'est écrit en petit à la fin qu'il faut demander cet autocollant si on ne veut plus recevoir leurs pubs).
Et ben vous savez quoi ? Ça a rien changé, je recevais toujours leur pub tous les jours. Et quand je suis allé râler à l'accueil, ils m'ont dit que c'était pas de leur faute, parce que la distribution était faite par une boite extérieure. Limite que c'est moi qui me serait fait engueuler.
Euh, là, il ne s'agit pas de piratage, mais de copie privée. Si j'ai bien compris la new, ça veut dire que c'est officiel : si tu veux copier un DVD sur un autre support, il faut repayer.
Oui, mais la copie locale, quand su sauves, tu sauves la copie locale justement. Et le but de passer l'URL, c'est que le logiciel sache où uploader quand tu sauves.
(et pour relancer un autre troll des cavernes, regardes l'historique de ces derniers jours, c'est assez rigolo)
Il y a plusieurs trucs que je trouve essentiels pour un gestionnaire de version distribué. En fait, le but, c'est qu'il soit utilisable pour une contribution occasionnelle de 50 lignes comme pour du développement au quotidien.
Pour une contribution occasionnelle, ce que tu veux, c'est en une commande, avoire une copie locale et une branche locale, coder, commiter en local, et publier les changements facilement. Par exemple, avec darcs, tu fais "darcs get; ...; darcs record; darcs send" et le patch est envoyé par email au mainteneur. Avec bzr, la version envoie par email n'est pas encore implémentée, mais c'est dans la todolist. Mais "bzr branch" te donne une branche et une copie locale en une commande. Pas la peine de dire ou est le repository, la branche est dans le répertoire .bzr/ de la copie locale.
Pour publier des changements, l'envoie par mail est excellent pour des petites contributions, mais dès que ça prends de l'envergure, il faut pouvoir uploader ça sur un serveur. Et là, l'idée de bzr, héritée de GNU Arch, c'est de n'utiliser qu'un serveur de fichier. Tu as un compte chez free ? bzr push ftp://...@ftpperso/tralala et ta branche est publiée. Ça marche aussi avec sourceforge et gna en sftp par exemple. Le support WebDAV qui permet de passer à travers firewall+proxy pourrait être ajouté assez facilement.
Après, le coup de la branche dans le répertoire de travail, je trouve que ça n'a pas que des avantages. Par exemple, j'ai souvent un répertoire de travail (checkout) sur un disque local non sauvegardé, alors que les données du gestionnaire de version sont bien à l'abris sur un disque réseau sauvegardé périodiquement. Et justement, bzr permet aussi ce mode de fonctionnement. C'est à ma connaissance le seul qui permette de choisir entre "répertoire de travail = repository" et "repository + checkout".
Au niveau performances, il est raisonnablement rapide (derrière mercurial et git pour l'instant), mais il y a encore beaucoup de possibilités d'optimisations, dont certaines prèsque terminées et bientôt intégrées, donc il devrait être encore plus rapide d'ici quelques mois (et pour l'instant, c'est du python pur, sans un gramme d'optimisation en C).
Il y a aussi un système de plugin, que je comparerais aux extensions de firefox : de base, tu as un système simple et relativement minimal, mais tu peux ajouter des trucs plus évolués si ça te chante. Les plugins sont aussi un moyen de tester du code avant de l'intégrer dans bzr lui-même.
Canonical a une position très ambigue à mon gout. Il y a pleins de choses très bien chez Canonical. Launchpad n'est pas distribué et ça fait chier, mais il y a des idées très intéressanted dedans. Rosetta, qui est grosso-modo aussi flexible qu'un wiki, appliqué à la traduction des logiciels, c'est un truc formidable. Malone est un excellent tracker de bugs aussi. Sur Bazaar-NG, malgré toutes les critiques que j'ai au niveau politique sur la façon dont ils ont abandonné Bazaar avant que Bazaar-NG soit fini, c'est un gestionnaire de version excellent.
Au moins, si il n'y avait que du mauvais, ça serait poubelle illico, mais je ne crois pas que tout soit à jetter. Je crois surtout que c'est une boite à fréquenter avec prudence.
> tu as également du contribuer à tla et donc du subir d'autres déceptions, me trompe-je ?
Mes contributions à tla, elles sont plutôt limitées. Un bugfix de deux lignes qui a mis 3 mois à être accepté par Tom, une gestion des mots de passes dans le ~/.authinfo qui est tombé aux oubliettes, et a finalement fait son chemin dans Bazaar. Mais bon, le fait que Tom était un mainteneur plutôt radical et pas très intéressé par les contributions extérieures, c'est pas un grand secret.
Le truc con, dans l'histoire, c'est que selon mes critères, Bazaar-NG a bien l'air d'être le meilleur gestionnaire de version dispo aujourd'hui.
Donc, le dilemne suivant, c'est privilégier la politique ou la technique ... (et par ailleurs, il y a aussi des tas de gens très bien dans les développeurs de Bazaar-NG).
(mais par ailleurs, mes compétences en matière de gestion de version sont quand même assez modestes. Les modifs que j'ai faites dans Bazaar étaient principalement des question d'ergonomie et nettoyage de code).
Il n'y a pas eu de contrat avec des millions d'euros, mais ils font une annonce publique, sur le Wiki, et envoyé à plusieurs mailing-lists. Il me semble qu'il y a comme un contrat moral non ? Mais en effet, la loi n'oblige pas à tenir ses promesses.
Bon, je le saurais pour la prochaine fois : une promesse de Canonical, si y'a pas un contrat signé, c'est comme si ils avaient rien dit.
Le truc, c'est que la relation entre Canonical et la communauté est pas mal basée sur des promesses. Tiens, par exemple :
S'il n'en ont rien à fouttre des clients qui ne leur rapportent pas directement de la thune, qu'ils le disent. Mais franchement, à entendre Robert, il est tout dévoué à la communauté de Bazaar, et il ne veut pas même pas reconnaitre que Bazaar 1 n'est plus maintenu. Officiellement, Bazaar 1, c'est un logiciel en mode maintenance sur lequel le mainteneur n'a pas passé plus de dix minutes en six mois.
> Y a t'il des clients qui ont payé pour la maintenance de Bazar ?
Bah, il me semble avoir payé de ma personne, oui. Je n'attends pas qu'il se mettent à genoux devant moi, juste qu'ils tiennent leurs promesses.
Par ailleurs, Canonical ne nie pas vouloir faire de la thune sur ses développement (même si pour l'instant, il n'y a pas tellement de revenu autre que les réserves de Mark Shuttleworth). Si vous avez envie d'acheter du support chez Canonical, bah, vous savez juste à quoi vous attendre.
C'est évident que la version 2 sera mieux que la version 1. Bazaar-NG est techniquement très bon, et les choses qui se préparent pour la future 0.8 sont tout simplement excellents. Que Bazaar soit petit à petit abandonné, ce n'est pas une mauvaise chose en soi. La version 1 n'a pas d'avenir a long terme.
Le problème, c'est qu'un éditeur de logiciel un minimum sérieux, il prépare une transition. Chez Microsoft, qui est bien connu pour être que des méchants, tout ça tout ça, une version d'un logiciel continue à être maintenue pendant très longtemps après la sortie de la version n+1. Pas parce que la vieille version était mieux, juste parce que les gens n'ont pas forcément envie de migrer quand l'éditeur claque des doigts.
Ce que je voulais simplement, c'est que Bazaar 1 ait une fin convenable. Que les gens puissent continuer à l'utiliser en bénéficiant des dernières améliorations de la communauté. Juste comme ça avait été annoncé en grande pompe à l'époque :
Canonical will continue to support Bazaar during the Bazaar-NG development process. Future releases of Bazaar after 1.5 will contain fixes (such as security) but generally will not contain improvements. Bazaar 1 will have one or two more releases sponsored by Canonical. This will bring the project to a stable position to finish Bazaar-NG and give us time to test conversion logic from Bazaar 1 to Bazaar-NG.
Aujourd'hui, je viens de vérifier, le paquet qui est dans Ubuntu n'est même pas la dernière version stable, c'est la 1.4.2 qui a une gestion des archives toute buggée (archive-mirror segfault dès qu'on a une config un peu exotique). Et devinez qui c'est qui a corrigé les bugs dans la 1.4.3 qui servira jamais à personne ?
> Comme quoi l'avenir de Arch dépend de Andy TAI, mais je suis confiant.
Il fait du bon boulot, mais c'est un choix délibéré de ne pas introduire de modifications majeurs dans tla. Le but est simplement de faire vivre tla en attendant que la multitude de nouveaux projets (bzr, hg, git, et autres) se stabilise un peu. Il est plus qu'improbable que le système de cache de Bazaar finisse dans tla par exemple.
> Ce que je n'apprécie pas c'est des choses comme baz est une implémentation
> obsolète de Arch sur le wiki.
Rassures-toi, baz n'est plus mentionné sur la page d'accueil du wiki.
Taquin que je suis, je m'étais permis de remplacer « obsolete » par « unmaintained ». Ça n'a pas trainé, dans les deux jours, ma modification était censurée^W^W^W reformulée. C'est à dire que le lien vers Bazaar était supprimé.
En l'occurence, le temps, c'est moi qui l'ai passé. Sur 65 révisions de cette version, j'en ai écrit 60. J'ai passé du temps là dessus en me basant sur leurs promesse. Si ils comptaient abandonner Bazaar, ils pouvaient simplement le dire dès le début.
La release, pour Canonical, c'est quelques commandes pour construire le paquet Debian, et deux mails à envoyer.
Aujourd'hui, ma confiance en Canonical est au niveau zero. Canonical fait des promesses en l'air, et j'ai juste envie que ça se sache.
A leur place, j'aurais juste rien promis. Et ça m'aurait évité de perdre tout ce temps.
Pour la 1.4.3, c'était pareil. Robert m'a dit de préparer les backports de bugfixes de la 1.5 si je voulais. Je l'ai fait, j'ai écrit les release notes, il a mis trois mois à se décider à faire la release. Enfin, il ne l'a même pas fait, il m'a donné les droits pour le faire, parce qu'il n'avait même pas le temps de faire un "merge + commit" lui-même.
En même temps, si tu livres le binaire d'un logiciel libre vérolé, c'est facile de refaire un binaire non vérolé, mais vérifier que le binaire fourni est bien issu des sources, c'est une autre paire de manches : le processus de build est rarement totalement déterministe, il inclue en général des timestamps à gauche à droite, la moindre modification de l'environnement de build peut changer le binaire (pour prendre un exemple grossier, changer de version de GCC va forcément changer le binaire). Bref, reproduire exactement à l'indentique la chaine de build, c'est quasi-impossible. Et comparer les binaires à la main pour vérifier que les modifications sont sans importance pour la sécurité, bah, bon courrage.
Je viens de faire l'expérience avec un package Debian assez simple. Creation du package, sauvegarde dans un coin. Re-creation à partir des mêmes sources, même pas un "touch" entre temps, le deuxième package est plus gros de 10 octets.
Et quand bien même tu aurais la certitude que les sources sont bien celles du binaire, la backdoor peut être un buffer overflow bien caché (on a déjà du mal à trouver les buffer overflow quand on n'a pas fait exprès de les cacher, alors ...), elle peut être dans le compilo (cf. le fameux papier de je-sais-plus-qui), dans l'éditeur de lien, bref, n'importe où ...
(mais par ailleurs, il me semble que les sources de Windows fournies par MS sont compilables ;-) ).
Ça ressemble fort à un truc genre `uname -a` bidouillé pour avoir ta version de Windows en face de la case avec ton nom, mais avec autre chose que Windows.
Gimp pourrait attirer du monde, c'est vrai. Mais abiword, franchement, vu que 95% des windowsiens ont déjà word, la valeur ajoutée est difficile à trouver, vu qu'abiword gère beaucoup moins de choses que Word.
Selon les bouts de KDE qui sont portés, peut-être que des applies comme amarok peuvent attirer du monde.
Enfin, on verra. 1%, c'est à la fois peu et beaucoup, selon le point de vue. Je crois que c'est plus une question de marketing que de technique. Opera n'a jamais vraiment décolé bien qu'étant très bon, alors que firefox a vraiment réussi à s'imposer en peu de temps.
Tout dépends de ce qu'on appelle « La GUI windows par défaut ». Si c'est le toolkit par défaut, je suppose que dès qu'on a la moindre applie non Qt lancée, il faut charger les bibliothèques qui vont bien (d'ailleurs, même avec Qt, je sais pas si il ne faut pas les charger aussi).
Enfin, c'est pas pire qu'une application Qt lancée dans Gnome en tous cas, rien d'anormal.
et sitecopy regarde en local la liste des fichiers modifiés/ajoutés/supprimés, et ne fait les opérations que pour les fichiers qu'il faut. C'est tout. (pour des petits transfers, c'est même plutôt plus efficace que rsync, qui doit calculer la liste des fichiers de chaque côté. Là, si tu as un fichier à uploader, sitecopy va uploader ce fichier, et rien d'autre en terme de bande passante).
Bref, je maintiens, sitecopy est l'outil que tu cherches.
Je me demande si ce portage aura une incidence sur Gnome.
Vu que pour l'instant, Linux représente environ 1% des ordinateurs (un peu moins selon Xiti, un peu plus selon d'autres sources), Gnome et KDE représentent sans doute chacun moins de 0,5% des ordinateurs installés. C'est à dire que si 1% des utilisateurs de Windows installent KDE (y'en a bien déjà 15% qui ont installé firefox ...), ça multiplie par 3 le nombre d'utilisateurs de KDE. Et ça veut dire que KDE sera le point d'entrée privilégié pour les gens qui migrent de Windows vers un OS libre.
Est-ce que ça veut dire que KDE risque de bouffer Gnome (en terme de nombre d'utilisateurs) ?
Des bots qui cherchent dans google des pages avec des mots clés genre « submit », « create », ... et qui remplissent les champs au pif avec des URL de sites de Q, ça se fait aussi ...
Dire de toute urgence à l'admin de la machine distante qu'il désactive le démon telnet et qu'il mette sshd à la place.
telnet, c'est un protocole où le mot de passe passe en clair (le reste aussi, mais bon), c'est à éviter absoluement.
Sinon, je suppose que ton routeur fait du NAT, donc tu ne peux pas avoir de serveur derrière, et ton serveur X est justement un serveur. Solution : forwarder le port qui va bien de la passerelle vers ton PC, et setenv DISPLAY passerelle:0, ou quelque chose comme ça.
[^] # Re: Vu ma grande maîtrise de l'anglais
Posté par Matthieu Moy (site web personnel) . En réponse au journal Un mainteneur de la sécurité pour Debian jette l'éponge.. Évalué à 7.
Sinon, c'est asshole
[^] # Re: Avis aux FUDs
Posté par Matthieu Moy (site web personnel) . En réponse au journal GNU/Windows ?. Évalué à 2.
[^] # Re: Mhhhh....
Posté par Matthieu Moy (site web personnel) . En réponse au journal Encore une raison de charger vos imprimantes en papier recyclé. Évalué à 5.
Et ben vous savez quoi ? Ça a rien changé, je recevais toujours leur pub tous les jours. Et quand je suis allé râler à l'accueil, ils m'ont dit que c'était pas de leur faute, parce que la distribution était faite par une boite extérieure. Limite que c'est moi qui me serait fait engueuler.
Trop fort !
[^] # Re: Pffff
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche Copie privée des DVD : la cour de cassation a tranché !. Évalué à 10.
[^] # Re: À propos de GEdit
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche Un aperçu de GNOME 2.14. Évalué à 1.
[^] # Re: En même temps
Posté par Matthieu Moy (site web personnel) . En réponse au journal Canonical, les « promesses » et la « maintenance » .... Évalué à 5.
(et pour relancer un autre troll des cavernes, regardes l'historique de ces derniers jours, c'est assez rigolo)
Il y a plusieurs trucs que je trouve essentiels pour un gestionnaire de version distribué. En fait, le but, c'est qu'il soit utilisable pour une contribution occasionnelle de 50 lignes comme pour du développement au quotidien.
Pour une contribution occasionnelle, ce que tu veux, c'est en une commande, avoire une copie locale et une branche locale, coder, commiter en local, et publier les changements facilement. Par exemple, avec darcs, tu fais "darcs get; ...; darcs record; darcs send" et le patch est envoyé par email au mainteneur. Avec bzr, la version envoie par email n'est pas encore implémentée, mais c'est dans la todolist. Mais "bzr branch" te donne une branche et une copie locale en une commande. Pas la peine de dire ou est le repository, la branche est dans le répertoire .bzr/ de la copie locale.
Pour publier des changements, l'envoie par mail est excellent pour des petites contributions, mais dès que ça prends de l'envergure, il faut pouvoir uploader ça sur un serveur. Et là, l'idée de bzr, héritée de GNU Arch, c'est de n'utiliser qu'un serveur de fichier. Tu as un compte chez free ? bzr push ftp://...@ftpperso/tralala et ta branche est publiée. Ça marche aussi avec sourceforge et gna en sftp par exemple. Le support WebDAV qui permet de passer à travers firewall+proxy pourrait être ajouté assez facilement.
Après, le coup de la branche dans le répertoire de travail, je trouve que ça n'a pas que des avantages. Par exemple, j'ai souvent un répertoire de travail (checkout) sur un disque local non sauvegardé, alors que les données du gestionnaire de version sont bien à l'abris sur un disque réseau sauvegardé périodiquement. Et justement, bzr permet aussi ce mode de fonctionnement. C'est à ma connaissance le seul qui permette de choisir entre "répertoire de travail = repository" et "repository + checkout".
Au niveau performances, il est raisonnablement rapide (derrière mercurial et git pour l'instant), mais il y a encore beaucoup de possibilités d'optimisations, dont certaines prèsque terminées et bientôt intégrées, donc il devrait être encore plus rapide d'ici quelques mois (et pour l'instant, c'est du python pur, sans un gramme d'optimisation en C).
Il y a aussi un système de plugin, que je comparerais aux extensions de firefox : de base, tu as un système simple et relativement minimal, mais tu peux ajouter des trucs plus évolués si ça te chante. Les plugins sont aussi un moyen de tester du code avant de l'intégrer dans bzr lui-même.
[^] # Re: désolé ! :(
Posté par Matthieu Moy (site web personnel) . En réponse au journal Canonical, les « promesses » et la « maintenance » .... Évalué à 5.
Au moins, si il n'y avait que du mauvais, ça serait poubelle illico, mais je ne crois pas que tout soit à jetter. Je crois surtout que c'est une boite à fréquenter avec prudence.
[^] # Re: En même temps
Posté par Matthieu Moy (site web personnel) . En réponse au journal Canonical, les « promesses » et la « maintenance » .... Évalué à 3.
Mes contributions à tla, elles sont plutôt limitées. Un bugfix de deux lignes qui a mis 3 mois à être accepté par Tom, une gestion des mots de passes dans le ~/.authinfo qui est tombé aux oubliettes, et a finalement fait son chemin dans Bazaar. Mais bon, le fait que Tom était un mainteneur plutôt radical et pas très intéressé par les contributions extérieures, c'est pas un grand secret.
[^] # Re: En même temps
Posté par Matthieu Moy (site web personnel) . En réponse au journal Canonical, les « promesses » et la « maintenance » .... Évalué à 5.
Donc, le dilemne suivant, c'est privilégier la politique ou la technique ... (et par ailleurs, il y a aussi des tas de gens très bien dans les développeurs de Bazaar-NG).
(mais par ailleurs, mes compétences en matière de gestion de version sont quand même assez modestes. Les modifs que j'ai faites dans Bazaar étaient principalement des question d'ergonomie et nettoyage de code).
[^] # Re: L'avantage du libre...
Posté par Matthieu Moy (site web personnel) . En réponse au journal Canonical, les « promesses » et la « maintenance » .... Évalué à 8.
Bon, je le saurais pour la prochaine fois : une promesse de Canonical, si y'a pas un contrat signé, c'est comme si ils avaient rien dit.
Le truc, c'est que la relation entre Canonical et la communauté est pas mal basée sur des promesses. Tiens, par exemple :
https://wiki.ubuntu.com/RosettaFAQ
Rosetta will become open source sometime in the future
Tu y crois, toi ? Moi, non.
[^] # Re: L'avantage du libre...
Posté par Matthieu Moy (site web personnel) . En réponse au journal Canonical, les « promesses » et la « maintenance » .... Évalué à 2.
[^] # Re: L'avantage du libre...
Posté par Matthieu Moy (site web personnel) . En réponse au journal Canonical, les « promesses » et la « maintenance » .... Évalué à 6.
Bah, il me semble avoir payé de ma personne, oui. Je n'attends pas qu'il se mettent à genoux devant moi, juste qu'ils tiennent leurs promesses.
Par ailleurs, Canonical ne nie pas vouloir faire de la thune sur ses développement (même si pour l'instant, il n'y a pas tellement de revenu autre que les réserves de Mark Shuttleworth). Si vous avez envie d'acheter du support chez Canonical, bah, vous savez juste à quoi vous attendre.
[^] # Re: L'avantage du libre...
Posté par Matthieu Moy (site web personnel) . En réponse au journal Canonical, les « promesses » et la « maintenance » .... Évalué à 8.
C'est évident que la version 2 sera mieux que la version 1. Bazaar-NG est techniquement très bon, et les choses qui se préparent pour la future 0.8 sont tout simplement excellents. Que Bazaar soit petit à petit abandonné, ce n'est pas une mauvaise chose en soi. La version 1 n'a pas d'avenir a long terme.
Le problème, c'est qu'un éditeur de logiciel un minimum sérieux, il prépare une transition. Chez Microsoft, qui est bien connu pour être que des méchants, tout ça tout ça, une version d'un logiciel continue à être maintenue pendant très longtemps après la sortie de la version n+1. Pas parce que la vieille version était mieux, juste parce que les gens n'ont pas forcément envie de migrer quand l'éditeur claque des doigts.
Ce que je voulais simplement, c'est que Bazaar 1 ait une fin convenable. Que les gens puissent continuer à l'utiliser en bénéficiant des dernières améliorations de la communauté. Juste comme ça avait été annoncé en grande pompe à l'époque :
Aujourd'hui, je viens de vérifier, le paquet qui est dans Ubuntu n'est même pas la dernière version stable, c'est la 1.4.2 qui a une gestion des archives toute buggée (archive-mirror segfault dès qu'on a une config un peu exotique). Et devinez qui c'est qui a corrigé les bugs dans la 1.4.3 qui servira jamais à personne ?
[^] # Re: En même temps
Posté par Matthieu Moy (site web personnel) . En réponse au journal Canonical, les « promesses » et la « maintenance » .... Évalué à 5.
Il fait du bon boulot, mais c'est un choix délibéré de ne pas introduire de modifications majeurs dans tla. Le but est simplement de faire vivre tla en attendant que la multitude de nouveaux projets (bzr, hg, git, et autres) se stabilise un peu. Il est plus qu'improbable que le système de cache de Bazaar finisse dans tla par exemple.
> Ce que je n'apprécie pas c'est des choses comme baz est une implémentation
> obsolète de Arch sur le wiki.
Rassures-toi, baz n'est plus mentionné sur la page d'accueil du wiki.
Taquin que je suis, je m'étais permis de remplacer « obsolete » par « unmaintained ». Ça n'a pas trainé, dans les deux jours, ma modification était censurée^W^W^W reformulée. C'est à dire que le lien vers Bazaar était supprimé.
http://bazaar-vcs.org/FrontPage/Sidebar?action=info
[^] # Re: En même temps
Posté par Matthieu Moy (site web personnel) . En réponse au journal Canonical, les « promesses » et la « maintenance » .... Évalué à 10.
La release, pour Canonical, c'est quelques commandes pour construire le paquet Debian, et deux mails à envoyer.
Aujourd'hui, ma confiance en Canonical est au niveau zero. Canonical fait des promesses en l'air, et j'ai juste envie que ça se sache.
A leur place, j'aurais juste rien promis. Et ça m'aurait évité de perdre tout ce temps.
Pour la 1.4.3, c'était pareil. Robert m'a dit de préparer les backports de bugfixes de la 1.5 si je voulais. Je l'ai fait, j'ai écrit les release notes, il a mis trois mois à se décider à faire la release. Enfin, il ne l'a même pas fait, il m'a donné les droits pour le faire, parce qu'il n'avait même pas le temps de faire un "merge + commit" lui-même.
[^] # Re: Le CD qui manquait !
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche Mandriva One : testez-la. Évalué à 5.
[^] # Re: 3eme réaction...
Posté par Matthieu Moy (site web personnel) . En réponse au journal Vista s'ouvre pour nos chers gouvernements. Évalué à 5.
Je viens de faire l'expérience avec un package Debian assez simple. Creation du package, sauvegarde dans un coin. Re-creation à partir des mêmes sources, même pas un "touch" entre temps, le deuxième package est plus gros de 10 octets.
Et quand bien même tu aurais la certitude que les sources sont bien celles du binaire, la backdoor peut être un buffer overflow bien caché (on a déjà du mal à trouver les buffer overflow quand on n'a pas fait exprès de les cacher, alors ...), elle peut être dans le compilo (cf. le fameux papier de je-sais-plus-qui), dans l'éditeur de lien, bref, n'importe où ...
(mais par ailleurs, il me semble que les sources de Windows fournies par MS sont compilables ;-) ).
# ???
Posté par Matthieu Moy (site web personnel) . En réponse au journal MSN aurait du code GPL. Évalué à 5.
Ça ressemble fort à un truc genre `uname -a` bidouillé pour avoir ta version de Windows en face de la case avec ton nom, mais avec autre chose que Windows.
[^] # Re: Et Gnome ?
Posté par Matthieu Moy (site web personnel) . En réponse au journal KDE sous Windows.... Évalué à 2.
Selon les bouts de KDE qui sont portés, peut-être que des applies comme amarok peuvent attirer du monde.
Enfin, on verra. 1%, c'est à la fois peu et beaucoup, selon le point de vue. Je crois que c'est plus une question de marketing que de technique. Opera n'a jamais vraiment décolé bien qu'étant très bon, alors que firefox a vraiment réussi à s'imposer en peu de temps.
[^] # Re: portez les sous windows
Posté par Matthieu Moy (site web personnel) . En réponse au journal KDE sous Windows.... Évalué à 2.
Enfin, c'est pas pire qu'une application Qt lancée dans Gnome en tous cas, rien d'anormal.
[^] # Re: sitecopy
Posté par Matthieu Moy (site web personnel) . En réponse au message Sauvegarde : rsync ?. Évalué à 3.
$ sitecopy -u free
et sitecopy regarde en local la liste des fichiers modifiés/ajoutés/supprimés, et ne fait les opérations que pour les fichiers qu'il faut. C'est tout. (pour des petits transfers, c'est même plutôt plus efficace que rsync, qui doit calculer la liste des fichiers de chaque côté. Là, si tu as un fichier à uploader, sitecopy va uploader ce fichier, et rien d'autre en terme de bande passante).
Bref, je maintiens, sitecopy est l'outil que tu cherches.
# Et Gnome ?
Posté par Matthieu Moy (site web personnel) . En réponse au journal KDE sous Windows.... Évalué à 1.
Vu que pour l'instant, Linux représente environ 1% des ordinateurs (un peu moins selon Xiti, un peu plus selon d'autres sources), Gnome et KDE représentent sans doute chacun moins de 0,5% des ordinateurs installés. C'est à dire que si 1% des utilisateurs de Windows installent KDE (y'en a bien déjà 15% qui ont installé firefox ...), ça multiplie par 3 le nombre d'utilisateurs de KDE. Et ça veut dire que KDE sera le point d'entrée privilégié pour les gens qui migrent de Windows vers un OS libre.
Est-ce que ça veut dire que KDE risque de bouffer Gnome (en terme de nombre d'utilisateurs) ?
[^] # Re: vu sur un blog...
Posté par Matthieu Moy (site web personnel) . En réponse au journal des idées pour éviter la création automatique de compte par des bots ?. Évalué à 2.
# sitecopy
Posté par Matthieu Moy (site web personnel) . En réponse au message Sauvegarde : rsync ?. Évalué à 4.
Mais tu n'ignores pas que tu violes les conditions d'utilisation de free, en te servant de leurs serveurs comme d'une sauvegarde ?
# Solution ...
Posté par Matthieu Moy (site web personnel) . En réponse au message telnet avec cygwin. Évalué à 6.
telnet, c'est un protocole où le mot de passe passe en clair (le reste aussi, mais bon), c'est à éviter absoluement.
Sinon, je suppose que ton routeur fait du NAT, donc tu ne peux pas avoir de serveur derrière, et ton serveur X est justement un serveur. Solution : forwarder le port qui va bien de la passerelle vers ton PC, et setenv DISPLAY passerelle:0, ou quelque chose comme ça.