Sébastien Wilmet a écrit 729 commentaires

Son seul défaut, à mes yeux ? Le principe de la rolling release, très appréciable par ailleurs, nous condamne à Gnome 3, à moins de bloquer la date des dépôts

Je ne sais pas exactement ce qu'implique de bloquer la date des dépôts (si ça s'applique pour tous les paquets, ou juste ceux de gnome, ou … ?).

En tout cas pour moi le défaut dans ce cas-ci n'est pas la rolling release. Le défaut c'est qu'il n'est apparemment pas possible d'installer en parallèle plusieurs versions d'un même logiciel avec Arch. Gentoo fait ça très bien avec les « slots » (mais le packageur a dû explicitement définir les différents slots, ça ne peut pas se faire facilement pour n'importe quel paquet).

Bon là Gentoo a un autre défaut, c'est que GNOME 3 n'est toujours pas disponible dans l'arbre officiel de portage (il faut passer par l'overlay gnome). Mais je suis presque certain que quand ce sera le cas, la version 2 restera dans un slot séparé pendant encore quelques temps. Il serait donc possible de bloquer le slot « 3 » et de rester sur le slot « 2 ». C'est déjà le cas pour les bibliothèques importantes (GTK+, …), dont la version 3 est présente dans portage, mais en testing.

Et s'ils pouvaient aussi arrêter de spamer toutes les pages wikipedia traitant de sujets dont ils ont parlé au moins une fois, ça serait bien aussi…

Ah je ne connaissais pas cette pratique. Par contre ce que j'ai remarqué en lisant l'article sur les bitcoins, qui semblait à première vue intéressant, c'est qu'ils ont fait un gros copier/coller de certaines parties, en provenance du site bitcoin.fr.

Donc ça ne m'étonnerait pas qu'ils fassent aussi des copiers/collers de wikipédia. C'est le chat qui se mord la queue…

C'est quoi WM ?

Window Manager, par exemple metacity (utilisé par GNOME 2), kwin (KDE), mutter (GNOME 3), xfwm (Xfce).

C'est quoi DM ?

Desktop Manager, par exemple GNOME, Xfce, KDE, etc.

Si je ne dis pas de bêtise, Awesome et compagnie peuvent être catégorisé dans les Window Manager aussi.

Je pense qu'il parlait de cookbooks justement.

En anglais : « topic-oriented help ».
Donc « documentation orientée topiques » me semble une bonne traduction.

Souvent, quand on veut se documenter sur un logiciel, on est intéressé seulement par faire une chose bien précise. Un manuel, qui s'apparente à un livre, c'est plutôt fait pour être lu du début à la fin.

C'est pour ça qu'une documentation orientée « topiques » est souvent plus simple pour l'utilisateur. Au lieu de ressembler à un livre, ça ressemble plus à une FAQ. Chaque topique peut être lu indépendamment des autres, avec si nécessaire des liens vers d'autres pages.

GNOME a migré déjà pas mal de sa documentation sous forme de topiques, en langage Mallard. Au Desktop Summit il y a eu une conférence sur le sujet, et l'auteur en a fait un résumé sur son blog.

Mais ce n'est pas le wiki de Btrfs ici, c'est un journal de Linuxfr.

Oui, Python ou Ruby sont beaucoup plus pratique pour ça.

Mais si tu dois faire du C, tu n'as pas le choix…

Refactoring: Improving the Design of Existing Code (Martin Fowler)

Je ne l'ai pas lu, mais à la fin du chapitre sur le refactoring dans Code Complete, c'est la seule ressource additionnelle qui est donnée, avec ce commentaire :

This is the definitive guide to refactoring. It contains detailed discussions of many of the specific refactorings summarized in this chapter, as well as a handful of other refactorings not summarized here. Fowler provides numerous code samples to illustrate how each refactoring is performed step by step.

Mais il faut savoir que la 2e édition de Code Complete est sortie en 2004, donc il se peut qu'un autre livre plus récent, et peut-être meilleur, est sorti.

Voici ce qui est dit dans le livre, qui s'applique tant pour les for, que pour les while :

Si un index de boucle doit être utilisé en-dehors de la boucle (parfois bien après), c'est préférable de lui donner un nom long.

Si une boucle est assez longue, il est facile d'oublier à quoi correspond le i ou le j (donc il faut souvent revenir en haut de la boucle pour voir à quoi elle correspond). Du code est souvent modifié, étendu, et copié dans d'autres programmes, donc beaucoup de programmeurs expérimentés évitent complètement des noms comme i.

Une des raisons pour lesquelles les boucles s'allongent est qu'elles sont imbriquées. Pour améliorer la lisibilité, il vaut mieux mettre des noms longs. Ça permet d'éviter de confondre i et j, et ça rend certaines lignes plus informatives (comme je l'ai expliqué dans le journal).

Si vous devez vraiment utiliser i, j et k, faites le uniquement pour des boucles simples (donc qui ne sont pas imbriquées, et qui ne sont pas très longues, et dont l'index n'est pas utilisé en-dehors). Mais pour éviter tout problème, c'est plus simple de se donner une règle où on n'utilise pas du tout les i, j et k.

---

Voilà, pour moi la meilleure raison est la première, que j'avais déjà expliqué dans le commentaire juste au-dessus.

En ayant lu The Pragmatic Programmer, tu risques de connaitre déjà beaucoup de chose en lisant Code Complete. Mais Code Complete parle de plus de sujets.

Beautiful Code est sorti en 2007, donc c'est normal que Code Complete (2e édition en 2004) ne le référence pas, mais ça a l'air intéressant. Il y a aussi Programmers at Work, qui est plus ancien.

Oui, c'est un des conseils qui est assez controversé.

Ce qui gêne plus, c'est quand le i ou le j est utilisé en-dehors de la boucle, pour retenir par exemple le dernier index valide ou qqch du genre. Dans ce cas il vaut carrément mieux créer une autre variable retenant cet index, avec un nom qui permet de savoir de quoi il s'agit.

Dans le lien que tu donnes, il y a un commentaire contradictoire :

[...]
le vocabulaire est parfois incorrect et que vous vous énerverez régulièrement devant les coquilles.

Ah ben tant mieux s'il est bien écrit, tu fais bien de le dire.

Mais personnellement, en informatique je préfère lire de l'anglais. J'ai donné une raison (les termes techniques qui ne sonnent pas bien en français). Mais c'est aussi un bon entrainement, on apprend du vocabulaire, etc.

Aussi, le dernier paragraphe c'était histoire de troller un peu vers la fin :) Il fallait bien que quelqu'un ne soit pas du même avis.

Oups. J'ai oublié de parler des points négatifs.

Dans le livre il y a dans les marges pas mal de références vers d'autres sections du livre, mais les références sont trop vagues (il faut chercher une sous-sous-section parmi une quinzaine de pages parfois…), il faudrait des numéros de pages.

Et aussi, le texte est en « fer à gauche » au lieu d'être justifié. Mais bon on s'y fait.

Sinon, hors-sujet, mais je dois pas être fait pour le marketing : je suis arrivé à écrire « Bref, à déconseiller. » tout à la fin, alors que je n'ai montré que des points positifs du livre :)

Si tu n'aimes pas le titre du thread^W fil, rien ne t'empêchais de la changer dans ton propre commentaire.

C'est d'ailleurs une fonctionnalité très peu utilisée sur Linuxfr je trouve, et qui serait bien pratique, pcq parfois certains fils deviennent monstrueusement long, et ça part dans tous les sens.

Si en plus tu organises ta façon de travailler correctement, c'est très correct.

C'est ça que je n'aime pas avec GNOME 3, c'est qu'il y a beaucoup moins de « façon de travailler correctement » qu'avec GNOME 2. Avec GNOME 2 c'était beaucoup plus flexible de ce côté-là.

Par exemple, pour ma part, j'aime bien avoir plusieurs fenêtres différentes maximisées sur le même espace de travail. Avec GNOME 2, en un seul clic je vais sur la fenêtre de mon choix. Avec GNOME 3, peut importe la méthode, ça demande plus d'étapes.

Ma mère et ma petite sœur n'ont jamais utilisé plus d'un espace de travail, bien que je leur ai déjà expliqué plusieurs fois, que c'est vraiment pratique, etc. Rien à faire. Avec GNOME 3, si tu n'utilises qu'un seul espace de travail, c'est l'enfer, là où avec GNOME 2 c'est encore gérable.

J'avoue que je considère assez fortement de rester sur gnome-panel+metacity plutôt que de passer à gnome-shell+mutter. Et si un jour ça n'est plus maintenu je créerais un fork sans hésiter

De nouveau, si le mode fallback te convient bien, pourquoi créer un fork ? Il « suffit » de continuer à maintenir gnome-panel et metacity, quand les développeurs décideront de les abandonner.

Commentaire de Linus :

While you are at it, could you also fork gnome, and support a gnome-2 environment?

Ce qu'il faudrait plutôt, c'est régler toutes les régressions de gnome-panel et de continuer à le maintenir¹. Je sais qu'il y a certaines applets manquantes, par exemple (mais certaines applets sont externes au projet GNOME, donc pour ça on ne peut pas leur en vouloir). Je ne sais pas où en est GNOME 3.1 à ce niveau-là, mais la version 3.0 apportait quand même pas mal d'améliorations de gnome-panel par rapport à GNOME 2, notamment le placement des applets (qui partait souvent en c... cacahouète avec GNOME 2).

Bon un autre problème, même avec le mode de fallback (gnome-panel au lieu de gnome-shell), c'est qu'il manque énormément d'options de configuration. gnome-tweak-tool règle partiellement ce problème, mais ça devrait aller mieux avec GNOME 3.2.

Et j'oublie aussi le passage à GTK+ 3 où les marges internes des widgets sont devenues trop grandes.

Donc pour moi ça ne sert pas à grand chose de forker GNOME 2. Mais c'est clair que le mode fallback ne devrait pas avoir de régressions.

¹ J'avais lu que les développeurs de GNOME comptent encore maintenir gnome-panel pendant encore quelques temps, mais pas indéfiniment.

Oui si je n'avais pas trouvé l'astuce, j'aurais sans doute demandé de changer l'adresse e-mail de l'ancien compte.

Pour empêcher certaines personnes de se réinscrire, une autre solution est d'avoir une liste noire. Et de corriger la petite faille qui consiste à rajouter « +qqch » avant le @.

Ce que j'aurais bien aimé, c'est qu'en fermant mon ancien compte, l'adresse e-mail utilisée soit de nouveau disponible. Ce qui est plus logique je trouve, puisqu'un compte fermé ne sait pas être réouvert.

Pour ma part, ce que je voulais c'était un changement de pseudo, mais ça pourrait arriver à d'autres personnes se disant un jour « je ne reviendrai plus jamais ici », mais que quelques années plus tard ils reviennent quand même, et en essayant de se réinscrire, ils doivent utiliser une autre adresse e-mail.

Pour le petit hack, en toute logique ça ne devrait pas être permis.

En Belgique on parle plutôt de guindaille.

Dans l'entretien avec Éric Dumazet :

[...] De manière générale, est‐ce que tu regardes les systèmes BSD pour les comparer avec Linux ?
[...] je ne regarde pas le code de FreeBSD : je préfère que les développements Linux soient « self contained », pour éviter des contaminations pouvant poser problème de droits d’auteur.

Je trouve ça dommage, pcq la pile réseau des systèmes BSD est réputée meilleure et plus performante (malheureusement je n'ai pas de lien, et peut-être que maintenant ce n'est plus le cas).

De plus, à moins que ça soit couvert par des brevets (ce qui m'étonnerait), s'inspirer d'un code sous licence BSD ne doit surement pas poser de problèmes de droits d'auteur.

Bon en fait le jeu de mot est contradictoire avec la phrase, donc on peut préciser : pour Red-Hat, par exemple.

Dû au contrat avec Microsoft, je dirais plutôt que « Satan l'habite ».

Oui la plupart des gens confondent. Sur wikipédia on peut lire :

C'est donc une « coupure de l'esprit », pas au sens d'une « double personnalité », comme il est parfois entendu, mais au sens d'une perte de contact avec la réalité