CrEv a écrit 4577 commentaires

Pareil, pourtant j'ai voulu testé, je me suis dit que j'allais enfin m'amuser un peu :)
Mais non. Pffff !

Merci pour ce retour, finalement ça va bien dans le sens de ce que je pense.
Y compris sur la partie productive passé 17h. C'est d'ailleurs parfois assez frustrant, de passer la journée (quand tu dois faire tes heures et non avoir un résultat) à ne "rien" faire, pour finalement être productif et efficace juste avant de partir. Là on se dit que quelque chose cloche mine de rien…

Concernant l'illusion d'avoir 8 heures productives en moyenne par jour, et la nécessité d'être comptable de 8 heures par jour, j'ai l'impression que les deux notes que tu cites enfoncent un peu des portes ouvertes. Il y bien que l'encadrement à la feuille excel et les couches hautes du management qui ne sont pas conscients de ça.

Et pourtant… En fait j'aimerais bien pouvoir être de ton avis.
Mais la réalité dans beaucoup d'entreprise est toute autre.
Beaucoup d'entreprises donnent des contrats cadre aux ingénieurs et développeurs (c'est mieux pour le calcul des heures sup) mais obligent une présence physique minimum de 39h. Du coup, le côté gestion du temps et variation est pour le moins inexistant. Enfin si, tu as toujours le droit de faire plus d'heures que prévus.

Et je ne parle pas des hautes couches du management, je parle aussi d'entreprises où il y a uniquement 3 niveaux de hiérarchie, donc assez peu de management au final.
Mais pour beaucoup de monde encore, le développeur ou l'ingénieur plus globalement, doit forcément faire toutes ces heures d'un bloc. Et que contraindre à rester au boulot résous les problèmes (alors que j'aurais un peu l'impression que c'est l'inverse). Ha oui, et aussi que toutes les minutes (ou presque) peuvent et doivent être réellement productives.
"Quoi, surfer sur le net, faire de la veille ? Nan mais bosse un peu à la place" est malheureusement très courant.
En fait, souvent, cela vient de personnes qui ne connaissent pas le travail effectué, qui n'ont malheureusement pas vraiment idée de comment ça fonctionne.
Et pourtant, l'organisation du temps de travail reste dans les prérogatives d'un cadre (au moins un minimum). Au final, on a une dualité assez particulière, néfaste (c'est au final moins productif et mauvais à moyen/long terme, y compris en terme de ressenti et d'image) et pourtant très courante.

Pour pas mal de raisons je ne peux pas refaire le test sur cette version exactement (en tout cas pas comme ça, et j'ai pas le temps de le faire).

C'est mieux, mais comme tu dis, il y a un facteur 46 en taille avec le test précédent, et pourtant le temps de chargement n'est pas diminué du tout du même ordre de grandeur. De plus, comme tu précises, tu es en local, donc tu dois avoir de bons débits. J'en conclue donc que de toutes façons, la taille n'a rien changé, c'est juste de concaténer qui a aidé.

Explication du temps : c'est l'intégration de mon script dans une page existante, il y a donc des composants que je ne maitrise pas. Par contre, on a quand même un gain de 1.7s. Et ça c'est très loin d'être négligeable.
J'ai lu par exemple que amazon gagne environ 1% de revenu en réduisant le temps de chargement de 100ms. Gagner plus d'une seconde peut donc nécessiter des efforts important.

Par contre, le gain de 10 en taille est d'autant plus significatif lorsqu'on est pas en locale, donc la concaténation peut ne pas suffire.

moi, j'aurais bien aimé voir le résultat du temps de chargement avec la version « simplement concaténée et gzipée »

Comme je l'ai dit, j'ai pas les chiffres pour l'application dont je parle au dessus.
Par contre, j'en ai d'autres, que j'avais justement utilisé comme bench :

• Version plain (concaténée mais pas minifiée) :
  • 1200ko, 1,28s
• Version plain gzip :
  • 440ko, 1,27s (en local le fait de gzipé ou non ne change pas beaucoup dans ce cas)
• Compilée :
  • 600ko, 0.767s (presque /2 par rapport à plain)
• Compilée gzip :
  • 225ko, 0.54s

Donc on voit bien les deux axes d'amélioration : gzip (même si en local ce n'est pas le primordial) et compilation

Bon, par contre j'ai pas, dans ce cas, la comparaison par rapport à une version non concaténée.

J'espère que ça répond un peu plus à tes questions.
Il est vraiment intéressant d'appréhender un peu les gains qu'on peut avoir, surtout que beaucoup beaucoup de sites pourraient être améliorés et donc les performances et le ressenti pourrait être bien augmenté.

ça veut dire que la condition "mon code doit être lisible" est moins importante pour lui que la condition "mon site doit être rapide". On ne peut pas dire que ça part d'une bonne intention.

Au contraire !

Quel est l'intention d'un dev web ? Nan mais pour de vrai, quel est le but de ce qu'il code ? Simplement écrire un programme / site / cketuveu qui réponde au besoin de l'internaute. C'est ça l'intention. Nono qui écrit le js de la toolbar de linuxfr sont but est d'offrir des fonctionnalités à l'utilisateur. L'intention elle est là.
Et que ce soit rapide fait partie des fonctionnalités, que ce soit rapide fait partie des souhaits des utilisateurs (il n'y a qu'à ce souvenir des premières versions avec le moteur templeet).
Donc faire un code fonctionnel mais également rapide part réellement d'une bonne intention et est plus important que d'avoir un code commenté visible dans un navigateur.

Sur le côté "mon code doit être lisible". Qui doit lire le code ? Attends, je recommence : qui doit lire le code ?
Le moteur js du navigateur. C'est lui le client du code. Un code minifié ou pas, on s'en fiche là tout de suite, celui qui doit avoir un code compréhensible c'est le moteur js et un code minifié y répond.

Ensuite, la question "mon code doit être lisible par l'internaute". Si on reprend l'exemple de la toolbar linuxfr, le code est lisible, il suffit d'aller chercher les sources sur github et tu l'as le code.
Et si on te fourni la sourcemap de correspondance entre le code minifié et le code source tu dois même pouvoir débuger et lire le code minifié.

D'ailleurs, je réagis en général complètement à l'inverse de vous. Lorsque je vois un code js sur un site qui est encore bien formatté, commenté (souvent de manière très ridicule et donnant énormément d'informations sur le fonctionnement interne du serveur) je me marre et me dit que le gars qui a pondu ça n'a vraiment rien compris au dev web.

Sources ?

Et les tiennes justement elles sont où ?

Minifier le JS, ça sert juste à raccourcir un peu le temps de chargement. Mais en fait, ça ne change quasiment rien si on le gzip, ou si on gère bien son cache

Ha ben j'aimerais bien voir ça…

vu que tout le monde utilise les même libs

Sauf que c'est pas la réalité des choses ça. Et même si c'était le cas, certains ont inventés les CDN…

Je dirais que l'argument de la performance est fallacieux car même si ça joue un tout petit peu, le bénéfice de l'obfuscation dans le sens de rendre la compréhension du code difficile est très apprécié par beaucoup de ses partisans.

Sauf que d'ailleurs (en général) personne ne parle d'obfuscation en javascript. Mais on parle bien de minification, de compression. Mais bon, c'est tellement facile de voir le mal et de dire que c'est rien que des méchants.

Si je vais une application / site web libre, tu peux être assuré d'une chose c'est que la version destinée à être exécutée et publiée sera minifiée, compilée et gzippée. Sauf que ça ne changera rien du tout au caractère libre de la chose. Et en aucun cas le but sera de masquer le code à l'utilisateur.

Allez, prenons un exemple réel, le dernier site (grand public, je parle pas d'un petit site à la con - c'est la partie localisation d'agences d'un site, je ne parle pas du site en entier) que j'ai monté pour un client :

• 91 fichiers javascript (en prenant en compte les fichiers provenant de la bibliothèque utilisée)
  • si je laisse comme ça c'est quand même 91 requêtes http avant d'avoir mon code chargé
  • version commentée, propre, justement pas minifiée : 1531 ko
  • onload : 2.86s (et encore je suis en local, j'ose même pas imaginer la catastrophe en prenant en compte la latence du réseau)
• une version simplement concaténée et gzipée tombe à 326 ko (c'est quand même beaucoup beaucoup mieux, mais c'est encore beaucoup beaucoup trop)
• version concaténée en enlevant tous les commentaires, lignes vides, mais en gardant une mise en forme (sauts de ligne, etc)
  • 722 ko
  • version gzip : 134 ko (tiens on est déjà à un facteur 10 !)
• la même sans la mise en forme :
  • 641ko
  • version gzip : 127 ko (ok là on ne gagne pas grand chose)
• version minifiée (renomage des variables par exemple) :
  • 351 ko
  • version gzip : 85 ko (facteur 1.6 par rapport à la version où on enlève les commentaires quand même…)
• version compilée (clairement illisible mais avec suppression du code mort, inlining des fonctions, réellement axé performances) :
  • 92 ko (à peine plus que la précédente gzip)
  • version gzip : 33 ko : facteur 46 par rapport à la première mesure, facteur 4 par rapport à la version lisible non commentée mais gzip et quasiment un facteur 10 avec la version initiale commentée et gzipée.
  • onload : 1.17s

Et donc maintenant tu veux me faire croire que ça joue un tout petit peu ? Ca charge 2x plus vite. Ca utilise 4x moins de bande passante (loin d'être négligeable sur un serveur d'une appli grand publique donc avec beaucoup de trafic). Mais non, ça ne change rien et l'obfuscation et là pour emmerder ceux qui voudraient lire le contenu du js.

Mouai, ben maintenant ça serait pas mal que tu sortes tes sources pour dire que ça sert à rien car clairement j'y crois pas.

Ha ok, bien vu, j'avais pas pensé à la localisation. Enfin ça doit être plus que ça car si je passe en version .com / anglais j'ai pas plus de pub…

PS

Merci :)

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 ?

Je viens de regarder un peu plus reviewboard (ça faisait 6 mois que j'en avais un dans un coin…) et en fait c'est plutôt sympa.
Je ne sais pas trop comment ça marche avec git donc je ne vais parler que de ce que ça donne avec mercurial.
Déjà, il faut prendre cette extension : https://bitbucket.org/haard/mercurial-reviewboard/overview Il y en a peut-être d'autres mais avec https://bitbucket.org/mdelagra/mercurial-reviewboard/overview j'ai eu des problèmes, et je n'ai pas essayé l'extension initiale http://code.google.com/p/mercurial-reviewboard mais ça vaudrait le coût de voir les différences.

Bon, quoi qu'il en soit cette extension fonctionne sans problème en ligne de commande (hg postreview tip par exemple) et ça fonctionne aussi dans tortoisehg (avec une interface correcte) donc c'est bien.

Là où ça m'intéresse beaucoup plus c'est qu'il est possible d'envoyer une review sur toute une branche. Et ça c'est bien.
Avec un fonctionnement du genre, je peux imaginer un workflow qui serait :

• création d'une feature branch
• code / commit / push
• code / commit / push
• code / commit / push
• fonctionnalité / story / … finie
• demande de review sur la branche
• review
• fix / commit (/ push ?)
• mise à jour de la review avec soit les commits non pushés, soit en resélectionnant les bons
• OK
• merge avec le tronc principal
• close de la feature branch

Bon c'est approximatif, fait rapidos, mais je pense que ça respecte en gros l'esprit de ce que je souhaiterais.

Dans un contexte d'entreprise, quand le chef dit, on râle un peu et on fait ;)

Oué, ça c'est avec des gens civilisés ;-)

On a un peu rechigné au départ, c'est normal

Et au final, après un moment, ça donne quoi ? Est-ce que vous reviendriez en arrière ? Est-ce que c'est vu comme un mal obligatoire, comme une perte de temps, ou comme un vrai mieux et une amélioration de la qualité ?
Et pour finir, le temps "perdu" en code review, est-il vraiment regagné en réduction / suppression de problèmes, bugs, etc ?

Et ça change quoi ? C'est un choix si leurs serveurs ne sont pas connectés aux autres. Tout comme je peux mettre un serveur jabber chez moi et ne faire que seuls les utilisateurs qui s'y trouvent puissent discuter.
Ok, dans ce cas ça n'aurait aucun intérêt…

D'ailleurs, pour les utilisateurs Google il y a quand même http://www.dataliberation.org/
Et c'est loin d'être négligeable, surtout que peu (aucune ?) grosse entreprise ne fait de même.

Même sans adblock

Ca c'est avec adblock : http://pix.toile-libre.org/?img=1338990467.jpg
Ca c'est sans adblock : http://pix.toile-libre.org/?img=1338990662.jpg

Tu la vois la différence ?
Ha oui, elle est ici la différence en fait : http://pix.toile-libre.org/?img=1338990730.jpg

Pour ma part j'en pense que c'est une idée intéressante mais :

• Pour le moment j'ai pas un vrai bon rythme et je pense que c'est par contre intéressant / important. J'ai réussi à tenir le rythme pendant un temps, env 1.5 ans (enfin pas en publiant ici) mais je suis pas sur de pouvoir/vouloir le tenir
• J'envisagerais plutôt avec une certaine ligne "éditoriale" et c'est pas encore ça.
• Il faudrait un peu plus de détail pour passer en dépêche je pense, comme tu dis pour que ce ne soit pas qu'une usine à liens

Bon, maintenant voilà c'est que mon avis.
Je crois que pour certains liens les petites brèves qui fleurissent sont pas mal, à condition de détailler un poil. Certains (nono ?) c'étaient essayés aux dépêches de liens de dev, mais je crois que ça avait pas forcément fait mouche, bien que je pense que c'était intéressant.
Ca y est, j'ai retrouvé : https://linuxfr.org/news/veille-technologique-sur-le-web et https://linuxfr.org/news/les-technos-web-cools-du-moment par exemple

OK, merci du retour.

J'ai aussi installé un ReviewBoard, mais je l'ai pas encore vraiment mis en place, entre autre car j'ai pas trouvé ça hyper simple.
L'un des problèmes pour le coup est que le code sur lequel je bosse est vraiment très modulaire (> 40 projets, tous dans un hg différent donc pas de racine commune) et de ce que j'avais vu il fallait créer tous les projets à la main dessus. Et c'est quand même un peu long.

Après, une question conne sur le principe : vous faites la review avant de commiter ? Donc pas moyen d'avoir un ensemble de commit ? Ou alors le commit à reviewer est un commit de merge entre une feature branch et la principale ?

Bon sinon, ça me semble intéressant.

Perso j'adore et c'est venu s'insérer assez naturellement dans notre processus de développement.

Aucun problème pour convaincre les devs ? Pas de réticences (à l'outil ou même au principe de review et de propriété de code ?)

Et question bonus (enfin probablement avant les suivantes) : est-il possible avec ce type d'outil de faire de la review d'un code existant (déjà commité) pour analyser et commenter un code réalisé avant de mettre en place des reviews ?

Ha oué, sympa aussi.
J'ai aussi celui-ci qui m'avait bien plus comme lien : http://www.pariszigzag.fr/visite-insolite-paris/dans-les-coulisses-du-metro-parisien (et http://www.pariszigzag.fr/visite-insolite-paris/les-stations-fantomes-du-metro par extension)

Notre capitale regorge de curiosités. Il ne se passe quasiment pas une semaine sans que j'en découvre une nouvelle.

Ben déjà que j'arrive pas à avoir le temps de visiter et découvrir la ville dans laquelle je suis (Lyon) alors qu'il y a pas mal de choses, je suis loin de découvrir réellement Paris :-)

Tu veux dire Red Hat et Fedora ?

Et non. Comme précisé plus bas je ne voulais pas dire RedHat et Fedora mais "les distrib qui ont réussi à intégrer des trucs comme pulseaudio sans vrai problème".

C'est quand même marrant, c'est exactement l'opposé de PulseAudio. Pire que ça, en général ceux qui se plaignent disent que les fonctionnalités apportées ne servent à rien.

Non ce n'est pas l'opposé de Pulse Audio. Pour les applis (ie pour les autres programmes qui tournent) Pulse Audio est supposé simplifier la connexion audio. Après qu'il fasse autre chose en aval c'est son problème.

Heu, là tu te gaufre. Qu'il fasse quelque chose d'autre en aval c'est justement l'intérêt de PulseAudio. Et c'est bien exactement l'opposé de ce que tu disais.
Je rappel que ce que tu as dis c'est : ce qui limite l'utilisateur et l'empêche de faire des choses exotiques On parle donc bien de l'utilisateur, pas simplement des autres programmes qui tournent. Alors après que les ajouts et améliorations ne t'intéressent pas spécialement en fait on s'en fiche un peu, le fait est que ça intéresse suffisamment de monde et que ça règle suffisamment de problèmes pour que toutes les distrib ou presque utilisent PA.

Si greplog te balance ce qu'il convient dans la sortie standard il est où le problème ?

greplog ne peut pas balancer ce qui me convient, parcequ'il n'est pas sentient

Sentient ?
Nan mais tu fais quand même exprès.

Des fois ce qui me convient c'est […] des fois c'est […]

Ok, mais dans ce cas il n'y a rien qui conviennent vraiment. Et avoir un outil unique pour faire tous ces cas différent c'est justement l'inverse d'un outil pour une action donnée le tout chainable.

Oh, et je sais même comment ils vont y répondre

Rien que ça. Tu as regardé pour de vrai ou tu es juste intimement persuadé que c'est le cas. Et si c'est la deuxième solution j'espère que tu es allé leur dire, non ?

C'est pas 'notre' vision d'Unix. C'est la philosophie Unix. Ca fait 40 ans qu'on la pratique elle commence à être plutôt normée et objective comme vision

Et ben faut croire que c'est pas si clair que ça.
Si on prend par exemple le fait que le créateur de rsyslog bosse sur lumberjack, y'a quand même de quoi se poser des questions, non ?

Je veux pouvoir utiliser […] comme je l'ai toujours fait mais surtout comme j'ai besoin de le faire.

Ok, c'est donc bien exactement ce que je dis. Mais dans ce cas, si tout est déjà bien, pourquoi tu veux changer ? Ne met pas à jour, passe les correctifs de sécurité, choisi une distrib en accord avec ta philosophie.

Et de plus greper un log ce n'est pas une perversion de grep, il est même fait pour ça

Non non, comme tu dis, il n'est pas fait pour greper un log il est fait pour greper un contenu texte.
Et donc si tu as un catlog qui te sort juste les messages de log alors ton grep fonctionnera toujours.
Et si tu fais un greplog qui t'extrait des choses en fonction de données inexistantes dans tes logs, tu pourra toujours rajouter un grep derrière.
Le truc dans l'histoire c'est que tu oublie totalement la structuration des données du log. Et ça, désolé, mais c'est une vrai fonctionnalité manquante. Le fait que chaque application ait sa propre structure de log est également un vrai problème qu'ils tente de résoudre.
Mais non, c'est pas des vrai problèmes, c'est vrai. Et c'est pas unix. Au fait, tu confondrais pas unix avec bordel bas niveau ?

C'est le problème des Lennarteries, elles partent sur tout un tas d'hypothèses de config et de configuration

Mais alors comment ont fait les distrib qui ont réussi à intégrer des trucs comme pulseaudio sans vrai problème ?

Bien sur que ca apporte quelque chose, du point de vue d'un mainteneur de distrib tout ce qui limite l'utilisateur et l'empêche de faire des choses exotiques est un plus.

C'est quand même marrant, c'est exactement l'opposé de PulseAudio. Pire que ça, en général ceux qui se plaignent disent que les fonctionnalités apportées ne servent à rien. Tiens, un journal qui montre justement certains intérêts de pulseaudio : https://linuxfr.org/users/yellowiscool/journaux/transferer-du-son-en-reseau-avec-pulseaudio-vlc-et-un-clavier-bepo

Mais je veux pas un outil greplog, un outil taillog, un outil sedlog, un outil perllog etc. Je veux une sortie standard qui je peux chainer aux outils que j'ai déjà et que je connais déjà.

Mais en quoi c'est opposable ? Si greplog te balance ce qu'il convient dans la sortie standard il est où le problème ? En fait vous êtes super fort pour ne pas lire ce point. Ce qui est écrit c'est justement qu'il n'y a qu'à écrire un greplog qui utilise les entrées/sorties standard et qu'on peut chainer, comme on le ferait avec grep ou autre.
Et dans ce cas aucun problème pour le chainer avec les outils que tu connais déjà.

de base de données - parceque des fois le système ne démarre pas comme il faut et que j'ai besoin de logguer ce que je peux même si les logiciels de base de données ne démarre pas.

C'est vrai que je pense qu'ils ne vont jamais se poser cette question…

de format de log XML

cool tu les aura en json

Et tu me traitera probablement de puriste immobiliste et passéiste

Ben en l’occurrence j'ai l'impression que beaucoup ferment les yeux devant les problèmes des solutions actuelles parce qu'ils ne comprennent pas / ne maîtrisent pas / n'ont pas envie des solutions apportées.
Ok, les solutions ne sont pas exemptes de problèmes, mais au moins certains cherchent à y remédier. Et malheureusement (ou heureusement) dans le libre c'est ceux qui codent qui décident au final. Alors oui il y a des cas où ça ne me plait pas non plus. Mais là on dirait que sous pretexte que ça ne respecte pas votre vision d'Unix c'est forcément de la merde en barre. Et lorsqu'on dit qu'au contraire il est possible de continuer à respecter la philo unix (par exemple faire un outil dédié, simple et ne faisant qu'une chose comme consulter les logs plutôt que de pervertir un autre) ça plait pas non plus, parce que c'est pas le grep standard. Donc à ce moment il est où le problème réellement ?

Oui, c'est juste que ton mirroir n'était pas à jour…

Ce qui est quand même très moche lorsqu'il choisi un miroir pendant l'installation, non ?

C'est pourtant bien ce que tu avais quoté :

Hop, tu as ton outil simple qui ne fait qu'une chose, qui peut se chainer comme tu le ferais avec grep

Ben non, c'est très bête. Avant on avait un outil, grep, qui était applicable partout.

Mais d'ailleurs, c'est pas contraire à KISS ça ?
C'est pas contraire à ce qui est énoncé dans le journal "des outils simples qui font peu de chose mais qui le font bien, qu'on fait interagir pour obtenir ce dont on a besoin avec souplesse"

En quoi faire un greplog est contraire à ça ? On aurait justement un outil simple, qui fait peu de chose mais qui le fait bien, et qu'on fait interagir pour obtenir ce dont on a besoin avec souplesse. Genre greplog --level=error | grep plop. C'est pas Unix ça ?

Ben non, c'est très bête.

Heu… C'est pas comme si c'était déjà largement le cas cette situation. Des "simili" grep il y en a des tas. Un exemple bidon git grep Et pourtant je vois pas trop les gens s'en plaindre pour dire "oué mais non, grep c'est plus mieux et c'était là avant !"

contrairement au grep "universel".

Qui pour le coup a des limitations, dont celle de ne pas pouvoir lire des fichiers formatés avec des informations qui ont un réel sens.

C'est marrant cet amalgame. Ce que je comprends moi, c'est pas que le gars n'aime pas le changement, mais il n'aime pas comment ça change.

Ben en tout cas lorsque je lis ça résonne plutôt comme "Unix say le bien il faut rien changer et ce que certains change c'est pas bien et ça sert à rien"

Non parceque la philosophie générique Mac OS X

Parce qu'il n'y a pas un beau morceau d'unix dans la philosophie Mac OS X justement ?

Pour le reste, pour alsa, pour systemd, pour le truc de log, etc. Y'a quand même un truc. C'est du libre. Donc les gens corrigent améliorent et développent ce qu'ils veulent. Tu veux que alsa reviennent au centre ? Tu veux qu'il soit amélioré ? Ben fait le. Quoi, certains ont voulu améliorer en oubliant l'existant ? C'est parfois la meilleur chose à faire. La mise en oeuvre n'a pas été simple, ok. On me souffle qu'il y a eu également pas mal de problèmes venant de l'intégration dans les distribs mais bon…
Et pour les autres sujets, c'est quand même assez marrant que les distros (et pas juste redhat) suivent quand même. C'est bien que ça apporte quelque chose, non ?
Ha oui, parfois ça s'éloigne du principe de base d'Unix. Mais est-ce réellement un problème ou est-ce juste du saytaimieuxavent ? Quand on voit que derrière lumberjack il y a entre autre le gars derrière rsyslog et qui écrit les specs de syslog, je me demande si c'est juste un gars qui c'est réveillé en se disant "bon, si on cassait du unix" ou s'il s'est dit "si on améliorait tout ça" ?

En fait ce qui est malheureusement sidérant c'est la capacité à l'immobilisme tout ça parce que ça change des choses. Et d'ailleurs, plus que des fichiers, unix c'est aussi des pipes et la gestion des entrées standards, non ? Pour les logs, une critique qui revient c'est par exemple "ouai mais mon grep il va plus fonctionner". Ok, et si un outil greplog est fourni et fait ce qu'il faut ? Hop, tu as ton outil simple qui ne fait qu'une chose, qui peut se chainer comme tu le ferais avec grep. Et donc c'est plus unix quand même ?
Ha oui, pour l'immobilisme : dommage, je croyais pourtant qu'une des forces du libre, de l'open source et de ces méthodes était justement une plus grande capacité à faire table rase du passé lorsque le besoin se fait sentir. Et mon ressenti c'est qu'il y a quand même du monde que ça intéresse systemd, pulesaudio, lumberjack, etc. N'en déplaise aux "puristes"

Au fait :

Quand on doit se frapper du policykit sauce Red Hat sur une RHEL pour obtenir un comportement qui n'est pas prévu à 100% par la maison mère on douille

Où est réellement le problème ?

• policykit ?
• policykit sauce red hat ?
• red hat ?

Oui je sais, je peux virer lightdm, mais là je voulais le laisser le plus près possible de l'installation standard cUbuntu (interface cinamon).

Cool, je viens d'apprendre que cubuntu existait… Donc c'est encore un autre fork d'ubuntu de derrière les fagots, c'est encore pas tout à fait pareil que les autres, faut ptetre pas s'étonner s'il y a des problèmes.
Question conne, ton problème de login il existe avec une ubuntu "standard" ou pas ? Si oui, ok j'ai rien dit. Si non, fallait ptetre pas prendre ça comme distro, non ?

Parce que bon, le truc, c'est que ça respire surtout le fait que tu prends une distrib avec un certain type d'usage et que tu veux en faire autre chose. Non que ce ne soit pas possible (d'ailleurs tu donne même des pistes pour le faire) mais forcément c'est plus complexe.
Par exemple une ubuntu c'est surtout fait pour avoir un compte sudo. Donc que ce soit pas forcément prévu de base pour avoir un compte admin qui en plus n'apparaît pas dans la liste ça ne me choque pas le moins du monde.

Donc si tu veux du "unix-like-saytaimieuavent" pourquoi ne pas s'orienter vers une slackware par exemple ? Je pense que c'est plus proche de l'esprit non ? Ou peut-être même simplement une debian non ? Et si tu es près à quitter linux pourquoi pas un bsd ? Tout dépend ce que tu cherches, du linux ou plus généralement du unix ?
Ha oui, et mac c'est aussi un unix par exemple, mais là tu risques de bondir…

Mon hypothèse c'est que peut-être chez Ubuntu ou chez Redhat, on se jette sur n'importe quelle idée qui rend compliqué un truc qui était simple, parce que ça doit leur permettre de vendre du support plus cher et plus souvent.

Ou alors ils cherchent à faire des choses utilisable par une personne normale, sans ligne de commande, sans compétences spécifiques (je dit pas que ce soit le cas par contre, qu'ils y arrivent) (deuxième parenthèse, ubuntu et redhat c'est pas tout à fait le même publique non plus hein…)

Au fait, dans ton boulot (si tu codes) tu commente ou non ? (oué désolé, j'ai vraiment du mal à comprendre la logique)

Peu.

Question conne : tu bosse dans quel type de boite ? SSII ou plutôt éditeur de logiciel ?
Si dans le premier cas je peux un peu comprendre ce que tu racontes (et encore) comment ferais-tu dans le deuxième, je veux dire avec du code que tu dois maintenir et faire évoluer sur au moins 5 ans ?

Si c'est le code trivial d'un jeu libre, je m'en sortirais :-)

Et si c'est pas le cas ?

Jabber n'a manifestement pas écrasé Live Messenger, même si il est mieux foutu

Heu si, au final, puisque tout le monde utilise XMPP.
Live Messenger c'est du XMPP
Facebook c'est du XMPP
GTalk c'est du XMPP
…

Nan mais y'a quand même une sacré grosse différence entre trop commenter, perdre trop de temps à faire des docs inutiles et ne rien foutre du tout.

Lorsque le projet est livré et passe en maintenance (éventuellement évolutive), on peut s'attaquer à produire de la documentation

Et ben, je plain le boulot de ces gens, commenter le code d'un autre 6 mois après avoir été écrit…

Et surtout ça ne change rien au fait que l'intention du programmeur ne sera pas inscrite.

Je comprends que ce soit difficile à accepter, car on enseigne aux étudiants à bien commenter leurs codes
Les commentaires et la documentation sont une charge de travail non négligeable et il est préférable de se concentrer d'abord sur un code qui marche et faire de la transmission de connaissances de programmeur à programmeur.

La difficulté de compréhension n'a rien à voir avec l'enseignement mais justement du fait d'experience pro. Il arrive (et arrivera) toujours un cas où tu devra reprendre le code d'un autre (absence, problème critique, tout ce que tu veux) et là tu va bien souffrir sans la moindre doc.
C'est vraiment présomptueux de croire que le code n'a pas besoin d'être commenté pour être lisible et souvent on va trouver des arguments (genre ça prend trop de temps) qui sont souvent motivés par "ça m'emmerde de commenter".

Et même si tout ceci était valide, là tu propose quand même aux autres d'utiliser et modifier ton code. On parle pas du voisin dans un open space hein. Et dans ce cas, pour moi c'est simple, s'il n'y a aucune doc aucun commentaire faudrait vraiment, vraiment, vraiment qu'il y ait quelque chose d'intéressant pour que je me fasse chier à comprendre le code que le dev n'a pas jugé utile de commenter.

Newton Adventure suit le même chemin.

Ben c'est quand même un chemin qui aide à restreindre les possibilités de contributions.