freem a écrit 4934 commentaires

Ça reste très en dessous des exigences du web actuel. Le système swape beaucoup.

Pas faux, mais pour éviter pas mal de sites bien merdiques, perso je trouve que désactiver JS et ne l'autoriser que via une liste blanche (que tu te fais au fil du temps) aide vachement. Idem, les images animées, dehors, et je ne parle bien sûr pas des cookies.
Le browser est l'un des logiciels que j'adorerai remplacer dans mon système, malheureusement je n'ai trouvé aucune alternative correcte à opera 12 ou iceweasel dans les browser dits légers (enfin, ok, ils bouffent moins de ram, mais tous ceux que j'ai testé avaient des performances déplorables ou ne supportaient pas JS du tout, ce qui est bloquant pour 1/3 des sites que je visite)…

Pour ce qui est des 3-4Go, je ne suis pas d'accord. Sur la machine depuis laquelle j'écrit, je suis à 1.9Go total d'utilisation, et il y à, à vue de nez, presque la moitié pour du cache.

il y a deux disques en Raid et je désactive quelques petits services KDE qui ne me servent jamais

RAID1 (c'est bien le RAID miroir le 1?) j'imagine, sinon c'est de la triche ;)
Mais en désactivant les services KDE qui ne servent à rien, ce n'est déjà plus une install KDE par défaut, sans compter que…

'est du Debian installé avec le paquet KDE minimal, puis je rajoute ce qui me sert.

… mais ça me paraît cependant tout à fait pertinent hein. Pour moi, tu as un KDE customisé la. La plupart des utilisateurs auraient installé le gros méta-paquet, et rien désactivé. Pas sûr que ça passe encore sur une vieille machine.

Tout de même pas inutiles pour les débutants ou ceux qui ont une machine récente.

Certes.

La partition système est limitée à 9 Go, donc j'évite souvent les paquets recommandés.

Sage décision. Mais ce n'est pas, encore une fois, le comportement par défaut de Debian.

Ma copine est sur une config (à peine plus puissante) avec XFCE et Gnome 2 / Mate.

Je le crois sans problème. Si elle n'à rien enlevé de ce qui ne lui sert pas… perso XFCE même quand je m'en servais, je n'installais les paquets que 1 par 1, sinon je me retrouvais avec des trucs calendriers (pas trop gênant, j'admets) ou gestionnaires réseau/cups/sane dépendants de dbus (déjà plus, franchement…).

Ma façon d'installer une Debian c'est install mini avec tout décoché (sauf les utilitaires systèmes et serveur ssh, en fonction de mon humeur), désactivation des install recommended par défaut, et ensuite j'installe les softs dont j'ai besoin, avec potentiellement certaines de leurs recommandations.
Avec ça, le système est léger et réactif, et certes c'est une Debian, mais je n'irai pas dire que c'est ce qu'il y a par défaut.

Les logiciels ont une tendance à l'embonpoint, c'est un fait. Et les DEs sont des collections de logiciels, alors on accroît encore cette tendance. Je ne suis pas contre les DEs, parce que s'il n'y en avait pas, je serais sûrement toujours sous windows, avec un niveau en info qui aurait nettement moins évolué. Mais bon, je fait partie des gens passionnés par l'info, ça aide. Pendant ce temps, mes potes ont appris à dépanner leurs voitures ou à faire de la musique ;)

Je suis assez inculte, mais d'après ce que je peux lire sur wikipedia, ce gars sait qu'il fait de la merde, peut-être contrairement au gars passé avant toi ;)

Le droit moral s'applique uniquement à l'art, non? Et je ne crois pas que le code soit considéré comme artistique (en même temps, vu la gueule moyenne des sources, je peux le comprendre).

Ce qu'il se passe, c'est que les gestionnaire réseau (network-manager et consort) n'utilisent pas ifup/ifdown, et /etc/network/interfaces est le fichier de config de ces commandes.
Les autres passent par un combo dbus+systemd+whatever, les fichiers de conf doivent probablement être stockés à la mode ~goret~ espace de nommage à rallonge dans ton ~/.config/.

Si j'utilise pour ma part /etc/network/interfaces, c'est pour deux raisons:

• j'utilise énormément la ligne de commande (voire pour de courtes sessions je ne prend pas la peine de démarrer Xorg, ça me fait gagner un peu de temps. Non, je n'ai pas de gestionnaire de session)
• je n'ai pas envie d'avoir des daemons pour gérer mon réseau, il ne change pas tout le temps après tout.

Classe! Je connaissais pas, mais je sens que ça va me rendre bien des services.

Mais par-dessus tout, ce que j'aimerai, c'est un xosview en mode texte. Si tu avais ça dans tes cartons… ça serait vraiment énorme.
Bon, il ne dispose pas de stats détaillées, mais il permets d'afficher les type d'occupation d'une ressource et leur ratio dans le temps (peut-être 2-3minutes? Je ne sais pas exactement), son taux d'utilisation totale, et ce, pour une bonne quantité de ressources.
Ici:

• la charge,
• les divers CPU/cœurs/thread,
• la RAM,
• le disque (tiens, je me demande comment il réagit dans le cas de plusieurs disques?),
• le swap,
• le réseau( idem que pour les disques dans le cas de plusieurs interfaces réseau… me semble qu'il merge) et …
• euh… page, mais je sais pas à quoi ça sert celui-la :S

J'avais un peu regardé son code, il est assez lisible (pour du C) mais j'avais eu la flemme de le hacker pour extraire le morceau qui mesure l'usage disque, parce que c'est vraiment pratique et via un ssh ça peut être vraiment pratique.

Attention, la page que j'ai indiquée qui semble être le site officiel indique la dernière version à 1.8.0, mais chez moi, sur Debian stable, j'ai 1.9.3. Aptitude m'indique ce lien.

ont tous des GCs, pour certaines utilisations c'est un problème.

Franchement, le problème des GCs, c'est que dès qu'il s'agit de gérer concurrentiellement autre chose que de la mémoire (fichiers, connexions base de données, sockets réseau, par exemple), on l'a où je pense, faut faire la gestion de la ressource à la main.
Et c'est un peu la très grande majorité des programmes qui gèrent des ressources…
C'est vraiment LA raison qui fait que j'aime tant C++, la RAII. À chaque fois que je regarde un langage qui semble sympa (le go, par exemple) je ne le retiens pas pour cette raison: devoir gérer mes ressources à la main, je ne suis pas assez bon pour ça.

C'est aussi une raison pour laquelle ADA me fait de l'œil, et pourquoi j'ai hâte que Rust passe en bêta (oui je sais, je devrais participer pour aider si ça m'intéresse tant), parce que ça à l'air plus que prometteur: meilleure analyse du code que le C++ à la compilation, RAII, à la fois impératif et objet (ça, c'est important, ça évite de faire une immonde classe qui contienne toutes les fonctions sous forme de méthodes statiques! Java te cache pas je te vois!), généricité… faut bien l'admettre, sur le papier ça déchire.

Comme quoi, les goûts et les couleurs…

Il y à un langage qui parviens à résoudre la moitié de ce problème. J'ai nommé: whitespace

la seule utilité du goto d'ailleurs…)

Hum… désolé, ça sera du C++, pas envie de me coltiner à la main des vérifs de longueur de chaîne… mais:

#include <string>
#include <array>
#include <cstdio>

int main(void)
{
  std::string foo;
  std::array<std::string, 5> bar { "azerty", "qsdfgh", "wxcvbn", "poiuyt", "mlkjhg" };

  std::array<std::string, 5>::iterator foo_it=bar.begin();
  goto first_stage;

  for( ; bar.end() != foo_it ; ++foo_it )
  {
    foo += ";";
first_stage:
    foo += *foo_it;
  }
  return 0;
}

Enregistrer ça dans /tmp/test.cpp puis: clang++ -Weverything -std=c++11 test.cpp ; ./a.out
donnera ceci:

test.cpp:8:34: warning: generalized initializer lists are incompatible with C++98 [-Wc++98-compat]
  std::array<std::string, 5> bar { "azerty", "qsdfgh", "wxcvbn", "poiuyt", "mlkjhg" };
                                 ^
test.cpp:8:36: warning: suggest braces around initialization of subobject [-Wmissing-braces]
  std::array<std::string, 5> bar { "azerty", "qsdfgh", "wxcvbn", "poiuyt", "mlkjhg" };
                                   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                                   {                                               }
2 warnings generated.
azerty;qsdfgh;wxcvbn;poiuyt;mlkjhg

Les warnings sont vraiment très cons puisque j'ai demandé expressément du C++11, mais passons.
Le plus intéressant, c'est le résultat: "azerty;qsdfgh;wxcvbn;poiuyt;mlkjhg". Je suis curieux de voir un algo, sans goto, qui fasse la même chose sans, au choix:

• mettre un if dans la boucle, et donc impact sur les performances (si c'est la boucle principale du programme, c'est dommage…),
• dupliquer la partie de code avant le label, et briser le justifié Do Not Repeat Yourself, et augmente la taille du runtime,
• créer une fonction qui ne sera appelée que 2 fois (en même temps, ça m'arrive de le faire pour des fonctions appelées une seule fois, certes, histoire de compartimenter le code) et qui nécessitera soit:
  • de l'inlining, mais ça augmente la taille du runtime
  • un jump avant le for et à chaque itération (tiens, je viens de penser qu'en fait, c'est pire que le if cette solution là…).

C'est une vraie question: pour ce pattern la, comment faire sans goto? À efficacité maximale, j'entend. Et franchement, cet usage précis je ne le trouve pas sale… je sais plus qui, sur linuxfr me l'a fait découvrir. Au début j'ai essayé de répondre, mais au fur et à mesure je m'apercevais qu'aucun argument ne gagnais.
Du coup, j'ai pas envoyé le message ;)

Comme quoi, le goto, on le critique souvent, mais peut-être que ce qu'on devrait critiquer, ce sont les mauvais usages du goto. Maintenant, on peut dire la même chose des singleton, des template, de l'héritage (surtout l'héritage pour le coup!) voire même des classes. Toutes les techniques sont mauvaises si mal employées, mais ce n'est pas la faute à la technique, juste à son utilisateur.

Je pense que la plupart des mamans, passé un certain âge, te diront que c'était mieux avant ;)

On est quand même à 512Mo de plus ;) oui je sais, c'est chipoter, et à l'heure actuelle c'est limite qu'on est plus à 200M près…

Tu as peut-être des réglages pour que ça consomme un peu moins? Et si tu es sur Debian (ou une de ses filles), tu as installé quel paquet? Me semble que la plupart des DEs proposent 2 méta-paquets: un core, et un "full" (qui en fait à le nom du DE).
Je pense que ça dépend pas mal de ce que la distro installe à côté, et démarre automatiquement.
Avec Kubuntu (j'avais testé vite fait pour tenter d'isoler un problème de config écran, mais impossible de m'en sortir :/… la dernière d'ubuntu je pense, début de l'an dernier?) je me souviens que ma machine (4Gio, dual core 3Ghz) était tout de même nettement plus lente à démarrer que XFCE ou LXDE.
Je n'ai pas vraiment utilisé le système, c'était pour tester un truc, mais la vitesse d'accès au bureau était très distincte.

Après, c'est peut-être aussi que Ubuntu installe 50 tonnes de merde par défaut sur le système, Debian moins mais malgré tout il reste les recommandations et des paquets inutiles installés par défaut (genre, wamerican alors que tu as sélectionné la langue française).
Je crois que Fedora travaille plus sur du KDE par défaut, donc c'est peut-être aussi mieux géré niveau foutoir installé?

Franchement, la plupart de ton journal n'est pas contre le code moderne, juste contre la façon de programmer majoritaire des utilisateur d'un seul langage, crade.
Je passerai outre les 90% de ton journal qui parlent de PHP et de quelques framework spécifiques.

Quand je lis ça:

au prix d'artifices plus ou moins alambiqués (genre certains design-patterns, les namespaces, les traits, etc.).

Alors… les design pattern, je vais devoir t'expliquer ce que c'est on dirait. Ce sont juste des noms et un peu d'explications mis sur des construction, que ce soit d'implémentation ou d'architecture, souvent utilisés. Entres autres pour éviter que quelqu'un ne les utilise à mauvais escient ou pour faciliter la communication (éviter de sortir un diagramme de classes pour parler d'une construction classique, ça fait gagner du temps dans les échanges)…
Personnellement, quand j'ai découvert leur existence, je me suis aperçu qu'il y en à 2-3 que j'utilisais déjà depuis longtemps, inconsciemment.

Les traits, j'ai lu dans un de tes messages que tu crois que c'est pour remplacer l'héritage multiple, ou les interfaces. Faux. C++ supporte depuis toujours l'héritage multiple. Sauf que l'héritage, ça à un coût au runtime (principalement à cause des méthodes virtuelles, il faut bien le dire), et quand tu le mêles à de la généricité, ça devient infernal de pas avoir de problèmes de compilation.
Bien sûr, je parle de langage natif, mais, tu as parlé de code moderne, ce n'est pas limité au seul web et encore moins au seul PHP.
Bref, les traits, ça permets, sans surcoût de performance (dans un langage compilé, hein) de pouvoir certifier à l'utilisateur (de la classe) que certaines conditions sont remplies. Ça simplifie potentiellement à la fois l'écriture du code, la documentation du code, et les messages d'erreur de la compilation (en tant que dev C++, je peux t'assurer que j'ai acquis un certain niveau en GNU-vaudou… ceci dit je préfère les incantations de clang, elles sont moins trash!).

Les namespace, c'est aussi très utile. Je suis en train de me bricoler une classe pour encapsuler les sockets BSD. Et tu sais quoi? Grâce à eux, je n'ai pas eu besoin de me casser la tête pour les noms de classe et de fonctions: j'ai utilisé socket et poll, en sachant que, grâce au namespace, je n'aurai pas de conflits de noms (évitable pour les fonction grâce au fait qu'en C++ le prototype inclue les types, mais pas pour les classes/structs).
Et c'est tellement plus lisible de pouvoir faire sdl::CreateSurface que de devoir se farcir des SDL_CreateSurface. Pourquoi? Parce que moyennant un import de l'espace de nom sdl, on peut juste appeler CreateSurface.

Bref, je suis en complet désaccord avec toi pour ce qui est du code moderne.

Maintenant… Comme toi, j'ai du mal avec les framework. Je leur préfère des collections de bibliothèques indépendantes, qui répondent très précisément à mon besoin. Et quand il faut mettre à jour ou changer (parce qu'il faut porter le projet à un autre système, par exemple) une bibliothèque, la part du code à mettre à jour est plus restreinte.
Évidemment, ça à les inconvénients de ses qualités: il faut prendre le temps de chercher les libs adaptées, et espérer ne pas se planter, parce que tu n'as pas l'éternité devant toi pour choisir ces libs: le but n'est pas de choisir des libs, mais de coder, pas vrai?
Donc, je comprend les utilisateurs de framework, même si je suis en désaccord avec eux.

Ensuite… ce n'est pas parce que certains framework sont mal branlés, buggués, mal architecturés, etc, que c'est le cas de tous, ou qu'aucune lib plus petite n'est pas affectée par ces problèmes.

Enfin… conclusion:
Change de langage. Non, mais sérieux… tu dis dans un post que tu gardes PHP pour faciliter la vie des débutants? Bah justement, arrêtes d'enrichir l'éco-système d'un langage si décrié, adoptes un langage plus propre (je suis sûr qu'il y en a. Peut-être python, ruby? J'en sais rien, honnêtement.) et arrêtes de basher le code moderne alors que tu parles en fait d'une fraction de ses utilisateurs, qui utilisent un langage qui n'à jamais eu pour vocation d'être un langage.
Je cite wikipedia: «Le langage PHP fut créé en 1994 par Rasmus Lerdorf pour son site web. C'était à l'origine une bibliothèque logicielle en C»…
Si tu savais ce que je pense du C… c'est l'anti-thèse de la modernité, un langage qui rend complexe l'écriture de code sécurisé et maintenable. Je ne le considère pertinent que pour de la maintenance d'applications historiques écrites en C (et encore) et l'embarqué où l'on doit avoir un contrôle total sur la taille du binaire et son empreinte mémoire (encore que, je pense qu'un subset de C++ permets d'améliorer les choses par rapport au C tout en ayant les mêmes tailles/empreintes).

Liste quasi-complète de ce que je lui reproche:

• type safety très faible,
• gestion de la mémoire complètement manuelle: ni RAII, ni GC, ni conteneurs standard (que ce soit pour les choses dynamiques ou statiques, hein),
• obligation de copier/coller le code quand juste le type change cf abs(int), labs(long int), llabs(long long int),
• macros qu'il ne faut jamais utiliser parce que quand ça pète, tu en as pour quelques heures pour trouver d'où ça peut bien venir.

On reproche souvent au C++ ses exceptions, sa RTTI, mais ces gens là oublient systématiquement de préciser, que l'on est jamais obligé d'utiliser la STL (je n'ai pas trouvé en moins de 2minutes de façon d'utiliser std::vector en mode nothrow. Je pense que ça existe ceci dit, ou que ça ne devrait pas être trop complexe de spécialiser vector pour utiliser nothrow) et que pour l'allocation de classes new/delete sont incomparablement supérieurs à malloc/calloc/free, parce qu'on peut choisir de l'utiliser avec ou sans exceptions.

Bref, vive le code moderne, à bas les langages pré-historiques, et laissez les gens choisir s'ils veulent ou non utiliser des framework.
Ah, et surtout: à bas les bâcleurs de code, même si je pardonne ceux qui n'ont pas le choix parce que leur chef le leur impose!

Parce qu'elles (commandes : féminin…) peuvent servir dans certains cas.

Huhu… ta formulation pourrait énerver certains ;) attention, les points de suspension sont une commande dangereuse en français, certains processeurs les interprètent mal :D

vouloir faire un rm -rf /toto et d'ajouter un espace par mégarde, du coup ça devient rm -rf / toto

Sinon il y à aussi le cas d'un script insuffisamment testé, dans lequel on fait rm -rf /$var avec $var étant vide :) un truc du genre (bon, un peu plus complexe que ça) est arrivé à un collègue. J'ai pas encore fait aussi fort, mais j'ai aussi déjà merdé avec une commande ou deux…

J'ajouterais que ce n'est pas propre à GNU/Linux, sous Windows également

Typiquement, le bon vieux «virus» des années 90-00: format c: /y

Allez, juste parce que c'est dredi…

Et sur un serveur, sur lequel tu vises la stabilité, sur lequel tu n'en à rien à faire d'avoir les derniers pilotes graphiques (œuf corse, c'est un serveur, n'pas?), sur lequel tu n'as pas envie de passer potentiellement ta journée à savoir pourquoi une MaJ à pété, tu mets ton arch?

Sérieux, tu me déçois, tu aurais au moins pu arguer du fait que depuis l'avènement de systemd, Debian va perdre son identité et mourir, et qu'elle sera remplacée par Devuan.

Attention, message long.

Comment se fait-il qu'une version supérieur du noyau va provoquer des problèmes sur des pcs qui fonctionnaient bien jusque là ?

J'y vois 3 raisons principales:

• le code source du noyau (ce qui sert à produite le binaire) est très complexe. Quand on modifie un tel logiciel, je ne pense pas qu'il soit possible d'avoir la garantie absolue de ne rien casser.
• il existe de nombreux matériels différents, certains obéissant aux standards complètement, d'autres partiellement, d'autres pas du tout. Corriger un bug qui affecte le matériel obéissant complètement aux standards, ou juste améliorer le code, peut très bien avoir l'effet inverse sur les 2 autres «familles»
• l'erreur est humaine, et même si je pense qu'il y à souvent une revue de code par d'autres personnes dans linux, il ne faut pas oublier que la volumétrie de code est telle qu'il est difficile de repérer les problèmes les plus subtils.

Je pensais qu'on essayais toujours d'avoir une compatibilité ascendante.

Pas du tout. Enfin, pas toujours.
Pour faire simple, il existe un schéma de numéros de version que pas mal de développeurs affectionnent. Ce schéma est constitué de 3 parties principales majeur.mineur.patch:

• numéro majeur: potentiellement aucune rétro-compatibilité garantie.
• numéro mineur: ajout de nouvelles fonctionnalités, API compatible avec la version majeure précédente modulo les nouvelles fonctionnalités.
• numéro de patch: correctif de bug, API compatible à 100% avec la version mineure précédente.

Malheureusement, ce schéma force l'utilisateur à aller voir le site officiel pour voir de combien il est en retard, donc Ubuntu à créé un système de version différent: mois.année. Avec celui-la, on perd les informations de compatibilité, mais au moins on garde une information à peu près exploitable. Enfin, on à le 3ème modèle populaire, celui de chrome (que Firefox à adopté, on est vendredi alors je me dois de le mentionner), qui est juste inutile: en effet, on perd tant les infos de compatibilité que les info d'âge…

par exemple certains pcs tournaient bien avec Ubuntu 12.04, mais deviennent limite pour accueillir Ubuntu 14.04

Ça, c'est du à un autre problème.
En fait, là, tu compares un OS avec une distribution.
L'OS, c'est, grosso modo, le noyau (linux) et les pilotes.
La distribution, c'est le noyau plus tout l'environnement utilisateur, dans beaucoup de cas composé uniquement de l'environnement de bureau (que j'abrège DE, pour Desktop Environment), c'est à dire dans le cas d'Ubuntu, Gnome, anciennement 2, qui était probablement plus léger, machines de l'époque oblige, et nouvellement 3, qui est… disons… très «aimé» par la majorité des utilisateurs de gnome 2.

Il faut aussi savoir que les 2 DEs les plus utilisés, à savoir Gnome et KDE n'ont toujours eu comme objectif que d'être complets en terme de fonctionnalités (dans le cas de gnome 3, il semblerait que ce ne soit pas tout à fait vrai ;)) y compris en fonctionnalités que l'utilisateur n'utilise pas. Cela alourdit le système, naturellement.

Il existe une autre «famille» de DEs, plus légers, dont les plus connus sont XFCE et LXDE. LXDE est à mon avis le plus léger, tandis que XFCE se positionne entre l'extrême légèreté (pour un DE) de LXDE et la lourdeur de Gnome.

Enfin, pour finir le tour du propriétaire, il y à des gens (comme moi) qui préfère composer eux-même leur environnement. On sélectionne divers logiciels, et on arrive à un résultat très léger, réactif, et surtout, très personnalisé, avec lequel on à une efficacité supérieure à ce que n'importe quel DE pré-construit pourrait nous proposer. Je pense toutefois que la majorité de ceux qui font ça sont des utilisateurs passionnés, souvent professionnels, parce que ça exige pas mal de temps au début pour se construire son petit nid douillet.
Mais à titre d'exemple, sur une machine dotée de moins de 256Mio de RAM, et d'un CPU n'ayant qu'un seul cœur à moins de 1GHz, j'arrive à avoir une machine tout à fait utilisable pour mes tâches du quotidien (et mêmes quelques jeux). Certes, c'est «un peu» spartiate niveau graphismes, mais il faut comprendre que les effets de transition, de transparence, animations… tout ça, ça exige pas mal de ressources, pour un rôle… inexistant, voire contre-productif (parce que moi, ça me dérange les trucs qui clignotent ou qui mettent du temps à faire ce que je leur demande).

J'espère avoir été compréhensible et ne pas avoir dit trop de bêtises (hors ce qu'on à le droit de dire un trolldi, bien sûr).

Par contre ne pas dire à un recruteur que la principale différence entre la méthode agile et la Rache, c'est que la Rache prévoie la perte de post'it, ils n'ont pas tous le sens de l'humour.

J'aime :D

Il faudrait en parler à l'équipe d'OpenMW je pense. À l'origine le projet était codé en D, si ma mémoire est bonne.

En tout cas, sur de petits projets que l'on peut accomplir seul ou avec peu de monde, je tendrai à être d'accord avec toi.
Dans les autres cas non, parce que même si apprendre un nouveau langage n'est pas particulièrement problématique, il n'y à pas que le langage lui même, mais aussi les libs qu'il faut fatalement réapprendre ou l'infra à adapter (admettons qu'il y ait par exemple des outils pour analyser le code, il faut qu'ils supportent le nouveau langage ou en changer).

Effectivement.

par eclipse

Parfois, je me demande si les IDEs ne sont pas l'une des causes du code dégueulasse. Ils facilitent la duplication de code, que ce soit avec la souris ou avec l'auto-complétion sur le projet complet… ils ont aussi tendance à embarquer des générateurs de code, et je n'ai pas encore vu de code généré qui soit maintenable sur le moyen-long terme.
Je ne dis pas que c'est la faute d'éclipse si l'utilisateur est un branque, hein, faut pas repousser la faute sur l'outil, mais la facilité engendre régulièrement ce genre d'«erreur humaine» j'ai l'impression.

Donc oui, sur les gros projets, il leur faut bien 6 mois pour apprendre les incantation magique pour qu'eclipse fonctionne a peu près,

Sauf qu'en l'occurrence, c'est moi qui doit me faire ch… à apprendre, et niveau personnel sur le merdier, y'a plus qu'un dev qui n'a que croisé un des dev de l'équipe d'origine il y à moins de 2 ans, et la… hum… chef de projet.

Quant à dégommer les bugs à la première lecture des fichiers sources, c'est risqué

Je ne le fais pas, de toute façon pour le moment je ne travaille pas officiellement dessus. Je me suis contenté de le signaler. De toute façon, tant que j'ai pas accès au SVN et au bugtracker je ne patcherai rien.

je fais du refactoring simple,

Dans le cas auquel je pense, le bug c'est un bloc de code qui n'a pas été transformé en fonction (20 lignes, copiées/collées 10 fois, et ces 20 lignes elles-même incluent un sous-copier-coller de 2x4 lignes…). Le refactoring simple ici corrigerai le bug du même coup ;) mais bon.

Je me dis surtout qu'il va être temps pour moi de changer de boîte, quitte à devoir bouger sur Paris… sauf que je manque "légèrement" de diplôme (oui, je suis auto-didacte, mais quand je vois le travail de certains qui ont appris à l'école, ça me désole). Verrai bien, y'a p'tet moyen de sauver les meubles quand même.

Je n'ai jamais osé, perso.
Il me suffit de constater le simple fait que le code de la STL est plutôt difficile à lire (bon, ça, à la rigueur… c'est du template après tout, mais malgré tout je pense que ça pourrait être mieux écrit/documenté. Enfin, avec l'habitude j'arrive à en extraire quelques infos…) et mélange des espaces et des tabulations (d'ailleurs, pour ceux que ça intéresse, je pense que les dev de ce truc utilisent un tabwidth de 6… pas commun comme nombre. 8, 4, 2, ok, mais 6 je vois que chez eux).
Ah, il y à aussi le fait que j'aie lu leurs coding guidelines, il y à quelques années (ça fait mal de parler d'années en fait… progboards me semble encore avant-hier). Il y avait pas mal de choses qui m'étaient rédhibitoire dedans (déjà, seule l'utilisation du langage C était acceptée quand le but n'est pas de faire un logiciel dédié à un langage particulier…).

D'ailleurs, c'est un autre argument qui me donne envie de passer à BSD: me semble qu'il y à peu l'un des BSD à switché sur clang par défaut.

Il a fallu l'arrivée de clang pour qu'ils commencent à faire des efforts de modularité,

Yep. Mais c'est trop tard, en ce qui me concerne, dès que j'aurai l'occasion de me passer complètement de GCC, ce sera avec bonheur. De manière générale, j'ai du mal avec GNU, je les trouve trop extrêmes dans pas mal de choix. Mais bon, utiliser GNU sous linux, c'est la voie de la facilité aussi ;)
D'ailleurs suis content, j'ai découvert il y à peu un repo clang basé sur libstdc++4.7 pour debian stable, je peux enfin utiliser clang et le C++11 sans utiliser Jessie (bon, j'avais surtout pas cherché avant, parce qu'avant je ne voyais pas de problème à utiliser des paquets testing sur une debian stable)!

Autrement on ne continuerai pas d'utiliser le C ou le C++ au lieu d'Ada (par exemple)..

Les avantages du C et du C++ sur l'AdA sont pourtant évidents:

• portabilité (du C ansi, je pense que ça passe juste sur 95% des µproc)
• base de code conséquente
• "communauté" plus vaste, donc plus simple de récupérer des contributeurs (éventuellement one-shot) ou de trouver des gens à qui demander à l'aide (petite pensée pour openmw qui à été commencé en D, puis qui est passé au C++ pour avoir plus de développeurs).

Enfin… ADA me plaît beaucoup sur le papier. Faut juste que je me trouve le temps d'installer un compilo, de lire la doc pour trouver la commande pour générer un binaire à partir d'un source, et que je me fasse les classiques programmes de début de langage: hello world, deviner un nombre, …
Sauf que trouver le temps pour ça, c'est pas évident, les journées sont courtes.

Tu aurais des infos sur l'application de fuzzing, dans la pratique? Je vois bien comment ça marche en théorie, mais dans la pratique, je ne vois pas trop comment le mettre en place. Tu écris un programme dédié pour tester la cible?

Néanmoins, je ne renie pas le fait que cela représente déjà beaucoup de boulot !

Moi non plus.
Porter des softs à toujours représenté un gros boulot quand les softs en question ne sont pas prévus pour être simples à porter. Et vue la mentalité de GNU, je doute fortement qu'ils aient fait le moindre effort pour une potentielle compat windows (bien que cygwin comme mingw aient réussi).
Porter bash n'a vraiment pas dû être simple, et la glibc à du être une horreur (modifier tous les appels au kernel doit être plutôt fastidieux, avec le risque d'erreur que ça implique, sans compter le fait que si j'en crois le peu que j'ai lu de l'implem GNU de la STL, je doute que le code soit super lisible, même avec tabwidth=6 pour contrer les effets des espaces + tabs mélangés).

Pour le coup, je pense que l'arrivée de clang et de projets du genre compiler tout Debian avec clang doit pas mal aider, et perso j'ai nettement plus confiance dans les dev de clang pour faire un truc plus simple à porter (J'allais dire qu'il faudrait encore que clang tourne sous windows, mais en fait ça à l'air d'être le cas.

En même temps, il faut dire qu'il n'y à pas mieux qu'un coiffeur pour démêler un chevelu (le nom que mes profs donnaient au schéma entre le schéma de conception et le dessin de la carte, qui portait très bien ce nom d'ailleurs).

Le problème n'est pas d'aimer, le problème est d'avoir la possibilité. Si seulement le… hum… chef de projet acceptait d'ouvrir les yeux sur le fait que, oui, le code qui à été pondu est dégueulasse (non, s'il faut 6 mois pour qu'un dev soit compétent sur le soft, c'est pas parce que le soft fait trop de trucs, c'est surtout que le code est immonde et mal conçu en fait) peut-être que l'on pourrait nettoyer, et dégommer les bugs que l'on peut trouver à la simple première lecture d'un fichier source.

Au fond, il a raison: si les futurs dev lisaient plus de code pendant leurs cours, au lieu d'écrire des snippets, peut-être que le code serait moins crade…

Pas celui qu'ils lisent, hein, non non, je parle de celui qu'ils écriront!

Désolé, suis encore écœuré de ce que j'ai lu hier au taf…. un fichier de 2kloc (en java, mais peu importe le langage, c'est bien la faute du dev quand il ne vérifie pas le retour d'une fonction… même en java, la mémoire est un problème: accéder à un pointeur nul, peu importe le langage, c'est plantage direct) écrit par des… hum… «développeurs». Ce truc inclue une fonction de plus de 1000Loc, des copier collé partout ou j'ai pu, rien qu'à la lecture, découvrir plusieurs bugs latents, et la taille globale du fichier pourrait être réduite de 25% à vue de nez!

Donc, ouai, on devrait faire lire plus de code aux étudiants, et de préférence le code bien immonde, et leur demander de refacto tout ça. Avec évidemment une review par un vrai dev. C'est beau de rêver.

Ce n'est pas la question de savoir quels types d'outils il y à.
La question, c'est de connaître au moins le nom de quelques logiciels phare, parce que je doute que, sur linuxfr, des gens vont recommander à leurs proches éloignés de l'informatique une collection de soft dont on ne sait même pas si on saurait dépanner les logiciels les plus en vue, faute de nom.

Franchement, je pense que ça ne serait pas un problème de citer sumatra, firefox, thunderbird, gimp, etc (je suppose pour les soft hein, je pourrais me tromper).