Benoît Sibaud a écrit 8844 commentaires

C'est https://linuxfr.org/redaction/news/le-materiel-libre-ou-en-sommes-nous le bon lien.

Le sondage en question n'existe pas dans la base de données (son ajout a été rejeté). Du coup la seule solution est de le refaire, désolé.

Corrigé, merci.

ce genre de billets de plus en plus régulier

Je n'ai pas 36 exemples en tête de précédents (1), la généralisation me paraît abusive ou hâtive, indépendamment de savoir si c'est une bonne chose ou non de les publier.

Par ailleurs, LinuxFr.org publie (ou refuse de publier) les contenus qui lui sont proposés ou sont co-écrits par ses visiteurs. N'hésite donc pas à proposer sur les sujets qui te conviennent.

En base de données, le champ answer est un varchar(128). L'entrée proposée faisait 153 octets. Mysql a râlé fort, et l'erreur est mal gérée pour la présenter à l'utilisateur.

Fait, merci.

un gentil administrateur ayant les droits qui vont bien pourrait-il bien pallier mes lacunes en français ? ;-)

Corrigé. Par contre il me faut une piste pour « de fréquentes discussions avec des collègues sur les <> »

Cf https://github.com/linuxfrorg/linuxfr.org/commit/e7824aaef9b6a680f0fd602945a06b80b4b46456

C'est un bug avéré de la même fonctionnalité, donc à traiter aussi.

Tandis que ce que tu demandes est une évolution. Quitte à changer cela, je me demande plutôt si on ne virerait pas la case pour obliger à publier sous CC By Sa, ceux qui ne le souhaitent pouvant trouver d'autres sites pour publier. La case est présente pour ceux qui nous ont demandé de publier sous Licence Art Libre ou autre licence libre, pas pour ceux qui ne voudraient pas une licence libre ou qui voudraient du copyright/droit d'auteur de base (cf https://linuxfr.org/suivi/dautres-licences-pour-les-journaux#comment-1253825 ).

Plus le bug touchant la prévisualisation uniquement :

Corrigé, merci.

Cf https://linuxfr.org/suivi/heberger-les-images-des-news-et-eventuellement-journal

Corrigé, merci.

Merci de rester courtois dans les échanges conformément aux règles de modération en vigueur sur le site.

Cf fracture numérique.

Corrigé, merci.

Plutôt NeuNeu ou Neuneu apparemment.

Pourquoi nettoyer s'il n'y a rien à nettoyer ?

• avec un conteneur, il est possible d'avoir installé plusieurs applications dedans et de vouloir en désinstaller une seule. Le fait de savoir désinstaller (de l'avoir testé réellement) peut aider à détecter des erreurs d'installation (on a créé des fichiers temporaires non prévus, créé des fichiers au mauvais endroit, mal géré des permissions, etc.). Dans une distribution, une partie de bugs est détecté via les mises à jour et les désinstallations.
• le fait de savoir désinstaller permet de confirmer que l'on fait ce que l'on pense faire (faire ce qui était prévu et uniquement ce qui était prévu).
• il me semble plus satisfaisant de maîtriser ce que l'on fait que de jeter tout, mais techniquement/pratiquement/économiquement c'est un compromis sur le fait que de toute façon c'est techniquement difficile alors on va au plus simple / ça coûte moins cher de tout jeter ici « l'écologie/recyclage » on s'en fout mais si ça consomme sûrement plus en énergie / ça permet d'aller vite et c'est tout ce qui compte dans ce monde.
• conceptuellement je trouve étrange de se dire en gros « l'informatique est à mon service et me permet de tout faire » mais bon en fait je suis dépassé, quand j'ai un souci je jette tout. C'est une particularité de l'informatique, heureusement que tous les architectes ne détruisent pas les bâtiments à chaque fois, les mécanos les voitures, etc. C'est une exception de travailler à « ressources quasi-infinies à coût quasi-nul ».
• « sans effet de bord » est difficile à montrer : le fait d'installer des conteneurs modifie l'hôte, le fait de créer des machines virtuelles modifie l'hyperviseur, la config réseau, etc. On fait plutôt ce que l'on peut/sait dans un domaine où une application tourne dans une machine virtuelle du langage qui tourne sur une machine virtuelle système qui tourne sur une machine virtuelle du processeur… qui finit par tourner sur un processeur physique (embarquant des couches de virtualisation interne). Idem pour entre le système et la tête de lecture d'un disque dur, il y a un paquet de caches, conversions et intermédiaires (FS, LVM, RAID, cache processeur, cache disque, microcode du disque, etc.). Ne pas nettoyer me semble plutôt un choix pragmatique « de toute façon on ne sait pas nettoyer vraiment sûrement en fait ».
• le fait de ne pas analyser ralentit probablement aussi la découverte de bugs. Exemple bateau : une appli crashe car tel port était déjà ouvert pour une raison non prévue. On la réinstalle, cool ça remarche. Mais on ne sait pas pourquoi et le point ne sera pas corrigé, donc ça tiendra jusqu'au prochain plantage.
• on doit pouvoir trouver d'autres raisons, mais comme on n'est déjà plus vendredi, je vais retourner faire des scripts d'automatisation ansible pour les conteneurs et machines virtuelles de LinuxFr.org…

La génération actuelle d'adminsys, et la prochaine encore plus, élevée au containeur, à la machine virtuelle et au déploiement automatique sait plus facilement réinstaller que réparer/analyser ou même désinstaller proprement. Il me semble difficile d'espérer plus de l'utilisateur final, surtout un vendredi.

Cf l'aide sur le karma : « max(-10, -2 + E(karma/30)) pour un karma négatif ou nul », ce qui concerne actuellement 24 comptes parmi 3277 actifs.

Les coulisses :

1. j'ai pris la liste des DVCS libres hormis Git sur Wikipédia (« ArX (2003) Codeville (2005) Darcs (2002) DCVS (2002) Fossil (2007) GNU arch (2001) GNU Bazaar (2005) Mercurial (2005) Monotone (2003) SVK (2003) Veracity (2010) »)
2. j'ai retiré ceux marqué « Unmaintained » or « Abandoned » or « Discontinued » or « deprecation » sur Wikipédia (ArX, Codeville, DCVS, GNU arch, SVK).
3. Parmi les restants, les noms de Monotone et Veracity ne m'étaient pas familiers et leurs dernières versions semblaient anciennes.
4. Ceux qui restent (Darcs, Mercurial, Bazaar ou Fossil) ont sorti des versions fin 2015 ou début 2016, donc sont encore maintenus (qu'ils soient largement utilisés ou non, qu'ils soient mourants ou non).

Corrigé, merci.

Corrigé, merci.

Corrigé, merci.

Corrigé, merci.