J'imagine que pour avoir une image zoomée, voire des chiffres, il faut raquer. Mais en gros, MSIE 6.0 règne en maître, MSIE 5.5 et 5.0 sont encore bien là, Mozilla/Netscape-récent montent petit à petit au coude à coude avec autres (qui inclut sans doute Opera et Konqueror/Safari). Par contre, MSIE 4.0 et Netscape 4.x sont pour moi bel et bien au musée et plus à prendre en compte.
Ben dans le genre Don Quichotte, t'es pas mal toi. Tu ramènes ta poire sur un sujet que tu ne connais pas à moitié (c'est toi qui le dis), tu balances des gros mots, tu montes sur tes grands chevaux et tu t'instigues en défenseur de quelque chose qui, pour autant qu'il me semble, n'a pas été attaqué !
Toute la journée des gens qui préfèrent Subversion et d'autres qui préfèrent Arch ont dialogué et argumenté, se sont échangés opinions, informations et URLs, le tout sans que ça parte en trolls et autres enfilades infinies. Moi je trouve ça pas banal, et je tire mon chapeau à tous les participants aux discussions ci-dessus.
J'ai l'impression que tu es rentré bien fatigué d'une longue journée harrassante, que voyant le sujet et certains mots clés (arch, subversion) tu t'es dis « ça va partir en troll », et tu as réagi comme si ça avait été le cas, sans prendre la peine de considérer ce qui s'était vraiment dit, sur le fond.
Par ailleurs, certaines personnes ont écrit des scripts de conversion et ont créé des archives qui suivent le développement de logiciels libres connus . Il y a ainsi quelqu'un qui suit le développement de Vim et un ou plusieurs autres qui font en tentent de faire pareil avec Linux. Il ne s'agit pas (encore) de convertisseurs génériques CVS -> Arch, mais c'est un premier pas.
- Subversion n'est pas forcément très stable (corruption de la base de données, rare mais possible), il est lui aussi assez jeune. Arch n'utilise au final que tar+gzip pour stocker les fichiers, ce qui facilite un éventuel sauvetage des données ou leur transfert vers une autre machine (plus lourd avec Subversion car si on change d'architecture - ou parfois même de version - on ne peut pas se contenter de copier la base, il faut l'exporter et la réimporter).
- Arch supporte très bien les référentiels centralisés (un petit coup de tla-pqm par exemple), et permet plus de flexibilité dans les autres cas, qui deviennent plus courants (équipe offshore qui ne travaille pas exactement pareil, par exemple).
Ceci dit, il est clair que Arch a besoin d'améliorer sa documentation et ses interfaces graphiques (il y en a en cours de développement). Mais Arch n'a pas les miyons de Subversion, donc ça prend plus de temps.
Oui mais alors, comment signer un email (qui sera modifié par les serveurs par lesquels il passera) ? Comme stocker plusieurs textes signés dans un seul fichier ? Le coeur du problème, c'est que GnuPG te garantit que le texte à l'intérieur des délimiteurs est correct, pas que l'ensemble du fichier texte l'est. Il faut clairement une option pour ça. Mais ce n'est pas facile : comment gérer d'éventuelles lignes vides ou espaces ajoutés avant ou après ? On a envie de les ignorer, mais il ne faut pas...
Non (ça date je dirais de septembre/octobre dernier), mais ça semblait très mineur. Mais comme les admins n'ont pas le temps, ça n'a pas (encore) été corrigé manifestement.
Je n'ai pas la réponse à ta question, mais je me la suis également posée, sans succès. Même en root je n'y suis pas arrivé. Le seul truc que j'ai réussi à faire, c'est des « dd » en série sur la mémoire (sur /proc/kcore, si je me souviens bien), ce qui m'a permis de tout récupérer ou presque, enfin surtout ce que je voulais retrouver.
D'ailleurs, si vous passez un texte signé correctement à GnuPG mais avec du texte hors balise, l'ensemble sera considéré comme signé, ce qui me semble être une faille dans la signature.
Je me souviens que ce genre de problème s'est posé sur la mailing-list d'Arch aussi. Je crois qu'il y a trois solutions à ce problème :
* Faire une signature extérieure. Problèmes : doublement du nombre de fichiers ; pas forcément possible si on veut plusieurs signatures dans un seul fichier.
* Gérer (virer) le texte externe avant de passer le reste à GnuPG. Problème : il faut écrire son propre parser de texte signé (alors que forcément, GnuPG en a déjà un) et il faut supporter les variations et éventuelles évolutions du format. Et puis plus de code égale plus de bugs.
* Ajouter une option à GnuPG pour qu'il signale la présence de texte externe. Problème : il faut écrire l'option et convaincre les auteurs de GnuPG (et attendre la prochaine version).
Oui, mais si on veut que de simples utilisateurs puissent récupérer une branche, comment fait-on ? On ne peut pas vraiment créer un compte SSH par téléchargeur potentiel, et encore moins créer un compte SSH « anonyme », non ? Alors quoi ? Un serveur HTTP sans WebDAV peut-il suffire, ou un serveur FTP ?
Manifestement ça fait plusieurs mois (voire années) que des gens viennent sur la mailing-list des hackers Savannah poser cette question. Voici ce que l'on peut retirer des (courtes) discussions qui ont suivi :
* Savannah n'est pas « mariée avec CVS », ses admins sont tout à fait ouvert à l'installation de plusieurs systèmes de gestion de sources sur Savannah.
* Les admins sont débordés, et ont mieux à faire que de passer du temps à comprendre, tester et installer Arch ou Subversion sur Savannah.
* Toute aide dans la catégorie « pré-mâchage du travail » est la bienvenue.
* Comme les admins sont débordés, c'est pas facile de travailler avec eux et donc de les aider.
* Les admins n'installent sur Savannah que des packages en provenance de Debian stable.
* Les admins ne veulent pas installer deux versions d'Apache sur Savannah, qui pour l'instant tourne sous Apache 1.3.xx.
* Les admins n'ont pas confiance en Apache 2.x, dont Subversion a besoin (ça date de 2002 ou 2003, leur opinion a peut-être évolué depuis).
* Les logiciels nécessaires au fonctionnement de Arch (sftp notamment) sont installés et en état de marche.
* Aux dernières nouvelles sur la mailing-list de Arch, il y a encore des détails qui coincent.
Voilà, je crois que j'ai fait le tour. Je précise pour ceux feraient quelques recherches à ce sujet de ne pas s'étonner de certains résultats : subversions.gnu.org est l'ancien nom de savannah.gnu.org.
Au fait, vu les récentes attaques sur les dépôts open-source, Richard Stallman aimerait que les gestionnaires de sources assurent l'authentification et l'intégrité des contributions. Arch le fera en version 1.2, pour Subversion je ne sais pas où ça en est (avec des hooks ça doit le faire, non ?).
-- ouais mais quel auteur ? T'as les patchs TrucMuche ?"
J'avoue que cela me manque énormément aujourd'hui.
Ça n'a pas du tout disparu : patches utilisateurs pour FreeS/WAN par exemple, il y en avait aussi pour OpenSSL à un moment je crois.
je me rend compte que tu vois Arch comme étant un outil favorisant l'absence de communication humaine
Mais absolument pas, je ne vois pas où tu as pu lire ça. Je pense que Arch permet à quelqu'un de continuer à travailler sur un projet quand des problèmes de communication humaine se posent, à partager son travail de manière utile et efficace dans ces cas là. C'est aussi valable quand le projet tourne bien : le gestionnaire du projet n'a pas à se prendre la tête à donner des accès CVS au compte-goutte sur le serveur ultra-sécurisé du projet, il peut facilement intégrer les patchsets envoyés par les contributeurs, même ceux qu'il ne connaît pas encore bien et en qui il n'a pas, par défaut, confiance.
Tiens, cela rejoint d'ailleurs ta première assertion. Linux (le noyau), c'est la cathédrale et Arch, c'est beau, c'est le bazar
Mais je n'ai pas écrit ça du tout ! Je ne sais pas lequel de nous deux est mal réveillé, mais on n'est pas sur la même fréquence on dirait. Je m'aperçois au passage que j'ai mal rédigé la paraphrase qui commence mon message. Mon but était de faire comprendre au posteur initial que sa question (mais alors avec arch c'est le boxon ?) se posait tout autant au noyau Linux (il y a plusieurs personnes qui publient leur version de Linux -- ac dans le passé, mm actuellement, sans compter Linus bien sûr ; il n'y a pas un CVS/Subversion/BitKeeper qui centralise tout), et que pourtant le noyau Linux s'en sortait très bien. BitKeeper tout comme Arch fonctionne par distribution de patchsets (enfin je crois, BitKeeper j'ai jamais essayé), ça fait toute la différence.
Déjà fait depuis plusieurs années. Un fabricant de fenêtres (je crois) a entamé des procédures judiciaires (ou peut-être juste des négociations, comme Microsoft avec wxWidgets), et WindowMaker a été renommé en Window Maker (avec une espace au milieu).
Comment fait-on pour créer des versions (releases) sur Linux sachant qu'il n'y a pas de référentiel centralisé ? Est-ce que cela veut dire que quiconque peut faire une release de son propre Linux ?
C'est fou ce que CVS (et donc Subversion) ont pu formatter la manière dont les gens concoivent le développement open source : s'il n'y a pas un serveur central (avec tout ce que cela implique de difficulté à obtenir un accès, de fork quand le serveur est en rade ou son admin faché avec le reste de l'équipe), les gens ont l'air tout perdu.
Avant CVS, on se débrouillait avec diff+tar+gzip+patch, n'importe qui pouvait publier sa version, et ça n'était pas plus mal (au niveau liberté de distribution et de forkage). Ça n'empêchait pas qu'il y ait une version maître, mais sa seule différence avec les autres était une différence politique (c'est moi le boss, c'est ma version qui compte - en général parce que c'est moi qui ait créé le logiciel, ou qui suis le plus apte à sortir des versions acceptables) plus que technique (c'est moi qui gère les logins sur le serveur CVS).
En fait, CVS/Subversion c'est la cathédrale, alors que Arch c'est le bazar.
# Re: Compter les navigateurs web
Posté par Boa Treize (site web personnel) . En réponse au journal Compter les navigateurs web. Évalué à 1.
http://www.google.com/press/zeitgeist/jan04_browsers.gif(...)
J'imagine que pour avoir une image zoomée, voire des chiffres, il faut raquer. Mais en gros, MSIE 6.0 règne en maître, MSIE 5.5 et 5.0 sont encore bien là, Mozilla/Netscape-récent montent petit à petit au coude à coude avec autres (qui inclut sans doute Opera et Konqueror/Safari). Par contre, MSIE 4.0 et Netscape 4.x sont pour moi bel et bien au musée et plus à prendre en compte.
Au fait :
http://www.google.com/press/zeitgeist/jan04_pie.gif(...)
1% pour Linux, ça n'évolue pas beaucoup (bon en fait on est peut-être passé de 0.6% à 0.8%, pas moyen de le savoir à moins de raquer).
[^] # Re: Sortie de Subversion 1.0.0
Posté par Boa Treize (site web personnel) . En réponse à la dépêche Sortie de Subversion 1.0.0. Évalué à 3.
arch/tla 1.2pre3 est sorti hier soir. Vous pouvez récupérer les sources là :
http://regexps.srparish.net/src/tla/(...)
Dans son mail Tom Lord précisait :
This release is a candidate for becoming tla-1.2 -- a major
milestone release of GNU arch.
N'hésitez donc pas à tester ! :-)
[^] # Re: Marrant
Posté par Boa Treize (site web personnel) . En réponse à la dépêche Sortie de Subversion 1.0.0. Évalué à 9.
Toute la journée des gens qui préfèrent Subversion et d'autres qui préfèrent Arch ont dialogué et argumenté, se sont échangés opinions, informations et URLs, le tout sans que ça parte en trolls et autres enfilades infinies. Moi je trouve ça pas banal, et je tire mon chapeau à tous les participants aux discussions ci-dessus.
J'ai l'impression que tu es rentré bien fatigué d'une longue journée harrassante, que voyant le sujet et certains mots clés (arch, subversion) tu t'es dis « ça va partir en troll », et tu as réagi comme si ça avait été le cas, sans prendre la peine de considérer ce qui s'était vraiment dit, sur le fond.
[^] # Re: Question technique
Posté par Boa Treize (site web personnel) . En réponse à la dépêche Sortie de Subversion 1.0.0. Évalué à 5.
Commit du soir, espoir.
Build du matin, chagrin.
[^] # Re: wxWi----s change de nom
Posté par Boa Treize (site web personnel) . En réponse à la dépêche wxWi----s change de nom. Évalué à 0.
Et c'est d'ailleurs toujours valable.
[^] # Re: Grande pétition contre le fortran
Posté par Boa Treize (site web personnel) . En réponse au journal Grande pétition contre le fortran. Évalué à 0.
[^] # Re: Donc qu'est-ce qu'il vaut mieux utiliser ?
Posté par Boa Treize (site web personnel) . En réponse à la dépêche Sortie de Subversion 1.0.0. Évalué à 3.
http://www.xouvert.org/download.html(...)
Par ailleurs, certaines personnes ont écrit des scripts de conversion et ont créé des archives qui suivent le développement de logiciels libres connus . Il y a ainsi quelqu'un qui suit le développement de Vim et un ou plusieurs autres qui font en tentent de faire pareil avec Linux. Il ne s'agit pas (encore) de convertisseurs génériques CVS -> Arch, mais c'est un premier pas.
# Re: De la métaphysique du matériel
Posté par Boa Treize (site web personnel) . En réponse au journal De la métaphysique du matériel. Évalué à 1.
- d'éteindre son ordi avec le bouton,
Tu veux dire, pendant que Linux tourne ? Ben, tu risque pas mal de compromettre tes données. Sinon, pas de problème.
- de démarrer un ordinateur éteint avec un cd dans le lecteur de cd ?
Ça m'a jamais gêné. Peut-être qu'un ou deux lecteurs bon marché avaient des problèmes à ce niveau, et une rumeur s'est répandue ?
[^] # Re: De la métaphysique du matériel
Posté par Boa Treize (site web personnel) . En réponse au journal De la métaphysique du matériel. Évalué à 2.
[^] # Re: De la métaphysique du matériel
Posté par Boa Treize (site web personnel) . En réponse au journal De la métaphysique du matériel. Évalué à 2.
installpkg slackware/a/apmd-3.0.2-i386-1.tgz
(+ noyal bien configuré)
[^] # Re: Media Player sous Linux
Posté par Boa Treize (site web personnel) . En réponse au journal Media Player sous Linux. Évalué à 2.
[^] # Re: Donc qu'est-ce qu'il vaut mieux utiliser ?
Posté par Boa Treize (site web personnel) . En réponse à la dépêche Sortie de Subversion 1.0.0. Évalué à 1.
http://platform.progeny.com/infrastructure/#subversion(...)
[^] # Re: Donc qu'est-ce qu'il vaut mieux utiliser ?
Posté par Boa Treize (site web personnel) . En réponse à la dépêche Sortie de Subversion 1.0.0. Évalué à 2.
- Subversion n'est pas forcément très stable (corruption de la base de données, rare mais possible), il est lui aussi assez jeune. Arch n'utilise au final que tar+gzip pour stocker les fichiers, ce qui facilite un éventuel sauvetage des données ou leur transfert vers une autre machine (plus lourd avec Subversion car si on change d'architecture - ou parfois même de version - on ne peut pas se contenter de copier la base, il faut l'exporter et la réimporter).
- Arch supporte très bien les référentiels centralisés (un petit coup de tla-pqm par exemple), et permet plus de flexibilité dans les autres cas, qui deviennent plus courants (équipe offshore qui ne travaille pas exactement pareil, par exemple).
Ceci dit, il est clair que Arch a besoin d'améliorer sa documentation et ses interfaces graphiques (il y en a en cours de développement). Mais Arch n'a pas les miyons de Subversion, donc ça prend plus de temps.
[^] # Re: Sortie de Subversion 1.0.0
Posté par Boa Treize (site web personnel) . En réponse à la dépêche Sortie de Subversion 1.0.0. Évalué à 3.
[^] # Re: Sortie de Subversion 1.0.0
Posté par Boa Treize (site web personnel) . En réponse à la dépêche Sortie de Subversion 1.0.0. Évalué à 3.
[^] # Re: Sortie de Subversion 1.0.0
Posté par Boa Treize (site web personnel) . En réponse à la dépêche Sortie de Subversion 1.0.0. Évalué à 1.
# Re: Accéder à la mémoire d'un processus
Posté par Boa Treize (site web personnel) . En réponse au journal Accéder à la mémoire d'un processus. Évalué à 1.
[^] # Re: Je suis
Posté par Boa Treize (site web personnel) . En réponse au sondage Je suis. Évalué à 1.
[^] # Re: Sortie de Subversion 1.0.0
Posté par Boa Treize (site web personnel) . En réponse à la dépêche Sortie de Subversion 1.0.0. Évalué à 3.
Je me souviens que ce genre de problème s'est posé sur la mailing-list d'Arch aussi. Je crois qu'il y a trois solutions à ce problème :
* Faire une signature extérieure. Problèmes : doublement du nombre de fichiers ; pas forcément possible si on veut plusieurs signatures dans un seul fichier.
* Gérer (virer) le texte externe avant de passer le reste à GnuPG. Problème : il faut écrire son propre parser de texte signé (alors que forcément, GnuPG en a déjà un) et il faut supporter les variations et éventuelles évolutions du format. Et puis plus de code égale plus de bugs.
* Ajouter une option à GnuPG pour qu'il signale la présence de texte externe. Problème : il faut écrire l'option et convaincre les auteurs de GnuPG (et attendre la prochaine version).
[^] # Re: Sortie de Subversion 1.0.0
Posté par Boa Treize (site web personnel) . En réponse à la dépêche Sortie de Subversion 1.0.0. Évalué à 1.
[^] # Re: Sortie de Subversion 1.0.0
Posté par Boa Treize (site web personnel) . En réponse à la dépêche Sortie de Subversion 1.0.0. Évalué à 5.
* Savannah n'est pas « mariée avec CVS », ses admins sont tout à fait ouvert à l'installation de plusieurs systèmes de gestion de sources sur Savannah.
* Les admins sont débordés, et ont mieux à faire que de passer du temps à comprendre, tester et installer Arch ou Subversion sur Savannah.
* Toute aide dans la catégorie « pré-mâchage du travail » est la bienvenue.
* Comme les admins sont débordés, c'est pas facile de travailler avec eux et donc de les aider.
* Les admins n'installent sur Savannah que des packages en provenance de Debian stable.
* Les admins ne veulent pas installer deux versions d'Apache sur Savannah, qui pour l'instant tourne sous Apache 1.3.xx.
* Les admins n'ont pas confiance en Apache 2.x, dont Subversion a besoin (ça date de 2002 ou 2003, leur opinion a peut-être évolué depuis).
* Les logiciels nécessaires au fonctionnement de Arch (sftp notamment) sont installés et en état de marche.
* Aux dernières nouvelles sur la mailing-list de Arch, il y a encore des détails qui coincent.
Voilà, je crois que j'ai fait le tour. Je précise pour ceux feraient quelques recherches à ce sujet de ne pas s'étonner de certains résultats : subversions.gnu.org est l'ancien nom de savannah.gnu.org.
Au fait, vu les récentes attaques sur les dépôts open-source, Richard Stallman aimerait que les gestionnaires de sources assurent l'authentification et l'intégrité des contributions. Arch le fera en version 1.2, pour Subversion je ne sais pas où ça en est (avec des hooks ça doit le faire, non ?).
[^] # Re: [HS] Arch
Posté par Boa Treize (site web personnel) . En réponse à la dépêche Sortie de Subversion 1.0.0. Évalué à 5.
J'avoue que cela me manque énormément aujourd'hui.
Ça n'a pas du tout disparu : patches utilisateurs pour FreeS/WAN par exemple, il y en avait aussi pour OpenSSL à un moment je crois.
je me rend compte que tu vois Arch comme étant un outil favorisant l'absence de communication humaine
Mais absolument pas, je ne vois pas où tu as pu lire ça. Je pense que Arch permet à quelqu'un de continuer à travailler sur un projet quand des problèmes de communication humaine se posent, à partager son travail de manière utile et efficace dans ces cas là. C'est aussi valable quand le projet tourne bien : le gestionnaire du projet n'a pas à se prendre la tête à donner des accès CVS au compte-goutte sur le serveur ultra-sécurisé du projet, il peut facilement intégrer les patchsets envoyés par les contributeurs, même ceux qu'il ne connaît pas encore bien et en qui il n'a pas, par défaut, confiance.
Tiens, cela rejoint d'ailleurs ta première assertion. Linux (le noyau), c'est la cathédrale et Arch, c'est beau, c'est le bazar
Mais je n'ai pas écrit ça du tout ! Je ne sais pas lequel de nous deux est mal réveillé, mais on n'est pas sur la même fréquence on dirait. Je m'aperçois au passage que j'ai mal rédigé la paraphrase qui commence mon message. Mon but était de faire comprendre au posteur initial que sa question (mais alors avec arch c'est le boxon ?) se posait tout autant au noyau Linux (il y a plusieurs personnes qui publient leur version de Linux -- ac dans le passé, mm actuellement, sans compter Linus bien sûr ; il n'y a pas un CVS/Subversion/BitKeeper qui centralise tout), et que pourtant le noyau Linux s'en sortait très bien. BitKeeper tout comme Arch fonctionne par distribution de patchsets (enfin je crois, BitKeeper j'ai jamais essayé), ça fait toute la différence.
[^] # Re: wxWi----s change de nom
Posté par Boa Treize (site web personnel) . En réponse à la dépêche wxWi----s change de nom. Évalué à 1.
Déjà fait depuis plusieurs années. Un fabricant de fenêtres (je crois) a entamé des procédures judiciaires (ou peut-être juste des négociations, comme Microsoft avec wxWidgets), et WindowMaker a été renommé en Window Maker (avec une espace au milieu).
[^] # Re: Sortie de Subversion 1.0.0
Posté par Boa Treize (site web personnel) . En réponse à la dépêche Sortie de Subversion 1.0.0. Évalué à 0.
(svn vs. tla, le grand troll de 2004)
[^] # Re: [HS] Arch
Posté par Boa Treize (site web personnel) . En réponse à la dépêche Sortie de Subversion 1.0.0. Évalué à 7.
Comment fait-on pour créer des versions (releases) sur Linux sachant qu'il n'y a pas de référentiel centralisé ? Est-ce que cela veut dire que quiconque peut faire une release de son propre Linux ?
C'est fou ce que CVS (et donc Subversion) ont pu formatter la manière dont les gens concoivent le développement open source : s'il n'y a pas un serveur central (avec tout ce que cela implique de difficulté à obtenir un accès, de fork quand le serveur est en rade ou son admin faché avec le reste de l'équipe), les gens ont l'air tout perdu.
Avant CVS, on se débrouillait avec diff+tar+gzip+patch, n'importe qui pouvait publier sa version, et ça n'était pas plus mal (au niveau liberté de distribution et de forkage). Ça n'empêchait pas qu'il y ait une version maître, mais sa seule différence avec les autres était une différence politique (c'est moi le boss, c'est ma version qui compte - en général parce que c'est moi qui ait créé le logiciel, ou qui suis le plus apte à sortir des versions acceptables) plus que technique (c'est moi qui gère les logins sur le serveur CVS).
En fait, CVS/Subversion c'est la cathédrale, alors que Arch c'est le bazar.