Boa Treize a écrit 3449 commentaires

On ne fait disparaître que ce que l'on veut bien voir disparaître.

Et que faire si, en restaurant ton service, il fait s'effondrer toute son infrastructure ? N'est-ce pas aussi son obligation de maintenir un maximum de services à défaut de pouvoir tous les maintenir ?

J'ai été dans une université où il n'y avait aucun filtrage au niveau des dortoirs (penses-tu !) et Internet était inutilisable en dehors des week-ends et des vacances : environ 1 ou 2 Ko/sec, au lieu de 1 Mo/sec !

Le très gros défaut d'Arch Linux, c'est qu'il n'y a pas de documentation installée : /usr/doc est quasiment (totalement ?) vide, la documentation est soigneusement effacée lors de la création des packages.

Les mainteneurs affirment que de toute façon personne ne lit ce genre de doc et que tout le monde va sur Internet. C'est effectivement assez souvent le cas, mais c'est justement quand ce n'est pas le cas qu'on se retrouve à avoir le plus besoin de documentation...

(Et puis ça m'arrive encore d'accéder à Internet à 33 kbps, et dans ce cas, mieux vaut avoir un max de choses déjà en local.)

Le bus AGP transporte 32 bits à chaque battement d'horloge. A moins que le protocole ne prévoie la possibilité de passer 2x 16 bits de données indépendantes (je serais surpris, c'est une grosse complication), passer 16 ou 32 bits de données ne devrait rien changer.

Par contre, c'est vrai que le 16-bit nécessite moins de RAM, et un peu moins de calcul au niveau du PC et de la carte graphique, en tout cas celles de bien anciennes générations.

De là à faire un x2 systématiquement, c'est un peu trop simpliste comme affirmation.

La famille de Nina Reiser lance une campagne pour faire parler de l'affaire et augmenter les chances de la retrouver. Entre autres :

http://www.ninareiser.com/

Le 16 bit permet de doubler le nombre d'images par secondes par rapport à du 24/32 bits ? Merci d'argumenter cette affirmation extraordinaire.

Il aurait fallu préciser qu'il s'agit de la première RC de la version 1.2. Ca fait plus d'un an que la version 1.0 est sortie.

J'ai essayé Wesnoth récemment (version de développement, proche de ce qui va sortir), j'ai été agréablement surpris, c'est très réussi.

Toutefois, la version française a bien besoin d'un coup de main, notamment au niveau des textes des campagnes (narratifs, dialogues, etc.), qui sont parfois très mal traduits, presque ridicule dans un ou deux cas. C'est pas forcément un boulot énorme, mais il faut avoir un peu la fibre littéraire, sur cette partie là.

Par contre, l'encyclopédie qui décrit les unités est très bien traduite, je trouve, en tout cas pour la petite centaine d'unités que j'ai eu l'occasion de voir.

Une page web peut être consultée au moyen d'un écran, d'une feuille de papier, d'un téléphone portable, d'un terminal en mode texte et même d'un haut-parleur.

C'est toute la différence entre le HTML et le LaTeX. Le premier cherche à décrire le fond du document et permet d'y joindre des instructions de mise en forme pour les divers media que j'ai listé ; le second se concentre presque exclusivement sur la mise en page en vue d'une impression sur papier. Ils n'ont pas les mêmes objectifs, et donc pas les mêmes capacités, les mêmes avantages et les mêmes inconvénients.

On peut tout à fait argumenter que les instructions de mise en forme HTML ne sont pas assez développées, et surtout sous-utilisées. Il serait effectivement agréable si, dans le cadre d'un rendu en haute-résolution (papier, ou écran avec beaucoup de points par centimètre), le navigateur se chargeait de mettre des espaces fines insécables avant les points virgules, des espaces mot après, et repérait les espaces perdus dans les tableaux de chiffres pour les remplacer par des espaces tabulaires. Attention quand même, les vieux textes historiques utilisaient d'autres conventions de mise en page, par exemple ils mettaient un peu d'espace avant les virgules.

En fait, c'est quand tu dis que les normes existent et que les règles de typographies sont bien connues que tu te trompes le plus. Il y a effectivement toute une série de règles de base sur lesquelles les typographes s'accordent actuellement, mais le diable se cache dans les détails : le petit monde de la typographie semble ravagé de guerres de chapelles sur ces points, et quand on commence à parler de la taille des marges, de la longueur des lignes, du gris de la page, on atteint le domaine de la subjectivité et du talent personnel. Car la typographie est un artisanat, pas une industrie. Il est impossible de la gérer « complètement ».

Moi en tout cas, je serai déjà bien content quand Firefox arrêtera de supprimer volontairement les espaces insécables... Car on en est là actuellement : non pas vouloir que les navigateurs fassent de la typographie, mais au moins qu'ils arrêtent de la démolir.

https://bugzilla.mozilla.org/show_bug.cgi?id=194498
https://bugzilla.mozilla.org/show_bug.cgi?id=218277

En anglais (américain en tous cas) c'est l'inverse, on ne met pas d'espace entre le mot et la ponctuation qui suit, genre point-virgule, point d'interrogation, point d'exclamation, etc.

Le français canadien suit les règles américaines je crois.

une distrib linux devra respecter la GPL V3

C'est à dire ?

De manière générale les distribs respectent les licenses des programmes qu'elles distribuent. (C'est une évidence non ?)

Si tu veux dire que la distrib devra tout passer en GPL v3, tu n'as pas compris. Les licences GPL (et les autres aussi) n'imposent pas que les programmes distribués ensemble sur le même support utilisent une même licence. Par ailleurs, les licences des programmes que tu cites n'imposent pas que les programmes créés ou exécutés grâce à eux soient sous une licence particulière. Donc une distrib Linux qui les utilise ou les distribue peut tout à fait mettre son propre code source (l'installeurs, les scripts d'admin, ce genre de chose) sous la licence qui lui plait.

Pour le problème des césures, le caractère soft-hyphen (U+00AD) a été inventé précisément pour ça, même s'il y a divergence d'opinions sur la manière de le gérer, et de nettes différences d'implémentation selon les navigateurs.

N'empêche qu'en HTML, ce caractère sert à indiquer au navigateur qu'il est autorisé à couper le mot qui le contient à l'endroit où il se trouve. C'est donc à l'auteur du document d'insérer des ­ aux bons endroits, pas au navigateur.

http://www.cs.tut.fi/~jkorpela/shy.html

Par ailleurs, pour ce qui est du langage, il y a déjà moyen en HTML d'indiquer quelle est la langue d'une portion de texte, grâce à l'attribut lang. Tu t'avances beaucoup sur un sujet que tu connais manifestement mal, c'est pas étonnant que tu ailles un peu dans le mur.

Mon argument c'était que quelqu'un qui prend la peine de l'utiliser prendra aussi la peine de bien rédiger son document, y compris les éventuelles indications typographiques que les normes prévoient. Sachant, encore une fois, que le HTML n'est pas un langage de mise en page ! Donc ton propos initial, qui était que les navigateurs doivent faire de la typo car les auteurs en sont incapables, ne tient pas la route : il faudrait que les navigateurs embarquent de sérieuses IA pour ce faire. (Et ne parlons pas du cauchemar inévitable des différences d'implémentation, ou du cauchemar encore plus terrible d'une tentative de normalisation !)

Je crois que tu peux t'arrêter, là, on est tous d'accord, on a tous compris, sauf l'autre là, qui va poster encore une réponse, une variante des précédentes... Plus la peine de répondre, tout a été dit. Laisse-lui le dernier mot, celui qui tombe dans une salle de conférence déserte...

Sauf qu'il n'y a pas de points de séparation dans les nombres en France, mais des espaces.

Et quitte à commencer à corriger la typographie, pourquoi ne pas corriger automatiquement l'orthographe tant qu'on y est ? Et la grammaire ? Et les fautes de mise en page ? Et les fautes de goût ?

Et quand on cite une phrase anglaise dans son texte, comment on fait pour deviner qu'il faut appliquer d'autres règles de transformation du texte ? Et pour le français canadien, on fait comment ?

Quelqu'un qui n'a pas pris le temps de mettre une espace avant le point d'interrogation prendra-t-il le temps de tagguer correctement le langage de sa page et chaque phrase ou mot étranger qu'il pourrait être amené à inclure dans son texte ?

Franchement, je ne pense pas que ce soit au navigateur de gérer tous ces problèmes, en tout cas certainement pas par défaut ; c'est aux outils de création de contenu de faire ce travail, en assistant plus ou moins automatiquement le rédacteur dans sa tâche.

Ceci dit, si tu veux créer un plugin Firefox qui transforme tes pages à la volée pour qu'elles te conviennent mieux, n'hésite pas !

Bref, là t'avais vraiment pas de chance (guichetière qui ne respecte pas le protocole et controleur qui l'applique à la lettre)

J'ajoute quand même passager qui ne vérifie pas ses billets, ni à l'achat, ni au compostage, ni à la montée dans le train...

Bon, moi je suis plutôt content, j'ai changé d'horaire et on m'a donné 10 euros...

Ca va plus loin que ça : il connaît et a toujours détesté CVS, il a regardé et n'aime pas beaucoup plus Subversion.

D'ailleurs, après avoir utilisé un truc proprio qui lui convenait bien, il a créé son propre truc qui lui convient bien. ;-)

Rappelons aussi que le concept d'ACL est très puissant (granularité fine des autorisations et des interdictions), et qu'il est présent depuis de nombreuses années dans VMS, Windows, d'autres Unix, et probablement d'autres systèmes que je ne connais pas.

En l'absence d'ACL, sous Linux, on est obligé de créer un groupe d'utilisateurs pour chaque combinaison possible de gens et d'ensembles de fichiers auxquels ils peuvent avoir accès. La combinatoire devient très vite ingérable, ce qui limite les permissions à des scénarios assez simples, d'autant plus que le nombre de groupes auxquels un utilisateur peut appartenir est assez limité (16 ou 32, de mémoire). Simples, mais suffisants dans la plupart des cas. Pour les autres, il y a les ACL.

Exemple typique et concret :

Des équipes d'étudiants qui font un TP. Chaque équipe a un groupe Unix bien sûr, pour que les fichiers créés par ses membres soient lisibles des autres membres, et pour qu'à l'inverse les membres de l'équipe ne puissent pas aller lire les fichiers des autres équipes. Jusqu'ici tout va bien.

Arrivent les assistants de TP. S'il n'y avait qu'un assistant, il serait root ou un truc du genre et n'aurait pas de problème. Mais il y a beaucoup d'équipes, donc plusieurs assistants, et pour diverses raisons, on ne veut pas qu'ils partagent le même compte, encore moins le compte root.

Donc on galère à mettre les assistants dans tous les groupes d'élèves qu'ils doivent encadrer, on se confronte à la limite du nombre de groupe maximum par utilisateur, on galère à maintenir tout ça, et en plus c'est pas propre car l'assistant peut modifier les fichiers des élèves.

Avec les ACL, il suffit de donner le droit de lecture seule à l'assistant qui va bien sur les répertoires (et sous-répertoires) qui vont bien, et c'est tout.

Si on ne connaît pas l'architecture de Git, c'est sûr que ce n'est pas facile à comprendre. J'aurais dû utiliser une formulation plus claire.

Rapidement :

Le coeur de Git, c'est de stocker des objets, et de les identifier par leurs somme de contrôle (SHA1 actuellement). Git ne gère que quatre types d'objets :

- le blob, qui est un gros tas d'octets dans lequel Git ne met pas son nez ; concrètement, les différentes versions des fichiers mis en conf sont stockées sous forme de blob

- l'arbre, qui contient des pointeurs vers des blobs et possiblement vers d'autres arbres ; c'est ce qui permet de mémoriser l'arborescence des fichiers

- le commit, qui contient un pointeur vers un arbre (la racine des fichiers dont on souhaite mémoriser l'état) et vers un ou plusieurs autres commits (les ancêtres de ce commit, ce qui permet de constituer l'historique du développement, et de gérer les branches)

- le tag, objet plus anodin qui pointe vers n'importe quel objet précédent, et porte un nom (genre v2.6.16.7) et optionnellement une signature.

Donc, comme Mercurial (et Monotone ?), Git stocke l'état des fichiers aux divers moments du développement, et génère le diff entre deux états à la volée. Contrairement à Arch ou Darcs, par exemple, qui stockent les diff et génèrent l'état à la demande.

Le reste de Git, c'est de la fioriture. ;-)

- Programmes de bas niveau pour gérer ces objets
- Programmes pour compacter tous ces objets en un pack qui consomme beaucoup moins d'espace disque et gérer ce genre de pack
- Programmes pour envoyer et recevoir ces objets par divers protocoles
- Programmes pour générer et digérer des patches de toutes sortes
- Programmes pour interroger les données dans tous les sens (diff, grep très puissant, logs plus ou moins verbeux, etc.)
- Programmes pour chercher à quel endroit on a introduit un bug
- Programmes pour importer les données d'autres gestionnaires de conf
- Programmes pour encore plein de trucs divers et variés plus ou moins annexes
- Et bien sûr programmes de plus haut niveau pour pas se prendre la tête dans la vie de tous les jours ;-)

Le tout étant à peu près correctement documenté. Git a fait beaucoup de progrès depuis ses débuts. :-)

Doc pour débuter :

Everyday Git
http://www.kernel.org/pub/software/scm/git/docs/everyday.htm(...)

Vue d'ensemble
http://www.kernel.org/pub/software/scm/git/docs/

C'est ce que je mentionnais quand je parlais "d'identifiant du commit" plus haut. Sur ce point Git fonctionne comme Monotone je crois. (Mais je connais très peu Monotone.)

Ce que la personne voulait, c'était un numéro séquentiel.

Une telle numérotation aurait bien sûr été limité au niveau du repository. Mais la plupart des projets ayant un seul repository officiel, la fonctionnalité aurait quand même pu être utile. Ceci dit, c'était effectivement un autre argument en défaveur de cette demande.

C'est pas dit. Une fois passée la phase de création des scripts Slackbuild, si la structure des sources n'évolue pas trop, il suffit presque de relancer les scripts quand une nouvelle version sort.

X est déjà découpé en plusieurs packages (x11, x11-devel, x11-xdmx, etc.), ça ne gêne pas particulièrement lorsqu'une nouvelle version sort.

Patrick Volkerding a continué d'utiliser la version 6.9 parce qu'au niveau du contenu elle est quasi-identique à la version 7.0, et que ça lui économisait le développement de ces nouveaux scripts Slackbuild. Peut-être craignait-il aussi que le découpage effectué ne soit pas encore bien stable.

En tout cas, je suis prêt à parier que pour la prochaine version il les aura créés. :-)

Ha ha, le café ça fait du bien, je n'avais pas bien compris le message auquel j'ai répondu. (Bon, j'espère que ma réponse sera utile à d'autres personnes.)

Je n'avais pas suivi cette histoire de Linux 2.6.16 qu'un des contributeurs veut maintenir indéfiniment, comme l'est actuellement la version 2.4 du noyau, et comme ont pu l'être (ou sont toujours ?) les versions 2.2 et 2.0.

Manifestement, Patrick Volkerding pense qu'utiliser une version stable 2.6.x.y, basée sur une 2.6.x d'il y a trois mois est suffisant pour n'avoir pas trop de bogues. Et au pire, il y a la version 2.4. ;-)

C'est pourtant un fork très classique.

Linus travaille sur 2.6.18, il patche, il modifie, il fait des release-candidate, et quand il est satisfait, il publie 2.6.19 et ça continue.

Par ailleurs, d'autres personnes suivent de près les patches intégrés à 2.6.18, ne retiennent que ceux qui corrigent des bugs, vérifient que le tout s'intègre bien et ne produit pas d'incompatibilité avec le 2.6.18 de base, et produisent des versions dérivées de 2.6.18 : bientôt 2.6.18.1, puis 2.6.18.2, etc.

Concrètement :

- 2.6.17 a été publié le 18 juin par Linus Torvalds

- 2.6.17.1 a été publié le 20 juin par Chris Wright
...etc...
- 2.6.17.13 a été publié le 9 septembre par Greg Kroah-Hartman

Pendant ce temps là, Linus Torvalds a continué à améliorer 2.6.17, ce qui a donné ça :

- 2.6.18 a été publié le 20 septembre par Linus Torvalds

- 2.6.18.1 n'a pas encore été publié, ce qui est un peu étonnant mais bon, si ça se trouve il n'y avait pas de bug dans 2.6.18 ;)

Pour plus de détails :

Ce que publie Linus Torvalds :
http://kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6(...)

Branche stable du noyau 2.6.17 :
http://kernel.org/git/?p=linux/kernel/git/stable/linux-2.6.1(...)

Branche stable du noyau 2.6.18 (pour l'instant identique à ce qu'a publié Linus) :
http://kernel.org/git/?p=linux/kernel/git/stable/linux-2.6.1(...)

Le but est (était ?) de comparer les gros trolls velus que certaines grandes gueules bien connues peuvent pondre parfois.

Je n'ai en aucun cas prétendu que Linus avait raison, et d'ailleurs, comme je l'avais dit quand j'avais traduit son troll lors de la sortie de la dernière version de Linux, sur ce point précis il avait tort. (Mais son opinion sur Subversion demeure.)

Sur ce point précis :

Un utilisateur est venu demander si on pouvait modifier Git pour disposer d'un numéro de révision qui s'incrémente monotoniquement, pour pouvoir faire comme sur les projets qui utilisent Subversion, et dire simplement aux utilisateurs "utilise la révision 393" ou "c'est corrigé dans la révision 532".

Linus est parti de travers la dessus (ce qui lui arrive rarement), et a donc pondu ces phrases mémorables sur la qualité de CVS et Subversion (bon ça, ça lui arrive plus souvent), et notamment une grande tirade sur la numérotation des branches dans CVS (1.1.1.5, ce genre de trucs effectivement bien horrible mais qui n'avait rien à voir avec ce que l'utilisateur demandait).

Après un petit recadrage d'autres contributeurs de Git, les arguments suivants ont été retenus :

- C'est faisable dans Git, mais ça fait une métadonnée à mémoriser en plus, et un changement qui impacte pas mal de commandes de Git
- Communiquer une version abrégée de l'identifiant du commit concerné fonctionne aussi bien ("utilise le commit 5ef24" ou "c'est corrigé dans le commit 63b43")
- Ce genre de communication est plus liée à un projet organisé autour d'un référentiel centralisé et qui utilise peu de branches ; dans les projets plus distribués et/ou qui utilisent plus de branches, on a plutôt tendance à dire "utilise la branche new_features" ou "c'est corrigé dans la branche bugfixes".

Au final, vu tout ça, la conclusion a été "si quelqu'un le veut vraiment, qu'il propose un patch".

Sur Subversion et CVS :

C'est tout l'argument centralisé contre distribué, politique des projets, etc. qu'il faudrait reprendre. Ce que je ne vais pas faire là maintenant.

Je ne pense pas que gérer une redondance supplémentaire des données au niveau du système de fichiers soit utile, sauf dans le cas des métadonnées (superblocks, allocation des inodes, arborescence des noms) dont la perte empêcherait d'accéder à des données pourtant encore parfaitement lisibles.

Par contre, ce que l'incident sur kernel.org a montré, c'est le besoin croissant de minimiser la phase de vérification / restauration de l'intégrité des données : ça, je comprends tout à fait.

Ce n'est d'ailleurs pas tant lié à la fiabilité des disques durs eux-mêmes qu'à la fiabilité de l'informatique en général : erreurs de disque, erreurs de mémoire, erreurs de réseau, plantages du système d'exploitation, etc. Quoi qu'il se passe, il faut que le système de fichiers ne se retrouve pas dans un état corrompu, ou puisse en sortir rapidement et sans trop de casse ; et qu'il puisse vérifier la bonne santé des données après un tel incident.

Là, c'est clair qu'il y a de la marge pour progresser. :-)

Sous Linux, si on veut s'approcher de ça, il faut PAM, désolé

Moi aussi ça me désole.