freem a écrit 4918 commentaires

Chez moi quand j'avais essayé d'installer Xorg, il avait refusé à cause de problèmes de dépendances. Je n'ai pas pu aller plus loin, et j'avoue que l'expérience m'à échaudé.

Vu que ce journal est dédié aux FPS libres, je me permets un petit lien vers un autre FPS plutôt digne de ce nom.

Pour avoir joué à Nexuiz, le père de Xonotic, je sais que ça se qualifie vraiment dans le style de quake, très nerveux et de mémoire pas mal de tricks basés sur le rocket jump.
ET je connais pas mais je l'imagine dans le style classique réaliste, et si Unvanquished est très bon jeu, j'avoue ne pas trop avoir de catégorie tout faite ou de jeu pour le comparer.

Pour moi, redeclipse (basé sur le moteur de cube2) se positionne plutôt dans la direction d'unreal tournament, le rocket jump il faut oublier: le seul lance-rocket du jeu dégomme tout ce qui se trouve dans les 10-20m (à vue de nez, je n'ai jamais pris le temps de mesurer). Mais il faut le trouver, le prendre et il n'à qu'une seule charge… heureusement.
Pour le reste des armes, elles ont vraiment toutes leur utilité, et sont équilibrées (je n'en dirais pas autant de Nexuiz, soyons honnêtes).
Les mouvements sont par contre à la fois simples à utiliser mais complexes à maîtriser: il y à une touche qui permets de rebondir à atterrissage d'un saut ou de courir sur les murs (ça pompe dans la stamina par contre, donc temps limité).
Pas mal de gameplays différents et de mods intégrés officiellement au jeu, également.
Les bots, s'ils ne sont pas exceptionnels, sont respectables, ne se bloquent pas dans des endroits comme des cons, et ça aide à apprendre à jouer avant de s'aventurer sur la toile. D'ailleurs, il existe un mode de jeu humain vs bots, et l'on peut configurer le talent des bots (hum… je ne sais pas si ce n'est pas juste leurs caracts qui sont boostées… faudrait aller regarder tiens) et dans ce mode précis, le nombre de bots par joueurs (dans un fichier de conf, comme pour la difficulté). Franchement, à partir de 2 vs 1, ça deviens fun. Ah, et puisqu'il est fait mention d'un nouveau mode invasion dans nexuiz, il y à un modificateur du même style dans redeclipse. Sur certaines map c'est vite injouable, on passe son temps à frag (ou se faire frag) par des sortes de zombies sans croiser l'ennemi. Ça doit être configurable aussi, mais jamais cherché.

Niveau machine, il tourne sur des machines bien moins puissantes que Nexuiz (et donc je présume Xonotic) sans le moindre souci et sans être dégueu. Pour les graphismes, justement, il correspond à mes besoins, aussi laxistes soient-ils: pas de pixels sales, pas de couleurs tape-à-l'œil, des cartes pas toutes juste carrées… C'est pas sublime, mais c'est bien assez beau pour pourrir des adversaires.

Ah, et pour finir, il est intégré dans Debian, mais sur Wheezy c'est une vieille version. Il vaut mieux activer les backports pour avoir une version propre. Niveau licence, Debian le classe dans contrib pour le moteur, non-free pour les data, mais la FAQ indique, elle:

Red Eclipse itself and the Cube Engine 2 are under the zlib License.
All content in the game is Free, and no more strict than the Creative Commons CC-BY-SA license.

Du coup, je ne sais pas trop quoi croire. Je n'ai jamais pris la peine de vérifier non plus.

De toute façon, je pense que ce serait dommage d'essayer les 3 jeux du journal et de passer à côté de celui-ci ;)

Cet argument il est naze, Arch Linux m’a jamais pété

Chez moi ça marche TM?

L'avantage d'une distro non rolling-release, c'est que pendant un certain temps tu n'a que des MaJ de sécurité: pas d'ajout/suppression de fonctionnalités, ce qui rend les choses quand même plus simples à maintenir.
Dans une rolling release, j'aurai personnellement beaucoup de mal à mettre à jour, sauf si je sais que les dev du logiciel en question maintiennent officiellement une version stable.

En C++ on aurait pas utilisé de cast C-style.

On peut, c'est vrai, mais c'est parce que ce langage ambitionnes d'être compatible avec le C.
Moi, je vois un cast C-style en C++, je me dis "Hé merde… ça, ça pue". Si je vois un static_cast, je suis plutôt confiant, un dynamic_cast, je vérifie si il y à une gestion des exceptions ou de pointeur null, et reinterpret_cast, je relis le code à plusieurs reprises, mais au moins je sais que c'est dangereux.
Contrairement au cast C-style, ou je me dis que ça pue parce que ça peut être l'équivalent de n'importe quel autre cast.

Finalement, plus le temps passe, plus j'ai l'impression que le plus gros défaut de C++ est sa compatibilité avec le C… mais c'est aussi ce qui fait qu'on peut utiliser sans prise de tête des libs codées en C, à la qualité aléatoire.

Moi j'ai une préférence pour DRY.
C'est justement un principe pour éviter les coûts de maintenance.

Tu dis que l'on aura peut-être pas de problème de perf sur cet endroit. Moi je te répondrai donc qu'il y en aura peut-être. Sur de petits bouts de code fréquemment utilisés, j'ai tendance à penser que je préfère connaître une version optimisée, qui n'ajoute au fond pas grand chose niveau complexité de lecture (mais la version du while est nettement supérieure, clairement) mais qui me permette de ne pas avoir à me poser la question si oui ou non c'est un endroit qui risque d'alourdir.

Et en bonus : une implémentation de cette fonction par des gens qui connaissent un peut le C++ et bizarrement, pas de goto !

C'est une raison pour laquelle j'utilise dès que je le peux les algos de la STL.

Il y à la performance, et il y à la maintenance. C'est surtout le 2nd qui me pose problème: un code copié une fois, j'ai toujours peur que quelqu'un arrive, modifie un truc à un endroit et zape l'autre copie…

Sinon, c'est moi ou ton exemple ne gère que les string?

Comme vérifier qu'un conteneur contient bien un élément donné.

std::find, en C++. Fonctionne sur tous les conteneurs standards, du foo* au std::multi_map en passant par std::array. La STL à pas mal de ces petits algo qui sont devenus subitement utilisables depuis 2011, mais celui cité manque toujours.

Bah, tu as le choix entre une Ferrari et une berline

Si le C++ est une berline, qui est la Ferrari? Le C, ou l'assembleur?
Je ne vois pas vraiment de raison pour que le C++ soit plus lent que le C.

Je vois 3 corrections à faire dans mon code, si j'avais vraiment voulu l'utiliser dans un vrai programme:

• vérifier que le tableau est pas vide (mais j'ai utilisé un array statique ici donc il n'y à aucun risque au runtime)
• utiliser des char[] dans l'array, et pas des std::string
• réserver correctement dès le début l'espace que le std::string occupera à la fin (on le connaît, puisque tout est statique, et au pire on pourrait le calculer) pour éviter les realloc.

Mais c'était censé être un code à la va-vite, rien de plus, pas un code parfait ;)
En tout cas merci pour ta solution.

Par curiosité, le compilo ne détecte pas la duplication de code quand tu fais quelque chose comme:

Aucune idée. Par contre je sais que le cerveau humain, lui, n'est pas toujours capable de fusionner un bout de copié/collé, surtout que tu peux avoir plus que quelques lignes de code. Encore une fois, ici, c'était un exemple trivial.

Bien vu!

Pour la liste vide, j'ai fait juste un code simple… Ça n'à rien de compliqué de tester avant de se lancer dans une boucle, après tout.

parfois j'ai des doutes… parce que certaines merdes que je vois nécessitent plus de motivation pour faire de la merde que du travail propre, ou alors ignorer qu'on peut faire proprement…

Ç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).