Guillaume Denry a écrit 2965 commentaires

On peut faire maigrir un obèse en lui coupant un bras, mais je suis pas persuadé que c'était ce qu'il voulait :)

Marrant, ça me rappelle un peu les différents avis autour des nouveaux champs dans les CSS, avec les vendor prefixes pour implémenter en avance de phase de nouvelles fonctionnalités avant leur standardisations.

Pour ne pas les utiliser il n'y a rien à faire, à part ne pas aller trifouiller la cacaouette…

Devine quelle est la première chose que les nouveaux utilisateurs font quand ils arrivent sous un environnement KDE….
Je me base pas sur du vent, j'ai installé KDE à quelques personnes autour de moi !

J'ai vraiment du mal à voir où est le problème, à part troller.

Putain, raz le cul, on peut plus donner son opinion sans se faire traiter de trolleur.
Tu ne me connais pas, j'ai développé un (court) temps dans KDE y'a quelques années et je le répète, j'aime et c'est mon environnement de bureau actuel, alors ton opinion de troll, tu peux te la garder…

Je me calme, je vais boire ma tisane "nuit calme" :)

J'aime KDE4, mais j'admets que c'est quand même pas simple leurs histoires d'activités, là.
Les développeurs se sont bien fait plaisir, on le sent, et quand on a une utilisation avancée d'un bureau, c'est sympa, mais on peut vraiment dire que ça soit orienté grand public. J'aurais vraiment imaginé que ce fût un mode à invoquer lorsqu'on veut aller plus loin avec son bureau et pas un truc de base avec 2 ou 3 activités par défaut, le truc qui perd tout le monde au départ.

Après en avoir discuté avec quelques amis décideurs pressés, il semblerait que la principale raison qui maintient l'utilisation de linux sur les bureaux dans une portion outrageusement négligeable, c'est que ce système ne possède pas de système de fichier case insensitive, il paraît que cela trouble énormément d'utilisateurs qui aimerait tomber sur le même fichier, qu'ils tapent "trolldi" ou bien "troLLdi" dans leur cellule de recherche.

Euh… Et après on me sort que les extensions de fichier et la sensibilité à la casse c'est simple et compréhensible pour les utilisateurs, la on est encore une niveau en dessous…

ça n'a juste rien à voir et c'est absurde de vouloir mettre l'un au dessus de l'autre.
On parle d'un côté d'un périphérique d'entrée (bouton droit) dont la plupart des applications s'arrangent pour permettre d'en contourner l'utilisation (si un utilisateur ne se sent pas obligé d'utiliser quelque chose, il ne l'utilise généralement pas), et de l'autre de l'information qui a été volontairement occulté pour ne pas « troubler » l'utilisateur. Personnellement, autant je peux comprendre qu'on cache les fichiers systèmes dans l'explorateur de fichiers windows, autant je trouve complètement naze de cacher les extensions et je ne comprends pas ce qu'il y a de troublant là dedans, de toute façon quand on reçoit un .jpg ou un .doc par mail, on les voit bien les extensions… c'était une fausse bonne idée.

Vous avez quand même conscience que c'est une discussion sans fin dans la mesure ou vous vous embarquez dans des allégories qui n'ont plus rien à voir avec les systèmes de fichiers informatisés ?
Il me semble que c'est vraiment le genre de sujet où le contexte est primordial et ne peut pas être transposé sans perdre l'essence de la problématique.

Je sais bien que les conversations ne sont pas très simples à suivre quand on attend les centaines de commentaires, mais je n'ai jamais affirmé que les FS non sensibles à casse (ou plutôt interdisant deux fichiers de même nom mais de casse différentes) étaient supérieures aux FS sensibles à la casse, juste que je n'avais jamais lu d'études affirmant la supériorité de l'un sur l'autre, car ça me semble plutôt complexe.

"faire toi-même le support" peut aussi passer par l'appel à un prestataire spécialisé en logiciels libres comme une SSLL. Tu payes aussi, mais pas à celui qui maintient le logiciel.
Maintenant, je ne sais pas à quel point il est simple/coûteux d'aller frapper à une porte de SSLL en leur disant "j'ai un problème avec tel logiciel, vous pouvez m'aider avec telle et telle garantie ?"

Ton commentaire a achevé de me convaincre, j'étais plutôt sceptique au départ (dans le sens, pas convaincu plus par l'un ou l'autre système pour l'utilisateur de base), mais après avoir lu certains commentaires plus haut et le tien, je pense que peu de chose justifie vraiment qu'un système de fichier ignore la casse.
Si on passait notre temps en tant qu'utilisateur à sauvegarder des fichiers avec le même nom mais une casse différente, ça serait effectivement emmerdant (se retrouver avec deux fichiers toto et Toto), mais ce genre de cas se présente tellement rarement que j'ai effectivement du mal à admettre que la gestion case insensitive puisse être techniquement justifiable (et à bien y réfléchir, le logiciel de sauvegarde pourrait même agir de façon singulière dans ce genre de cas).
En fait, j'ai même plus généralement du mal à imaginer des cas où avoir "Toto" et "toto" dans le même répertoire serait problématique pour l'utilisateur, ergonomiquement parlant.
Au niveau linguistique et sémantique, je n'ai jamais été convaincu par les langages non sensibles à la casse comme Pascal ou Basic, car ça limite le champs des possibilités (nommer une classe "Classe" et une variable d'instance "classe" par exemple) tout en permettant de voir des horreurs (BEGIN et Begin ou begin dans le même code), et je me demande si du coup les mêmes limites ne s'appliquent pas au nommage de fichiers (impossibilité d'utiliser une nomenclature particulière pour les répertoires et les fichiers).
Maintenant, il est certain que le monde des applications Windows a pris de telles habitudes (il suffit juste d'imaginer une procédure d'un installeur de programme qui écrase une dll par une nouvelle sans faire gaffe à la casse dans un contexte case-sensitive pour imaginer les dégâts…) qu'il me semble impossible de revenir en arrière.

Merci pour cette brillante démonstration pour prouver que le fait de pouvoir nommer deux fichiers du même nom mais avec une casse différente n'est absolument pas un problème pour l'utilisateur de base, beaucoup d'ergonomes pourront maintenant s'appuyer sur tes travaux.

Allez, je caricature, mais pourquoi est-ce que les réflexions d'une église n'auraient pas le droit d'éclairer un débat ?

Considères-tu que les réflexions de l'église de la licorne rose invisible (loué soit son nom, ainsi que le poulet d'appellation d'origine contrôlée) aurait le droit d'éclairer un débat ?

Autrement dit, le choix d'un OS doit etre un opt-in (ie je veux specifiquement qu'on me rajoute ca) plutot qu'un opt-out (ie je veux specifiquement qu'on m'enleve ca). Si quelqu'un veut l'acheter avec un OS, il peut tres bien demander a son magasin qu'il lui installe. Bon sang, ca creerait meme des emplois locaux !

Ça pourrait même être encore plus simple en matière de gestion de sortie d'usine ; l'OS est pré-installé, mais la clef d'activation n'est donnée à l'utilisateur que si celui-ci à coché la case "Avec OS". Dans le cas contraire, le client se débrouille pour installer ce qu'il veut.

Il limite les possibilités techniques, mais il augmente l'ergonomie.
Enfin, c'est comme ça qu'il doit être justifié par les gens de chez Microsoft.

Oui mais les icônes sont différentes :)

J'ai pas l'impression qu'on résoudra quoique ce soit aujourd'hui : il y a des partisans des deux solutions (prise en compte ou pas de la casse), c'est une question éminemment complexe et qui fait appel à des études ergonomiques et même si chacun a son avis sur la question, je n'ai encore vu personne prouver par A+B que l'une des deux solutions est la plus pertinente.

Sans vouloir chercher la petite bête, c'est pas qu'une question de recherche : sous linux, dans ton dolphin/nautilus tu peux avoir "classeur" et "Classeur", sous windows, c'est impossible.

J'aime comme tu mets tout le monde dans le même panier du côté du libre, des gens qui s'expriment sur un forum public, des gens qui conçoivent des interfaces, etc etc
Comme si y'avait UNE grosse entité des linuxiens-qui-refusent-le-progrès-ergonomique-et-fonctionnel.
C'est surprenant de manquer à ce point de nuance.

C'est marrant, j'ai souvent tendance a me méfier…

[captain obvious]
Intuitivement, il semble simplement que l'apparition d'une technologie nouvelle telle que pouvait l'être le noyau linux dans les années 90 -a fortiori à une époque où les systèmes d'exploitation répandus étaient encore peu fiables, ou bien à défricher- provoque un engouement particulier et "embarque" avec elle une bonne partie de passionnés qui ensuite vieillissent avec la technologie.
Par la suite, je dirais en "vitesse de croisière", les jeunes passionnés deviennent moins jeunes, ce qui n'empêche pas qu'un peu de sang neuf entre de temps en temps dans la communauté, mais on a effectivement l'impression que l'"âge d'or" est plus ou moins achevé. (ce qui est probablement une impression de vieux con incapable de voir au delà d'un voile nostalgique :))
Ca a fait pareil avec le demomaking, le côté bricolage et découverte des premières années avait quelque chose de magique, et puis l'informatique était nouveau pour le grand public, on avait l'impression de faire partie d'une poignée d'initiés, des gens s'amusaient à taper du basic sur les CPC dans les rayons des grandes surfaces ou bien à regarder les démos qui tournaient sur des amigas (ou bien les autres machines dont le nom terminait par ST, mince, impossible de me souvenir :)).
Et je ne veux pas dire de conneries, mais j'ai lu un jour que ce fût à peu près la même chose à la découverte de l'automobile, beaucoup de bidouilleurs, de bricoleurs au début (par rapport à la proportion d'utilisateurs, s'entend).
[/captain obvious]

En ce qui concerne la pérennité de Linux, c'est une bonne question mais qui à mon sens fait appel à d'autres réflexions en englobant la question du devenir du matériel et de ses limitations, des usages, etc

Oui, vraiment bien trouvé cette histoire de eingousef.
Comme quoi, il suffit parfois d'un seul mot pour sublimer une histoire drôle.

Que vous le vouliez ou non, cela aura des effets néfastes.

En tout cas, du point de vue des utilisateurs eux-même, et d'après ce que j'ai pu lire à droite à gauche sur les forums, la réception du geste de Linus Torvalds a plutôt été "bonne". C'est pas une personne à qui il adresse un "fuck you" mais une multinationale. C'est un peu comme David contre Goliath, et à ce jeu là, c'est rarement Goliath qui est populaire.

Y'a que moi qui trouve que ce fuck est une très bonne nouvelle sur la façon dont Linus Torvalds mène sa barque ? Ce mec là n'est pas un chef d'entreprise, il a une parole complètement libre, et s'il veut dire publiquement à nvidia que ce sont des enfoirés (et en argumentant), il le dit. Franchement, quoi de plus sain ? Vous voudriez qu'il fasse des courbettes et utilise un langage châtié ? fuck it!

Faut pas déconner, Linus Torvalds, c'est quand même pas Lennart Poettering !

Les "reviewers" sont-ils des personnes dédiées ou ça fait partie des dev ? En gros les devs font la revue des autres dev ?

Chez nous ça ne reste qu'entre codeurs et la règle, c'est de fonctionner par trinôme. Les trinômes se forment pour une période plus ou moins longue ou de façon très temporaire pour une intervention "extra-ordinaire" dans un module spécifique que le développeur ne maîtrise pas forcément.
Chez nous également, un commit = une review, mais c'est parce qu'on fonctionne avec subversion, avec Git ou Mercurial, le plus naturel serait probablement "un push = une review".

Et au final, après un moment, ça donne quoi ? Est-ce que vous reviendriez en arrière ?

J'espère ne pas me tromper en affirmant que la majorité des équipes sont convaincues comme moi par l'utilité du review board (et je ne suis pas chef) car en plus d'être un outil qui va accroître la qualité et diminuer l'entropie des connaissances au sein de l'équipe, il permet d'initier des débats techniques intéressants.
En tout cas, il n'est plus remis en question par qui que ce soit, ça a vraiment bien pris.
En revanche je suis convaincu que c'est le genre d'outil qui, pour ne pas être perçu comme pénible doit vraiment être instantané à utiliser, ça ne doit pas casser le rythme et proposer une interface simple et directe. Une commande à taper et/ou un clic, point barre.
C'est pareil du point de vue du reviewer : on reçoit les demandes de review par mail, en un clic on arrive sur le diff de code, et on peut immédiatement commenter les portions de code et hop, on envoie la review.

Et pour finir, le temps "perdu" en code review, est-il vraiment regagné en réduction / suppression de problèmes, bugs, etc ?

Ouch, faudrait une petite étude pour savoir ça, mesurer la progression qualitative d'un gros projet, c'est déjà pas trivial…
Pour être honnête, les codeurs qui composent le trinôme ont déjà leur propre travail à effectuer et ne passeront pas la journée sur une review, et AMHA les bugs les plus perfides passeront vraisemblablement à travers les mailles du filet, mais ça peut déjà servir à repérer les trucs bien dégueulasses, et à se resynchroniser sur la syntaxe, l'indentation, etc.