C'est ça. Sentiment partagé, rassures-toi, mais dans ce type de code les commentaires sont un mal nécessaire, et on ne peut nettoyer le bordel que petit à petit… et croiser les doigts pour ne rien casser au passage.
Si le code est moche, il vaut mieux le changer, il y a de grande chance que malgré le commentaire, il pose problème plus tard.
Ce n'est pas toujours possible, pour diverses contraintes.
Genre: usine à gaz qui pète à la moindre modif (cause principale: variables globales, je vous hais!), manque de temps, fonction qui fait le café, le thé et accessoirement qui effectue une tâche utile, etc.
et il me semble qu’il y en a aussi sur Debian et Ubuntu.
Pour Ubuntu je ne sais pas. Pour une Debian "classique" avec grub, systemd et gnome, je ne sais pas non plus.
Mais chez moi (enfin, à mon taf sur mon desktop):
Sachant bien sûr, que cette liste contiens énormément de faux positifs. En regardant de plus près, j'ai:
mailcap
fpc-2.6.4.cfg (que je devrais d'ailleurs dégager, finalement je n'ai pas eu à faire de pascal…)
fmtutil.cnf (en fait, il est mentionné dans texmf/fmt.d/00tex.cnf que "In Debian, fmtutil.cnf is a file that is generated from configuration files in /etc/texmf/fmt.d/. This file, 00tex.cnf, contains only some comments on how to edit these files.")
ca-certificates.conf.dpkg-old
ca-certificates.conf
X11/Xwrapper.config
ssh/sshd_config (mais bon, en fait il est généré par le paquet, alors je ne sais pas si il est pertinent de l'avoir dans cette liste…)
default/locale
udev/rules.d/70-persistent-cd.rules
udev/rules.d/70-persistent-net.rules
Mais il est vrai que je n'ai que 1028 paquets installés, dont la moitié sont des lib et ~70 libs de dev. Un système léger quoi (pas de DE, ça doit jouer à mort). Ceci dit, je pense que Debian reste malgré tout peu génératrice de config, pour éviter d'avoir un niveau trop peu élevé de "bidouillabilité".
Je suis d'accord, mais parfois il n'y à pas le choix.
Je connais 2 sortes de commentaires
Tu as oublié:
le code zombifié,
les notes style TODO,
ceux qui disent ce que le dev pense de son propre code,
ceux qui résument une ligne longue comme le bras et illisible, genre quand la ligne inclue des appels à std::mem_fun, std::bind1st, ou std::bind2nd (je sais, depuis C++11, on peut simplifier considérablement ça, mais on ne peux pas l'utiliser partout, le C++11…)
ceux qui parlent des règles de gestion stupides
ceux qui permettent de générer une doc
Mais c'est clair: je suis aussi du genre à préférer éviter les commentaires que je le peux, par exemple un truc genre "i = 2* 3.14 * r; //3.14 is PI" n'apparaîtra jamais dans mes codes. Je préfère faire une constante et lui filer la valeur 3.14… bon, avec PI, c'est trivial, mais un autre exemple déjà cité ici: i = 0x5f3759df - ( i >> 1 ); montre que ça ne l'est pas toujours… (oui, je trouve ce truc crade, peu m'importe qui l'a écrit à l'origine. Les magic values, c'est déjà pas top, mais quand en plus c'est pas mis dans des constantes… berk)
Laisser vide 2 des 4 instructions faisant partie de la boucle for
Des 4? Tu considères donc le corps d'une boucle comme partie intégrante de la boucle?
Pas moi, mais c'est une question d'opinion j'imagine.
Mais du coup, dans mon opinion, il n'y à donc qu'un champ sur 3 qui n'est pas utilisé, et il s'agit de l'initialisation de la boucle. Ce champ est régulièrement laissé vide, pour un tas de raisons.
Accessoirement, si le code n'est, par malheur, pas assez parlant lui-même, il reste les commentaires. Les commentaires qui peuvent aussi servir à pointer un endroit ou l'on à du tordre le code pour obéir à des règles métier un peu farfelues, ou parce que le code avec lequel on interagit (et sur lequel on à bien entendu aucun pouvoir) est buggué/complexe/bancal.
Je pense que tout le monde sera d'accord avec moi pour dire que quand on maintien du 10 ans d'âge, on fait attention quand on refacto, et même si c'est hyper tentant de refacto en masse, il faut savoir se contenir…
On pourrait aussi rendre obligatoire la boîte aux lettre et remédier au problème des monceaux de pubs non sollicitées, par exemple par une loi rendant l'autocollant "Stop Pub" contraignant.
Ça ne servirait à rien. Parce que, en fait, une telle loi existe déjà: c'est illégal, de mettre de la pub dans une BaL, sauf si la personne à déjà fait montre d'un intérêt envers la pub en question. Autrement dit, si tu as une carte de fidélité machin, machin aura le droit de te spammer.
Donc, le problème n'est pas de passer une loi, mais de forcer ces emmerdeurs à la respecter, tout simplement.
Et puisque ça me gonfle sérieux aussi, je ne les qualifierai pas que d'emmerdeurs, mais aussi d'êtres irresponsables qui pourrissent notre planète avec du papier glacé et en dégommant quantité d'arbres pour rien. En fait, j'ai envie d'utiliser un terme bien plus puissant qu'emmerdeurs…
Mais d'un autre côté, c'est un truc qui fait vivoter (parce que livrer de la pub, je doute que ça paye plus que livrer des annuaires, chose que j'ai faite, et ça paye que dalle ou presque, surtout si on respecte la procédure qui implique de d'abord aller toquer pour livrer en main propre, et pire si on se voit attribuer un village genre cambrousse profonde) un certain nombre de gens (les petites mains qui livrent et que l'on maudit).
Donc, je ne réserve pas mes noms d'oiseau à ces gens, mais à ceux qui les payent: si le système est le même que pour les annuaires, ils sont payés au nombre de déchets déposés dans les BaL. Pour qu'ils respectent les "pas de pub", il faudrait qu'ils ne soient pas payés à la performance, mais sur un salaire fixe.
Je suis aussi loin d'être admin, mais j'essaie de me mettre aux scripts shell, parce que c'est vraiment puissant, même à mon très faible niveau.
Par exemple, quand on doit se taper des comparaisons de fichiers de log qui peuvent différer d'un serveur à un autre, ou d'une date à une autre, pour trouver des infos supplémentaires au sujet d'un bug qu'il faut corriger.
Ou quand on est dans une petite boîte et qu'il faut modifier une entrée SQL dans 5 bases de données, répliquées sur un autre serveur ( ce qui fait donc 10 fois la même manipulation à faire, à la main… c'est ce que mes collègues faisaient, c'est ce que je refuse de faire. ).
Pour ces situations, écrire un programme complet serait un peu overkill, quand on peut coder ça en 10-20 lignes de shell.
En fait, dans ma boîte je fait un peu de tout, sûrement pas du grand art, mais bon, faut bien que quelqu'un le fasse, et j'avoue que ça ne me déplaît pas. Tant qu'on me demandera pas de faire ce genre de trucs sur des serveurs windows du moins :)
Malheureusement, sed/cut/grep et Cie sont en effet assez peu adaptés à la manipulation des fichiers de conf (même textuels),
Si, ils sont très efficaces quand il s'agit de gérer des fichiers de type clé=valeur, genre INI ou… en fait la plupart de ce que je trouve dans mes /etc.
Ce n'est pas parce que c'est un *-like, que c'est moins bien ou pas pertinent. Au contraire, surtout que toi, tu utilises une approche radicalement différente (xml au lieu de langage de script).
Je ne sais pas si tu publies tes scripts, mais je pense qu'ici plusieurs seraient intéressés, à lire les différentes interventions.
Je ne sais pas à qui la faute, et franchement je m'en moque. Quelque part, ça me semble pertinent de ne pas appeler apache httpd, puisqu'on pourrait imaginer installer plusieurs httpd sur la même machine.
Mais ils auraient pu utiliser le système d'alternatives (comme pour les éditeurs de texte, émulateurs de terminal, etc) pour fournir un lien symbolique vers le fichier qui va bien.
Ça aurait permis une meilleure généricité, non? Mais je suppose qu'il doit y avoir une raison.
Ce n'est pas faux. Du coup, tu utilises quels outils classiques pour modifier de la conf xml/json? Parce que sed, grep, cut & co, ça me paraît difficilement adapté?
Bien entendu, je n'ai exécuté en pas à pas que quelques itérations, pour l'exemple. Donc, problème résolu?
À noter tout de même pour l'honnêteté intellectuelle, il me semblait qu'il fallait faire appel à des trucs plus retors (à l'époque ou j'utilisais C::B, il me semble qu'il y avait besoin de faire appel à du python. Je n'ai jamais creusé la question ceci dit…), il y à quelques mois. J'imagine que ça ne fonctionne que sur des versions un minimum récentes de gdb donc.
"On doit", contre des "exemples concrets"…
Donnes-moi un outil concret qui accepte ton truc et compile?
Enfin, admettons. Tu trouves ton truc plus lisible pour un humain (enfin, pour un dev, puisque ce sont les dev qui maintiennent les cmakelists.txt en général) que le pendant cmake? Plus maintenable?
Dans ce cas, vraiment, on à des goûts différents et je doute qu'on puisse se convaincre l'un l'autre.
Quant au format… je vois ton truc, j'ai peur. Parce que je me dis que si je dois utiliser un outil de manipulation de texte (grep, sed, cut, etc) pour extraire une info précise de ce machin, je suis dans une merde assez profonde. Mais nul doute que ton usine à gaz outil qui interprète ça te fournira tout ce dont tu as besoin je suppose?
Utiliser -O3 par défaut serait une ânerie, ce niveau d'optim peut déclencher des bugs (je n'ai pas d'exemples précis en tête, cependant, mais une recherche devrait pouvoir te guider rapidement. Du côté du wiki de gentoo, peut-être?).
Idem, "-DPLUMA_EXPORTS" n'à rien de standard.
Générer des libs shared par défaut serait, encore, de bien mauvais goût, selon la taille, ça peut juste être un coup à générer du méchant bloatware (dans le cas de pluma, comme tout le monde l'aura lu dans le très concis exemple de VS, il y à 4 cibles: debug/release et share/static).
Imposer des paths n'est pas non plus une bonne idée, j'ai cru constater que les dev c++ sont loin de tous avoir les mêmes conventions, et ça peut même varier selon le projet: par exemple pour une lib, séparer les include d'interface des include utilisés par le source est fréquent.
Je ne parle même pas du cas ou le src contiens des sous-dossiers en fonction de l'interface utilisé… (aptitude est un exemple).
D'ailleurs, je pense qu'il est largement faisable de faire ce que tu as fait en autant de lignes avec cmake, si tu as un template à inclure… je ne vois pas pourquoi ça le serait.
Un truc genre (syntaxe à l'arrache):
Ne doit pas être infaisable. À ce niveau, je me demande(en tout cas on peut creer des fonctions) si on ne pourrait pas construire un template, ou plutôt une lib, qui permettrait d'écrire:
Parceque le langage ou plus exactement les extensions de GCC avaient évolué.
D'où l'intérêt de ne pas utiliser d'extensions. Si ces langages (C et C++) se tapent des procédures assez longues, c'est qu'il doit bien y avoir une raison autre que faire chier à rester immobile, non?
Je serai curieux de savoir combien de codes sources C/C++ d'il y a 10 ans compilent encore avec les compilateurs d'aujourd'hui (y compris les révisions de GCC).
Je serai curieux de savoir combien de codes sources C/C++ standards d'il y à 10 ans ne compilent plus avec un compilateur qui supporte le standard de l'époque (aka: c++98* ou c++03. On à aussi le -ansi.), et donc qui respecte le standard de cette époque. Je ne sais plus laquelle…) récent.
Évidemment, il faut alors se "résoudre" à utiliser les flags qui forcent l'utilisation d'un standard, sinon c'est s'exposer aux emmerdes…
*:
Attention tout de même au standard 98, qui intègre de mémoire une fonctionnalité tellement à la con qu'il n'y à que commeau à l'avoir implémentée --ils avaient d'ailleurs fortement conseillé aux autres de ne pas le faire, la feature en question ayant coûté un refacto massif pour un usage très… parcellaire.-- je ne pourrai pas citer le nom exact de la feature en question: je n'ai appris mes premières notion de C que bien après 98… et donc je ne m'en suis jamais servi.
Bien que je préfère ça aussi, je suis parfois hélas obliger de faire face à un monde différent du tien, ou les choses bougent plus vite.
Naturellement que les choses peuvent bouger. Et ça ne me pose même pas de problème, en soit. Le problème que les gesticulations de systemd me pose, en fait, c'est qu'il s'agit d'un élément central du système (du moins, il souhaite le devenir, et semble y parvenir…), et que donc on peut légitimement je pense, craindre pour le reste du système du même coup.
Python est, ma foi, un excellent exemple. On m'a parlé d'un code python 2.7 qui ne pouvait être exécuté par un interpréteur 2.8. Pour une version majeure, je peux le comprendre hein, pas de souci, parfois il faut savoir péter les API. Mais habituellement, le numéro de version mineur d'un outil est quand même censé être une garantie qu'un interpréteur plus récent pourra digérer de la même façon si ce n'est mieux un code plus ancien que lui (raisonnablement, on parle d'une différence d'une version mineure ici).
Bien sûr, il n'y à pas que python, si j'en crois apt, lsof dépend soit de perl < 5.12.3 (sur ma machine actuelle) soit de libperl4-corelibs-perl. Au moins pour perl, il y à une lib de compat… maintenant, pour me convaincre que c'est une bonne chose, que de casser la compat descendante, ça risque de ne pas être simple.
Oh, et, bien sûr, dans le cas de python/perl/langage-X il est souvent possible d'installer plusieurs fois l'interpréteur/compilateur/whatever. Dans le cas de systemd, j'ai un gros doute?
Il y en a d'autres. Par exemple, splunk.
J'ai précisé que je ne connaissais que celui de windows… savoir qu'il en existe des exploitables est une excellente nouvelle!
Je n'en connaissais aucune, mais c'est une excellente question, qui mène à ceci:
Compatibility with Windows and Macintosh[edit]
ext4 does not yet have as much support as ext2 and ext3 on non-Linux operating systems. ext2 and ext3 have stable drivers such as Ext2IFS, which are not yet available for ext4. It is possible to create compatible ext4 filesystems for use in Windows by disabling the extents feature, and sometimes specifying an inode size.[20] Another option for using ext4 in Windows is to use Ext2Fsd,[21] an open-source driver that, like Ext2IFS, supports writing in ext4 partitions where extents have been disabled. Viewing and copying files from ext4 to Windows, even with extents enabled, is also possible with the Ext2Read software.[22] More recently Paragon released its ExtFS for Windows which allows read/write capabilities for ext2/3/4.
Mac OS X has full ext2/3/4 read/write capability through the Paragon ExtFS [23] software, which is a commercial product. Free software such as ext4fuse has only read-only support with limited functionality.
Donc, il semble qu'il en existe d'autre, sur d'autres OS.
Accessoirement, il me semble avoir lu qu'il est possible de lire de l'ext4 (jamais testé cependant) en mode dégradé avec des outils lisant ses prédécesseurs? (question rélle)
Et pour finir, ext4 est nettement moins invasif. Je veux dire, quel que soit le système de fichiers de mes partoches, je ne crois pas qu'un seul outil s'en apercevra, sauf ceux dédiés à la gestion des FS.
PAX demande pas mal de configuration car certaines applications (firefox, python, mono…) sont incompatibles avec certains mécanismes de protections (par exemple Python a besoin que sa pile soit exécutable).
Serait-ce lié au fait que tous les outils dont tu parles interprètent (et donc compilent en JIT) un fichier? Firefox interprète JS, python les .py, mono les je-ne-sais-quoi (.exe?)… avec java, ça donne quoi, même combat?
Il n'existe, à ma connaissance, aucune protection contre ça.
Lancer un serveur X par application :D Je déconne, mais en fait, il y à wayland qui, en théorie, est protégé contre ce problème (c'est un de leurs arguments massue en fait, mais je parle de théorie parce que je n'ai pas vérifié…).
[^] # Re: Il faut apprendre à respecter les règles !
Posté par freem . En réponse au message aider moi avec les pointeurs. Évalué à 4.
Un source, ça n'existe pas. Une source, à la rigueur… mais ce n'est pas la même chose.
[^] # Re: relativité étendue
Posté par freem . En réponse au journal "beauté du code". Évalué à 2.
C'est ça. Sentiment partagé, rassures-toi, mais dans ce type de code les commentaires sont un mal nécessaire, et on ne peut nettoyer le bordel que petit à petit… et croiser les doigts pour ne rien casser au passage.
[^] # Re: relativité étendue
Posté par freem . En réponse au journal "beauté du code". Évalué à 2.
Ce n'est pas toujours possible, pour diverses contraintes.
Genre: usine à gaz qui pète à la moindre modif (cause principale: variables globales, je vous hais!), manque de temps, fonction qui fait le café, le thé et accessoirement qui effectue une tâche utile, etc.
[^] # Re: Mandrake
Posté par freem . En réponse au journal Swiss Re migre de Solaris vers Linux, et bientôt Windows vers Linux. Évalué à 2.
Pour Ubuntu je ne sais pas. Pour une Debian "classique" avec grub, systemd et gnome, je ne sais pas non plus.
Mais chez moi (enfin, à mon taf sur mon desktop):
Sachant bien sûr, que cette liste contiens énormément de faux positifs. En regardant de plus près, j'ai:
Mais il est vrai que je n'ai que 1028 paquets installés, dont la moitié sont des lib et ~70 libs de dev. Un système léger quoi (pas de DE, ça doit jouer à mort). Ceci dit, je pense que Debian reste malgré tout peu génératrice de config, pour éviter d'avoir un niveau trop peu élevé de "bidouillabilité".
[^] # Re: relativité étendue
Posté par freem . En réponse au journal "beauté du code". Évalué à 2.
Je suis d'accord, mais parfois il n'y à pas le choix.
Tu as oublié:
Mais c'est clair: je suis aussi du genre à préférer éviter les commentaires que je le peux, par exemple un truc genre "i = 2* 3.14 * r; //3.14 is PI" n'apparaîtra jamais dans mes codes. Je préfère faire une constante et lui filer la valeur 3.14… bon, avec PI, c'est trivial, mais un autre exemple déjà cité ici:
i = 0x5f3759df - ( i >> 1 );montre que ça ne l'est pas toujours… (oui, je trouve ce truc crade, peu m'importe qui l'a écrit à l'origine. Les magic values, c'est déjà pas top, mais quand en plus c'est pas mis dans des constantes… berk)[^] # Re: Non merci
Posté par freem . En réponse au journal Coup de gueule : il devrait être obligatoire d'avoir une boîte aux lettres. Évalué à 5.
Sinon, y'a pas que les tinaïdjeurs qui parfois ont l'obligation de faire un taf de merde :)
[^] # Re: Non merci
Posté par freem . En réponse au journal Coup de gueule : il devrait être obligatoire d'avoir une boîte aux lettres. Évalué à 3.
Yep, surtout quand tu as laissé ta bagnole toute la journée sur un parking (de gare, par exemple) et qu'il à flotté à sceaux…
[^] # Re: relativité étendue
Posté par freem . En réponse au journal "beauté du code". Évalué à 3.
Je suis bien certain que tu es certain d'avoir peur des certitudes…
[^] # Re: Plutôt beauté du design
Posté par freem . En réponse au journal "beauté du code". Évalué à 2.
Des 4? Tu considères donc le corps d'une boucle comme partie intégrante de la boucle?
Pas moi, mais c'est une question d'opinion j'imagine.
Mais du coup, dans mon opinion, il n'y à donc qu'un champ sur 3 qui n'est pas utilisé, et il s'agit de l'initialisation de la boucle. Ce champ est régulièrement laissé vide, pour un tas de raisons.
[^] # Re: Asimov...
Posté par freem . En réponse au journal "beauté du code". Évalué à 2.
Élégant? Euhhhh si on veux… les goûts et les couleurs après tout…
[^] # Re: relativité étendue
Posté par freem . En réponse au journal "beauté du code". Évalué à 2.
Accessoirement, si le code n'est, par malheur, pas assez parlant lui-même, il reste les commentaires. Les commentaires qui peuvent aussi servir à pointer un endroit ou l'on à du tordre le code pour obéir à des règles métier un peu farfelues, ou parce que le code avec lequel on interagit (et sur lequel on à bien entendu aucun pouvoir) est buggué/complexe/bancal.
Je pense que tout le monde sera d'accord avec moi pour dire que quand on maintien du 10 ans d'âge, on fait attention quand on refacto, et même si c'est hyper tentant de refacto en masse, il faut savoir se contenir…
Donc, je suis complètement d'accord avec toi :)
[^] # Re: Non merci
Posté par freem . En réponse au journal Coup de gueule : il devrait être obligatoire d'avoir une boîte aux lettres. Évalué à 7. Dernière modification le 03 octobre 2014 à 12:16.
Ça ne servirait à rien. Parce que, en fait, une telle loi existe déjà: c'est illégal, de mettre de la pub dans une BaL, sauf si la personne à déjà fait montre d'un intérêt envers la pub en question. Autrement dit, si tu as une carte de fidélité machin, machin aura le droit de te spammer.
Donc, le problème n'est pas de passer une loi, mais de forcer ces emmerdeurs à la respecter, tout simplement.
Et puisque ça me gonfle sérieux aussi, je ne les qualifierai pas que d'emmerdeurs, mais aussi d'êtres irresponsables qui pourrissent notre planète avec du papier glacé et en dégommant quantité d'arbres pour rien. En fait, j'ai envie d'utiliser un terme bien plus puissant qu'emmerdeurs…
Mais d'un autre côté, c'est un truc qui fait vivoter (parce que livrer de la pub, je doute que ça paye plus que livrer des annuaires, chose que j'ai faite, et ça paye que dalle ou presque, surtout si on respecte la procédure qui implique de d'abord aller toquer pour livrer en main propre, et pire si on se voit attribuer un village genre cambrousse profonde) un certain nombre de gens (les petites mains qui livrent et que l'on maudit).
Donc, je ne réserve pas mes noms d'oiseau à ces gens, mais à ceux qui les payent: si le système est le même que pour les annuaires, ils sont payés au nombre de déchets déposés dans les BaL. Pour qu'ils respectent les "pas de pub", il faudrait qu'ils ne soient pas payés à la performance, mais sur un salaire fixe.
[^] # Re: Gestionnaire de projets
Posté par freem . En réponse au journal Retour aux sources. Évalué à 2.
Je trouve bien xpath, mais pas moyen de mettre la main sur un man de xfind. Tu aurais une URI?
[^] # Re: Gestionnaire de projets
Posté par freem . En réponse au journal Retour aux sources. Évalué à 2.
Je suis aussi loin d'être admin, mais j'essaie de me mettre aux scripts shell, parce que c'est vraiment puissant, même à mon très faible niveau.
Par exemple, quand on doit se taper des comparaisons de fichiers de log qui peuvent différer d'un serveur à un autre, ou d'une date à une autre, pour trouver des infos supplémentaires au sujet d'un bug qu'il faut corriger.
Ou quand on est dans une petite boîte et qu'il faut modifier une entrée SQL dans 5 bases de données, répliquées sur un autre serveur ( ce qui fait donc 10 fois la même manipulation à faire, à la main… c'est ce que mes collègues faisaient, c'est ce que je refuse de faire. ).
Pour ces situations, écrire un programme complet serait un peu overkill, quand on peut coder ça en 10-20 lignes de shell.
En fait, dans ma boîte je fait un peu de tout, sûrement pas du grand art, mais bon, faut bien que quelqu'un le fasse, et j'avoue que ça ne me déplaît pas. Tant qu'on me demandera pas de faire ce genre de trucs sur des serveurs windows du moins :)
Si, ils sont très efficaces quand il s'agit de gérer des fichiers de type clé=valeur, genre INI ou… en fait la plupart de ce que je trouve dans mes /etc.
[^] # Re: Gestionnaire de projets
Posté par freem . En réponse au journal Retour aux sources. Évalué à 3.
Ce n'est pas parce que c'est un *-like, que c'est moins bien ou pas pertinent. Au contraire, surtout que toi, tu utilises une approche radicalement différente (xml au lieu de langage de script).
Je ne sais pas si tu publies tes scripts, mais je pense qu'ici plusieurs seraient intéressés, à lire les différentes interventions.
[^] # Re: Surprenant, non ?
Posté par freem . En réponse au journal Ne dites pas à ma mère que j'ai installé systemd, elle croit que je suis pianiste dans un bordel.. Évalué à 2.
Qu'est-ce qui te force à utiliser udev?
[^] # Re: Surprenant, non ?
Posté par freem . En réponse au journal Ne dites pas à ma mère que j'ai installé systemd, elle croit que je suis pianiste dans un bordel.. Évalué à 1.
Je ne sais pas à qui la faute, et franchement je m'en moque. Quelque part, ça me semble pertinent de ne pas appeler apache httpd, puisqu'on pourrait imaginer installer plusieurs httpd sur la même machine.
Mais ils auraient pu utiliser le système d'alternatives (comme pour les éditeurs de texte, émulateurs de terminal, etc) pour fournir un lien symbolique vers le fichier qui va bien.
Ça aurait permis une meilleure généricité, non? Mais je suppose qu'il doit y avoir une raison.
[^] # Re: Gestionnaire de projets
Posté par freem . En réponse au journal Retour aux sources. Évalué à 2.
Ce n'est pas faux. Du coup, tu utilises quels outils classiques pour modifier de la conf xml/json? Parce que sed, grep, cut & co, ça me paraît difficilement adapté?
[^] # Re: smart pointer
Posté par freem . En réponse au journal Retour aux sources. Évalué à 5.
Chez moi ça marche.
Source:
Sortie de gdb (enfin, cgdb, mais c'est juste un frontend):
Bien entendu, je n'ai exécuté en pas à pas que quelques itérations, pour l'exemple. Donc, problème résolu?
À noter tout de même pour l'honnêteté intellectuelle, il me semblait qu'il fallait faire appel à des trucs plus retors (à l'époque ou j'utilisais C::B, il me semble qu'il y avait besoin de faire appel à du python. Je n'ai jamais creusé la question ceci dit…), il y à quelques mois. J'imagine que ça ne fonctionne que sur des versions un minimum récentes de gdb donc.
[^] # Re: Gestionnaire de projets
Posté par freem . En réponse au journal Retour aux sources. Évalué à 3.
"On doit", contre des "exemples concrets"…
Donnes-moi un outil concret qui accepte ton truc et compile?
Enfin, admettons. Tu trouves ton truc plus lisible pour un humain (enfin, pour un dev, puisque ce sont les dev qui maintiennent les cmakelists.txt en général) que le pendant cmake? Plus maintenable?
Dans ce cas, vraiment, on à des goûts différents et je doute qu'on puisse se convaincre l'un l'autre.
Quant au format… je vois ton truc, j'ai peur. Parce que je me dis que si je dois utiliser un outil de manipulation de texte (grep, sed, cut, etc) pour extraire une info précise de ce machin, je suis dans une merde assez profonde. Mais nul doute que ton
usine à gazoutil qui interprète ça te fournira tout ce dont tu as besoin je suppose?[^] # Re: Gestionnaire de projets
Posté par freem . En réponse au journal Retour aux sources. Évalué à 2.
Utiliser -O3 par défaut serait une ânerie, ce niveau d'optim peut déclencher des bugs (je n'ai pas d'exemples précis en tête, cependant, mais une recherche devrait pouvoir te guider rapidement. Du côté du wiki de gentoo, peut-être?).
Idem, "-DPLUMA_EXPORTS" n'à rien de standard.
Générer des libs shared par défaut serait, encore, de bien mauvais goût, selon la taille, ça peut juste être un coup à générer du méchant bloatware (dans le cas de pluma, comme tout le monde l'aura lu dans le très concis exemple de VS, il y à 4 cibles: debug/release et share/static).
Imposer des paths n'est pas non plus une bonne idée, j'ai cru constater que les dev c++ sont loin de tous avoir les mêmes conventions, et ça peut même varier selon le projet: par exemple pour une lib, séparer les include d'interface des include utilisés par le source est fréquent.
Je ne parle même pas du cas ou le src contiens des sous-dossiers en fonction de l'interface utilisé… (aptitude est un exemple).
D'ailleurs, je pense qu'il est largement faisable de faire ce que tu as fait en autant de lignes avec cmake, si tu as un template à inclure… je ne vois pas pourquoi ça le serait.
Un truc genre (syntaxe à l'arrache):
Ne doit pas être infaisable. À ce niveau, je me demande(en tout cas on peut creer des fonctions) si on ne pourrait pas construire un template, ou plutôt une lib, qui permettrait d'écrire:
Alors, ok, c'est pas en standard, mais bon, ça fait bien ce que tu demandes, avec encore moins d'infos "inutiles" que ton xml.
[^] # Re: Du point de vue utilisateur ou mainteneur ?
Posté par freem . En réponse au journal Ne dites pas à ma mère que j'ai installé systemd, elle croit que je suis pianiste dans un bordel.. Évalué à 2.
D'où l'intérêt de ne pas utiliser d'extensions. Si ces langages (C et C++) se tapent des procédures assez longues, c'est qu'il doit bien y avoir une raison autre que faire chier à rester immobile, non?
Je serai curieux de savoir combien de codes sources C/C++ standards d'il y à 10 ans ne compilent plus avec un compilateur qui supporte le standard de l'époque (aka: c++98* ou c++03. On à aussi le -ansi.), et donc qui respecte le standard de cette époque. Je ne sais plus laquelle…) récent.
Évidemment, il faut alors se "résoudre" à utiliser les flags qui forcent l'utilisation d'un standard, sinon c'est s'exposer aux emmerdes…
*:
Attention tout de même au standard 98, qui intègre de mémoire une fonctionnalité tellement à la con qu'il n'y à que commeau à l'avoir implémentée --ils avaient d'ailleurs fortement conseillé aux autres de ne pas le faire, la feature en question ayant coûté un refacto massif pour un usage très… parcellaire.-- je ne pourrai pas citer le nom exact de la feature en question: je n'ai appris mes premières notion de C que bien après 98… et donc je ne m'en suis jamais servi.
[^] # Re: Du point de vue utilisateur ou mainteneur ?
Posté par freem . En réponse au journal Ne dites pas à ma mère que j'ai installé systemd, elle croit que je suis pianiste dans un bordel.. Évalué à 0.
Naturellement que les choses peuvent bouger. Et ça ne me pose même pas de problème, en soit. Le problème que les gesticulations de systemd me pose, en fait, c'est qu'il s'agit d'un élément central du système (du moins, il souhaite le devenir, et semble y parvenir…), et que donc on peut légitimement je pense, craindre pour le reste du système du même coup.
Python est, ma foi, un excellent exemple. On m'a parlé d'un code python 2.7 qui ne pouvait être exécuté par un interpréteur 2.8. Pour une version majeure, je peux le comprendre hein, pas de souci, parfois il faut savoir péter les API. Mais habituellement, le numéro de version mineur d'un outil est quand même censé être une garantie qu'un interpréteur plus récent pourra digérer de la même façon si ce n'est mieux un code plus ancien que lui (raisonnablement, on parle d'une différence d'une version mineure ici).
Bien sûr, il n'y à pas que python, si j'en crois apt, lsof dépend soit de perl < 5.12.3 (sur ma machine actuelle) soit de libperl4-corelibs-perl. Au moins pour perl, il y à une lib de compat… maintenant, pour me convaincre que c'est une bonne chose, que de casser la compat descendante, ça risque de ne pas être simple.
Oh, et, bien sûr, dans le cas de python/perl/langage-X il est souvent possible d'installer plusieurs fois l'interpréteur/compilateur/whatever. Dans le cas de systemd, j'ai un gros doute?
J'ai précisé que je ne connaissais que celui de windows… savoir qu'il en existe des exploitables est une excellente nouvelle!
[^] # Re: Du point de vue utilisateur ou mainteneur ?
Posté par freem . En réponse au journal Ne dites pas à ma mère que j'ai installé systemd, elle croit que je suis pianiste dans un bordel.. Évalué à 3.
Je n'en connaissais aucune, mais c'est une excellente question, qui mène à ceci:
Donc, il semble qu'il en existe d'autre, sur d'autres OS.
Accessoirement, il me semble avoir lu qu'il est possible de lire de l'ext4 (jamais testé cependant) en mode dégradé avec des outils lisant ses prédécesseurs? (question rélle)
Et pour finir, ext4 est nettement moins invasif. Je veux dire, quel que soit le système de fichiers de mes partoches, je ne crois pas qu'un seul outil s'en apercevra, sauf ceux dédiés à la gestion des FS.
[^] # Re: grsecurity
Posté par freem . En réponse au sondage Quel mécanisme de contrôle d'accès utilisez-vous pour votre système d'exploitation ?. Évalué à 2.
Serait-ce lié au fait que tous les outils dont tu parles interprètent (et donc compilent en JIT) un fichier? Firefox interprète JS, python les .py, mono les je-ne-sais-quoi (.exe?)… avec java, ça donne quoi, même combat?
Lancer un serveur X par application :D Je déconne, mais en fait, il y à wayland qui, en théorie, est protégé contre ce problème (c'est un de leurs arguments massue en fait, mais je parle de théorie parce que je n'ai pas vérifié…).
En tout cas, merci pour ce message informatif.