Soit un total de 737760 KiB (et y a probablement des choses uniquement à archiver, pas à convertir, ou alors juste à dumper en attendant un éventuel réimport plus tard)
Création du SVN
(surtout ne pas oublier le 'fsfs', on n'en veut pas de la base Berkeley DB 'bdb'…)
$ svnadmin create --fs-type fsfs /data/svn
(ça créé plein de fichiers dans /data/svn)
$ cvs2svn --existing-svnrepos -s /data/svn /data/cvs
(...)
Pass 1 complete.
===========================================================================
Error summary:
ERROR: A CVS repository cannot contain both /data/cvs/htdocs/association/ca_temp .wml,v and /data/cvs/htdocs/association/Attic/ca_temp.wml,v
Exited due to fatal error(s).
Bon, de toute façon, ce fichier ne sert à rien (qui existe encore en ayant été supprimé).
Pouf viré du CVS. On recommence tout…
(...)
----- pass 2 -----
Checking for blocked exclusions...
Checking for forced tags with commits...
Checking for tag/branch mismatches...
ERROR: The following symbols are tags in some files and branches in others.
Use --force-tag, --force-branch and/or --exclude to resolve the symbols.
'start' is a tag in 208 files, a branch in 1 files and has commits in 1 files.
Humm certes. (utilisé dans candidats.fr, cgi-bin, xray, software et htdocs apparemment). ça serait pas un tag par défaut dans CVS ? Et quelqu'un aurait appelé une branche 'start' ? On doit pouvoir forcer comme tag a priori.
$ cvs2svn --force-tag start --existing-svnrepos -s /data/svn /data/cvs
(...)
----- pass 2 -----
Checking for blocked exclusions...
Checking for forced tags with commits...
ERROR: The following branches cannot be forced to be tags because they have commits:
'start'
Bon, toujours pass2… et ben on va oublier start alors…
$ cvs2svn --exclude start --existing-svnrepos -s /data/svn /data/cvs
(...)
----- pass 2 -----
Checking for blocked exclusions...
ERROR: The branch 'start' cannot be excluded because the following symbols depend on it:
'initial'
Perdu, tu y as cru hein ? Bon reste plus qu'un choix alors…
Je n'avais jamais lu « mastaire » jusqu'ici mais une des raisons est qu'il est devenu désuet entretemps. Cf mastaire : « le décret n° 2002-480 du 8 avril 2002 qui dit que le mot : « mastaire » est remplacé par le mot : "master" dans le décret 99-747 de 1999 relatif à la création du grade de mastaire. ». Du coup JORF n°0084 du 10 avril 2002 page 6323 texte n° 34 : « Article 1 Dans le titre et dans toutes les dispositions du décret du 30 août 1999 susvisé, le mot : "mastaire" est remplacé par le mot : "master". » (Décret n°99-747 du 30 août 1999 relatif à la création du grade de master consolidé)
le test ajouté pour détecter la présence de dépêches publiée réaffectée à l'utilisateur Anonyme et ayant des infos non vides de nom/courriel (*)
le nettoyage fait en base pour les milliers de dépêches concernées
(*) ça ne change rien pour les dépêches soumises anonymement mais non réaffectées à Anonyme. Ni pour les dépêches non publiées pour lesquelles on conserve les infos et qu'il faut traiter par ailleurs (par exemple un nettoyage complet au bout d'un an).
Je me suis posé la même question en allant voir (alors on va dire que ce n'est pas une question con :). Par contre c'est du code à ajouter dans une page et pas de l'analyse de logs, ça m'intéresse moins pour LinuxFr.org.
Le système actuel (cf https://linuxfr.org/aide#aide-authentification ):
- on peut rééditer pendant quelques minutes ses propres commentaires ;
- on ne peut pas rééditer ses propres contenus (qu'ils soient modérés a priori comme les dépêches et les sondages, ou a posteriori comme les autres contenus du site).
Dans l'absolu (et pour des raisons de responsabilité juridique notamment), il y aurait moins de sens à permettre de rééditer les contenus modérés a priori (ou alors il faut revérifier toutes les éditions post-publication).
En dehors de cette question, de façon externe au site, le greffon Grammalecte pour navigateur permet de nettoyer pas mal de fautes d'orthographe/grammaire typiques avant de soumettre.
Je me serais attendu à ce que ce qui suit (qui n'aidera pas en javascript) marche par défaut :
$ LC_ALL=en_GB date +"%m" -d "01 January 1970 00:00:00"
01
$ LC_ALL=fr_FR date +"%m" -d "01 décembre 1970 00:00:00"
date: invalid date '01 d\303\251cembre 1970 00:00:00'
$ LC_ALL=de_DE date +"%m" -d "01 Dezember 1970 00:00:00"
date: invalid date '01 Dezember 1970 00:00:00'
Du coup quand tu traduis, soit tu disposes d'un contexte qui te dit si on parle de homme ou d'une femme, soit tu fais un choix : « I'm a doctor » -> « Ich bin (ein) Artz » ou « Ich bin (eine) Ärtzin », « je suis un docteur » ou « je suis une docteure ». Ce choix est encore plus marqué si tu fais une double traduction (potentiellement le cas sur des outils de traduction automatique avec un langue pivot, par exemple si on imagine que la traduction se fait allemand -> anglais -> français car la traduction directe n'est pas possible, et en anglais on n'utilise que rarement male/female pour qualifier une personne exerçant un métier). Quand tu apprends/révises une langue avec un outil type Duolingo/Babel (par exemple anglais->allemand et allemand->anglais), tu le notes assez vite.
Ce ne me semble pas incompatible. Techniquement je fais des choses intéressantes au taf dans un milieu dit « devops » (je coche un paquet de mots clés à la mode). Et pourtant, je constate néanmoins des logiciels qui consomment un max de RAM, de bande passante, de l'empaquetage foireux, du pipeau marketing, de requêtes mal optimisées (SQL ou noSQL), chaque commit brûle une forêt en déclenchant une débauche de tests à tout niveau dans l'intégration continue, etc., bref ce qui est décrit dans ce journal.
Globalement les "valeurs" des personnes ne sont juste pas les mêmes : peut-être qu'avant on privilégiait (plus) l'optimisation des ressources, la compréhension et la maîtrise de l'ensemble, la qualité des spécifications, le coût, etc. que sais-je encore, alors que maintenant on privilégierait (plus) les fonctionnalités, la rapidité de mise sur le marché (TTM), la capacité à tester vite, une forme de pragmatisme (la qualité doit être suffisante parce que les gens continuent d'acheter…), etc. Chacune de ces priorités a des conséquences : tu vas plus vite en réutilisant des dizaines de composants existants, mais tu galères à les gérer, à éviter les trous de sécu, à garantir une certaine qualité et tu empiles des couches auxquelles tu ne comprends plus grand chose ; tu développes plus vite en ayant du code d'infra et des API partout, mais tu gaspilles plus d'argent (forcément avant on t'en donnait moins et t'avais pas la carte de crédit). Tu voulais des spécifications claires et précises pour « bien coder », mais maintenant on se dit agile et on veut que ça bouge vite. Etc., etc. Et forcément des gens se trouvent en décalage avec les valeurs « à la mode »/du moment. Et ça ne veut pas (forcément) non plus dire qu'avant les gens étaient des génies parfaits et que maintenant les gens sont des incultes incompétents. Ça veut plutôt dire qu'il y a eu tellement de changements (ou juste de temps écoulé) que ça a finit par créer des "générations", bref que l'on est devenus les vieux d'autres gens (tout étant étant plus jeunes que les vieux d'avant qui étaient mieux aussi).
Ta généralité permet juste d'empêcher toute critique basée sur l'expérience, vu qu'il devient impossible de commenter un hypothétique recul sur quoi que ce soit. Vraiment la critique, c'était mieux avant. Je ne nie pas que souvent le « c'était mieux avant » peut être un problème de « vieux cons », mais je ne suis pas d'accord pour que ça devienne une implication.
La dépêche ne me semble pas dire « des gens ne nous disent pas tout » mais « nous auteurs de la dépêche choisissons de parler des sujets que nous jugeons les plus importants ». Donc oui les sujets ont pu être abordés dans les médias classiques (mais pas forcément en proportion de l'importance jugée par les auteurs de la dépêche) et cette dépêche n'a pas vocation à lutter contre la désinformation. En fait j'ai l'impression que cette partie de ta critique tombe à côté.
# Flux
Posté par Benoît Sibaud (site web personnel) . En réponse au lien [Humour] Supers pouvoirs. Évalué à 2.
Il ne lui manque qu'un flux RSS :(.
[^] # Re: me semblait pourtant qu'il existait déjà des outils pour passer de cvs à git?
Posté par Benoît Sibaud (site web personnel) . En réponse au journal Le compilateur GCC passe à Git. Évalué à 8.
Sommaire
Et histoire de donner un exemple de cvs vers svn, voici mes notes d'octobre 2006, sur la conversion du dépôt CVS de l'association April :
Taille du dépôt CVS local
Taille du dépôt CVS côté serveur
Soit un total de 737760 KiB (et y a probablement des choses uniquement à archiver, pas à convertir, ou alors juste à dumper en attendant un éventuel réimport plus tard)
Création du SVN
(surtout ne pas oublier le 'fsfs', on n'en veut pas de la base Berkeley DB 'bdb'…)
(ça créé plein de fichiers dans /data/svn)
Bon, de toute façon, ce fichier ne sert à rien (qui existe encore en ayant été supprimé).
Pouf viré du CVS. On recommence tout…
Humm certes. (utilisé dans candidats.fr, cgi-bin, xray, software et htdocs apparemment). ça serait pas un tag par défaut dans CVS ? Et quelqu'un aurait appelé une branche 'start' ? On doit pouvoir forcer comme tag a priori.
Bon, toujours pass2… et ben on va oublier start alors…
Perdu, tu y as cru hein ? Bon reste plus qu'un choix alors…
OK on renomme, on choisit le jeu de caractères et on reprend.
YES !
Taille du dépôt SVN local
Taille du dépôt SVN sur le serveur
Vraie migration sur le serveur
[^] # Re: me semblait pourtant qu'il existait déjà des outils pour passer de cvs à git?
Posté par Benoît Sibaud (site web personnel) . En réponse au journal Le compilateur GCC passe à Git. Évalué à 6.
Pour être plus précis il écrit « from Subversion to Git » donc svn vers git, pas cvs vers git.
# Est-ce que j'ai une tête d'atmosphaire ?
Posté par Benoît Sibaud (site web personnel) . En réponse au journal Partage d’expérience : comment je suis devenu ingénieur diplômé par l’État à 44 ans. Évalué à 6. Dernière modification le 25 janvier 2020 à 09:55.
Je n'avais jamais lu « mastaire » jusqu'ici mais une des raisons est qu'il est devenu désuet entretemps. Cf mastaire : « le décret n° 2002-480 du 8 avril 2002 qui dit que le mot : « mastaire » est remplacé par le mot : "master" dans le décret 99-747 de 1999 relatif à la création du grade de mastaire. ». Du coup JORF n°0084 du 10 avril 2002 page 6323 texte n° 34 : « Article 1 Dans le titre et dans toutes les dispositions du décret du 30 août 1999 susvisé, le mot : "mastaire" est remplacé par le mot : "master". » (Décret n°99-747 du 30 août 1999 relatif à la création du grade de master consolidé)
(et merci pour le retour d'expérience)
# grande valeur de 14 ou petite valeur de 16 ?
Posté par Benoît Sibaud (site web personnel) . En réponse au lien La recherche française inaugure Jean Zay, un supercalculateur de 14 pétaflops installé à l'Idris. Évalué à 3. Dernière modification le 24 janvier 2020 à 08:01.
14 ou 16 Pflops ? L'info varie suivant les sources journalistiques.
Par ex https://www.usinenouvelle.com/editorial/quatre-questions-sur-jean-zay-le-nouveau-supercalculateur-du-cnrs-dedie-a-l-ia.N922244 (ou France Inter, Le Monde Info, …)
[^] # Re: et moi et moi et moi
Posté par Benoît Sibaud (site web personnel) . En réponse au lien s/man/tldr.sh/. Évalué à 5.
« Journal > Lien » 34° règle de Abraham Jean-Kevin Newton sur l'Internet
[^] # Re: Typo
Posté par Benoît Sibaud (site web personnel) . En réponse à la dépêche La libération des FPGA et des ASIC bien engagée pour 2020. Évalué à 4. Dernière modification le 22 janvier 2020 à 09:21.
Corrigé, merci.
[^] # Re: Typo
Posté par Benoît Sibaud (site web personnel) . En réponse à la dépêche La libération des FPGA et des ASIC bien engagée pour 2020. Évalué à 6.
Corrigé, merci.
[^] # Re: Précises ta pensée
Posté par Benoît Sibaud (site web personnel) . En réponse au message un Linux pour les rédacteurs. Évalué à 7.
Il est possible que le but soit juste de placer un lien perso (retiré) dans un but publicitaire.
[^] # Re: Piste: vote sur des commentaires de comptes supprimés ?
Posté par Benoît Sibaud (site web personnel) . En réponse à l’entrée du suivi Entrée redis louche "users//diff_karma". Évalué à 3 (+0/-0).
(*) ça ne change rien pour les dépêches soumises anonymement mais non réaffectées à Anonyme. Ni pour les dépêches non publiées pour lesquelles on conserve les infos et qu'il faut traiter par ailleurs (par exemple un nettoyage complet au bout d'un an).
[^] # Re: Piste: vote sur des commentaires de comptes supprimés ?
Posté par Benoît Sibaud (site web personnel) . En réponse à l’entrée du suivi Entrée redis louche "users//diff_karma". Évalué à 3 (+0/-0).
On ne devrait plus avoir cette entrée.
https://github.com/linuxfrorg/linuxfr.org/commit/33c640854b5b88c8c9e6706ddfb65fe66849ef1e
[^] # Re: Question con...
Posté par Benoît Sibaud (site web personnel) . En réponse au journal GoatCounter 1.0 un Web analytique léger, libre et respectueux. Évalué à 5.
Je me suis posé la même question en allant voir (alors on va dire que ce n'est pas une question con :). Par contre c'est du code à ajouter dans une page et pas de l'analyse de logs, ça m'intéresse moins pour LinuxFr.org.
[^] # Re: typo
Posté par Benoît Sibaud (site web personnel) . En réponse au journal Guix : un outil pour les remplacer tous. Évalué à 6. Dernière modification le 19 janvier 2020 à 13:51.
Le système actuel (cf https://linuxfr.org/aide#aide-authentification ):
- on peut rééditer pendant quelques minutes ses propres commentaires ;
- on ne peut pas rééditer ses propres contenus (qu'ils soient modérés a priori comme les dépêches et les sondages, ou a posteriori comme les autres contenus du site).
Dans l'absolu (et pour des raisons de responsabilité juridique notamment), il y aurait moins de sens à permettre de rééditer les contenus modérés a priori (ou alors il faut revérifier toutes les éditions post-publication).
En dehors de cette question, de façon externe au site, le greffon Grammalecte pour navigateur permet de nettoyer pas mal de fautes d'orthographe/grammaire typiques avant de soumettre.
[^] # Re: typo
Posté par Benoît Sibaud (site web personnel) . En réponse au journal Guix : un outil pour les remplacer tous. Évalué à 3.
Corrigé, merci.
[^] # GNU Date ?
Posté par Benoît Sibaud (site web personnel) . En réponse au journal Convertir des dates avec month_nb. Évalué à 4. Dernière modification le 14 janvier 2020 à 09:38.
Certes…
Je me serais attendu à ce que ce qui suit (qui n'aidera pas en javascript) marche par défaut :
$ LC_ALL=en_GB date +"%m" -d "01 January 1970 00:00:00"
01
$ LC_ALL=fr_FR date +"%m" -d "01 décembre 1970 00:00:00"
date: invalid date '01 d\303\251cembre 1970 00:00:00'
$ LC_ALL=de_DE date +"%m" -d "01 Dezember 1970 00:00:00"
date: invalid date '01 Dezember 1970 00:00:00'
(mais non cf https://www.gnu.org/software/coreutils/manual/coreutils.html#Calendar-date-items )
# Quid des années bissextiles ?
Posté par Benoît Sibaud (site web personnel) . En réponse au journal Convertir des dates avec month_nb. Évalué à -3.
month_nb('février') == 28.25 ?
[^] # Re: Allemand
Posté par Benoît Sibaud (site web personnel) . En réponse au lien Interrogée, la communauté Wikipédia française rejette massivement l’écriture inclusive - numerama. Évalué à 5. Dernière modification le 12 janvier 2020 à 14:03.
Il y a un autre aspect avec l'allemand, la question de la traduction :
Du coup quand tu traduis, soit tu disposes d'un contexte qui te dit si on parle de homme ou d'une femme, soit tu fais un choix : « I'm a doctor » -> « Ich bin (ein) Artz » ou « Ich bin (eine) Ärtzin », « je suis un docteur » ou « je suis une docteure ». Ce choix est encore plus marqué si tu fais une double traduction (potentiellement le cas sur des outils de traduction automatique avec un langue pivot, par exemple si on imagine que la traduction se fait allemand -> anglais -> français car la traduction directe n'est pas possible, et en anglais on n'utilise que rarement male/female pour qualifier une personne exerçant un métier). Quand tu apprends/révises une langue avec un outil type Duolingo/Babel (par exemple anglais->allemand et allemand->anglais), tu le notes assez vite.
[^] # Re: paquet deb
Posté par Benoît Sibaud (site web personnel) . En réponse à la dépêche mcMidiPlayer : un nouveau lecteur MIDI. Évalué à 10.
LinuxFr.org, ce site de speeddating entre développeur et empaqueteur. Merci à vous deux.
[^] # Re: Ce journal, c'est un peu un rond-point...
Posté par Benoît Sibaud (site web personnel) . En réponse au journal Tout cela me fatigue…. Évalué à 10.
Ce ne me semble pas incompatible. Techniquement je fais des choses intéressantes au taf dans un milieu dit « devops » (je coche un paquet de mots clés à la mode). Et pourtant, je constate néanmoins des logiciels qui consomment un max de RAM, de bande passante, de l'empaquetage foireux, du pipeau marketing, de requêtes mal optimisées (SQL ou noSQL), chaque commit brûle une forêt en déclenchant une débauche de tests à tout niveau dans l'intégration continue, etc., bref ce qui est décrit dans ce journal.
Globalement les "valeurs" des personnes ne sont juste pas les mêmes : peut-être qu'avant on privilégiait (plus) l'optimisation des ressources, la compréhension et la maîtrise de l'ensemble, la qualité des spécifications, le coût, etc. que sais-je encore, alors que maintenant on privilégierait (plus) les fonctionnalités, la rapidité de mise sur le marché (TTM), la capacité à tester vite, une forme de pragmatisme (la qualité doit être suffisante parce que les gens continuent d'acheter…), etc. Chacune de ces priorités a des conséquences : tu vas plus vite en réutilisant des dizaines de composants existants, mais tu galères à les gérer, à éviter les trous de sécu, à garantir une certaine qualité et tu empiles des couches auxquelles tu ne comprends plus grand chose ; tu développes plus vite en ayant du code d'infra et des API partout, mais tu gaspilles plus d'argent (forcément avant on t'en donnait moins et t'avais pas la carte de crédit). Tu voulais des spécifications claires et précises pour « bien coder », mais maintenant on se dit agile et on veut que ça bouge vite. Etc., etc. Et forcément des gens se trouvent en décalage avec les valeurs « à la mode »/du moment. Et ça ne veut pas (forcément) non plus dire qu'avant les gens étaient des génies parfaits et que maintenant les gens sont des incultes incompétents. Ça veut plutôt dire qu'il y a eu tellement de changements (ou juste de temps écoulé) que ça a finit par créer des "générations", bref que l'on est devenus les vieux d'autres gens (tout étant étant plus jeunes que les vieux d'avant qui étaient mieux aussi).
[^] # Re: Ce journal, c'est un peu un rond-point...
Posté par Benoît Sibaud (site web personnel) . En réponse au journal Tout cela me fatigue…. Évalué à 10.
Ta généralité permet juste d'empêcher toute critique basée sur l'expérience, vu qu'il devient impossible de commenter un hypothétique recul sur quoi que ce soit. Vraiment la critique, c'était mieux avant. Je ne nie pas que souvent le « c'était mieux avant » peut être un problème de « vieux cons », mais je ne suis pas d'accord pour que ça devienne une implication.
[^] # Re: IPv6, aide nous.
Posté par Benoît Sibaud (site web personnel) . En réponse au journal GeoIP change de licence à cause de la réglementation. Évalué à 3.
( https://fr.wikipedia.org/wiki/Registre_Internet_r%C3%A9gional )
[^] # Re: Ligne éditoriale LinuxFR
Posté par Benoît Sibaud (site web personnel) . En réponse à la dépêche Que retenir de l’année 2019 ? Le point de vue de quelques membres de LinuxFr.org. Évalué à 5. Dernière modification le 06 janvier 2020 à 10:45.
Notamment dans la section cuisine (comme https://linuxfr.org/news/cake-automnal ) ou dans la section Rien à voir (par définition, d'ailleurs c'est celle utilisée ici) ou dans la section Culture (par exemple https://linuxfr.org/news/film-la-strategie-d-ender ).
[^] # Re: Les notes
Posté par Benoît Sibaud (site web personnel) . En réponse à la dépêche Les meilleurs contenus LinuxFr.org des années 201? et 200[89]. Évalué à 7.
[^] # Re: Monde de merde ?
Posté par Benoît Sibaud (site web personnel) . En réponse à la dépêche Que retenir de l’année 2019 ? Le point de vue de quelques membres de LinuxFr.org. Évalué à 8.
Un exemple de biais de couverture : https://sustainabilitymath.org/wp-content/uploads/2019/06/Causes-of-death-in-USA-vs.-media-coverage-s.png
[^] # Re: Pas emballé
Posté par Benoît Sibaud (site web personnel) . En réponse à la dépêche Que retenir de l’année 2019 ? Le point de vue de quelques membres de LinuxFr.org. Évalué à 9. Dernière modification le 05 janvier 2020 à 13:01.
La dépêche ne me semble pas dire « des gens ne nous disent pas tout » mais « nous auteurs de la dépêche choisissons de parler des sujets que nous jugeons les plus importants ». Donc oui les sujets ont pu être abordés dans les médias classiques (mais pas forcément en proportion de l'importance jugée par les auteurs de la dépêche) et cette dépêche n'a pas vocation à lutter contre la désinformation. En fait j'ai l'impression que cette partie de ta critique tombe à côté.