barmic a écrit 10455 commentaires

Une relecture fait par soi-même, ce n'est pas une relecture.

1. Tu ne te relis donc jamais ?
2. Au dessus ça parle de relecture faite par des experts, je parle de relecture faite par des développeurs qui ne sont pas forcément plus qualifiés que le prime développeur.

Ensuite, est-ce que vous avez fait des fiches de relecture ? Genre une série de point à vérifier (ex: est-ce que le coding standard est respecté ? Est-ce qu'il peut y avoir des divisions par zéro ?, est-ce que des exceptions peuvent remonter sans être pris en charge ? etc…)

Oui et la grille est enrichie/améliorée au fure et à mesure.

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

Ça n'est pas un choix, c'est juste que personne (ou peu de personnes) ne s'en occupe. Si des KDEistes se motivent pour le faire rien ne les freinera.

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

J'ai pas dis que ça ne l'étais pas.

J'ai l'impression que pour beaucoup dès qu'on parle rolling release on a tous dis. Je pense au contraire que comme il y a une diversité des distributions à release time based ou when it's done, il y a de quoi se différencier dans les rolling release. Par exemple Arch et LMDE n'ont rien avoir.

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

J'aime bien ton générateur de salade :)

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

Ce n'est pas qu'une rolling release, non plus.

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

Là où je bosse on a mis en place une relecture (code, test et doc), mais faite par un autre de l'équipe. Un moins bon qui relis le code d'un bon, doit vraiment chercher à le comprendre et pourra une fois qu'il aura compris le code voir s'il y a des manques (ce n'est pas parfait bien sûr). Ça crée une dynamique ou chacun progresse. C'est un peu comme du pair programing en étant moins coûteux et plus flexible.

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

il y a le fait que ça augmente la taille du code et met donc plus de pressions sur le(s) cache(s) et au final peut ralentir l'exécution d'un programme complexe (ce qui ne se verra pas forcément dans un micro benchmark).

On s'en fout de la taille du code (dans les cas généraux), non ? C'est la longueur du chemin parcouru qui peut augmenter la pression sur le cache, je pense. Le fait d'avoir des optimisation comme la suppression de variables va au contraire diminuer la charge par rapport à une méthode qui recrée tout son contexte.

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

Quand tout ce que tu connais est un ordinateur, les problèmes ressemble à un algorithme…

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

Il n'y a aucune anomalie à ça… Ça s'appelle juste le grand public.

Non, c'est un syndrome qui existe tout autant chez les geeks, les nerds ou autre.

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

Et ne me dites pas qu'avec le papier, on n'a jamais ce problème: copies de secours, vieillissement du papier, on fait également des "migrations". Vu le papier "moderne", j'ai un doute sur le fait qu'il tiendra 50ans dans une salle d'archives.

Si tu choisi correctement ton papier, ton encre (il faut que l'encre s'imprègne dans le papier et ne soit pas simplement déposé dessus) et ce qui enveloppera tes feuilles ça ne devrait pas poser trop de problème non plus.

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

Bon tu troll largement sur la licence, mais pour le reste je suis d'accord.

Moi j'apprécie d'utiliser un markup ou LaTeX, mais je ne conseil pas d'utiliser ça de manière plus généralisée. Même si je répugne à utiliser les traitement de texte, je n'ai pas d'alternative à proposer (Lyx est peut être pas trop mal, mais il n'existe pas pour toutes les plateformes et manque de finition pour être un peu plus sexy).

Le PDF est pas mal, mais je trouve dommage que le djvu ne soit pas normalisé lui aussi. C'est un format qui a vraiment était conçu pour l'archivage et qui me semble plus simple (on ne pointe pas vers des fichiers externes au document).

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

Je ne vois pas bien la différence entre « Au mieux un programme est typé, plus il a de chance d'être correct, en C comme dans les autres langages » et « quand je fais de la merde le compilateur me demande de mettre des casts partout et après, à l’exécution, le programme fait de la merde ».

L'idée c'est que le typage c'est un ensemble de validation que le compilateur fait (c'est particulièrement visible lorsqu'on utilise un langage qui a de l'inférence de type). Dans le système de type le cast est une façon de dire au compilateur « nan mais t'inquiète, je sais ce que je fais ne t'inquiète pas c'est moi qui gère » et ça désactive le système de type pour une action donnée.

Si le typage est assez sophistiqué pour exprimer ce que tu fait, tu peut faire des programme plus sûr car mieux validé par le compilateur. Alors que les typages plus faibles ou plus basiques donnent plus de travail aux développeurs pour s'assurer de ce qu'ils font et/ou ne pas avoir à dupliquer du code.

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

Ça illustre parfaitement ce que je dis, le C++ fait partis des langages où le typage est un outil du développeur (puissant et complexe mais un outil) là où en C il est une contrainte : on cast la mémoire dans le type que l'on veut parce que l'on sait mieux que le compilateur ce qu'il y a dans la mémoire. Quand on parle de cast, on sait qu'on a aucune vérification statique et là pour le coup on peut avoir la pire chose possible : mettre n'importe quoi dans la strcuture et que ça continue à fonctionner (un certain temps).

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

Ça fait un paquet de temps que je n'en ai pas vu, notamment parce qu'utiliser une délégation (même s'il s'agit d'une délégation du pauvre comparé à ce que propose certains langages) est plus flexible. Il y a des cas classiques (le carré par exemple), mais globalement, je ne fait de l'héritage que pour manipuler le système de type, si ça permet de factoriser du code tant mieux, mais ce n'est pas l'objectif, les cas où tu va avoir à de l'héritage en diamant n'est pas existant mais assez rare du coup.

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

Crée un arbre bicolore pour des int et pour des char toute l'intelligence de la structure devras soit être générée via des macro, soit considérée que tout est void*, soit être réécrite.

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

N'importe quelle structure de données par exemple.

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

Et tu va dire que la libc n'existe pas parce que sinon GObject n'existerait pas par exemple ? Tu te rend compte que tu avance des choses fausses en voulant faire un euphémisme et pour l'expliquer tu avance des arguments bidons ? Que la bibliothèque standard du C++ soit light et n'adresse pas suffisament de cas d'utilisation, ça peut se discuter, le fait qu'elle n'existe pas est tout simplement faux.

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

Je pense qu'il y a un gros mélange entre :

• la complexité d'implémentation du langage : l'implémentation du C++ est largement plus complexe que celle du C. Là dessus celui qui dis le contraire ne sait probablement pas de quoi il parle. Les templates par exemple sont une galère pour les compilateurs et ont eu des bugs assez importants pendant longtemps. Une preuve de la complexité est le nombre de parseur de C++ bien moindre que pour le C ;
• la complexité des concepts du langage : les langages plus sophistiqués apportent des concepts plus sophistiqués, ces concepts sont là pour apporté plus de simplicité (comme le ducktyping) ou plus de flexibilité (comme la généricité). Il faut mettre en balance le coté magique que ça peut avoir et l'intérêt que ça apporte. Un exemple simple, le système de type du C est trivial, celui du C++ est plus complexe. N'importe qui peut comprendre le premier, le second permet (entre autre) de faire du polymorphisme ;
• la complexité d'utilisation du langage : les langages de (très) haut niveau sont généralement plus simple à utiliser. Le scripting shell ou le PHP sont très simple à utiliser par rapport au C ou au C++. La dessus je trouve que le C et probablement plus simple que le C++ car ce dernier est un sur-ensemble de l'autre. Mais le C++ apporte des facilités importantes, il permet notamment d'utiliser le système de type comme un outil (les structures de données sont typées par exemple), là où C oblige soit à duppliquer le code soit à utiliser le jocker void*. C'est le genre de cas où si l'implémentation initiale est simple, la complexité vient après sur la maintenance du code (un code constitué de copier/coller est plus compliqué à maintenir que celui qui possède une grande factorisation).

Après je pense que la complexité (quelque soit le type de complexité) n'est pas très important. Implémenter un noyau c'est compliqué (incroyablement) c'est pas pour ça que Linus ne l'a pas fait. Je pense à mon avis que c'est un bon gros geek qui s'intéresse trop au langage (quoi ton batiment est en parpain et pas en brique ?! C'est idiot les parpains moi je préfère reconstruire un batiment en brique plutôt qu'utiliser le tien (en plus c'est que des connards qui utilisent les parpains)). Il n'aime pas l'orienté objet de base et le décrit généralement comme le grand mal, c'est à prendre avec des pincettes lorsque l'on voit de bons logiciels bien fonctionner avec des langages objets. Pour moi une bonne partie de son argumentaire doit être vue comme une querelle de clochet (même s'il peut avoir de bons arguments).

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

J'entends plus souvent parler de forth comme langage d'assemblage (avec la particularité d'utiliser une pile plutôt que des registres).

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

J'ai en premier demandé si Debian était vraiment la réponse à tout car le parent avait dit "un kernel et un userspace à jour" et avait cité Debian Sid.

Tu commence en introduisant un biais (tu extrapole le fait que quelqu'un ai donné Debian Sid comme exemple par « Debain est la réponse à tous »¹).

Ensuite, j'ai donné mon point de vue en temps que développeur upstream sur la tendance nuisible à ce que tous les utilisateurs utilisent une distribution pas à jour et voilà que toi tu arrives à la rescousse de ta distribution et tu me sors ce qui me semble être un total hors sujet sur … tout et n'importe quoi avec Debian.

Le sous-entendu c'est que Debian est un poids pour les développeurs et/ou pour la communauté du libre. J'explique ce que cette distribution apporte. C'est toi qui commence par un biais et qui continue avec un HS.

Je suis désolé si tu t'es senti agressé (ou que j'agressais ta distribution), c'était pas mon intention.

Je ressens surtout un animosité mal placée. Debian l'a déjà montrée en cas de besoin elle possède des solutions pour être plus à jour (les dépôts backport ou updates autrefois appellés volatille) il faut juste que quelqu'un le fasse comme dans toutes les distributions (plus ou moins facilement on est d'accord).

On passe notre temps à expliquer que le libre au sens général est un moteur d'innovation arrêtons alors de cracher sur celui qui fait pas les choses comme nous et demandons-nous plutôt pourquoi il fait ainsi et si on a pas quelque chose à en tirer.

Du coup, je me désabonne du sujet. J'étais déjà à la limite du hors sujet, on est vraiment parti dedans là. Les guerres entre distributions n'ont pas leur place ici.

Non tu l'étais déjà.

Bonne fin de week end.

[1] c'est quand même dommage que quelqu'un ne puisse plus donner comme exemple une distribution sans se faire reprendre à la volé à devoir expliquer pourquoi est-ce qu'il a parlé de celle-ci et pas de l'une des centaines d'autres.

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

C'est quoi ton souci ? Chacun fait bien ce qu'il veut, non ? Si tu préfère utiliser une rolling release ou une time-based released tant mieux personne ne vient te chercher des noises, non ?

Debian est une distribution communautaire qui a 2 versions une stable souvent présentée comme bien pour une utilisation serveur possèdant des logiciels en version un peu vielle et une de développement relativement à jour (note je pense qu'il y a peu de distribution qui ont autant d'utilisateurs de la version de développement, la seule que je vois c'est Fedora pour RHEL).

Le process Debian c'est une grosse industrialisation et une tentative de mettre au carré les développement (par exemple en utilisant des dossiers de configuration plutôt qu'un simple fichier). Il est loin d'être parfait et s'appuie beaucoup sur ce que les autres font ça tombe bien l'inverse aussi. Debian est la seule distribution à supporter certaines architectures ou le noyau Hurd. Debian essaie de s'outiller du meiux qu'elle peut pour être facile à forker (voir par exemple les outils de debian live).

Il y a un certains nombre de points où elle n'est pas à jour ou où elle peche, mais de là à s'en prendre à elle comme ça.

Personnellement, je m'en sert avec plaisir parce que je la connais bien (suffisament pour en faire ce que je veux) et si je veux un logiciel en dernière version, il me suffit de l'installer moi-même (soit dans /opt soit via un paquet fait par checkinstall ou à la main). Je me réjoui de voir des distributions rolling release comme arch ou frugal faire parler d'elles et gagner en popularité, mais je ne vois pas pourquoi ça devrait être une guerre entre elles chacun son besoin chacun sa distrib'.

Pourquoi cherches-tu a dénigrer Debian ? En quoi elle te gêne ?

Pour ce qui est de la stabilité de l'API (le fait de rester avec des versions parfois anciennes de certaines bibliothèques), c'est marrant parce que l'un des reproches que certains font aux distributions linux est justement ce manque de stabilité (API/ABI) et ça pousse à faire des SDK (comme ubuntu voulais en faire un) ou à compiler en statique (comme en go).

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

Je ne connaissais pas du tout, c'est intéressant. Comment il fait pour déterminer si une attaque a réussi ou non ?

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

Rappel : OOM Killer c'est specifique a Linux… Tous les OS ne traitent pas le manque de memoire de la meme maniere.

Ça tombe bien j'ai dis qu'il fallait l'ignorer (windows fait quoi lorsqu'il n'a plus de mémoire ?).

Regarde les PDF d'aujourd'hui, il y en a plein qui font cette taille. Si ton serveur explose en vol a cause d'une alloc de 20Mb parce que t'es temporairement a court de RAM il y a quand meme un sacre probleme.

Et tu voudrais qu'on processus en traite des centaines ? (puisque tu refuse les pools de processus)

et tu perdras toujours des connections vu que c'est un pool, a moins de faire 1 process / connection mais la c'est tellement un desastre niveau architectural qu'il vaut mieux pas imaginer.

Si tu as un malloc() qui plante tu perdra quoi qu'il en soit des connexions quoi qu'il arrive.

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

C'est un pattern pas terrible si tu en arrive là. Soit tu essaie de faire une grosse allocation et c'est terriblement fragile, soit tu fait une allocation relativement petite et ton système n'est plus capable de faire grand chose.

Si ton client veux travailler avec une grande quantité de données il va falloir lui demander de les découper comme c'est fait partout ailleurs. L'utilisation d'un pool de processus permet de donner au noyau plus de visibilité quant à la gestion de la mémoire.

Pour ce qui est du OOM killer il s'activera de toute façon que l'on vérifie ou non le résultat du malloc() donc ça n'est pas vraiment à prendre en compte (à part s'il s'active après que le processus fautif se soit suicidé).

Si on a vraiment besoin de faire de grosses allocations, il faudrait AMHA utiliser des huge pages et ça ne se gère pas de la même manière.

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

En conclusion, vu que c'est mal supporté, mal intégré, et pas fait pour ça

Le mauvais support est plus la faute des lecteurs que de la norme qui décris bien le fonctionnement (dans le cas des 2 premières solutions).
Le fait que ce n'est pas fait pour ça à la base ne veut pas dire grand chose. HTML n'est pas fait pour être dynamique, wikipedia n'est pas fait pour être une source de définition (ce sont les références que l'on trouve dans wikipedia qui devraient l'être), etc

Il faut lutter par contre contre la troisième solution qui d'un point de vu éthique n'est pas normalisée, ni documentée et produit une incompatibilité importante et qui d'un point de vu technique est monstrueuse (intégrer une VM complète dans un langage de description de document).

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)