Journal Systemd vs Linux, quand l'intransigeance d'un développeur tourne au ridicule...

Posté par dcp le 03 avril 2014 à 14:06. Licence CC By‑SA.

Étiquettes :

avr.

2014

Theodore T'so a rapporté un échange de mails très vif entre Kay Sievers
(un des principaux dev de systemd) et Borislav Petkov (un dev Linux).

Le problème levé par Borislav

systemd parse la ligne de commande utilisé pour booter le noyau Linux (via
/proc/cmdline). Si l'option debug a été passé au noyau, systemd considère
que l'option le concerne au même titre que Linux et peut inonder dmesg au point
que la machine n'arrive plus à booter…

Le post de Borislav, la réponse de Kay

Borislav a donc remonté le problème sur le bugzilla de systemd et s'est
montré plutôt constructif en proposant :

d'une part que systemd prenne en considération l'option systemd.debug (donc en utilisant un espace de nom) et plus le générique debug(Borislab considère que debug exclusivement est réservé au noyau, ce qui semble discutable et discuté par ailleurs, sur la LKML)
d'autre part qu'une nouvelle option pour systemd soit mise en place afin que ce dernier n'expédie pas systématiquement ses logs vers dmesg.

Les réponses de Kay Sievers a été pour le moins abrupte et cinglante dans la
mesure ou il renvoit en bloc le problème du coté de Linux:
- debug est générique et n'est pas une option exclusivement réservé à Linux.
- Que quelque chose de vrillé emballe les logs inutilement est un
comportement auquel on doit s'attendre

Au bout de quelques échanges assez vifs, Kay Sievers a fermé le ban (et le
ticket bugzilla!) en déclarant qu'il ne s'agissait en aucun d'un bug (en tout
cas, pour lui, ça ne concerne pas systemd). Le bug a été réouvert depuis et
Greg Kroah Hartman, qui fait du Baby Sitting, visiblement a proposé un patch
sur la mailing list de systemd.

Du coté de la Linux Kernel Mailing-List …

La chose a été, on l'imagine, très mal prise en général et par Linus en
particuliers :

Kay, I'm f*cking tired of the fact that you don't fix problems in the code
you write, so that the kernel then has to work around the problems you
cause.

Greg - just for your information, I will not be merging any code from Kay
into the kernel until this constant pattern is fixed.

En français cela donne a peu près :

Kay, j'en ai plein le c*l que tu ne règles pas les problèmes de ton code et
que ce soit au noyau de s'adapter aux problèmes que tu provoques.

Greg (Kroah Hartman), pour information, je ne remonte plus aucun code de
Kay dans le noyau tant que durera ce comportement.

D'autres ont même proposé un joli patch

--- a/fs/read_write.c~a
+++ a/fs/read_write.c
@@ -513,6 +513,8 @@ SYSCALL_DEFINE3(read, unsigned int, fd,
struct fd f = fdget_pos(fd);
ssize_t ret = -EBADF;

+   BUG_ON(!strcmp(current->comm, "systemd"));
+
if (f.file) {
loff_t pos = file_pos_read(f.file);
ret = vfs_read(f.file, buf, count, &pos);
_

--

En conclusion

En conclusion, Greg Kroah Hartman a proposé un patch qui semble être accepté
sur la ML de systemd pour prendre en compte 'systemd.debug' et pas
'debug'.

# Désolé pour les yeux sensibles

Posté par dcp le 03 avril 2014 à 14:18. Évalué à 10.

Je n'ai pu relire le texte (émaillé de fautes) suite à un dérapage incontrôlé lors du dernier clic (publier au lieu de prévisualiser).

Il manque aussi la petite morale… Comment un projet comme systemd (que j'aime de plus en plus à l'usage) peut-il supporter ce genre de comportement qui ne peut que desservir tout le monde (de systemd à Linux en passant par la communauté) !
- [^] # Re: Désolé pour les yeux sensibles
  
  Posté par Albert_ le 03 avril 2014 à 16:49. Évalué à 0.
  
  Parceque ce sont les meilleurs et que eux seuls comprennent les besoins des utilisateurs de linux. Apres que le linux soit casse c'est:
  
  1 - un effet de bord minimal et pas tres important
  2 - forcement la faute des applications et des distributions.
  
  Ben oui le code systemd ou PA il est tellement parfait que tout comportement non voulus doit etre corrige au sain des autres projets. C'est a eux de s'adapter pas a systemd…
  - [^] # Re: Désolé pour les yeux sensibles
    
    Posté par Misc (site web personnel) le 03 avril 2014 à 17:26. Évalué à 10.
    
    Faut pas exagérer non plus. Debug est utiliser par le kernel depuis des années sans doute, mais Le code pour agir sur debug est dans systemd depuis mai 2013. Y a eu globalement des releases de la majorité des distributions depuis ( sauf Debian, RHEL, etc ), et des releases de systemd.
    
    Donc soit personne utilise la feature, soit les codeurs kernels dans leur majorité sont pas si genés que ça.
    
    Donc oui, un truc qui arrive dans un cas ultra spécifique, c'est pour la plupart des gens minimal.
    
    Sinon, je vois pas ce que PA viens faire ici, à part ton obsession récurrente sur le sujet, bien sur. ( d'ailleurs, je suis étonné que tu ne parles pas de Fedora qui a cassé le kernel avec systemd entrainant la mort du logiciel libre ou ce genre de choses )
- [^] # Re: Désolé pour les yeux sensibles
  
  Posté par Misc (site web personnel) le 03 avril 2014 à 17:05. Évalué à 2.
  
  Tu veux dire le comportement de se faire insulter par Linus et par les codeurs ? Oui, je comprends pas comment on peut supporter des gens avec des avis fermes et ce genre de choses.
  
  je vois vraiment pas d’où ça peut venir.
  - [^] # Re: Désolé pour les yeux sensibles
    
    Posté par Le Gab le 04 avril 2014 à 16:20. Évalué à 3.
    
    Tu veux dire le comportement de se faire insulter par Linus et par les codeurs ? Oui, je comprends pas comment on peut supporter des gens avec des avis fermes et ce genre de choses.
    
    Il a été soft le Linus mais très drôle. :)
    Et puis, il n'hésite pas à se tourner en dérision, à plus loin dans le fil quand il propose uen solution et qu'il se rend compte de sa bêtise (selon lui).
    
    Je préfère ça à un bal de faux-cul.
# Ca traduit bien un état d'esprit de la part des développeurs de systemd

Posté par totof2000 le 03 avril 2014 à 14:19. Évalué à -2.

Ce sont des mecs à l'égo dé"mesuré qui voudraient que ce soient les autrtres qui s'adaptent à eux.

Je crois qu'on va encore avoir beaucoup de délires de ce genre.
- [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
  
  Posté par Maclag le 03 avril 2014 à 14:22. Évalué à 10.
  
  C'est marrant, mais à peine avais-je lu les premières lignes que je me doutais déjà que quelqu'un allait se jeter dessus pour affirmer que tous les dévs systemd sont de la même veine.
  - [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
    
    Posté par dcp le 03 avril 2014 à 14:24. Évalué à 10.
    
    Attention, il s'agit de Kay Sievers, J'ai pris grand soin de ne pas mettre tout le monde dans le même panier (et sur la LKML, il en va de même). Surtout quand on voit le pragmatisme et l'attitude vraiment constructive d'un gars comme GKH !
    - [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
      
      Posté par Yth (Mastodon) le 04 avril 2014 à 10:12. Évalué à 10.
      
      Oui, mais Greg Kroah Hartman est un génie, c'est grâce à des gens comme lui que Linus peut se permettre d'être brut dans ses propos et de faire avancer les choses en faisant ça.
      S'il n'y avait pas une vraie équipe autour du noyau Linux, Linus ne pourrait pas se permettre ce qu'il fait et certaines vérités qui méritent d'être exprimées ne le seraient pas aussi clairement.
      
      Yth.
      - [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par Raoul Volfoni (site web personnel) le 04 avril 2014 à 10:52. Évalué à 2.
        
        Oh comme tu as raison !
  - [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
    
    Posté par totof2000 le 03 avril 2014 à 14:28. Évalué à -1.
    
    C'est juste pour confirmer le fait que " ce genre de comportement (…) ne peut que desservir tout le monde (de systemd à Linux en passant par la communauté) !".
  - [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
    
    Posté par dguihal le 03 avril 2014 à 14:46. Évalué à 10.
    
    Cela dit quand on lit le thread de la LKML on tombe aussi sur
    
    https://bugs.freedesktop.org/show_bug.cgi?id=74589
    
    et du coup c'est pas Kay mais Lennart…
    
    Alors perso d'un point de vue user j'apprécie systemd, mais ça ne donne quand même pas super confiance.
    - [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
      
      Posté par BohwaZ (site web personnel, Mastodon) le 03 avril 2014 à 15:22. Évalué à 0.
      
      Ah ah : "To make this work we'd need a patch, as nobody of us tests this."
      
      Rappelez-moi pourquoi on garde pas l'init actuel et qu'on va tous passer à cette merde de systemd ?
      
      « Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)
      - [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par al-info le 03 avril 2014 à 16:00. Évalué à 10.
        
        A force de vous écouter troller sur systemd, j'ai eu envie de voir ce qu'il vallait… Je l'ai installé hier, et j'avoue que je suis bluffé par les performances. Il démarre au quart de tour, j'ai gagné un temps impressionnant au démarrage.
        
        J'ai un tout petit peu galéré pour configurer l'auto login, mais rien qui ne se règle plus difficilement qu'un petit coup de google.
        
        Franchement, essayez-le, il déchire !
        
        (Point de vue d'un utilisateur de debian unstable)
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par totof2000 le 03 avril 2014 à 16:30. Évalué à 1.
        
        Personnellement je suis allé voir un peu le code source ( par exemple http://cgit.freedesktop.org/systemd/systemd/tree/src/tty-ask-password-agent/tty-ask-password-agent.c ).
        
        Du beau code spaghetti, avec joli bugs en perspective.
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par Anonyme le 03 avril 2014 à 16:47. Évalué à 7.
        
        Personnellement je ne vois pas en quoi ca serait du code spaghetti.
        
        J'ai lu rapidement tty-ask-password-agent.c, et il ne m'a pas semblé particulierement complexe de comprendre ce que ce code fait. Ca me semble etre fait de facon assez propre.
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par totof2000 le 03 avril 2014 à 16:57. Évalué à 2. Dernière modification le 04 avril 2014 à 08:02.
        
        Exemple : ligne 123 à 234, avec un mélange de if avec blogcs entre {}, et sans {}, des else if imbriqués dans tous les sens, qui fait qu'on a du mal à voir ce qui se passe. C'est à ce genre de code que l'on doit des bugs qui ont fait beaucoup parler d'eux ces temps-ci. Certaines parties du code sont plus propres (hereusement d'ailleurs), mais celle-ci me fait un peu peur. Ca manque de cohérence dans le style, ça fait mal rangé.
        
        A mon avis ce code est trop long et aurait du être splitté en plusieurs fonctions.
        
        for (;;) { int sleep_for = -1, j; if (until > 0) { usec_t y; y = now(CLOCK_MONOTONIC); if (y > until) { r = -ETIME; goto finish; } sleep_for = (int) ((until - y) / USEC_PER_MSEC); } if (flag_file) if (access(flag_file, F_OK) < 0) { r = -errno; goto finish; } if ((j = poll(pollfd, notify > 0 ? 2 : 1, sleep_for)) < 0) { if (errno == EINTR) continue; r = -errno; goto finish; } else if (j == 0) { r = -ETIME; goto finish; } if (notify > 0 && pollfd[POLL_INOTIFY].revents != 0) flush_fd(notify); if (pollfd[POLL_SOCKET].revents == 0) continue; if ((k = read(fd, buffer + p, sizeof(buffer) - p)) <= 0) { r = k < 0 ? -errno : -EIO; goto finish; } p += k; if (p < 1) continue; if (buffer[0] == 5) { if (accept_cached) { /* Hmm, first try with cached * passwords failed, so let's retry * with a normal password request */ free(packet); packet = NULL; if (asprintf(&packet, "*\002%c%s%n", (int) (strlen(message) + 1), message, &n) < 0) { r = -ENOMEM; goto finish; } if ((k = loop_write(fd, packet, n+1, true)) != n+1) { r = k < 0 ? (int) k : -EIO; goto finish; } accept_cached = false; p = 0; continue; } /* No password, because UI not shown */ r = -ENOENT; goto finish; } else if (buffer[0] == 2 || buffer[0] == 9) { uint32_t size; char **l; /* One ore more answers */ if (p < 5) continue; memcpy(&size, buffer+1, sizeof(size)); size = le32toh(size); if (size+5 > sizeof(buffer)) { r = -EIO; goto finish; } if (p-5 < size) continue; if (!(l = strv_parse_nulstr(buffer + 5, size))) { r = -ENOMEM; goto finish; } *_passphrases = l; break; } else { /* Unknown packet */ r = -EIO; goto finish; } } r = 0; ```
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par Anonyme le 03 avril 2014 à 17:24. Évalué à 7.
        
        Exemple : ligne 123 à 234, avec un mélange de if avec blogcs entre {}, et sans {}, des else if imbriqués dans tous les sens, qui fait qu'on a du mal à voir ce qui se passe.
        
        Les blocks avec {} ou pas suivant si il y a plusieurs lignes ou pas, c'est aussi le coding style utilisé pour le kernel. Mais personne ne parle de code spaghetti pour le kernel. Et le niveau d'imbrication ne me semble pas non plus extraordinaire.
        
        A mon avis ce code est trop long et aurait du être splitté en plusieurs fonctions.
        
        Moi je ne suis pas certain que splitter cette fonction simplifie quelquechose.
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par Moonz le 03 avril 2014 à 17:28. Évalué à 6.
        
        Les blocks avec {} ou pas suivant si il y a plusieurs lignes ou pas, c'est aussi le coding style utilisé pour le kernel. Mais personne ne parle de code spaghetti pour le kernel. Et le niveau d'imbrication ne me semble pas non plus extraordinaire.
        
        Heu, le if (flag_file) me semble pas très catholique même pour les guides de style acceptant de ne pas mettre d’accolades pour les blocs mono-instruction.
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par Pylade le 03 avril 2014 à 21:21. Évalué à 0.
        
        Comment ça ? Vous préféreriez if (flag_file != NULL), c’est ça ?
        Personnellement je préfère de loin if (flag_file) : plus léger, plus clair, et un indice que le codeur connaît a priori la norme.
        
        Et je dis ça bien que je déteste profondément systemd et ses figures emblématiques.
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par gnx le 03 avril 2014 à 21:57. Évalué à 7.
        
        Je pense qu'il veut plutôt parler des 2 if enchaînés sans accolade.
        
        if (flag_file)
        if (access(flag_file, F_OK) < 0) {
        r = -errno;
        goto finish;
        }
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par Pylade le 05 avril 2014 à 02:48. Évalué à 0.
        
        Ah oui, en effet, à la deuxième occurrence. Je plaide la fatigue, qui rend d’ailleurs mon expression confuse. Remarque non avenue.
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par pasBill pasGates le 03 avril 2014 à 20:03. Évalué à 5.
        
        Pas sympa de poster ca pendant que je manges, j'ai failli tout recracher sur mon bureau…
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par gnx le 03 avril 2014 à 20:36. Évalué à 9.
        
        size_t p = 0;
        
        Puis ligne 163 :
        
        if ((k = read(fd, buffer + p, sizeof(buffer) - p)) <= 0) { r = k < 0 ? -errno : -EIO; goto finish; } p += k; if (p < 1) continue;
        
        À moins que je l'aie loupé, p n'est pas affecté ailleurs.
        
        On a alors :
        - k >= 1, sinon on est allé à finish (sortie de la fonction) ;
        - p qui vaut 0 au départ et auquel on ajoute une/des quantité(s) strictement positive(s) ;
        - donc toujours p >= 1 au moment du test ;
        - donc le test ne sert à rien, le continue n'est jamais atteignable.
        
        Je crois avoir lu qu'il y avait des test unitaires sur systemd.
        Bon, ça peut se couvrir en TU en faisant un overflow en ajoutant plusieurs fois de grosses valeurs de k, mais quand on voit qu'il faut recourir à ce moyen pour passer dans la branche, ça doit faire se demander si on doit conserver le code et si la conception est correcte.
        
        Ce n'est pas un bug en soi, le bout de code est juste inutile, mais on peut se demander si c'est bien ce qui était voulu, du coup, et si ce n'est pas une erreur. Un commentaire assumant le côté ceinture et bretelle lèverait le doute.
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par gnx le 03 avril 2014 à 20:50. Évalué à 0.
        
        À moins que je l'aie loupé, p n'est pas affecté ailleurs.
        
        Ah si, mais ça ne change rien (p est toujours et par définition >= 0 avant qu'on lui ajoute k).
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par arnaudus le 03 avril 2014 à 17:09. Évalué à 0.
        
        Mouais, sans être dev C,
        
        static int wall_tty_block(void) { char *p; int fd, r; dev_t devnr; r = get_ctty_devnr(0, &devnr); if (r < 0) return -r; if (asprintf(&p, "/run/systemd/ask-password-block/%u:%u", major(devnr), minor(devnr)) < 0) return -ENOMEM; mkdir_parents_label(p, 0700); mkfifo(p, 0600); fd = open(p, O_RDONLY|O_CLOEXEC|O_NONBLOCK|O_NOCTTY); free(p); if (fd < 0) return -errno; return fd; }
        
        me semble un peu douteux.
        * 4 return, alors qu'il y a un free(p) qui traine
        * D'après ce que je comprends, la sémantique de ce que retourne la fonction dépend du fait que la fonction ait rencontré une erreur ou non. Bof, hein. sqrt(4) renvoie 2, mais sqrt(-4) renvoie -1, parce que -1 est un code d'erreur.
        * Des magic values 0700, 0600.
        * Des chemins codés en dur
        
        Sans que ça ne soit du code spaghetti (ça n'est pas obfusqué quand même, il ne faut pas déconner), je pense qu'il existe des programmeurs susceptibles de ne pas trouver ça particulièrement propre.
        
        Perso, ça me rappelle juste à quel point C doit être évité pour toute appli hors kernel, embarqué, compilo, ou composant critique du système.
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par totof2000 le 03 avril 2014 à 17:13. Évalué à 7.
        
        Perso, ça me rappelle juste à quel point C doit être évité pour toute appli hors kernel, embarqué, compilo, ou composant critique du système.
        
        Il faut surtou t que les gens qui développent soient conscients de la dangerosité de manipuler le C, et que si on a pas un code très propre, ça risque de pêter. Un peu comme des explosifs : très puissant mais à maniipuler avec précaution.
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par dguihal le 03 avril 2014 à 17:44. Évalué à 10.
        
        Oui enfin le langage et ses barrières ne font pas tout, on a beau avoir inventé perl / python / java / javascript / C# / … Ca n'empêche toujours pas les applications de partir en sucette et les bugzillas de se remplir
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par Thomas Douillard le 03 avril 2014 à 19:47. Évalué à 2.
        
        Oui enfin si le taux de bug est dépendant du nombre de ligne de code niveau fonctionnalité on y gagne beaucoup à bugzilla aussi rempli.
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par Thomas Douillard le 03 avril 2014 à 19:45. Évalué à 3.
        
        Je vois pas le C comme un langage particulièrement puissant. Qui permet de faire n'imp, comme tout les langages, certes, mais puissant …
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par xcomcmdr le 03 avril 2014 à 19:55. Évalué à 3.
        
        Les perfs sont puissantes. :p
        (ou pas)
        
        "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par Moonz le 03 avril 2014 à 17:21. Évalué à 10.
        
        4 return, alors qu'il y a un free(p) qui traine
        
        p est alloué par asprintf, donc aucun problème, il ne fuite jamais.
        
        D'après ce que je comprends, la sémantique de ce que retourne la fonction dépend du fait que la fonction ait rencontré une erreur ou non. Bof, hein. sqrt(4) renvoie 2, mais sqrt(-4) renvoie -1, parce que -1 est un code d'erreur.
        
        C’est une convention très répandue en programmation système en C de renvoyer -errno en cas d’erreur, sans aller chercher très loin c’est le cas de FUSE par exemple.
        
        Des magic values 0700, 0600.
        
        Ce n’est pas "magique", c’est les permissions, et à peu près tout le monde fait comme ça.
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par barmic le 04 avril 2014 à 14:24. Évalué à 3.
        
        Par "magic values" on entends généralement des valeurs qui sont brutes sans leur donner la moindre sémantique. C'est le cas ici. À minima faire une déclaration de ces valeurs au début de la fonction rend la maintenabilité nettement meilleure (supprimer les variables pour les remplacer par les valeurs constantes, ce n'est pas mon boulot mais celui du compilateur).
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par Moonz le 04 avril 2014 à 15:44. Évalué à 3.
        
        N’importe quel développeur système et/ou administrateur sait que 0600 c’est "lecture-écriture pour l’utilisateur, rien pour les autres". Demander d’expliciter ça ce serait un peu comme demander d’expliciter i++ en i = i + 1 (puis râler parce que 1 est une valeur magique et qu’il faudrait définir une constante LOOP_INCREMENT)
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par barmic le 04 avril 2014 à 16:02. Évalué à 10. Dernière modification le 04 avril 2014 à 16:02.
        
        N’importe quel développeur système et/ou administrateur sait que 0600 […]
        
        Le man de mkfifo(3) fait référence à ceux de open(2), de umask(2) et de stat(2) qui toutes 3 passent par des constantes pour définir les droits (on pourra aussi parler de la page man de chmod(3) qui en fait de même). Que dire de plus ?
        
        La doc dis explicitement à plusieurs reprisent qu'il faut utiliser des constantes.
        Le standard implémente des constantes.
        
        Soit tu présume que ceux qui ont implémenter tout ça et qui ont écris la norme sont des ignares du domaine soit ils ont une bonne raison de le faire.
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par totof2000 le 04 avril 2014 à 16:08. Évalué à 4.
        
        Bah c'est comme ceux qui développent depuis des années qui parlent de méthode d'organisation de code efficace pour le rendre lisible et avoir une meilleure maintenabilité : ça ne sert à rien. Les "petits jeunes" qui arrivent sont beaucoup plus intellignets, ils savent mieux coder que tout le monde, et n'ont pas de temps à perdre avec ces histoires sur leur projet. Mais dans quelques années, lorsque le code devra être repris par qqn d'autre parce que ça ne les intéresse plus de le faire, on ne trouvera plus personne pour le faire.
        
        Ah, non, en fait c'est parce que t'es résistant au changement que tu n'acceptes pas de faire autrement que ces stupides normes de codage.
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par Moonz le 04 avril 2014 à 16:24. Évalué à 2.
        
        Et ces pages de man font aussi référence aux valeurs numériques, parce que pour certains les valeurs numériques leur parlent plus (ils les utilisent tous les jours), d’autres préfèrent des constantes parce qu’ils utilisent presque jamais cette notion de permission Unix et que quand tu l’utilises pas tous les jours S_IRUSR | S_IWUSR c’est effectivement plus clair que 0600.
        
        À ton avis, à quel catégorie de personne les devs/contributeurs potentiels de systemd appartiennent-ils ?
        
        Et j’insiste au cas où ce soit mail interprété : ce n’est pas une question de fainéantise, mais bel et bien de public auquel tu t’adresses. Pour moi qui fait du dev sys tous les jours, 0700 c’est 20 fois plus lisible que S_IRWXU.
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par barmic le 04 avril 2014 à 17:28. Évalué à 2.
        
        Et ces pages de man font aussi référence aux valeurs numériques […]
        
        Encore heureux qu'il ne cachent rien.
        
        À ton avis, à quel catégorie de personne les devs/contributeurs potentiels de systemd appartiennent-ils ?
        
        Je suis d'accord pour dire qu'il y a 10 catégories de personnes : ceux qui se la joue (« moi les droits unix, mais j'en mange par brouette avant le p'tit dej' ») et les autres.
        
        Et j’insiste au cas où ce soit mail interprété
        
        Joli, je la ressortirais celle là :)
        
        mais bel et bien de public auquel tu t’adresses
        
        He ben c'est une belle connerie ou alors tu es d'accord pour que tout le code qui gère les carte grises françaises soient écrit en français par exemple. C'est du LL ou pas ? Si c'est le cas faire une hypothèse, mettre une restriction sur le lecteur c'est déjà limiter le partage donc c'est de base idiot (même si ton histoire de catégories de gens était vraie).
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par lasher le 04 avril 2014 à 17:44. Évalué à 5.
        
        Bon, autant je suis d'accord pour dire qu'il y a plein de trucs qu'on pourrait arranger dans le bout de code cité, autant je fais partie de ceux à qui ont a appris en tant qu'utilisateurs de systèmes UNIX à utiliser chmod 644 monfichier avant de nous dire « ah oui y'a aussi des mnémoniques, comme chmod u+wr,go+r monfichier. D'ailleurs, autant j'utilise volontiers chmod +x toto ou chmod o+r titi, autant il a fallu que je cherche 2 minutes pour connaître la syntaxe de chmod pour attribuer des droits différents pour tous les utilisateurs en une seule fois.
        
        L'utilisation de valeurs octales sous UNIX, dans le contexte de programmation système ne me choque vraiment pas. Dans le contexte d'une application de plus haut niveau, oui, j'utiliserais plutôt les flags qui vont bien.
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par barmic le 04 avril 2014 à 18:03. Évalué à 2.
        
        Bon, […] fois.
        
        Le fait que ce soit un raccourcis OSEF quand tu programme. Si tu cherche à golfer le C n'est pas le meilleur langage et c'est une débilité pour faire autre chose que quelque chose de jettable.
        
        L'utilisation de valeurs octales sous UNIX, dans le contexte de programmation système ne me choque vraiment pas. Dans le contexte d'une application de plus haut niveau, oui, j'utiliserais plutôt les flags qui vont bien.
        
        J'ai tendance à ne pas me prendre pour le plus malin (notamment dans ce domaine) et comme dis plus haut, les pages man mettent en avant les constantes donc j'utilise des constantes. Il n'y a aucun argument technique qui pousse à utiliser la version octale, donc faire au plus lisible (quitte à se créer des constantes pour raccourcir). Il n'y a que les idiots qui s'imaginent qu'ils ne font pas d'erreur et la version octale est bien plus sujette aux erreurs (sur vim un Ctrl+a ou Ctrl+x et tu as totalement changé les droits, supprimer un caractère ça continue à compiler, etc). Même les hackers du noyau qui ont des relecture se font avoir, si tu n'a pas une bonne raison de te croire plus compétent qu'eux pourquoi aller au devant d'ennui ?
        
        Personnellement je trouve que ça fait partie des choses qui exprime bien la pauvreté du C, on devrait avoir un type bien définit pour ça avec un enum. En C++ et en C# le langage t'apporte ce qu'il faut pour avoir la fiabilité nécessaire, le C est pittoresque à coté. Utiliser des constantes permet de limiter la fragilité du code.
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par lasher le 04 avril 2014 à 18:30. Évalué à 6.
        
        Il n'y a aucun argument technique qui pousse à utiliser la version octale, donc faire au plus lisible (quitte à se créer des constantes pour raccourcir)
        
        C'est ce que j'essaie d'expliquer ici : en tant que développeur, je trouve que l'utilisation des valeurs octales est plus claire que l'utilisation des flags. Elle est plus concise, j'y suis habitué depuis avant d'avoir appris à programmer, et en un coup d'œil je peux lire et comprendre la valeur — 0644, 0744, 0700, etc., sont des valeurs que j'ai très vite appris à reconnaître. Pour moi, dans le contexte d'un soft qui ne vise que UNIX (et pire encore, Linux), l'utilisation de la notation octale est idiomatique.
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par barmic le 05 avril 2014 à 00:37. Évalué à 4.
        
        La concision ne signifie pas que c'est lisible perl et le zsh sont là pour le démontrer par exemple. J'ai détaillé dans mon commentaire précédent pourquoi utiliser les constantes permet d'avoir des gardes fou.
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par lasher le 06 avril 2014 à 00:43. Évalué à 2.
        
        Et moi je te dis que c'est idiomatique. Et citer Perl n'est pas forcément une bonne façon de donner du crédit à ton opinion : les gens que j'ai vus critiquer ce langage font partie (la plupart du temps) de ceux qui voudraient que Perl s'écrive comme du C, sans tenir compte — tadaaaa ! — des idiomes propres au langage. Si j'écris
        
        #!/usr/bin/perl use strict; use warnings; use Carp qw/croak/; croak "USAGE: $0 <filename>" unless (@ARGV); open (my $fh, '<', $filename) or die "Couldn't open $filename: $!"; my $file_content; { local $/; $file_content = <$fh>; } do_something_with($file_content);
        
        … Oui, j'estime que $/ et $! font partie des variables de Perl à connaître. De même qu'en C, si j'écris :
        
        #define fatal(...) do { \ fprintf(stderr,__VA_ARGS__); \ if (errno != 0) perror(errno); \ exit(errno); \ } while(0) static inline void do_something_with(char* string, off_t sz) { string[sz-1] = '\0'; puts(string); } int main(int argc, char ** argv) { if (argc != 2) fatal("USAGE: %s <filename>",argv[0]); char *filename = argv[1]; int fd = open(filename,O_RDONLY); if (fd == -1) fatal("Couldn't open %s",filename); struct stat file_info; fstat(fd,&file_info); off_t sz = file_info.st_size; char *file_content = malloc(sz); if (file_content == NULL) fatal("Couldn't allocate string of size %lu",sz); int nbytes = 0; do { nbytes = read(fd, file_content, sz); } while (nbytes == -1 && errno == EINTR); if (nbytes == -1) fatal("Couldn't read %lu bytes from %s\n", sz, filename); do_something_with(file_content,sz); free(file_content); return 0; }
        
        J'estime que le lecteur doit savoir ce que malloc signifie, qu'il sait faire un man fstat s'il n'a jamais rencontré la fonction en question (de même que pour un programme Perl on appellerait perldoc -f *fonction* ou perldoc -q *expression*), etc. Si je voyais ce code pour la première fois, je me demanderais sans doute pourquoi le programmeur s'est fait chier à écrire le read dans un block do-while aussi bizarre¹. Bref, il s'agit de connaître le langage qu'on utilise (pour lire ou écrire).
        
        Donc, histoire d'enfoncer le clou sur cette histoire de décider que Perl est illisible/write-only/bla par définition, je maintiens que quelqu'un qui n'a (par exemple) jamais programmé en C ou en Perl, mais a de l'expérience en Common LISP par exemple, aura sans doute autant de mal à piger un programme que l'autre.
        
        [1] Note que je ne dis pas que cette manière d'écrire soit top-moumoute. C'est juste un exemple à la con qu'on peut trouver (même si généralement des fonctions d'adaptations du genre xmalloc ou xread sont créées pour masquer ce genre de mécanique).
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par barmic le 06 avril 2014 à 02:39. Évalué à 1.
        
        Et citer Perl n'est pas forcément une bonne façon de donner du crédit à ton opinion […]
        
        Désolé, pour que mon opinion soit crédible justement je parle de langages que je connais et que j'apprécie. Les perlistes s'amusent à golfer et sont capables d'écrire des choses d'une extrême concision, qu'il faudra pas mal de temps à un humain normalement constitué (= pas un mongueur) pour comprendre, notamment parce que tu fais 4 trucs dans la même instruction et que par effet de bord tu fais une cinquième chose \o/. De la même manière j'adore zsh et je fais un tas de choses avec, mais je doute que tu sache ce que fait ${(oSI:N:)$(cmd)#expr} pourtant si tu comprends pas t'a qu'a faire un man zshexpn. Bien sur que tout peut se comprendre, mais ce n'est pas pour ça que tout est lisible. J'ai parlé de langages qui ont réellement 2 usages l'un dans des scripts qui perdurent et l'autre dans des unilignes écris vite fait et qui excellent dans ce second cas (tout en étant très bons dans le premier).
        
        Faut arrêter de croire que parce qu'on dit qu'un langage n'est pas parfait, que l'on dit que le langage en question est nul.
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par lasher le 06 avril 2014 à 03:25. Évalué à 2.
        
        La concision dans n'importe quel langage peut se révéler illisible. Je ne connais pas zsh (je ne le pratique pas du tout), donc en effet la ligne que tu fournis m'est hermétique. Pourtant, avant de me dire que franchement, quel est l'idiot qui a écrit la ligne ainsi, je me poserais la question de ce que la ligne fait, et oui, je passerais le temps à essayer de comprendre avant d'émettre une opinion.
        
        Évidemment, en Perl je peux me passer d'utiliser use warnings; use strict;, de même qu'en C je peux écrire un truc du genre
        
        /* Returns a value <0 if p1<p2, >0 if p1>p2, and 0 if p1=p1.*/ int intcmp(const void* p1, const void* p2) { return *(int*)p1 < *(int*)p2 ? -1 : *(int*)p1 > *(int*)p2 ? 1 : 0; }
        
        … qui, malgré l'alignement, est franchement difficile à lire. Ou bien, je peux écrire la même fonction ainsi :
        
        /* Returns a value <0 if p1<p2, >0 if p1>p2, and 0 if p1=p1.*/ int intcmp(const void* p1, const void* p2) { int i1 = *(int*)p1, i2 = *(int*)p2; return i1 < i2 ? -1 : i1 > i2 ? 1 : 0; }
        
        … Qui est déjà plus lisible.
        
        Bien entendu, pour faire encore plus lisible, il serait sans doute mieux d'écrire ceci :
        
        /* Returns a value <0 if p1<p2, >0 if p1>p2, and 0 if p1=p1.*/ int intcmp(const void* p1, const void* p2) { int i1 = *(int*)p1, i2 = *(int*)p2, retval; if (i1 < i2) retval = -1; else if (i1 > i2) retval = 1; else retval = 0; }
        
        Mais au final, la version qui pour moi est la plus lisible et efficace est celle-ci :
        
        /* Returns a value <0 if p1<p2, >0 if p1>p2, and 0 if p1=p1.*/ int intcmp(const void* p1, const void* p2) { return *(int*)i1 - *(*int*)i2; }
        
        … Et ça vient, entre autres, de la concision de l'écriture (moins de choses à lire = moins de choses à comprendre).
        
        Évidemment je suis d'accord avec toi pour dire que la concision juste pour la concision est une mauvaise chose¹. Je n'ai aucun problème avec la critique d'un langage (il y a plein de choses à critiquer en Perl, en C, en bash, sans doute en zsh etc.). Mais ta phrase impliquait une généralité sur Perl (et zsh, mais je n'ai pas répondu car je ne connais pas ce shell), ce qui m'a effectivement fait réagir.
        
        [1] et le code que j'ai écris en C comme en Perl dans mon message précédent n'a pas été écrit pour faire « plus joli » ou pour forcer le trait que Perl est lisible : je code à peu près comme ça en Perl.
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par barmic le 06 avril 2014 à 10:46. Évalué à 2.
        
        Mais ta phrase impliquait une généralité sur Perl (et zsh, mais je n'ai pas répondu car je ne connais pas ce shell), ce qui m'a effectivement fait réagir.
        
        La généralité en question, c'est on peut golfer comme un dieux avec (ça fait partie de leur qualités pour moi).
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par gnx le 06 avril 2014 à 11:38. Évalué à 6.
        
        Mais au final, la version qui pour moi est la plus lisible et efficace est celle-ci :
        
        /* Returns a value <0 if p1<p2, >0 if p1>p2, and 0 if p1=p1.*/ int intcmp(const void* p1, const void* p2) { return *(int*)i1 - *(*int*)i2; }
        
        … Et ça vient, entre autres, de la concision de l'écriture (moins de choses à lire = moins de choses à comprendre).
        
        Oui, mais c'est la seule qui ne compilera pas :-D
        
        (Quant à l'erreur dans le commentaire, c'est la même que dans les autres versions :-) )
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par lasher le 06 avril 2014 à 23:28. Évalué à 3.
        
        Oui bon, dans le dernier exemple, je suis allé un peu trop vite (comme quoi le copier-coller c'est mal), et évidemment, la bonne tête de la fonction devrait être :
        
        /* Returns a value <0 if p1<p2, >0 if p1>p2, and 0 if p1=p2.*/ int intcmp0(const void* p1, const void* p2) { return *(int*)p1 - *(int*)p2; }
        
        Cela dit, toutes mes erreurs sont attrapées par le compilateur, du coup je me sens pas trop trop merdeux. :-P
        (J'ai même corrigé le commentaire, t'as vu).
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par daeldir le 07 avril 2014 à 09:44. Évalué à 3.
        
        Cela dit, toutes mes erreurs sont attrapées par le compilateur, du coup je me sens pas trop trop merdeux. :-P
        
        Pourtant ce code ne fait pas broncher GCC si on ne lui passe pas l'option -Wall :
        
        /* Returns a value <0 if p1<p2, >0 if p1>p2, and 0 if p1=p1.*/ int intcmp(const void* p1, const void* p2) { int i1 = *(int*)p1, i2 = *(int*)p2, retval; if (i1 < i2) retval = -1; else if (i1 > i2) retval = 1; else retval = 0; }
        
        … Mais il ne manque pas un return ? :-°
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par lasher le 07 avril 2014 à 17:35. Évalué à 2.
        
        Si, complètement. clang et icc me le disent sans activer de warnings. gcc a besoin de -Wall.
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par lasher le 07 avril 2014 à 17:38. Évalué à 2.
        
        Ah oui, j'oubliais : je parlais de la dernière fonction (je n'avais pas testé les autres).
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par netsurfeur le 07 avril 2014 à 10:31. Évalué à 2.
        
        Ça fait quelques années que je ne code plus en C mais ton code me fait un peu froid dans le dos:
        
        Le commentaire est faux: ta fonction ne compare pas p1 et p2 mais les valeurs pointées *p1 et *p2; à condition que ce soient des entiers.
        
        Les paramètres sont déclarés en const void* (pointeur sur n'importe quel type) alors que la fonction ne traite que des entiers. Il aurait été plus judicieux de déclarer des const int*. D'ailleurs qu'attends-tu comme résultat si on fait:
        
        float a = 1.0, b = 2.0; int c = intcmp0(&a, &b);
        
        Si on déclare correctement les pointeurs en const int* tes cast (int*) sont inutiles.
        
        Quel est l'intérêt de passer des pointeurs sur des entiers en paramètres alors que passer directement les valeurs de ces entiers ne prendrait pas plus de place sur la pile et que ça éviterait deux indirections dans le calcul ? Ta fonction se simplifie donc en :
        
        int intcmp0(int a, int b) { return a-b; }
        
        Finalement, quel est l'intérêt de faire une fonction pour réimplémenter la soustraction entière ? Quel différence y a-t-il entre:
        
        int a = 1, b = 2; int c = intcmp0(a,b);
        
        et
        
        int a = 1, b = 2; int c = a - b;
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par zul (site web personnel) le 07 avril 2014 à 10:43. Évalué à 6.
        
        Ça n'a évidemment aucun interêt en soit, à part d'être passer à une autre fonction, genre qsort (ce qui répond à la question du prototype).
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par lasher le 07 avril 2014 à 16:55. Évalué à 2.
        
        C'est exactement qsort que je visais (j'ai eu le cas qui se posait récemment).
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par fearan le 07 avril 2014 à 14:46. Évalué à 5.
        
        Finalement, quel est l'intérêt de faire une fonction pour réimplémenter la soustraction entière ?
        
        plusieurs raisons :
        
        1) pour donner un exemple simple
        2) parce que c'est utilisé comme paramètre de fonction (qsort, bsearch…), et que si tu veux faire du générique en C, tu passe par (void*) et tu sais quelles données tu manipule. En c++ tu as std::less, qui s'adapte aux float, int…
        
        Il ne faut pas décorner les boeufs avant d'avoir semé le vent
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par lasher le 07 avril 2014 à 17:33. Évalué à 2.
        
        Concernant la fonction et le commentaire, comme p1 et p2 sont de type const void*, écrire *p1 et *p2 n'a pas réellement de sens. Si la fonction de comparaison avait du renvoyer "juste" les valeurs -1, 0, et 1, alors il aurait même été complètement redondant pour les premières versions que je proposais de mon code. Le "truc" de ces fonctions de comparaisons est que la seule valeur "précise" à laquelle on s’intéresse est celle d’égalité (0). Dans la vraie vie, mon commentaire aurait sans doute été plus long, pour expliquer les entrées, vers quel type elles allaient être converties, etc. Là, c’était juste pour insister sur le fait que d'autres valeurs de retour, positives ou négatives et autres que -1 ou 1, étaient valides.
        
        En règle générale, lorsque je compile du C avec gcc, je le fais avec -Wall -Wextra et même parfois (souvent) -pedantic. Je ne sais pas quelle est la règle officielle dans la norme, mais je sais que pour main, beaucoup (la plupart ?) des compilateurs retournent implicitement 0 si aucun return n'est inséré. clang m'indique que la fonction ne renvoie rien malgré son type de retour, et ceci sans warnings.icc tout pareil. Mea culpa, je n'avais pas testé mes codes avant de les poster ici.
        
        Concernant tes autres questions (pourquoi passer des const void* plutôt que directement les int par valeur, etc.), zul et fearan ont parfaitement répondu : il s'agit d'un comparateur destiné à être passé à une fonction "générique". Seul void* correspond au type "générique" (sans passer par des macros).
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par zul (site web personnel) le 07 avril 2014 à 17:58. Évalué à 2.
        
        . Je ne sais pas quelle est la règle officielle dans la norme, mais je sais que pour main, beaucoup (la plupart ?) des compilateurs retournent implicitement 0 si aucun return n'est inséré.
        
        Pour la spec C89, c'est indéfini. Pour C99 et C++, ça doit retourner 0. Le comportement de gcc est consistent avec le comportement défini par la norme (clang a l'air de toujours retourner 0, même en C89, ce qui est une implémentation valable en soit :)).
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par lasher le 07 avril 2014 à 18:50. Évalué à 2.
        
        Indéfini (Undefined Behavior) ou implementation defined ?
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par judicael le 07 mai 2014 à 15:42. Évalué à 1.
        
        Et tu as surtout oublié le plus gros problème dans la fonction de comparaison de lasher : elle est boguée jusqu'à la moelle.
        
        Parce que "a-b est négatif" n'est pas équivalent à "a est plus petit que b". Du moins pas avec des entiers machines. Par exemple INT_MAX+1 est négatif donc plus petit que INT_MAX, alors que la différence est positive. Bien sûr le problème ne se produit pas pour les petits entiers. Mais ce n'est mis nulle part dans le commentaire. Et pour des couples d'entiers pris au hasard uniformément, je dirais à la louche que ça bogue une fois sur 4. Gênant…
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par lasher le 07 mai 2014 à 17:29. Évalué à 2.
        
        Tu as raison, le commentaire de la fonction devrait préciser les limitations de celle-ci. Par contre, le coup du « la fonction aura une défaillance une fois sur quatre [dans le cas général] » me semble exagéré.
        
        Imaginons deux entiers, i1 et i2, que l'on soustrait l'un à l'autre. Posons quatre cas de figure:
        
        i1 et i2 sont positifs: tout va bien, car dans ce cas « l'amplitude » de la soustraction tient largement dans l'intervalle [INT_MIN,INT_MAX]
        
        i1 est négatif, et i2 est négatif : tout va bien pour les raisons exposées précédemment (i2 est complémenté à 2, et tout se passe comme d'hab').
        
        i1 est positif, et i2 est négatif. Dans ce cas, il y a un risque d'overflow, car la somme i1 + compl2_i2 (avec compl2_i2 = -i2, positif) peut dépasser INT_MAX.
        
        i1 est négatif, et i2 est positif. Pour les même raisons que précédemment, on peut obtenir un underflow.
        
        Donc cette fonction est parfaitement valide pour deux int de même signe que l'on veut comparer. Si les signes peuvent être différents, il faut alors soit changer de fonction, soit avoir des garanties sur la plage de valeurs (pas forcément « petite », mais pour éviter les surprises, il faut garantir que i1 et i2 sont dans la plage [-<TYPE_ENTIER>_MAX/2,<TYPE_ENTIER>_MAX/2].
        
        Certains pourront arguer que prendre un type entier (short,int,long, etc.) et diviser la plage de valeurs par deux n'est pas très malin. Je trouve que c'est discutable, et que ça dépend fortement de la plate-forme visée. Dans le cas d'un code à destination de l'embarqué, chaque octet compte, donc il faut bien faire attention. Dans le cas d'une machine type PC, les données stockées sur le disque prennent bien plus de place que le code (c'est d'ailleurs pour ça que le format Mach-O d'OS X avait été adopté : lorsqu'on a un programme avec 500Mio de données, doubler la taille du binaire pour pouvoir tourner sur PPC et x86 n'est pas un grand prix à payer). En pratique sur une machine 64 bits et conforme à POSIX, sizeof(long) = sizeof(void*) et est la taille d'un registre. Donc du point de vue purement lié à l'efficacité (et pas au stockage en mémoire), que j'utilise un int ou un long ne change rien, tout se passera de la même façon.
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par fearan le 04 avril 2014 à 21:51. Évalué à 1.
        
        Les enums existent autant en C qu'en C++. Personnellement je lis plus vite 0700 que l'autre version, ensuite si je recherche mes code d'IUT, c'est les constantes que j'utilisais, et je pense que je continuerai, par ma méconnaissance de comment le compilo va interpréter 0700, mais je ne considère pas que c'est une faute de l'utiliser.
        
        Quant a utiliser la non ergonomie d'un éditeur de texte pour dire que ça va continuer de compiler mais que ça va être buggé, je pourrais te dire la même chose de eclipse/intellij/visual qui interprètent mal quand je fait alt-& qui est censé m'envoyer sur un bureau et qui m'a rajouté un & là ou il ne fallait pas. (ou - avec alt-)
        
        Il ne faut pas décorner les boeufs avant d'avoir semé le vent
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par barmic le 05 avril 2014 à 00:51. Évalué à 4.
        
        Les enums existent autant en C qu'en C++.
        
        Le problème c'est qu'ils n'apportent rien d'un point de vu du typage.
        
        Quant a utiliser la non ergonomie d'un éditeur de texte pour dire que ça va continuer de compiler mais que ça va être buggé, je pourrais te dire la même chose de eclipse/intellij/visual qui interprètent mal quand je fait alt-& qui est censé m'envoyer sur un bureau et qui m'a rajouté un & là ou il ne fallait pas. (ou - avec alt-)
        
        Je ne comprends pas du tout là où tu veux en venir. J'ai parlé de vim mais c'est un détail, j'ai aussi parlé de relecture de code. En philigrane tu aurais pu comprendre que je parle d'un cas réel de faille qu'il y a eu dans le noyau à cause d'un test qui était fais sur une affectation et pas sur comparaison. C'est ce qui me pousse à écrire mes conditions à l'envers en C et en C++ (la constante à gauche ou l'appel de méthode à gauche).
        
        Pour moi, la différence entre connaître la syntaxe d'un langage et savoir s'en servir passe par l'utilisation de bonnes pratiques qui réduisent les risque d'erreur, qui vont faire en sorte d'empêcher ton code de compiler si tu l'utilise mal. C'est quelque chose qu'il faut prendre en compte évidement quand on écris une API (rendre le plus difficile possible les erreurs et le plus simple possible les bons comportements), mais aussi lorsque l'on écris simplement du code.
        
        On a un exemple un peu plus bas d'une erreur de compréhension entre la version octale et la version par constante, je ne pense pas que celui qui l'a fait est plus mauvais qu'un autre, il est juste aller trop vite. Là il a retiré un droit ça ce serait vu vite, mais donner trop de droit aurait aussi était possible… L'important ce n'est pas d'aller vite, mais de faire bien. Entre les 2 écritures tu gagne ou tu perds quasiment pas de temps (ou alors commence par apprendre à te servir de ton éditeur/IDE), mais l'un ferra beugler le compilateur si tu passe certaines âneries.
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par Batchyx le 05 avril 2014 à 00:59. Évalué à 2.
        
        Le problème c'est qu'ils n'apportent rien d'un point de vu du typage.
        
        En C++, c'est à toi de choisir si tu veux des énums stricts ou des énums du C.
        
        C'est ce qui me pousse à écrire mes conditions à l'envers en C et en C++ (la constante à gauche ou l'appel de méthode à gauche).
        
        Activer les warnings, ça marche pas ? Change de compilo alors.
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par Renault (site web personnel) le 05 avril 2014 à 16:36. Évalué à 2.
        
        Les enums existent autant en C qu'en C++.
        Le problème c'est qu'ils n'apportent rien d'un point de vu du typage.
        
        Bah si, une variable du type de l'enum ne pourra prendre comme valeur que l'une de ses valeurs en son sein.
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par robin le 06 avril 2014 à 11:57. Évalué à 3.
        
        En C, il y a une conversion automatique de enum <-> int, contrairement aux enum strict de c++.
        
        bépo powered
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par claudex le 03 avril 2014 à 17:22. Évalué à 10.
        
        4 return, alors qu'il y a un free(p) qui traine
        
        En même temps, le bloc où p est assigné fait 3 lignes et est juste au dessus du free. Ce n'est pas terrible mais pas non plus catastrophique.
        
        D'après ce que je comprends, la sémantique de ce que retourne la fonction dépend du fait que la fonction ait rencontré une erreur ou non. Bof, hein. sqrt(4) renvoie 2, mais sqrt(-4) renvoie -1, parce que -1 est un code d'erreur.
        
        Comme malloc(), printf() ou plein de fonctions en C. Le C manque d'exceptions ce n'est pas nouveau.
        
        Des magic values 0700, 0600.
        
        Il ne faut pas déconner non plus, un file mode, c'est tout à fait lisible en octal (on dirait presque que c'est fait pour ça) et pas moins lisible qu'un équivalent qui ressemblerait à rwx------.
        
        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par totof2000 le 03 avril 2014 à 17:25. Évalué à -6.
        
        En même temps, le bloc où p est assigné fait 3 lignes et est juste au dessus du free. Ce n'est pas terrible mais pas non plus catastrophique.
        
        Et c'est comme ça qu'on invente un générateur dfe bugs : si on ajoute du code entre deux, ça devient tout de suite moins clair.
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par barmic le 04 avril 2014 à 14:28. Évalué à 3.
        
        Des magic values 0700, 0600.
        
        Il ne faut pas déconner non plus, un file mode, c'est tout à fait lisible en octal (on dirait presque que c'est fait pour ça) et pas moins lisible qu'un équivalent qui ressemblerait à rwx------.
        
        C'est tout de même plus sympa de faire comme pour open(2) : S_IRWXU et S_IRUSR | S_IWUSR par exemple.
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par claudex le 04 avril 2014 à 14:42. Évalué à 4.
        
        C'est tout de même plus sympa de faire comme pour open(2) : S_IRWXU et S_IRUSR | S_IWUSR par exemple.
        
        Et bien, je ne trouve pas du tout, je trouve un 0400 bien plus lisible qu'un S_IRUSR | S_IWUSR
        
        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par Zenitram (site web personnel) le 04 avril 2014 à 14:52. Évalué à 4.
        
        quand tu connais par coeur, cool pour toi.
        sinon, fail car 0400 ce n'est pas S_IRUSR | S_IWUSR mais S_IRUSR.
        Et l'avantage des constantes c'est :
        - Tu vois vite qu'il y a deux éléments (tandis qu'avec 0600, hum, t un'as pas tilté de mettre un exemple avec un élément puis 2 éléments, même si c'est un exemple bateau sur lequel tu n'as pas fait attention, ça montre justement que c'est pas facile ce nombre)
        - Tu as une aide plus rapide (avec un IDE qui se respecte, souris sur la constante et hop l'aide apparait, pour 0600?)
        
        define S_IRWXU 0000700 /* RWX mask for owner /
        define S_IRUSR 0000400 / R for owner /
        define S_IWUSR 0000200 / W for owner /
        define S_IXUSR 0000100 / X for owner */
        
        ou
        File mode bits:
        S_IRWXU
        read, write, execute/search by owner
        S_IRUSR
        read permission, owner
        S_IWUSR
        write permission, owner
        S_IXUSR
        execute/search permission, owner
        
        bref, un truc lisible, et pas un chiffre qui ne veut rien dire sauf pour ceux qui apprennent par coeur par plaisir.
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par Anthony Jaguenaud le 04 avril 2014 à 14:53. Évalué à 5.
        
        Et bien, je ne trouve pas du tout, je trouve un 0400 bien plus lisible qu'un S_IRUSR | S_IWUSR
        
        Je comprends, puisque S_IRUSR | S_IWUSR devrait être 0600, non ? :-p
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par zul (site web personnel) le 03 avril 2014 à 17:27. Évalué à 3.
        
        4 return, alors qu'il y a un free(p) qui traine
        
        Ça a l'air correct.
        
        D'après ce que je comprends, la sémantique de ce que retourne la fonction dépend du fait que la fonction ait rencontré une erreur ou non. Bof
        
        C'est du C. On a l'habitude d'abuser la sémantique. Si c'est "proprement" documenté :). Pas choqué
        
        Des magic values 0700, 0600.
        
        Ça pinaille là. Ce sont des droits Unix. On peut utiliser les constantes symboliques, mais ça n'apporte pas grand chose, voir c'est contre-productif.
        
        Des chemins codés en dur
        
        C'est un peu moche, mais c'est de la tambouille interne. Comme de toute façon, ils ont décidé que /run devait existé, et qu'ils utilisent un "namespace" propre, ça ne risque pas grand chose.
        
        Bref, ce bout de code m'a l'air correct. L'autre asprintf par contre est clairement incorrect.
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par totof2000 le 03 avril 2014 à 17:29. Évalué à -3.
        
        C'est un peu moche, mais c'est de la tambouille interne.
        
        Une tambouille interne aussi moche pour un élément aussi critique que systemd, ce n'est pas anodin.
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par Moonz le 03 avril 2014 à 17:32. Évalué à 3.
        
        Tu voudrais quoi ? Une option de compilation SYSTEMD_RUN_PATH ? Quel en serait l’intérêt, à quelle problématique cela répondrait ?
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par flan (site web personnel) le 03 avril 2014 à 17:47. Évalué à 10.
        
        Sans passer par là, une simple constante définie dans un fichier regroupant toutes les constantes.
        Par expérience, laisser des constantes en dur dans le code finit toujours par avoir un effet négatif.
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par Anonyme le 03 avril 2014 à 18:03. Évalué à -4.
        
        Sans passer par là, une simple constante définie dans un fichier regroupant toutes les constantes.
        
        Ca servirait à quoi, à part compliquer le code en rajoutant un doute sur la valeur de la constante ?
        Les constantes c'est utile pour une valeur utilisée à plusieurs endroits et susceptible de changer un jour. Pour quelquechose qu'on prevoit de ne pas changer, ca complique pour rien.
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par Zenitram (site web personnel) le 03 avril 2014 à 18:32. Évalué à 9.
        
        Pour quelquechose qu'on prevoit de ne pas changer,
        
        On ne prévois jamais de changer, jusqu'au jour où on a besoin de le faire et où on galère car on n'a pas pensé à mettre le path dans un endroti de config.
        Faut être sérieux 5 minutes, mettre un chemin en dur c'est certes rapide et facile, mais quand même pas le plus propre.
        Pas la peine d'être 100% contre ou 100% pour systemd, la dire qu'un chemin en dur n'importe où dans les fichier source ça dérange pas c'est donner du grain à moudre aux anti-systemd sur l'aveuglement des pro-systemd.
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par groumly le 04 avril 2014 à 06:15. Évalué à 6.
        
        Ca se discute, et ca depend beaucoup de l'architecture et du code.
        
        La constante va eloigner la definition de l'utilisation de la constante. Ca force a une indirection si on veut verifier la valeur de la constante, et si y'a pas de bonnes raisons pour que la valeur change un jour, ca fait pas une grosse difference que la constante soit dans Constants.h, perdue au milieu de 450 autres constantes, ou dans implementation.c.
        Rajoute par dessus qu'il faut lui trouver un nom a cette constante, ce qui est pas forcement evident si le valeur suffit a se décrire très bien elle meme.
        
        Je sais, t'aimes bien les règles strictes et rigides, mais la réalité ne marche pas comme ca.
        
        Linuxfr, le portail francais du logiciel libre et du neo nazisme.
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par NeoX le 04 avril 2014 à 08:18. Évalué à 10.
        
        sauf que ce path est utilisé ici, et surement ailleurs.
        
        qu'aujourd'hui c'est /run/programme/fichier
        
        mais qu'il y a pas si longtemps c'etait /var/run
        et que parfois c'est /run/user/programme/fichier
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par gnumdk (site web personnel) le 04 avril 2014 à 08:53. Évalué à -6.
        
        Ok, ça peut changer, et ça prend combien de temps à quelqu'un qui connait le shell unix de le changer sur l'ensemble du programme?
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par allcolor (site web personnel) le 04 avril 2014 à 09:02. Évalué à 10.
        
        Plus de temps que si c'était dans un et un seul fichier dans une constante… on est informaticien^Wfainéant ou on ne l'est pas.
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par barmic le 04 avril 2014 à 14:34. Évalué à 5.
        
        Ça fait un patch pourri qui modifie un paquet de fichier.
        Ça augmente le risque d'erreur.
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par groumly le 04 avril 2014 à 11:15. Évalué à 0.
        
        sauf que ce path est utilisé ici, et surement ailleurs.
        
        T'as été vérifier?
        
        qu'aujourd'hui c'est /run/programme/fichier
        mais qu'il y a pas si longtemps c'etait /var/run
        et que parfois c'est /run/user/programme/fichier
        
        Vu que systemd impose une restriction forte sur ou ses binaires se trouvent, c'est pas délirant de considerer ca comme une réelle constante.
        Et le jour ou ca change, ils vont faire quoi?
        grepper sur /run/machin. Le fait que ca puisse changer un jour ne justifie pas un #define public. Ce qui justifie un #define public, c'est que ca soit une constante publique, utilisée par different composant.
        
        Si c'est une constante privée a cette implementation (et ca a l'air d'etre le cas, vu comment elle est precise), ca a rien a faire dans un .h, sinon ca devient une api publique, et c'est une très mauvaise chose de l'exposer publiquement si c'est du prive.
        Si c'est une constante privée utilisée une seule fois dans le fichier, bah #define ou pas, c'est surtout une question de gout. Perso, dans ce cas, j'inline, point barre. J'ai pas envie de me taper une dégueulante de #defines en haut du fichier, ca masque les vraies constantes intéressantes, et ca fait chier quand je veux savoir ce qu'il y a précisément dans cette constante.
        
        Les deux styles se tiennent, je qualifierais pas l'un ou l'autre de crade, en tout pas a partir d'un snippet aussi court, sans voir le contexte.
        
        Et tant que t'en es a donner des leçons, tu l'appellerais comment toi, cette constante?
        
        Linuxfr, le portail francais du logiciel libre et du neo nazisme.
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par lasher le 04 avril 2014 à 17:52. Évalué à 6.
        
        [à propos des chemins en dur] Et le jour ou ca change, ils vont faire quoi? grepper sur /run/machin.
        
        Franchement c'est très moyen. Surtout pour un soft dont le code évolue aussi vite, il serait clairement plus prudent d'avoir une constante au moins pour le préfixe. Et comme on parle de (as)printf, tu peux faire des trucs sioux du genre
        
        printf(PATH_PREFIX "/le/reste/de/mon/chemin", ...);
        
        … pour éviter des appels inutiles à str*cat/str*cpy pour des chaînes constantes.
        
        Entre grepper surtout TOUS les fichiers (parce que tu ne sais pas forcément exactement quel fichier source utilise ce préfixe), ou aller changer le préfixe du chemin dans un seul fichier bien identifié (et sans doute documenté), tu penses vraiment que les méthodes sont équivalentes en termes de sûreté et d'efficacité ?
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par totof2000 le 04 avril 2014 à 11:18. Évalué à 1.
        
        La constante va eloigner la definition de l'utilisation de la constante. Ca force a une indirection si on veut verifier la valeur de la constante, et si y'a pas de bonnes raisons pour que la valeur change un jour, ca fait pas une grosse difference que la constante soit dans Constants.h, perdue au milieu de 450 autres constantes, ou dans implementation.c.
        
        On a inventé des IDE qui savent retrouver facilement ce genre d'infos, donc ton argument ne tient plus.
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par groumly le 04 avril 2014 à 11:36. Évalué à 2.
        
        ca fait chier quand meme, et ca apporte pas forcement grand chose.
        
        Les bonnes pratiques sont la pour une raison, j'entends pas beaucoup de raisons autres qu'un apparent dogme "une chaine hardcodee c'est mal".
        
        Tu crees pas un #define quand tu fais "var = valeur - 1;", ni quand tu fais un "originX = (view.frame.size.width - label.frame.size.width) / 2.0f;".
        Ben pour les chaines, parfois, c'est pareil (c'est juste).
        La chaine est unique, utilisée a un seul endroit, et se décrit mieux elle meme que par un nom tordu et tarabiscoté, écrit tout en majuscule.
        
        Linuxfr, le portail francais du logiciel libre et du neo nazisme.
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par totof2000 le 04 avril 2014 à 12:20. Évalué à 3.
        
        Tu crees pas un #define quand tu fais "var = valeur - 1;"
        
        Tout dépend d'ou sort le -1.
        
        ni quand tu fais un "originX = (view.frame.size.width - label.frame.size.width) / 2.0f;".
        
        Si, touit dépend d'ou sort le 2.0f. S'il a une signification particulière, je fais un define qui sera plus parlant à la lecture pour la personne qui reprendra le code. C'est parfois bien plus lisible qu'un commentaire.
        
        Sinon, pourquoi a-t-on défini une constante pour Pi par exemple ?
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par windu.2b le 04 avril 2014 à 14:41. Évalué à 5.
        
        Sinon, pourquoi a-t-on défini une constante pour Pi par exemple ?
        
        parce que les "développeurs" d'aujourd'hui n'apprennent plus toutes les décimales de PI, ces feignasses…
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par flan (site web personnel) le 04 avril 2014 à 15:30. Évalué à 4.
        
        Et imaginez que la valeur de π change !
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par lasher le 04 avril 2014 à 17:54. Évalué à 5.
        
        #define PI 3 // Ça va quoi, c'est bien suffisant pour 99% de nos problèmes !
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par Moonz le 04 avril 2014 à 17:57. Évalué à 3.
        
        #define PI (asin(-1)) // Pour avoir la valeur exacte
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par totof2000 le 04 avril 2014 à 18:14. Évalué à 2.
        
        C'est pas plutôt #define PI (asin(-1))*2 ? ou alors tu as défini HALF_PI non ?
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par Maclag le 04 avril 2014 à 18:28. Évalué à 4.
        
        Comme quoi définir une constante PEUT augmenter le risque d'avoir un bug!
        
        -----------> [ ]
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par Moonz le 04 avril 2014 à 18:59. Évalué à 2.
        
        Je voulais dire acos en fait :)
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par flan (site web personnel) le 03 avril 2014 à 22:55. Évalué à 5.
        
        Mais en pratique, il y aura souvent un moment où la constante sera utilisée une seconde fois, ou un moment où elle sera modifiée.
        
        Mais je ne vois pas en quoi ça complique le code, n'importe quel IDE digne de ce nom sait afficher facilement la valeur d'une constante si tu as un doute.
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par nud le 04 avril 2014 à 09:26. Évalué à 5.
        
        Je suis sûr que tous les contributeurs de systemd utilisent un IDE. Il s'appelle probablement vim ou emacs d'ailleurs.
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par Lutin le 04 avril 2014 à 11:54. Évalué à 10.
        
        Ils ne font pas ça sous visual-studiod ?
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par lasher le 04 avril 2014 à 17:55. Évalué à 2.
        
        En même temps, que ce soit sous ViM ou Emacs, tu as les {c|e}tags. Sous ViM, un coup de C-] pour mater la définition, puis C-t pour revenir à ton bout de code, et c'est plié…
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par barmic le 04 avril 2014 à 18:07. Évalué à 4.
        
        Non pour plier avec vim c'est z…
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par pasBill pasGates le 04 avril 2014 à 00:30. Évalué à 10.
        
        Pour quelquechose qu'on prevoit de ne pas changer, ca complique pour rien.
        
        Parce que c'est bien connu, on sait tout du futur au debut du developpement…
        
        Utiliser une constante definie plutot qu'un chiffre est toujours la bonne chose a faire.
        
        A) Parce que ca donne un nom a la valeur, qui explique ce qu'elle represente, sans empecher la lecture car tout IDE qui se respecte montrera la valeur
        B) Parce que si un jour elle doit changer, ou doit etre differente sur une nouvelle platforme, ou etc… ben il n'y a qu'un seul changement a faire plutot qu'essayer de retrouver les 43 endroits ou elle aurait pu etre utilisee.
        C) Parce que si d'autres valeurs en dependent, il est de nouveau bcp plus lisible d'avoir le nom de la valeur plutot qu'un chiffre qui sort d'on ne sait ou
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par Anonyme le 04 avril 2014 à 00:43. Évalué à -4.
        
        Utiliser une constante definie plutot qu'un chiffre est toujours la bonne chose a faire.
        
        On parlait d'une constante pour un nom de fichier.
        
        A) Parce que ca donne un nom a la valeur, qui explique ce qu'elle represente, sans empecher la lecture car tout IDE qui se respecte montrera la valeur
        
        Le nom de fichier c'est deja un nom. Aucun interet à un rajouter un different.
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par pasBill pasGates le 04 avril 2014 à 01:13. Évalué à 5.
        
        Le nom du fichier ne te donne pas la raison pour laquelle il est utilise dans le code, qui peut etre differente pour des softs differents utilisant le meme fichier.
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par Anonyme le 04 avril 2014 à 09:48. Évalué à 0.
        
        Le nom de la constante non plus. Et si la raison pour laquelle le fichier est utilisé n'est pas evidente, on rajoute un commentaire.
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par pasBill pasGates le 04 avril 2014 à 20:13. Évalué à 5.
        
        Le nom de la constante non plus ? Ben t'as mal choisi ton nom de constante alors…
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par Antoine le 05 avril 2014 à 02:28. Évalué à 9.
        
        En même temps, tu réponds à un gars qui s'appelle "b" :-)
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par barmic le 04 avril 2014 à 14:32. Évalué à 3.
        
        Ca servirait à quoi, à part compliquer le code en rajoutant un doute sur la valeur de la constante ?
        
        Tu décris quelque chose de génial justement. Le code qui l'utilise ne doit pas faire de supposition à la noix sur la valeur.
        
        Les constantes c'est utile pour une valeur utilisée à plusieurs endroits et susceptible de changer un jour.
        
        Et tant pis pour quiconque voudrait faire un peu de hacking et réutiliser ton code pour faire un truc dont tu n'a absolument pas conscience ?
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par arnaudus le 03 avril 2014 à 17:57. Évalué à 8.
        
        Bah, par exemple, à la problématique du type qui gère une distribution et qui ne veut pas que les applications décident à sa place de l'arborescence du système?
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par totof2000 le 03 avril 2014 à 18:02. Évalué à 2.
        
        Mais tu n'as pas encore compris ? TU DOIS FAIRE COMME SYSTEMD TE DIT DE FAIRE.
        
        Si tu veux gérer ta distrib autrement, c'est que tu es stupide, et résistant au changement.
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par Moonz le 03 avril 2014 à 18:05. Évalué à 3.
        
        Ou que systemd n’est pas fait pour toi.
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par totof2000 le 03 avril 2014 à 18:09. Évalué à 4.
        
        Non, systemd est fait pour tout le meonde, mais tout le monde n'est pas fait pour systemd …
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par windu.2b le 04 avril 2014 à 08:31. Évalué à 5.
        
        Soit je suis seul à avoir vu de l'ironie dans ce commentaire, et je ne comprends alors pas son moinsage, soit je suis le seul à ne pas avoir compris que tu étais sérieux…
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par totof2000 le 04 avril 2014 à 11:24. Évalué à 1.
        
        Soit je suis seul à avoir vu de l'ironie dans ce commentaire
        
        Je ne pense pas
        
        je ne comprends alors pas son moinsage
        
        Moi je le comprends, même avec l'ironie
        
        soit je suis le seul à ne pas avoir compris que tu étais sérieux…
        
        Disons que c'est de la caricature : une exagération de ce que je pense être la réalité et c'est pour ça que ça ne plaît pas. Pour être plus précis : je ne pense pas que ce soit la réalité vraie, mais c'est la façon dont je perçois les messages qu'envoient les devs de systemd.
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par Anonyme le 03 avril 2014 à 18:20. Évalué à 2. Dernière modification le 03 avril 2014 à 18:22.
        
        Bah, par exemple, à la problématique du type qui gère une distribution et qui ne veut pas que les applications décident à sa place de l'arborescence du système?
        
        Et le type qui veut mettre la liste d'utilisateurs dans /etc/utilisateurs plutot que /etc/passwd, remplacer /proc par /processus, /var par /données, il fait comment ?
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par arnaudus le 03 avril 2014 à 18:33. Évalué à 4.
        
        Je ne sais pas, je ne connais pas le kernel par cœur. Le noyau linux fait un open("/etc/passwd"); ?
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par Anonyme le 03 avril 2014 à 18:49. Évalué à 4.
        
        Au hasard si je regarde le code de procps, on trouve des trucs comme ca:
        
        if (!freopen("/proc/self/maps", "r", stdin))
        
        https://gitorious.org/procps/procps/source/9c7e8b82f872e2d46ce866255ff132e0e6a0f937:pmap.c#L156
        
        Mon dieu procps hardcode des chemins dans son code ! Et un grep '/proc' dans les sources montre qu'il y en a plein.
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par arnaudus le 03 avril 2014 à 19:02. Évalué à -2.
        
        /proc c'est vraiment très très spécial. Je crois me souvenir qu'il y avait des raisons techniques pour forcer l'arborescence—en gros, /proc est virtuel, et ouvrir "/proc/self/maps" c'est un peu comme lire une variable qui s'appellerait proc_self_maps. Mais je crois aussi me souvenir que ça avait un peu gueulé au début, à cause justement du fait que la structure du répertoire était imposée.
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par Moonz le 03 avril 2014 à 19:35. Évalué à 7. Dernière modification le 03 avril 2014 à 19:36.
        
        self/maps est virtuel mais /proc ne l’est pas. Tu peux très bien faire (en root) :
        
        mkdir /processes mount -t proc proc /processes
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par oinkoink_daotter le 04 avril 2014 à 17:27. Évalué à 3.
        
        Oui, par contre, si tu ne montes pas proc sur /proc, ça ne va pas probablement pas booter très loin, ou pas marcher longtemps.
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par Anonyme le 03 avril 2014 à 19:41. Évalué à 5.
        
        /proc c'est vraiment très très spécial. Je crois me souvenir qu'il y avait des raisons techniques pour forcer l'arborescence
        
        Et /run/systemd c'est aussi très spécial, et il y a des raisons techniques pour forcer l'arborescence.
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par pasBill pasGates le 03 avril 2014 à 20:05. Évalué à 8.
        
        Soyons francs…
        
        Je suis pour systemd, je trouves que c'est une bonne chose pour le systeme.
        
        Mais ce code qui a ete poste la, il est moche, pas facilement maintenable, pas facilement portable.
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par Anonyme le 03 avril 2014 à 20:27. Évalué à -5.
        
        Mais ce code qui a ete poste la, il est moche,
        
        Du code moche ca veut dire quoi ?
        
        pas facilement maintenable,
        
        Les developeurs de systemd ne semblent pas avoir de problème particulier pour le maintenir.
        
        pas facilement portable.
        
        Ne pas etre portable sur d'autres OS est un choix des developeurs de systemd, pour simplifier le code.
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par pasBill pasGates le 03 avril 2014 à 20:34. Évalué à 10.
        
        Moche ca veut justement dire pas maintenable et pas facilement portable.
        
        Les developeurs de systemd ne semblent pas avoir de problème particulier pour le maintenir.
        
        Ah oui ? Tu utilises quoi pour evaluer ca ?
        
        J'ai passe 10 ans dans une equipe dont tout le boulot etait la maintenance, j'ai vu la difference enorme qu'il y a entre du code propre et maintenable, et du code moche et pas maintenable.
        
        Ce n'est pas parce que des releases de systemd continuent de sortir que leur code est maintenable et propre.
        Tu vois si c'est maintenable quand tu fais un changement et que tout ne s'ecroule pas, ou que tu n'as pas besoin de chercher 3 jours pourquoi un changement d'une ligne a droite pete une feature a gauche ou d'ou vient un effet de bord bizarre.
        
        La maniere dont ce code poste a ete ecrit est clairement non maintenable, il n'y a pas d'isolation des elements, la fonction est enorme, il manque des verifications de retour d'erreur.
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par Anonyme le 03 avril 2014 à 20:40. Évalué à -8.
        
        Ah oui ? Tu utilises quoi pour evaluer ca ?
        
        De nouvelles versions de systemd sortent très regulierement avec des tas de nouvelles fonctionnalités, sans regressions importantes.
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par Albert_ le 03 avril 2014 à 22:01. Évalué à 4.
        
        Je suis pret a parier que le jour ou les developpeurs historiques auront decide de passer a autre chose ca va etre legerement plus complique a maintenir et on va refaire un truc comme avahi qui est en mode "maintenance", traduction: plus personne ne s'en occupe.
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par gnumdk (site web personnel) le 04 avril 2014 à 08:59. Évalué à 0.
        
        Euh, si avahi fonctionne, répond au besoin et ne présente pas de faille, tu veux que quelqu'un commit régulièrement pour faire semblant que c'est en cours de dev?
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par Albert_ le 04 avril 2014 à 11:13. Évalué à 3.
        
        Oh il manque juste quelques petits details pour que cela soit utilisable par monsieur tout le monde. En particulier comment interagir avec sans mettre les mains dans le cambouis.
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par Batchyx le 04 avril 2014 à 19:36. Évalué à 6.
        
        Oui, Avahi fonctionne, Il y a juste un bug qui rend le support d'IPv6 link local inutilisable. Sachant que IPv6 link-local à plus tendance à Juste Marcher qu'IPv4 et qu'avahi cherche à utiliser les deux protocoles si une application fait un getaddrinfo sur coucou.local, en utilisant le premier qui arrive en priorité. Ça veut dire qu'une résolution de 'coucou.local' a une chance sur deux de tomber sur une IPv6 link-local sans scope que le noyau te rejettera avec EINVAL si tu l'utilise.
        
        Et c'est pareil avec tout les services : si tu ne demande pas à ton appli des adresses IPv4 uniquement, tu à une chance sur deux pour tomber sur une IPv6 bidon. Ou bien tu utilise IPv4 si il marche correctement (ex ssh -4 coucou.local), ou bien tu corrige à la main les adresses IPv6 qu'Avahi te sort.
        
        Juste un petit bug.
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par totof2000 le 03 avril 2014 à 21:02. Évalué à 10.
        
        Je crois qu'il faut avoir passé beaucoup de temps à rechercher des erreurs tordus, même dans du code bien écrit pour comprendre cette évidence.
        
        Personnellement, à une époque j'écrivais du code aussi crade que celui-là, mais j'ai vite arrêté, parce qu'au bout d'un moment, je ne pouvais plus y toucher sans tout casser.
        
        Là c'est pareil. Un jour quelqu'un fera une modif qui introduira un bug subtil. Pour un truc aussi sensible que systemd, je trouve ça inacceptable.
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par gnumdk (site web personnel) le 04 avril 2014 à 08:57. Évalué à -6.
        
        il manque des verifications de retour d'erreur.
        
        Tu vas pas recommencé avec ça, tu n'est pas d'accord avec Lennart, on a compris…
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par arnaudus le 03 avril 2014 à 17:54. Évalué à 2.
        
        Bref, ce bout de code m'a l'air correct.
        
        Je n'ai jamais prétendu qu'il était incorrect! C'est juste que je le trouve crade. Rien ne t'empêche de définir une variable de retour au début, et de la retourner une seule fois à la fin.
        
        Ça pinaille là. Ce sont des droits Unix. On peut utiliser les constantes symboliques, mais ça n'apporte pas grand chose, voir c'est contre-productif.
        
        J'aurais dû expliquer, mais ce qui me gène, c'est la duplication de code. Ici tu as 0700, et dans une autre fonction tu as 0700, et dans un autre fichier tu as 0700, etc. Je ne voulais surtout pas dire qu'il fallait remplacer 0700 par une constante user_access_only, mais plutôt par une variable globale int permission_parent_dir = 0700; . En gros, dintinguer le signifiant du signifié, et faciliter la maintenance du code.
        
        C'est un peu moche, mais c'est de la tambouille interne. Comme de toute façon, ils ont décidé que /run devait exister
        
        Ouais, c'est super sympa pour les mainteneurs des distributions qui décideront d'organiser le système autrement. C'est juste de l'égoïsme, "Moi je ne vois pas pourquoi je changerais ça, donc je le met en dur". 1) tu n'es jamais sûr que tu n'auras pas besoin de le changer, et 2) tu n'es jamais sûr que quelqu'un d'autre n'aura pas besoin de le changer.
        
        C'est du C. On a l'habitude d'abuser la sémantique. Si c'est "proprement" documenté :). Pas choqué
        
        Abuser la sémantique est une chose, mais là, ça renvoie 4 trucs différents :
        * l'opposé du retour de get_ctty_devnr si ce retour est positif
        * -ENOMEM si l'asprint a foiré
        * -errno si l'open a foiré
        * le file descriptor si open a réussi
        Il me semble que la sémantique, c'est que si le retour est positif, alors c'est le file descriptor, s'il est négatif, c'est n'importe quoi. Le traitement de l'erreur va être vachement facile.
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par totof2000 le 03 avril 2014 à 18:04. Évalué à 6.
        
        Yen a qui ont du mal à comprendre que ce n'est pas un détail relevé par-ci par-là qui est dangereux, mais l'accumulation de ces petits détails qui fait que ça risque de sauter.
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par Anonyme le 03 avril 2014 à 18:30. Évalué à -5.
        
        Le truc que toi tu as du mal à comprendre c'est que tu as rien relevé du tout. On peut pinailler sur ce genre de trucs sur le code du noyau de la meme facon et sur à peu près 100% du code qui existe partout ailleurs.
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par arnaudus le 03 avril 2014 à 18:54. Évalué à 10.
        
        On peut pinailler sur ce genre de trucs sur le code du noyau de la meme facon
        
        Du peu que j'ai vu du code du noyau, c'est assez faux. Le code du noyau n'est pas forcément lisible, parce qu'il est écrit par des gens qui ne sont pas des programmeurs moyens, mais les fonctions sont hyper courtes, on a rarement plus de deux niveaux de if, il y a des millions de constantes pour tout, beaucoup de fonctions commencent par "int retval;" et dintinguent très clairement les retours d'erreurs et les retours de valeurs attendues, etc.
        
        Je pense qu'on a relevé plein de petits trucs bizarres, pas très propres, pas très orthodoxes. Après, je ne suis pas développeur, et j'ai dit plus haut que le code n'était pas "pourri" : il fait juste un peu "premier jet". Si j'ai un étudiant qui me met les chemins en dur, je lui dis de refaire cette fonction pour qu'il aille lire les chemins dans une variable. S'il a 5 niveaux de if/else, je lui dis de fractionner son code en fonctions plus courtes. Je lui dirais aussi de ne pas appeler ses variables r, p, ou d.
        
        À partir de ça, il serait con de conclure que systemd ne fonctionne pas, qu'il est buggué, ou qu'il n'est pas efficace. Par contre, c'est légitime de se poser des questions sur sa maturité, et sur le nombre de gens qui ont relu le code. Je ne comprends toujours pas le "return -r;" par exemple, c'est probablement un bug ou un truc pas net, simplement dû à la complexité de la fonction. Si elle avait un "int retval = 0;" au début, puis "retval = -r;", et "if (! (retval < 0))" avant le code qui fait vraiment quelque chose, il serait évident à la lecture que la fonction fait un truc idiot. Alors que là, on ne sait pas trop si retourner un code d'erreur positif n'est pas voulu, c'est bizarre quand même, non?
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par Anonyme le 03 avril 2014 à 19:21. Évalué à 5.
        
        Je regarde un fichier du kernel au hasard, par exemple kernel/cgroup.c, et je tombe sur la fonction parse_cgroupfs_options:
        https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/kernel/cgroup.c#n1129
        
        Fonction de 150 lignes. 4 niveaux d'imbriquation. Des "return -EINVAL" et pas de variable retval. Des if sans {} sur plusieurs lignes. Les noms des options hardcodés sans un define.
        
        En gros, comme ce qui est reproché au code de systemd.
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par modr123 le 03 avril 2014 à 19:55. Évalué à -6.
        
        sans systemd, personne utilisait cgroup si j'ai bien compris donc bon…
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par Anonyme le 03 avril 2014 à 20:34. Évalué à 0.
        
        Et ca change quoi ? Les cgroups existaient avant systemd, ce code n'a pas été écrit par les developeurs de systemd, et il fait partie du kernel.
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par modr123 le 03 avril 2014 à 21:02. Évalué à -7.
        
        sans systemd on utiliserait pas cgroup dont le code est aussi moche que celui de systemd
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par Anonyme le 03 avril 2014 à 21:16. Évalué à 5.
        
        J'ai pris cgroup.c par ce que c'est le premier fichier que j'ai ouvert, au hasard. On trouve le meme genre de code ailleurs dans le kernel.
        
        De toute facon les cgroups ne sont pas utilisés que par systemd, et si le code a été accepté c'est qu'il répond aux critères de qualité du kernel.
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par GnunuX (site web personnel) le 03 avril 2014 à 22:03. Évalué à 7.
        
        J'utilise les cgroups depuis au moins 3 ans avec LXC. Je pense qu'il y a de plus en plus d'utilisateur de LXC (donc de cgroups).
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par Domi le 03 avril 2014 à 23:43. Évalué à 9.
        
        Faux, j'utilise les cgroup sans systemd depuis des années.
        
        Aux agents des services secrets qui lisez ce message, veuillez considérer que défendre votre nation contre ces ennemis interieurs et extérieurs implique de suivre l'exemple de Snowden.
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par Domi le 03 avril 2014 à 23:55. Évalué à 0.
        
        Apparemment, il y en a qui sont dur de la feuille. Je dis un fait, j'utilise les cgroups depuis des années sans systemd, et je me retrouve noté à -3. Ces courageux anonymes qui m'ont ainsi noté feraient mieux d'apprendre à utiliser leur système. Alors je répète ce fait têtu:
        
        !!! J'utilise les cgroups du kernel depuis des années, et ce sans systemd !!!
        
        Et comme le dit très bien Steven Rostedt sur le rapport de bug de systemd:
        This bugzilla is the poster child of why people hate systemd and do not trust the developers that work on it.
        
        Aux agents des services secrets qui lisez ce message, veuillez considérer que défendre votre nation contre ces ennemis interieurs et extérieurs implique de suivre l'exemple de Snowden.
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par barmic le 05 avril 2014 à 10:34. Évalué à 2.
        
        Ce n'est pas parce que quelque chose est vrai que c'est pertinent, sinon je vais m'offusquer de voir mes commentaires parlant de ce que j'ai mangé ce matin ou du temps qu'il fait considérer comme non pertinent.
        
        Plus haut quelqu'un dis que les cgroups n'étaient pas utilisés avant systemd, il faut être zenitram pour ne pas comprendre « très peu » et donc s'immaginer que ton commentaire n'est pas un contre argument (contrairement au fait de parler de LXC).
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par khivapia le 03 avril 2014 à 21:45. Évalué à 2.
        
        https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/kernel/cgroup.c#n1129
        
        En même temps le code d'un parseur est généralement bourré de suites de 'while (readline) { if (strncmp(' etc. etc.
        Essentiellement dans le fichier que tu incrimines, il n'y a guère que le petit bout pour le "name" qui aurait pu être mis dans une fonction séparée.
        
        Les EINVAL sont une constante clairement définie et clairement retournée pour toutes les erreurs de la grammaire du truc parsé, il n'y a pas de trucs alloués ou incrémentés entre deux tests et retour de fonction hors erreur…
        
        Bref il n'y a pas grand-chose à redire à ce bout de code.
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par Anonyme le 03 avril 2014 à 22:32. Évalué à -4.
        
        Bref il n'y a pas grand-chose à redire à ce bout de code.
        
        Oui, tout comme dans celui de systemd qui a été cité.
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par Batchyx le 04 avril 2014 à 08:23. Évalué à 6.
        
        Hein ? quoi ?
        
        Dans un cas, on parle d'une fonction dans le noyau qui est utilisée par des processus privilégiés et qui parse une bête ligne séparée par des virgules. La fonction mélange certes le parsing, la validation et l'interprétation, mais c'est typique des devs C qui aiment bien coder directement les choses plutôt que de chercher à les abstraire. Mais bon, c'est le langage qui veut que les solutions les plus propres soit les plus lentes et grosses.
        
        Dans l'autre cas, on parle d'un processus utilisateur avec des problématiques de sécurité, vu que ça gère des mots de passes. Certains appels de fonction ne sont pas vérifiés, pas même pour afficher un message d'erreur. La fonction wall_tty_block() exposée au dessus crée un fifo sans même vérifier le message d'erreur, et ne vérifie qu'il à été crée qu'avec un open(), qui peut ouvrir n'importe quoi, sans parler de races. Tout ça pour quoi ? pour faire de l'IPC à la sauce étudiant, comme le montre ce commentaire :
        
        /* We use named pipes to ensure that wall messages suggesting * password entry are not printed over password prompts * already shown. We use the fact here that opening a pipe in * non-blocking mode for write-only will succeed only if * there's some writer behind it. Using pipes has the * advantage that the block will automatically go away if the * process dies. */
        
        Pas non plus de trace de mlock() pour éviter que le mot de passe se retrouve dans le swap. Enfin bref, les pieds nickelés font de la sécurité.
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par Zenitram (site web personnel) le 04 avril 2014 à 09:00. Évalué à 2.
        
        Enfin bref, les pieds nickelés font de la sécurité.
        
        Les gars, vous êtes trop des surdoués, vous voyez les problèmes partout chez les autres.
        Et si on jouait à ce que vous proposiez un patch pour mieux sécuriser le bousin, pour voir?
        A ce demander pourquoi eux sont payés (cher) pour faire le taf et pas vous… Vous méritez ieux que votre salaire actuel! (ou pas)
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par arnaudus le 04 avril 2014 à 10:07. Évalué à 5.
        
        C'est un argument fallacieux. On peut critiquer la bouffe de la cantine sans être cuisinier, on peut critiquer le boulot d'un maçon sans être capable de faire mieux. C'est tout à fait légitime.
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par pepp le 04 avril 2014 à 10:16. Évalué à 4.
        
        Moué, analogies foireuses.
        
        Pour le cas du cuisinier, ça serait plutôt aller voir en cuisine, et dire : "je ne suis pas cuisinier, mais à votre place je ne ferais pas comme ça. Et puis vous devriez faire attention avec ce couteau pointu, vous risquez de vous couper."
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par totof2000 le 04 avril 2014 à 11:40. Évalué à 1.
        
        L'analogie avec le cuisinier je la vois plutôt comme ça :
        - je vous ai préparé un plat à moitié cuit, à moitié assaisonné et sur lequel il risque d'y avoir des ingrédients périmés qui vous rendront malades. Je l'ai laissé dans la marmite, servez-vous, et débrouillez-vous pour la présentation. Mais ne vous inquiétez pas, il est mangeable quand même. Si ça ne vous plait pas, reprenez le plat et améliore-le. Enlevez ce qui ne vous plait pas, ce qui pourrait être périmé, et ajoutez ce qui vous plait. Mettez-le dans l'assiette de la façon qui vous plait. Moi je m'en vais préparer un autre plat à moitié fini, ça ne m'intéresse plus de finir celui-là.
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par totof2000 le 04 avril 2014 à 11:32. Évalué à 2.
        
        Les gars, vous êtes trop des surdoués, vous voyez les problèmes partout chez les autres.
        Et si on jouait à ce que vous proposiez un patch pour mieux sécuriser le bousin, pour voir?
        
        Parce que je ne suis pas payé pour faire ça mais pour faire autre chose : notamment utiliser leur code.
        
        A ce demander pourquoi eux sont payés (cher) pour faire le taf et pas vous… Vous méritez ieux que votre salaire actuel! (ou pas)
        
        Justement : on peut s'attendre à mieux pour des personnes payées à plein temps pour coder. Je t'assure que ça me démange de réécrire ce code, mais je ne peux pas le faire pour le moment. A moins que Redhat ne me paye poyur le faire.
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par Zenitram (site web personnel) le 04 avril 2014 à 11:36. Évalué à -1.
        
        A moins que Redhat ne me paye poyur le faire.
        
        Ils préfèrent payer le gars que tu critiques que toi. Et ils ont l'air d'en être content, ils incluent son code dans leur prochaine version de leur distro hyper critique.
        Demande-toi pourquoi : tu es un dieu trop meilleur que les autres, juste pas le temps, ou alors c'est que…
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par totof2000 le 04 avril 2014 à 12:26. Évalué à 2.
        
        Ils préfèrent payer le gars que tu critiques que toi.
        
        Tant mieux pour lui. Mais ce n'est pas parce que quelmqu'un est payé (cher) pour quelque chose que ça en fait qqn de bon dans ce qu'il fait .
        
        ils incluent son code dans leur prochaine version de leur distro hyper critique.
        
        C'est une erreur technique, mais il ont probablement d'autres raisons que des raisons techniques de le faire (être sur le marché avec un code pourri, quitte ensuite à le débugger). Ce ne serait pas la première fois que je verrais ça. J'ai bossé pour une boite en tant que prestataire, qui préférait sortir leur produit même s'il ne marchait pas plutôt que de risquer de laisser la place à quelqu'un d'autre. Ca pousse les autres à sortir leur produit en avance, même s'il n'est pas terminé oui stable. De fait tout le monde sort son produit bugge et personne n'a l'avantage suir les autres. Mais au moins tout le monde est sur le marché.
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par Albert_ le 04 avril 2014 à 12:31. Évalué à 3.
        
        T'as bosse pour Microsoft? :)
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par totof2000 le 04 avril 2014 à 12:37. Évalué à 4.
        
        Non, :) ce ne sont malhereusement pas les seuls à agir ainsi.
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par Albert_ le 04 avril 2014 à 12:52. Évalué à 8.
        
        Je sais bien, malheureusement, mais il faut bien que je maintienne la reputation de Albert_ non? :D
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par Yann Hodique (site web personnel) le 04 avril 2014 à 16:27. Évalué à 3.
        
        Moui, faut nuancer un peu quand même. Redhat est loin d'être parmi les employeurs les plus compétitifs et un rapide coup d'oeil à glassdoor me montre que le gars gagne probablement nettement moins qu'un développeur un poil expérimenté chez Google par exemple.
        
        Je ne dis pas qu'ils ne sont pas bon, loin de là. Au contraire, je pense que le rapport qualité/prix est assez élevé. Il n'en reste pas moins que Redhat fait exactement comme toutes les autres boîtes: recruter les meilleurs parmi ceux qu'ils peuvent s'offrir, ce qui est différent des meilleurs dans l'absolu.
        
        Bref je pense qu'il est assez légitime de dire que tel ou tel bout de code ne serait pas jugé acceptable ailleurs. Et la réponse n'est pas nécessairement que ceux qui l'affirment pourraient aller prétendre au salaire du gars qui a pondu le code, mais aussi parfois qu'ils gagnent déjà bien plus (ou bien assez) ailleurs.
        Et puis y a pas que l'argent dans la vie non plus, donc l'argument "si tu peux faire mieux, va te faire payer à sa place" est beaucoup trop simpliste, peu importe la façon dont on aborde le problème.
        
        Au passage, ce bout de code ne serait jamais accepté chez moi ;)
        Ça n'en fait pas quelque chose d'intrinsèquement mauvais mais, selon la durée de vie du code en question, ça peut être un choix globalement rentable ou non: pour schématiser, capex-- vs opex++. L'argument des gens qui râlent contre ce code est qu'un système d'init devrait avoir pour vocation de durer dans le temps, donc avoir un coût de maintenance le plus faible possible (bon y en a aussi qui râlent parce que le code moche c'est Mal(tm), mais c'est un autre problème :)).
        En même temps je comprends parfaitement Redhat, et une des spécificités du libre c'est que l'"opex" est mutualisé dans une certaine mesure, ce qui rend l'optimisation de "capex" plus attractive… En gros le point critique est d'être juste assez bon pour convaincre les autres d'adopter, et hop, par magie les coûts de maintenance sont partiellement transférés à des tiers. Finalement c'est un bel exemple de l'économie autour du libre :)
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par totof2000 le 04 avril 2014 à 11:30. Évalué à 1.
        
        Dans l'autre cas, on parle d'un processus utilisateur avec des problématiques de sécurité, vu que ça gère des mots de passes.
        
        Je n'ai pas choisi ce bout de code au hasard. ;). Mais je vous laisse le soin de le démonter : je n'aime pas systemd, c'est connu ici, et si d'autres personnes mettent en avant les problèmes de ce code, ça sera plus crédible je pense.
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par moi1392 le 04 avril 2014 à 00:21. Évalué à 4.
        
        En même temps le code d'un parseur est généralement bourré de suites de 'while (readline) { if (strncmp(' etc. etc.
        
        Un parser pour moi, ça se code avec un automate à état fini quand on est étudiant, et ensuite on utilise lex qui le fait à ta place.
        
        Le coup du gros bloc de if avec des str(n)cmp, je trouve ça assez moyen (euphémisme)
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par Anonyme le 04 avril 2014 à 12:44. Évalué à 2.
        
        Le coup du gros bloc de if avec des str(n)cmp, je trouve ça assez moyen (euphémisme)
        
        Ben pourtant c'est une methode assez classique pour parser des arguments/options dans un format basic. Par exemple dans git:
        https://git.kernel.org/cgit/git/git.git/tree/builtin/commit-tree.c#n43
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par moi1392 le 04 avril 2014 à 13:15. Évalué à 2.
        
        Ça marche quand tu en as un nombre assez faible et que tu n'as pas besoin de performances importantes.
        
        Dans ce cas là oui, je trouve même que c'est plus lisible de la sorte.
        
        Mais j'ai un peu de mal à appeler cela un parser (ou un analyseur lexical)
        
        Mais si tu dois passer à la moulinette de plus gros fichiers, que tu as beaucoup de mots clés à y reperer et qui peuvent revenir souvent (et c'est le cas pour des fichiers de configuration), je pense qu'utiliser flex (sans l'associer à bison) et plus efficace et maintenable (ajout de nouveaux mots clés, de patterns, …)
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par moi1392 le 04 avril 2014 à 13:19. Évalué à 2.
        
        Par exemple dans git:
        https://git.kernel.org/cgit/git/git.git/tree/builtin/commit-tree.c#n43
        
        Au passage, je sais que git n'est pas un composant critique en terme de sécurité, mais ça ne coutait pas grand chose de mettre des strNcmp.
        D'ailleurs, il y en a un au milieu qui est un memcmp, ça ne doit pas être la même personne qui l'a écrit, celui là :)
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par Anonyme le 04 avril 2014 à 14:05. Évalué à 0.
        
        Au passage, je sais que git n'est pas un composant critique en terme de sécurité, mais ça ne coutait pas grand chose de mettre des strNcmp.
        
        Ca servirait à quoi ?
        
        D'ailleurs, il y en a un au milieu qui est un memcmp, ça ne doit pas être la même personne qui l'a écrit, celui là :)
        
        C'est la meme personne, mais il y a une raison pour utiliser memcmp et pas strcmp dans ce cas la. Ca permet de ne regarder que les 2 premiers caracteres.
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par moi1392 le 04 avril 2014 à 14:59. Évalué à 3.
        
        Ca servirait à quoi ?
        
        C'est la meme personne, mais il y a une raison pour utiliser memcmp et pas strcmp dans ce cas la. Ca permet de ne regarder que les 2 premiers caracteres.
        
        c'est un monologue ????
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par Batchyx le 04 avril 2014 à 20:42. Évalué à 3.
        
        Sauf qu'ici on est dans le noyau. Tout le monde n'a pas les mêmes contraintes, mais si tu arrive avec ton code imbitable généré par lex et que par magie tu arrive à le faire accepter, n'importe quel idiot pourra passer derrière toi avec un patch "Bonjour, j'ai ré-écrit le gros pathé de code imbitable en une série de strcmp(), J'ai économisé 3 Kio de taille de binaire en x86, et en plus j'enlève 50 lignes de code" et il sera accepté direct si le code est pas trop moche. Et des gens qui courent après les kilos, il y en a (genre OpenWRT) et ils sont très actifs.
        
        Et franchement, même s'il n'y avait pas la contrainte de taille, faudrai quand même être KISS un peu: Si tu est en C et que tu a un langage simple à parser, tu commence pas par sortir ton lexeur/parseur. tu le juste parse.
        
        Et si tu n'a aucune contrainte et que c'est toi qui choisi le langage que tu va parser (comme c'est souvent le cas), tu va prendre le langage le plus simple et le plus évident que même un idiot comprendra et tu va le parser le plus simplement possible. Inventer une soupe contextuelle et sortir ton lex/yacc en bloatant ton système de build est juste inacceptable.
        
        Naturellement, tout dépend du langage. Si tu est en perl, rien ne vaut une regex bien placée. Si tu est en C++, rien ne vaudra une petite grammaire Qi avec des actions qui vont bien (et s'ils sont pas d'accord, montre leur la taille de ton code).
        
        Le plus simple restant encore de ne pas écrire de grammaire soi-même et d'utiliser des parseurs que d'autres ont écrits.
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par oinkoink_daotter le 04 avril 2014 à 21:09. Évalué à 1.
        
        le gros pathé de code imbitable
        
        Ouh qu'elle est belle celle-là :)
        
        Si tu est en C et que tu a un langage simple à parser, tu commence pas par sortir ton lexeur/parseur. tu le juste parse.
        
        Ouais, ça commence comme ça et ca finit comme slip dans wmcoincoin.
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par Batchyx le 04 avril 2014 à 21:38. Évalué à 2.
        
        Faut réfléchir un peu aussi. Si à chaque fois que tu à un problème, tu ne pense qu'a bloater ton parseur, tu te retrouvera immanquablement avec un parseur bloaté.
        
        À chaque fois que tu veut faire un changement sur ton parseur, tu doit te poser la question de si c'est dans ce sens la que tu veux aller. La bonne solution est souvent de virer ton parseur maison et d'utiliser un format standard avec des parseurs tout prêts.
        
        L'avantage des parseurs maisons simple, comme de tout les codes simples en général, c'est qu'on peut les virer rapidement sans scrupule si besoin. Alors que si tu à sorti ta bloatinerie de flex/bison ou autre, t'aura beaucoup moins envie de virer le code que t'a passé deux journées à écrire, et t'aura plus tendance à vouloir le bloater encore plus plutôt que de partir sur une solution propre.
        
        Dans le cas du noyau, si la gestion des options deviens trop chiante, alors ça se doit de passer dans Netlink.
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par fearan le 04 avril 2014 à 21:54. Évalué à 2.
        
        je sens qu'on va finir par parler XML dans le coin…
        
        Il ne faut pas décorner les boeufs avant d'avoir semé le vent
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par Batchyx le 05 avril 2014 à 00:55. Évalué à 4.
        
        Dans le genre prophétie auto-réalisatrice, c'est sûr que si tu sens que ça va finir par parler de XML, autant en parler soi-même.
        
        Sinon, la première règle du club de tautologie est la première règle du club de tautologie.
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par moi1392 le 05 avril 2014 à 12:19. Évalué à 1. Dernière modification le 05 avril 2014 à 12:21.
        
        si tu arrive avec ton code imbitable généré par lex et que par magie tu arrive à le faire accepter
        
        Je n'arrive pas avec du code imbitable généré par lex. J'arrive avec un fichier lex lisible qui est compilé pendant la phase de compilation.
        
        "Bonjour, j'ai ré-écrit le gros pathé de code imbitable en une série de strcmp(), J'ai économisé 3 Kio de taille de binaire en x86, et en plus j'enlève 50 lignes de code"
        
        Il n'aura rien ré-écrit du tout car ce "pathé de code imbitable" n'est pas écrit. Encore une fois, c'est un fichier lex simple, très lisible (pour peu que l'on conaisse la syntaxe, comme tout format de fichiers) et sincèrement très compliqué à battre, tant en terme de performance que de consomation mémoire (bon, peut-être pas en consomation, mais c'est pas la mort non plus)
        
        Inventer une soupe contextuelle et sortir ton lex/yacc en bloatant ton système de build est juste inacceptable.
        
        Je n'ai rien inventé, les fichiers de configurations sont déjà là avec leur format, et quand j'ai à analyser cela, je crée un analiser lexical avec lex que je couble avec un petit switch. Tu as remarqué que dans mon post original, je prenais soin de mentionner que je ne couplais en aucun cas ça avec du yacc/bison.
        Encore une fois, si j'ai 3 mots clés que je lis 2 fois chacuns, je ne le fais pas. Quand cela commence à gonfler, c'est le tas de if/else avec des comparaisons de chaines qui deviens du bloat.
        
        Le plus simple restant encore de ne pas écrire de grammaire soi-même et d'utiliser des parseurs que d'autres ont écrits.
        
        Une fois encore, je n'écris pas de grammaire !! juste un automate à état finis généré par lex que je couple avec un switch en C
        Après si c'est lex qui te donne des boutons, tu n'as qu'à l'écrire à la main ton automate, mais tu seras moins bon que lui et quand ce que tu auras à parser change, il faudra le réécrire, c'est pas terrible.
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par Batchyx le 05 avril 2014 à 18:12. Évalué à 3.
        
        Je n'arrive pas avec du code imbitable généré par lex. J'arrive avec un fichier lex lisible qui est compilé pendant la phase de compilation.
        
        Il va aussi falloir que tu touche au système de build. Et si il y a bien un truc chiant, c'est bien les systèmes de build. Va falloir gérer correctement la cross-compilation (surtout pour un noyau) permettre de configurer le chemin vers lex/yacc, documenter tout ça … Au final, ça fait bien plus de travail et plus de lignes ajoutées par rapport à une boucle while avec des strcmp().
        
        Encore une fois, c'est un fichier lex simple, très lisible (pour peu que l'on conaisse la syntaxe, comme tout format de fichiers) et sincèrement très compliqué à battre, tant en terme de performance que de consomation mémoire (bon, peut-être pas en consomation, mais c'est pas la mort non plus)
        
        Le code généré par Lex sera gros, imbitable, chiant à déboguer (va comprendre le code assembleur généré) et générera des exécutables plus gros. Dans le cas d'un noyau, c'est ce qui compte, plus que les performances. Personne n'appellera ce code des milliers de fois par seconde, et même si c'était le cas, alors il serait simplement interdit de parser une chaîne dans ce code, et il aurai faudrai faire autrement pour passer des paramètres (netlink !!! ;) ). En plus des développeurs parlaient de le récrire.
        
        Je n'ai rien inventé, les fichiers de configurations sont déjà là avec leur format
        
        Donc tout ce que tu dit est totalement hors sujet. Si tu n'a pas le choix du langage que tu parse et que ton langage est complexe, j'ai aucune objection. Sauf qu'ici c'est celui qui à écrit le code qui à choisi la syntaxe de ses paramètres, et il à justement choisi des mots séparés par des virgules pour qu'il puisse faire son parseur simplement avec strtok et strcmp.
        
        Et si tu à le choix du langage que tu parse et que tu sort autre chose que ça, c'est que tu adore te complexifier la vie pour rien.
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par pepp le 03 avril 2014 à 21:15. Évalué à 0.
        
        Donc, tu n'est pas développeur C, mais ça ne t'empêches pas de prendre du code C au hasard et de le juger "bizarre", "douteux" ou "pas très propre".
        Et aussi d'enseigner des bonnes pratiques à tes étudiants.
        
        Perso, le code ci-dessus ne me dérange pas - même si je ne l'aurais pas écrit de cette manière.
        
        Et ce code a un mérite : il existe et il fonctionne.
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par Albert_ le 03 avril 2014 à 22:06. Évalué à 4.
        
        Il y a des gens qui ne sont pas forcement developpeurs dans le sens ou ils ne pondent pas du code toutes la journee pour pondre du code mais qui enseigne et font de la recherche et vu ce qu'il dit j'ai un peu l'impression que c'est son cas.
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par oinkoink_daotter le 04 avril 2014 à 17:44. Évalué à 2.
        
        Le problème c'est que les gens qui enseignent ou qui font de la recherche disent des trucs qui ne sont pas toujours désirables dans la vraie vie, par exemple les accolades inutiles, les return uniques, et l'absence absolue de goto. Ce qui se discute, se défend et nous entraîne dans un troll déjà vu.
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par diorcety le 04 avril 2014 à 08:56. Évalué à 8.
        
        https://www.mail-archive.com/systemd-devel@lists.freedesktop.org/msg18134.html
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par arnaudus le 04 avril 2014 à 09:28. Évalué à 7.
        
        Merci :-) J'ai l'impression que les non-développeurs C qui se sont fait allumés sur cette page ont trouvé un bug que les méga-pro-développeurs C, qui trouvaient le code très clair, n'avaient pas vu.
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par Antoine le 05 avril 2014 à 02:40. Évalué à 4.
        
        En tout cas, on voit qu'il y a des tests unitaires.
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par Moonz le 03 avril 2014 à 18:04. Évalué à 5.
        
        l'opposé du retour de get_ctty_devnr si ce retour est positif
        
        Je pense que tu viens de trouver un bug dans systemd, je mettrai ma main au feu qu’il devrait renvoyer la valeur de retour de get_ctty_devnr si ce retour est négatif.
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par arnaudus le 03 avril 2014 à 18:27. Évalué à 3.
        
        Non, pardon, je me suis emmélé les pinceaux. Si get_ctty_devnr est négatif, il renvoir l'opposé (donc un truc positif). Mais pourquoi, alors que c'est visiblement un code d'erreur? Ailleurs dans le code de systemd (par exemple dans util.c), on a bien
        
        k = get_ctty_devnr(pid, &devnr); if (k < 0) return k;
        
        qui me semble cohérent avec la logique "erreur = on arrête et on renvoie un nombre négatif".
        
        C'est rigolo de tomber la-dessus dans un exemple pris pour discuter de la qualité du code. En tout cas, si c'est valable (si la fonction doit vraiment retourner l'opposé du code d'erreur), là, pour le coup, c'est de l'obfuscation évidente. Autrement c'est un bug.
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par Anonyme le 03 avril 2014 à 19:00. Évalué à -3.
        
        Ouais, c'est super sympa pour les mainteneurs des distributions qui décideront d'organiser le système autrement. C'est juste de l'égoïsme, "Moi je ne vois pas pourquoi je changerais ça, donc je le met en dur". 1) tu n'es jamais sûr que tu n'auras pas besoin de le changer, et 2) tu n'es jamais sûr que quelqu'un d'autre n'aura pas besoin de le changer.
        
        La question c'est, est ce qu'il y a une raison valable pour voulloir changer ca. Si il n'y en a pas, alors il ne faut pas qu'il y ait d'option pour le changer:
        - ca simplifie le code
        - si l'option est la, des gens vont l'utiliser sans reflechir et rajouter des incompatibilités entre distributions pour rien
        - si quelqu'un a une raison valable pour changer ca, il est toujours possible d'envoyer un patch pour rajouter l'option
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par arnaudus le 03 avril 2014 à 19:13. Évalué à 7.
        
        La question c'est, est ce qu'il y a une raison valable pour voulloir changer ca. Si il n'y en a pas, alors il ne faut pas qu'il y ait d'option pour le changer
        
        C'est EXACTEMENT ce que répond Microsoft quand tu demande pourquoi il n'est pas prévu de booter un autre OS. Ça va largement au delà de l'informatique. Pourquoi s'emmerder à mettre des boitiers de dérivation quand on rajoute un truc électrique? On met les dominos dans le platre du mur et puis voila. Pourquoi s'emmerder à utiliser la balayette dans les toilettes? Le suivant va aussi y démouler son cake.
        
        Ce n'est pas à toi de décider s'il y a des raisons valables de faire quelque chose ou non. Surtout pour du code libre : après tout, il est fait pour être réutilisé. Et surtout si la seule raison évidente, c'est la flemme de faire les choses correctement. Franchement, combien de fois chacun a pesté contre une API parce que les concepteurs ont bloqué une possibilité triviale, tout ça parce qu'eux n'en voyaient pas l'intérêt? On peut toujours vouloir appeler une fonction sur un pointeur NULL parce qu'elle a des effets de bord, on peut toujours vouloir passer une valeur négative quelque part parce qu'on a modifié un peu le code ailleurs, et que la fonction qui te bloque le fait juste par simple bêtise, parce que les devs ne voyaient pas l'intérêt de te laisser mettre un pointeur NULL ou une valeur négative. Alors oui, la probabilité que quelqu'un ait un jour besoin d'utiliser un truc dont on ne voit pas l'intérêt immédiat est, quoi, 10%? 1%? Mais comme ça arrive à des milliers d'endroits dans le code, tu es presque sûr que tu pourriras la vie de quelqu'un un jour ou l'autre (avec une très forte probabilité pour que la victime soit toi-même).
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par xcomcmdr le 03 avril 2014 à 19:25. Évalué à 1.
        
        On peut toujours vouloir appeler une fonction sur un pointeur NULL parce qu'elle a des effets de bord
        
        Ah, la programmation par accidents, c'est une bonne méthode de nos jours ?
        
        Tout se perd…
        
        "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par arnaudus le 04 avril 2014 à 13:53. Évalué à 2.
        
        Ah, la programmation par accidents, c'est une bonne méthode de nos jours ?
        
        Je n'arrive pas à savoir si c'était ironique ou non, mais je connais de nombreux cas où les fonctions sont utilisées pour leurs effets de bord…
        
        plot(NULL, xmin=0, xmax=1, ymin=0, ymax=1);
        
        par exemple produit un graphe vide du plus bel effect. Si le type qui a codé le truc ne voyait pas l'intérêt de faire ça, il va tester si le float** que tu lui passes n'est pas NULL et ne va rien faire.
        
        Ça arrive super-souvent ce genre de trucs, et c'est super chiant : un type a décidé à ta place ce que tu devais faire ou non, alors que ça ne lui coutait rien.
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par Anonyme le 03 avril 2014 à 19:37. Évalué à -1.
        
        C'est EXACTEMENT ce que répond Microsoft quand tu demande pourquoi il n'est pas prévu de booter un autre OS.
        
        Sauf que ca n'a rien à voir. Booter un autre OS c'est une raison valable d'avoir une option pour ca. Changer le nom d'un fichier juste pour le plaisir de le changer, non.
        
        Ce n'est pas à toi de décider s'il y a des raisons valables de faire quelque chose ou non. Surtout pour du code libre : après tout, il est fait pour être réutilisé.
        
        C'est au developeur de choisir quelles parties il veut rendre configurables ou pas. Et au pire tu peux toujours patcher le code pour faire ce que tu veux, mais c'est pas au developpeur de se compliquer la vie pour te faciliter la tache pour faire un truc qu'il estime ne pas etre une bonne chose à faire.
        
        Et comme deja dit, il est toujours possible d'envoyer un patch pour rajouter l'option si vraiment ca sert à quelquechose.
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par Zenitram (site web personnel) le 03 avril 2014 à 19:50. Évalué à 1. Dernière modification le 03 avril 2014 à 19:51.
        
        Booter un autre OS c'est une raison valable d'avoir une option pour ca.
        
        Pas, c'est aussi valable que de vouloir changer le nom d'un fichier.
        Ca dépend du point de vue.
        Pour certains, booter un autre OS est une raison non valable (il faut tout faire pour l'empécher, quelle idée saugrenue, pire que de ovuloir changer le nom d'un fichier hard codé)
        
        c'est pas au developpeur de se compliquer la vie pour te faciliter la tache pour faire un truc qu'il estime ne pas etre une bonne chose à faire.
        
        Tu copies la réponse de Microsoft sur le boot sur un autre OS, la ;-).
        
        C'est au developeur de choisir quelles parties il veut rendre configurables ou pas.
        
        Donc il faut accepter quand Microsoft décide de ne pas te simplifier la vie lors d'un boot, il a décidé que c'était mieux.
        bizarrement, je connais une tonne de Linuxiens qui disent que c'est chiant quand c'est le développeur qui décider de quelles parties il veut rendre configurables ou pas (genre celles qui l'embètent, alors que quand ça l'embète pas les principes ne sont plus les mêmes).
        2 poids, 2 mesures.
        
        Et comme deja dit, il est toujours possible d'envoyer un patch pour rajouter l'option si vraiment ca sert à quelquechose.
        
        Bon, ça, raté pour Microsoft, certes, mais comme l'auteur uptream peut refuser ton patch aussi, car Microsft et l'auteur upstream (et toi) ont décidé que ce n'était pas une bonne chose (pourquoi Microsoft t'aiderai à faire un truc qui n'est pas une bonne chose genre mettre Linux en paralèle? Comme quoi la "pas une bonne chose" est relatif…).
        
        bref, reste à voir qui décide de ce qui est une bonne chose (pour ton bien, évidement).
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par Moonz le 03 avril 2014 à 19:53. Évalué à 1.
        
        Tu copies la réponse de Microsoft sur le boot sur un autre OS, la ;-).
        
        Je ne comprend pas du tout votre analogie. Depuis quand Microsoft interdit le dual-boot ?
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par Zenitram (site web personnel) le 03 avril 2014 à 20:04. Évalué à 3.
        
        Il ne l'interdit pas (comme un chemin hard codé n'interdit pas de changer le code source)
        Mais il n'aide pas non plus, en écrasant le boot en place si ce n'est pas un autre Windows plutôt que de s'ajouter, à toi de bidouiller (comme un chemin hard codé n'aide pas à changer facilement, il faut éditer le code on ne sait où et il faut recompiler)
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par oinkoink_daotter le 04 avril 2014 à 17:51. Évalué à 2.
        
        Mais il n'aide pas non plus, en écrasant le boot en place si ce n'est pas un autre Windows plutôt que de s'ajouter
        
        Selon quel standard ? :)
        Grub ? Grub2? Le grub 2 efi ? le grub qui fait du secure boot ? Lilo ? eLilo ? redboot ?
        
        Le but de windows, c'est quand même booter, non ?
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par Albert_ le 04 avril 2014 à 18:10. Évalué à 1.
        
        Le but de windows je suis pas sur que ce soit de booter, je ne suis meme pas sur qu'un logiciel est un quelconque but par contre le but de Microsoft c'est de faire du pognon et donc de vendre son logiciel et donc de faire en sorte de faire chier la concurrence et tu peux prendre n'importe quel autre systeme de boot Microsoft l'ecrasera. C'est l'ecrasement qui est critique par que Microsoft installe un truc pour booter.
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par oinkoink_daotter le 04 avril 2014 à 19:55. Évalué à 2.
        
        Je réitère ma question : comment fait Microsoft pour s'assurer que son système bootera (ou sera même bootable) après installation, en l'absence d'une norme quelconque de gestion du multiboot ?
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par pasBill pasGates le 04 avril 2014 à 20:20. Évalué à 1.
        
        Arretes, tu lui demandes un truc constructif sur Microsoft la, aucune chance que tu aies une reponse
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par Albert_ le 04 avril 2014 à 21:39. Évalué à -1.
        
        Maintenant à toi de répondre:
        
        Incompétence ou malveillance?
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par pasBill pasGates le 04 avril 2014 à 22:21. Évalué à 0.
        
        cf. ma reponse plus bas, incompetence, de ton cote comme d'habitude.
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par Albert_ le 04 avril 2014 à 22:41. Évalué à -1.
        
        Donc Microsoft a decider, comme toi, de prendre les gens pour des cons et en plus de les faire chier.
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par Batchyx le 04 avril 2014 à 21:13. Évalué à 6.
        
        Tu pourrai commencer par simplement poser la question avant d'écraser le putain de MBR. Ça réglerai une grande partie du problème. Point bonus: tu pourrai demander sur quel disque il faut installer le MBR. Parce que ce n'est pas forcement celui que tu croit que l'utilisateur veut écraser.
        
        Pour le reste, c'est un problème classique: Si tu veux que les gens puissent faire du multiboot qui soit capable de booter ton OS, alors tu rend ton OS simple à booter, tu documente comment il doit booter et tu laisse les autres implémenter le reste. La standardisation viendra naturellement après, quand les uns commenceront à copier les mécanismes de boot des autres.
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par oinkoink_daotter le 04 avril 2014 à 21:26. Évalué à 3.
        
        Point bonus: tu pourrai demander sur quel disque il faut installer le MBR. Parce que ce n'est pas forcement celui que tu croit que l'utilisateur veut écraser.
        
        Spa faux, ça.
        
        tu rend ton OS simple à booter,
        
        Ben stadire que si on parle du même OS, c'est assez simple en fait : en boîte noire, t'exécute le boot sector de la partition où ledit OS est installé (c'est ce que font d'ailleurs Grub et Lilo) et pouf. Après si tu veux savoir exactement comment ça boote, ben faut regarder microsoft.com, rayon msdn ou technet, c'est bien possible que ce soit écrit.
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par Batchyx le 04 avril 2014 à 21:47. Évalué à 2.
        
        Bizarre, parce que chez moi, ça, d'habitude ça marche, mais quand j'ai transformé la partition Windows en une partition logique sans changer son emplacement, et bien ça bootait plus du tout. Et c'était pas genre qu'il trouvais pas sa partition. En cherchant à corriger ça, Windows m'a installé un secteur de boot sur un splice FreeBSD …
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par oinkoink_daotter le 04 avril 2014 à 22:07. Évalué à 2.
        
        mais quand j'ai transformé la partition Windows en une partition logique sans changer son emplacement, et bien ça bootait plus du tout
        
        Dieu du ciel, quel pervers *tombe dans les pommes*.
        
        Je ne suis pas sur du tout que le grub d'un linux survive à ça non plus (et qu'ensuite un linux époque pre-jemetsdeslabelspartoutdansfstab arrive à faire quelque chose)
        
        Windows m'a installé un secteur de boot sur un splice FreeBSD …
        
        Tout le reste était "légal", genre partition étendue définie, partition logique à l'intérieur, pas de chevauchement, adressage LBA/CHS synchrone etc ? Parce que la le symptôme fait penser à une bouillie dans la table de partition.
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par Batchyx le 05 avril 2014 à 10:57. Évalué à 2.
        
        Un vieux lilo installé sur un secteur de boot d'une partition devrai s'en sortir. Le noyau bootera pas, mais lilo affichera au moins quelque chose. Pour grub, c'est sur qu'il s'en sortira, vu qu'il sait reconnaître des UUID/labels.
        
        Mais windows … affichait rien du tout et redémarrait. Et après on viens dire que c'est un OS facile à utiliser …
        
        Pour le splice FreeBSD, c'était la deuxième partition primaire, juste après l'espèce de première partition du bios/efi. La partition Windows était sur la troisième partition primaire avant.
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par oinkoink_daotter le 05 avril 2014 à 12:03. Évalué à 1.
        
        Le noyau bootera pas, mais lilo affichera au moins quelque chose.
        
        Wai, lil ou qqch du genre. Nan, je déconne, vu que lilo va chercher son stage 2 à un endroit absolu du disque ça devrait marcher.
        
        Pour grub, c'est sur qu'il s'en sortira, vu qu'il sait reconnaître des UUID/labels.
        
        A condition de ne pas avoir massacré l'endroit où le stage 1.5 est stocké.
        
        Et après on viens dire que c'est un OS facile à utiliser …
        
        Ben à utiliser, oui. Par contre quand le sysadmin fait des trucs hardcore… *retombe dans les pommes*
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par Batchyx le 05 avril 2014 à 18:14. Évalué à 2.
        
        A condition de ne pas avoir massacré l'endroit où le stage 1.5 est stocké.
        
        L'emplacement de la partition n'a pas changé, hein …
        
        Ben à utiliser, oui. Par contre quand le sysadmin fait des trucs hardcore… retombe dans les pommes
        
        Ça c'est loin d'être hardcore. Ceux qui sont hardcore, c'est ceux qui font ça sur un serveur pendant que le système tourne et qu'il y a des utilisateurs dessus.
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par Albert_ le 04 avril 2014 à 21:27. Évalué à 4.
        
        Premièrement en n'ecrasant pas l'existant sans poser une question.
        
        Deuxièmement ils sont vraiment géniaux les développeurs de grub, lilo, et cie car eux ils arrivent à le faire, installer un boot loader sans écraser comme un bourrin le précédent et en prime en le rajoutant dans le menu de démarrage. Donc franchement des génies ou chez Microsoft ils sont débiles ou il existe une volonté de faire chier du côté de redmond.
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par oinkoink_daotter le 04 avril 2014 à 21:56. Évalué à 2.
        
        Premièrement en n'ecrasant pas l'existant sans poser une question.
        
        Oui. Cela dit, il faudrait se poser la question de comment on détecte l'existant, mais ok.
        
        [Microsoft c'est Belzebuth]
        
        N'imp.
        
        Tout d'abord, il est beaucoup plus facile pour les concurrents de fonctionner pour l'OS dominant que l'inverse. Ben oui, MS en face devrait regarder comment détecter et booter tous les concurrents. Rappelons que Windows ne parle pas ext2/3/4, BTRFS ou n'importe quel autre FS linux, bsd ou solarissien. Enfin, je me rappelle d'une époque ou quand Lilo s'installait, il fallait rajouter l'entrée à la main si on voulait booter un windows. Tiens d'ailleurs c'est toujours pas net net la gestion du grub entre deux distribs installée côte à côte quand on met à jour les noyaux et que le script automatique de grub met à jour le menu.lst/cfg.
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par Albert_ le 04 avril 2014 à 22:53. Évalué à 1.
        
        Pour Lilo ca fait bien longtemps que le probleme a ete regle non? Ne serait ce que en passant par Grub. Facilement plus de 10 ans, je veux bien que les devs de Microsoft soient cons (et c'est pas ce que je pense) mais tout de meme 10 pour faire un boot loader multi-OS cela aurait pu se faire SI ils avaient voulu mais comme ils veulent faire chier ils le font pas, comme MS Office sous linux. Exactement la meme problematique. Ils ont eu raison tu vas me dire, ils ont arnaque tout le monde pendant plus de 15 ans comme cela et s'en mettant plein les poches.
        
        Mais bon aujourd'hui quand tu veux un truc serieux c'est pas tres complique pour les serveurs c'est du linux, pour les desktop c'est du mac et pour les tablettes/telephone c'est du mac ou android.
        
        Apres windows resiste encore sur les pc pour deux raisons:
        
        1- la vente lie
        2- les vieilles applis metier
        
        mais le 1 comme les ventes de pc decroissent exponentiellement ca va pas etre aussi rentable et le 2 avec la virtualisation cela ne devient plus un probleme. Oh il y a encore des "decidors" has been ou corrompus mais bon la tendance est pas en faveur de MS loin de la.
        
        En ce qui concerne Grub j'ai jamais eu de probleme avec plusieurs linux mais bon je dois etre chanceux (et j'ai pas fait ca souvent :) )
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par oinkoink_daotter le 04 avril 2014 à 23:13. Évalué à 2.
        
        Apres windows resiste encore sur les pc pour deux raisons:
        […]
        
        3- Les jeux
        4- L'habitude
        
        En ce qui concerne Grub j'ai jamais eu de probleme avec plusieurs linux
        
        Imagine que tu as 2 linux, A et B.
        
        Tu installes A. A install GrubA.
        Tu installes B. Se pose la question de savoir 1/si tu gardes GrubA, 2/tu installes GrubB par dessus GrubA.
        Dans un cas comme dans l'autre, il va falloir choisir si tu chainloades l'autre bootloader ou si tu vas juste aller chercher les noyaux de l'autre Linux. Mais dans ce dernier cas, tu prends quoi comme variables de grub, celles de A ? Celles de B, celles de A pour A, celles de B pour B ? Si tu as un thème grub sur chaque distrib, tu auras lequel au final ?
        
        Maintenant, imagine que la configuration de grub est générée par A, tu bootes B et tu installes un nouveau noyau, il faut modifier quel grub.cfg ? Celui de B ? Ca ne marchera que si B a été programmé pour écraser le MBR. Celui de A ? Pour ça il faut rebooter sur linux A et régénérer la conf.
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par Albert_ le 04 avril 2014 à 23:27. Évalué à 2.
        
        3 - les jeux ca passe de plus en plus sur les consoles et sinon c'est majoritairement du steam ou similaire.
        
        4 - Les habitudes : windows 8 a bien tout casse sur ce sujet et de tout de facon je suis persuade (et c'est ce que montre les chiffres) que les gens sont en train de migrer du pc a la tablette donc les habitudes ca se change.
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par oinkoink_daotter le 05 avril 2014 à 00:06. Évalué à 2.
        
        3 - les jeux ca passe de plus en plus sur les consoles et sinon c'est majoritairement du steam ou similaire.
        
        N'en reste pas moins que même sur steam, y a quasi rien sous linux par rapport à windows
        
        4 - Les habitudes : windows 8 a bien tout casse sur ce sujet
        
        C'est bien pour ça que le nouveau patron de crosoft fait machine arrière toute et remet un vrai menu démarrer dans le prochain update. Avec la possibilité de démarrer en mode bureau, ca redeviendra comme "avant". (et je le regrette, parce que le mode bureau sur tablette, c'est insupportable, à commencer par le clavier virtuel qui ne sort pas tout seul quand tu cliques sur une zone de texte; full disclore, j'aime bien metro en fait - sur tablette tactile)
        
        les gens sont en train de migrer du pc a la tablette
        
        PAr contre c'est loin d'être exponentiel comme tu le dis plus haut (ou bas?) dans la page.
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par Albert_ le 05 avril 2014 à 00:13. Évalué à 3.
        
        Ok c'est pas exponentiel j'ai un peu exagere mais je pense serieusement que chez les particuliers c'est vraiment en train de sortir de la maison les pc soit pour les tablettes et/ou pour les smart TV et honnetement pour 95% des gens c'est plus que largement suffisant.
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par pasBill pasGates le 04 avril 2014 à 22:20. Évalué à 1. Dernière modification le 04 avril 2014 à 22:23.
        
        Premièrement en n'ecrasant pas l'existant sans poser une question.
        
        Et tu poses quoi comme question exactement ?
        
        Sachant que l'utilisateur moyen n'a aucun moyen de comprendre ce qu'est un bootloader, voire meme un OS, et que Windows ne connaissant pas les formats des 4325 bootloaders qui changent tout le temps, il ne peut pas faire d'inference sur le contenu du MBR pour savoir si c'est du bordel ou un vrai bootloader.
        
        Deuxièmement ils sont vraiment géniaux les développeurs de grub, lilo, et cie car eux ils arrivent à le faire, installer un boot loader sans écraser comme un bourrin le précédent et en prime en le rajoutant dans le menu de démarrage. Donc franchement des génies ou chez Microsoft ils sont débiles ou il existe une volonté de faire chier du côté de redmond.
        
        Non, ils ont simplement 1% des systemes que doit gerer MS, et ils ont des utilisateurs en moyenne beaucoup, beaucoup plus experimentes que l'utilisateur Windows moyen ce qui facilite enormement la vie.
        
        Alors MS a le choix entre mettre un boulot de taille serieuse, avec un resultat qui va interloquer la grosse majorite de leurs utilisateurs et potentiellement leur causer des problemes, histoire que moins de 1% de la population, qui eux sont debrouilles d'habitude, n'aient pas a faire une petite manip a la fin, ou bien ecraser le MBR car dans l'enorme, enorme, enorme majorite de cas, c'est exactement ce que l'utilisateur veut.
        
        Tout chef de projet, developpeur, etc… avec un minimum de jugeotte prendra la meme decision que MS dans cette situation.
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par oinkoink_daotter le 04 avril 2014 à 22:25. Évalué à 3.
        
        Et tu poses quoi comme question exactement ?
        
        "Do you want to scratch bootloader" ?
        Pis tu peux rajouter comme dans la configuration du noyau linux pour la compil "if unsure, say yes".
        
        :-)
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par Albert_ le 04 avril 2014 à 22:44. Évalué à -1.
        
        Ah mais non d'apres Billou les utilisateurs sont trop cons pour une question comme celle la…
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par pasBill pasGates le 04 avril 2014 à 23:29. Évalué à 0.
        
        C'est ce que certains (heureusement que t'as mis le smiley :) ) penseraient, et viendrait alors :
        
        Pourquoi poser une question pareille a 99% des gens qui n'en ont rien a faire ?
        
        Pourquoi les apeurer pour eviter 5 minutes de travail a 1% de la population ? (ouh la, le systeme va EFFACER QUELQUE CHOSE !!!!, appelons le support !)
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par Shuba le 04 avril 2014 à 23:36. Évalué à 5.
        
        La plupart des installeurs de logiciels sous windows sont remplis d'options cochées par défaut, et 99% des gens n'en ont rien à faire et cliquent sans regarder. Ça pourrait être raisonnable présenté comme celà non?
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par pasBill pasGates le 04 avril 2014 à 23:53. Évalué à 1.
        
        De nouveau, pourquoi ajouter une option qui va faire peur a plein de gens (ouh la, ca efface des trucs), et qui ne sert qu'a moins de 1% de la population ?
        
        Quel benefice pour 99% des gens ? Aucun au contraire, ca rend l'experience pire, ca va empecher certains d'utiliser leur ordinateur immediatement car ils ont peur des implications
        Quel benefice pour MS ou Windows ? Aucun
        
        Tout ca pour faire plaisir a moins de 1% de la population, des gens qui pour nombre d'entre eux ne sont meme pas interesses par Windows du tout ? Ca n'a absolument aucun sens.
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par Shuba le 05 avril 2014 à 09:35. Évalué à 3.
        
        L'option pourrait être présent uniquement dans un mode avancé par exemple, est-ce que ça serait si effrayant que ça?
        
        Après oui MS n'y trouverait pas de bénéfice immédiat, donc j'imagine bien qu'il ne le feront pas, mais c'est pas parce qu'il n'est pas possible de le faire sans effrayer les gens (on pourrait même imaginer une combinaison clavier précise à effectuer à un moment donné pour montrer cette option, ça ne dérangerait probablement pas les 1% qui veulent mettre un linux).
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par pasBill pasGates le 07 avril 2014 à 01:21. Évalué à 3.
        
        Mais bien sur que cela serait possible !
        
        Mais mets toi a la place d'un chef de projet pour Windows.
        
        Il y a 40'000 trucs qu'il peut ajouter, chacun qui va ameliorer Windows pour 2%, 3%, 95% des utilisateurs de Windows, et il y a ca qui arrive sur son bureau.
        
        Ca tombe ou dans les priorites ? Tout en bas evidemment.
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par Anonyme le 07 avril 2014 à 12:28. Évalué à 1.
        
        Il y a 40'000 trucs qu'il peut ajouter, chacun qui va ameliorer Windows pour 2%, 3%, 95% des utilisateurs de Windows, et il y a ca qui arrive sur son bureau.
        Ca tombe ou dans les priorites ? Tout en bas evidemment.
        
        Voir meme priorité negative, par ce que ca simplifie la vie des gens qui voudraient commencer à se passer de Windows. Par ce que je doute que ca soit la charge de travail que represente l'ajout d'une telle option qui empeche que ca soit fait.
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par pasBill pasGates le 07 avril 2014 à 18:48. Évalué à 4.
        
        Ah la charge de travail….
        
        Si c'etait le seul element qui entre en compte dans l'ajout de features dans un programme ca se saurait.
        
        Quel effet cela a sur les utilisateurs ?
        
        Quel risque cela pose aux utilisateurs ? (chances que cela casse qqe chose, que cela les pousse a faire la mauvaise chose, etc…)
        
        Quel cout en test ?
        
        Quel cout en support ? (est-ce que les utilisateurs vont se mettre a appeler car ils ne comprennent pas , ils ont peur, …) …
        
        Faut sortir un peu de ce monde OSS ou il n'y a quasiment pas de test, pas de support, ou l'utilisateur n'a qu'a RTFM. Le monde exterieur, qui est 99% du marche Desktop ne ressemble pas a ca.
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par totof2000 le 08 avril 2014 à 09:46. Évalué à 3.
        
        Faut sortir un peu de ce monde OSS ou il n'y a quasiment pas de test, pas de support, ou l'utilisateur n'a qu'a RTFM. Le monde exterieur, qui est 99% du marche Desktop ne ressemble pas a ca.
        
        Le marché desktop est je pense un des pires marché de l'informatique. Je ne suis pas sur qu'il soit aussi rentable que ça d'ailleurs, vu toutes les contraintes que celà apporte, et il est logique que seule une grosse structure comme Microsoft puisse avoir les reins solides pour y rester.
        
        Google s'y met, mais ses revenus ne viennent pas de la vente d'OS mais de l'utilisation de ses services et de la pub. L'OS n'est plus un but mais un moyen. Et là encore, c'est une grosse structure avec beaucoup de moyens qui tient la route.
        
        Le marché serveur, qui s'adresse à des admins plus aguerris et habitués à l'info doit être plus simple et plus rentable. C'est d'ailleurs pour ça que Linux s'y est développé, de même pour le marché de l'embarqué ou il n'y a pas ou peuu d'interactivité avec l'utilisateur.
        
        Je pense que c'est difficile à comprendre pour quelqu'un qui n'a jamais fait de support utilisateur "de base" ;)
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par Anonyme le 08 avril 2014 à 15:50. Évalué à 2.
        
        On parlait d'une option présente uniquement dans un mode avancé, donc que les utilisateurs normaux ne sont pas censés voir.
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par khivapia le 10 avril 2014 à 09:53. Évalué à 3.
        
        ce monde OSS ou il n'y a quasiment pas de test,
        Ce n'est pas mon impression : par le simple fait que l'équipe qui développe un logiciel libre est largement ouverte à la collaboration extérieure et non pas une équipe restreinte, il faut être très rigoureux et notamment pousser les tests (notamment unitaires et de régression) assez loin.
        Sinon la faible communication au sein d'une équipe répartie sur toute la planète plutôt que dans le même openspace va vite rendre les choses difficiles.
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par Albert_ le 11 avril 2014 à 17:48. Évalué à 2.
        
        Tu sais son ex-~~secte~~boite a toujours fait des tests de premiere classes et les updates ne foirent jamais chez eux et la sécurité c'est le top du top, a tel point que l'on peut vivre sans antivirus sur leurs OS depuis toujours. Ne parlons pas de la quantité de matis et de plateforme supportes sans compter les compagnies qui viennent écraser leur boot:
        
        http://www.zdnet.com/uefi-and-windows-8-update-on-windowslinux-dual-boot-systems-7000028217/
        
        mais non ce n'est pas de la malveillance si un update de windows modifie l'ordre de boot de UEFI cela a été teste par Microsoft…
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par pasBill pasGates le 11 avril 2014 à 19:29. Évalué à -1.
        
        a toujours fait des tests de premiere classes
        
        C'est tout a fait vrai, ravi que tu t'en sois finalement rendu compte !
        
        les updates ne foirent jamais chez eux
        
        Tu exageres, on va dire "tres tres rarement" plutot
        
        la sécurité c'est le top du top
        
        Effectivement, ravi que tu aies enfin realise ce que toute l'industrie de la securite dit
        
        a tel point que l'on peut vivre sans antivirus sur leurs OS depuis toujours
        
        Si tu evites de lancer kournikova.exe oui certainement, comme sous Linux quoi
        
        mais non ce n'est pas de la malveillance si un update de windows modifie l'ordre de boot de UEFI cela a été teste par Microsoft…
        
        Non, c'est juste toi qui comme d'habitude fait des commentaires sans meme chercher a comprendre le pourquoi du comment, mais bon, on commence a avoir l'habitude
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par Albert_ le 13 avril 2014 à 22:58. Évalué à 1. Dernière modification le 13 avril 2014 à 23:00.
        
        man ironie
        
        et en effet je sais je sais tu le dis suffisamment que je suis debile, c'est pas un probleme pour moi et donc si c'est pas fait expres le coup de l'UEFI c'est que c'est de l'incompetence et sinon tu vas expliquer la troisieme possibilite.
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par pasBill pasGates le 14 avril 2014 à 06:39. Évalué à 1.
        
        Je n'ai rien a t'expliquer, tu n'as jamais cherche ni fait l'effort en plusieurs annees de regarder si il pouvait y avoir quoi que ce soit d'autre dans les decisions de MS que de l'incompetence ou de la volonte de creer des dommages.
        
        Partant de la, il est inutile de perdre du temps a t'expliquer des choses dont tu te fous totalement vu que ton seul objectif est de cracher ton venin sur cette boite.
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par Albert_ le 14 avril 2014 à 10:30. Évalué à -2.
        
        Et voila donc tu insultes gratuitement et tu n'as strictement aucun argument ni preuves que je raconte des conneries. Tu joues a la methode coue en resume. Crois tu que cela a jamais fonctionne?
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par pasBill pasGates le 14 avril 2014 à 18:56. Évalué à 0.
        
        Je n'ai aucun besoin de prouver que tu racontes des conneries, c'est toi qui accuses, c'est a toi de prouver que MS l'a fait par incompetence ou malice.
        
        Et comme 99.5% de tes posts, tu n'as jamais amene la moindre once de preuve de tes dires, tu regardes un ou deux symptomes et tu en tires la conclusion que tu veux car ca arrange ta haine de MS. Tu fais toujours bien attention a ne pas chercher la moindre explication qui pourrait amener a une autre conclusion.
        
        Pathetique comme approche, mais bon, avec toi on commence a avoir l'habitude.
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par Albert_ le 15 avril 2014 à 07:19. Évalué à -3. Dernière modification le 15 avril 2014 à 07:22.
        
        Je n'ai aucun besoin de prouver que tu racontes des conneries, c'est toi qui accuses, c'est a toi de prouver que MS l'a fait par incompetence ou malice.
        
        Absolument pas c'est toi qui pretend que ce n'est ni l'un ni l'autre et donc c'est a toi de donner la troisieme possibilite. Je n'ai absolument pas demande que tu prouves la troisieme possibilite mais que tu dises ce que cela peut etre mais visiblement tu n'en as strictement aucune idee, ce qui ne me surprend pas trop…
        
        Je n'ai donc absolument pas a donner de preuves et je laisse les personnes de ce site juge eux meme sur le sujet. Personnelement je ne prends pas les gens pour des debiles. Mais par contre TU pretends que ces deux hypothes sont fausses par consequent c'est a toi d'apporter la preuve (ou un autre hypothese valable) qui expliquent cela.
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par pasBill pasGates le 15 avril 2014 à 08:00. Évalué à 1.
        
        Absolument pas c'est toi qui pretend que ce n'est ni l'un ni l'autre et donc c'est a toi de donner la troisieme possibilite. Je n'ai absolument pas demande que tu prouves la troisieme possibilite mais que tu dises ce que cela peut etre mais visiblement tu n'en as strictement aucune idee, ce qui ne me surprend pas trop…
        
        LOL. Quelle belle logique : Un FUDeur lance des rumeurs, et l'onus est aux autres de prouver qu'il a tort. Tu fais vraiment pitie.
        
        Je n'ai donc absolument pas a donner de preuves et je laisse les personnes de ce site juge eux meme sur le sujet. Personnelement je ne prends pas les gens pour des debiles.
        
        Pas a donner de preuves ? Ah oui tiens, allez, balancons des conneries, pas besoin d'etayer ses dires !! C'est a l'accuse de prouver son innocence !
        
        Personnelement je ne prends pas les gens pour des debiles.
        
        Oh que si justement, car tu sors constamment connerie sur connerie a la maniere d'un propagandiste de bas etage.
        
        Et le pire c'est que sais parfaitement quel jeu tu joues, tu es parfaitement conscient de la strategie degueulasse que tu utilises, et c'est vraiment repugnant.
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par ZeroHeure (site web personnel) le 15 avril 2014 à 10:47. Évalué à 10.
        
        Eh oh, merci de vous calmer tous les deux. Y'a vraiment pas de quoi s'insulter. Respirez un coup, faites une pause à la fenêtre.
        
        "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par Albert_ le 15 avril 2014 à 12:52. Évalué à -4.
        
        Tu remarqueras que JE ne l'ai pas insulte ce qui n'est pas son cas vu qu'il n'arrete pas de "suggerer" tres gentiment que je suis un parfait debile.
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par oinkoink_daotter le 15 avril 2014 à 13:11. Évalué à 9.
        
        Force est de constater que tu le traites assez régulièrement de menteur, ce qui à ma connaissance est insultant.
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par Albert_ le 15 avril 2014 à 12:56. Évalué à -3.
        
        Donc tu n'as toujours pas de 3eme possibilite. Donc je FUD (peut etre) mais au moins j'appelle ca des possibilites, des hypotheses. Je comprend que vu que tu n'arrives pas a trouver une raaison valable qui puisse justifier le changement d'ordre dans l'UEFI cela t'enerve un peu.
        
        Mais donne donc une raison valable differente de l'incompetence (tout le monde a le droit de faire une erreur) ou que cela soit fait pour embeter les dual booter, je suis tres tres curieux de la connaitre. Ceci contrairement a ce que tu dis n'est pas un FUD mais une QUESTION. Auquel je ne te demande pas d'apporter de preuves juste de proposer une autre hypothese.
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par oinkoink_daotter le 15 avril 2014 à 13:20. Évalué à 4.
        
        Auquel je ne te demande pas d'apporter de preuves juste de proposer une autre hypothese.
        
        Il te l'a expliquée 42 fois : sur le desktop Linux n'est pas vraiment un concurrent de Windows (en terme d'argent). Partant de là, il n'est pas vraiment choquant à mon sens que le truc cherche à booter par tous les moyens, sachant que de toute façon les enthousiastes sauront facilement retomber sur leurs pieds.
        Que ça te plaise ou non, linux reste dans l'épaisseur du trait niveau part de marché sur le desktop, et à ma connaissance on se fout d'avoir des serveurs multiboot.
        Quand un pourcentage significatif de gens gueulera à cause de ça, Microsoft reconsidèrera sa position. Pour le moment, ne sont embêtés que les gens avec un linux qui en plus utilisent un Windows.
        Bref, pas un scandale.
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par Albert_ le 15 avril 2014 à 16:06. Évalué à -1.
        
        Ceci explique le fait de ne pas fournir un boot loader mais le fait de changer l'ordre de boot choisit par l'utilisteur dans UEFI ca c'est une autre histoire.
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par lasher le 15 avril 2014 à 22:41. Évalué à 6.
        
        Quand un pourcentage significatif de gens gueulera à cause de ça, Microsoft reconsidèrera sa position. Pour le moment, ne sont embêtés que les gens avec un linux qui en plus utilisent un Windows.
        
        C'est d'ailleurs ce qu'a fait Apple pour BootCamp etc. : un certain nombre de personnes voulaient un Windows parce que c'était pour le boulot, parce que y'a tel ou tel jeu qui ne marche pas sous MacOS X, etc.
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par oinkoink_daotter le 15 avril 2014 à 13:42. Évalué à 2.
        
        Chacun ses travers, toi tu quand ça devient gênant, tu évites soigneusement de répondre.
        Exemple : https://linuxfr.org/users/ben_le_sphinx/journaux/fin-du-support-de-ms-windows-xp, plus particulièrement les commentaires https://linuxfr.org/users/ben_le_sphinx/journaux/fin-du-support-de-ms-windows-xp#comment-1525160, https://linuxfr.org/users/ben_le_sphinx/journaux/fin-du-support-de-ms-windows-xp#comment-1526208 et https://linuxfr.org/nodes/101426/comments/1525456 où je t'indique à plusieurs reprises la taille occupée par Windows 8.1 sur une surface pro 2 qui semble indiquer que le windows en question est plutôt un gros bébé.
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par Albert_ le 15 avril 2014 à 16:08. Évalué à 0.
        
        Je n'insulte pas et le fait de ne pas repondre je pense que sur le sujet il n'a pas a dire quoique ce soit (ni quiconque).
        
        Quand a tes liens je ne vois pas de question me concernant peut etre peux tu etre plus explicite et puis a certains moment je prefere ne pas repondre a quelqu'un qui m'insulte de facon systematique. Cela ne surprendra personne je suppose.
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par oinkoink_daotter le 16 avril 2014 à 09:46. Évalué à 3.
        
        T'as percuté que c'est à pbpg< que je réponds et pas à toi ?
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par Albert_ le 16 avril 2014 à 14:53. Évalué à 2.
        
        Oups non desole :)
        
        Mode reaction trop rapide enclenche… toutes mes excuses.
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par Albert_ le 15 avril 2014 à 16:15. Évalué à 0.
        
        merde la correction a pas ete assez rapide:
        
        Je n'insulte pas et le fait de ne pas repondre je pense que sur le sujet il n'a pas a dire quoique ce soit (ni quiconque).
        
        Quand a tes liens je ne vois pas de question me concernant peut etre peux tu etre plus explicite et puis a certains moment je prefere ne pas repondre a quelqu'un qui m'insulte de facon systematique. Cela ne surprendra personne je suppose.
        
        Je suis ravi de savoir que la taille de windows sur les forums peut etre descendu, je n'y suis pas arrive personnellement. J'ai montre certains screenshot sur le sujet pour prouver mes dires mais bon je vais pas me fatiguer plus. J'ai demande ce qui pouvait etre en trop, comment tenter de faire maigrir le bousin, j'ai eu quelques liens que j'ai teste (qui n'ont pas fait grand chose) et des insultes. Au bout d'un moment j'en ai un peu assez des insultes. Je pense que c'est comprehensible. Il me prend pour un debile et il sait exactement ce que pense de lui: que c'est un personnage imbus de sa petite personne sur internet, pretentieux comme pas deux et malpoli. Que ca l'emmerde que je sois sur ce site dedies au logiciels libre et a linux dont je suis utilisateur c'est son probleme, si il n'aime pas ma presence, il peut aller voir ailleurs voir arreter de lire mes posts et d'y repondre. Personnne ne le force a le faire et personne ne le force a insulter les gens qui ne sont pas d'accord avec lui.
        
        J'ai ce truc sur une partition separe, aujourd'hui vu que le pc est neuf cela ne me pose pas de probleme le jour ou j'aurai besoin de la place il degagera.
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par pasBill pasGates le 15 avril 2014 à 21:06. Évalué à 1.
        
        J'ai demande ce qui pouvait etre en trop, comment tenter de faire maigrir le bousin, j'ai eu quelques liens que j'ai teste (qui n'ont pas fait grand chose) et des insultes. Au bout d'un moment j'en ai un peu assez des insultes. Je pense que c'est comprehensible.
        
        Si seulement c'etait vrai. Le truc c'est que tu n'as pas hesite une seconde a affirmer que Windows prenait >20Gb de base. Tu n'as jamais laisse la place a l'hypothese que tu aurais rate un truc, non comme d'habitude tu as affirme quelque chose de totalement faux sur Windows/MS en le posant comme si c'etait un fait avere. Et ca fait des annees que tu joues ce petit jeu pourri.
        
        Avec un comportement pareil, rien d'impressionant au fait que tu sois traite d'incompetent ou FUDeur, c'est le resultat de ton comportement. Tu ne l'aimes pas ? Change de comportement.
        
        Personnne ne le force a le faire et personne ne le force a insulter les gens qui ne sont pas d'accord avec lui.
        
        Mes reponses a tes posts ne te sont pas destinees, elle n'ont pas pour but de te faire changer d'avis, ni de t'expliquer quoi que ce soit, parce que tout le monde sait parfaitement que tu n'as jamais ete interesse par la verite, ton objectif n'a jamais ete autre que cracher ton venin sur MS, peu importe la realite des choses.
        Je reponds pour que les gens qui lisent ce forum aient la possibilite d'avoir un contre-argument a tes salades.
        
        Pour le reste :
        1) Te traiter d'incompetent et FUDeur n'est pas une insulte (tu devrais acheter un dictionnaire pour comprendre ce mot), c'est simplement une realite.
        2) Venant de qq'un qui me traite de :
        - menteur
        - connard ( http://linuxfr.org/users/dcp/journaux/systemd-vs-linux-quand-l-intransigeance-d-un-developpeur-tourne-au-ridicule#comment-1530619 )
        - vendu / paye par ma boite pour etre la
        - …
        
        et que tu n'as pas hesite a mettre des infos me concernant en publique ici, ce qui t'a valu de te faire ejecter ton compte par les admins, on va dire que tu fais bien attention a ne pas regarder la poutre qui est dans ton oeil
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par Albert_ le 16 avril 2014 à 15:05. Évalué à 0.
        
        Je ne vais pas repondre point par point a ta prose. Ca me fatigue trop juste un truc va reprendre des cours de francais.
        
        Ils agissent comme de gros connards
        
        Meme si tu es plusieurs personnes dans ta tete (et si c'est le cas je ne suis pas au courrant) cela ne concene pas "monsieur" pbpg et de plus en francais "agir comme" ne veut pas dire "etre un". Donc non je n'ai jamais dit que TU etais un connard. Peut etre que je le pense ou peut etre pas mais quoiqu'il en soit je ne l'ai pas dit dans le lien que tu donnes.
        
        Le reste je pourrai y repondre aussi mais je n'en ai pas besoin vu que tu "dis" que j'ai dit quelques choses mais sans apporter les preuves (d'ailleurs "…" ca c'est une sacre insulte :) )
        
        sur ce, ce fil devenant particulierement illisible et surtout totalement HS et inutile je vais te laisser et aller m'occuper de chose nettement plus interessante que de faire monter ta tension.
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par pasBill pasGates le 16 avril 2014 à 20:54. Évalué à -1.
        
        cela ne concene pas "monsieur" pbpg
        
        Non bien sur, tu parles des employes de MS, tu sais parfaitement que j'ai bosse des annees la-bas, mais non voyons, ca ne me concerne pas
        
        Le reste je pourrai y repondre aussi mais je n'en ai pas besoin vu que tu "dis" que j'ai dit quelques choses mais sans apporter les preuves
        
        Preuves ?
        
        Menteur : http://linuxfr.org/users/pied/journaux/microsoft-sort-un-pilote-libre-du-flan#comment-1052081 et http://linuxfr.org/users/pied/journaux/microsoft-sort-un-pilote-libre-du-flan#comment-1052285 entre autres
        
        On notera d'ailleurs que c'est toi qui ment dans le dernier post, en effet, tu n'etais pas 'parti' du site, tu t'etais fais virer par les admins
        
        Vendu / payer pour etre ici : http://linuxfr.org/users/zaurus/journaux/plus-deee-pc-vendus-sous-linux-par-defaut#comment-1200324 et de nombreux autres
        
        Virer du site, c'est deja mentionne sur http://linuxfr.org/users/pied/journaux/microsoft-sort-un-pilote-libre-du-flan et ca c'est passe ici : http://linuxfr.org/users/anonyme/journaux/odf-et-microsoft-office-2007-sp2-suite-et-surement-pas-fin#comment-1030857
        
        Mais comme d'hab, quand on te met le nez dans le merde, tu pars vite te cacher.
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par Albert_ le 17 avril 2014 à 08:15. Évalué à 0.
        
        Mais comme d'hab, quand on te met le nez dans le merde, tu pars vite te cacher.
        
        Je ne me cache pas mais je ne repondrai pas car j'ai deja repondu a tout cela depuis bien longtemps et dire que tu es un menteur (en le prouvant), que tu es payye par la boite pour laquelle tu travaillais (je pense pas que tu faisais du benevolat) et que je me sois fait fermer un compte (je vois meme pas pourquoi tu as sorti cette attaque de nulle part de ton chapeau) lorsque j'en avais deux je ne vois pas comment l'on peut dire que j'ai ete virer du site vu que j'ai toujours celui la mais c'est pas grave, que j'ai ete vire ou pas je suis toujours la. J'ai peut etre "insulte" une des personnes se cachant derriere le pseudo pbpg il y a 5 ans mais voila il y a 5 ans. Toi cela fait 15 ans que tu insultes les gens en desaccord avec toi et tu ne t'es jamais arrete voir tu empires carrement avec le temps.
        
        Maintenant, comme tu ne sais pas lire, je vais me repeter en hurlant:
        
        J'ARRETE CE FIL DE "DISCUSSION".
        
        Donc je ne me cache pas j'en ai juste assez et je trouve cela totalement ininteressant. Tu penses que je suis un debile et un con. J'ai le droit de penser ce que je veux de toi.
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par pasBill pasGates le 15 avril 2014 à 20:55. Évalué à 0.
        
        Besoin de repondre ?
        
        Il y a qq'un (pas moi donc) sur ce meme journal qui a fait l'essai pour verifier mes dires, et qui a fini son install en moins de 10Gb ( commentaire : http://linuxfr.org/users/ben_le_sphinx/journaux/fin-du-support-de-ms-windows-xp#comment-1525935 )
        
        Résultat 10G à l'installation. Je n'ai bêtement pas pris de capture d'écran, mais j'avais 29G de libre sur 39.
        
        Que veux tu que je rajoutes de plus ? La question etait : quelle est la taille minimale d'installation d'un Windows, la reponse est la, exactement comme je l'avais dite.
        
        Ton Surface Pro, a toi de regarder ce qu'il contient, je suis pas (plus) le support technique de MS, j'ai pas acces a ta machine ou un Surface Pro pour regarder, et si je devais faire ce genre d'effort pour chaque personne sur linuxfr.org qui me dit qu'il aimerait savoir pourquoi Windows fait/ne fait pas X,Y,Z j'aurais du boulot pour 3 personnes a plein temps.
        
        Oh et vu qu'on est sur le sujet des installs minimales :
        
        http://blogs.windows.com/windows/b/springboard/archive/2014/04/10/what-is-windows-image-boot-wimboot.aspx
        
        Windows 8.1 Update a un nouveau format d'installation qui permet des installs completes en 4Gb, partion de sauvegarde incluse.
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par pasBill pasGates le 11 avril 2014 à 19:26. Évalué à 1.
        
        Moi je me contentes de comparer a ce que j'ai vu.
        
        Je prends Samba par exemple, ce qu'ils ont en tests est :
        
        a) Plus que la grande majorite des projets open source
        b) Bcp moins que ce que MS a
        
        Si ca se trouve, Samba a bcp plus que la grande majorite des boites proprios, ca je peux pas comparer, j'en connais que 2 de l'interieur, mais quand je compares a ce que je connais, ben il n'y a pas photo.
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par xcomcmdr le 05 avril 2014 à 11:36. Évalué à 3. Dernière modification le 05 avril 2014 à 11:38.
        
        De nouveau, pourquoi ajouter une option qui va faire peur a plein de gens (ouh la, ca efface des trucs), et qui ne sert qu'a moins de 1% de la population ?
        
        C'est pas comme si c'était la première fois :
        - l'inclusion du clavier américain par défaut (à qui ça sert ? Et c'est super sympa de se retrouver en qwerty le jour où on fait sans le savoir la combinaison de touches pour changer de clavier)
        - l'aide qui te demande nawak
        - Word qui me pose une question WTF
        
        Mais je suis d'accord, ça n'a aucun intérêt. Et c'est même une question obsolète si on a une table de partition GPT, où chaque bootloader va se mettre sur la partition EFI, sans gêner les autres.
        
        Adieu le MBR de merde !
        
        "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par claudex le 05 avril 2014 à 12:01. Évalué à 3.
        
        Mais je suis d'accord, ça n'a aucun intérêt. Et c'est même une question obsolète si on a une table de partition GPT, où chaque bootloader va se mettre sur la partition EFI, sans gêner les autres.
        
        La bonne blague, quand Windows s'installe en UEFI, il se met en boot par défaut. Du coup, ça revient au même pour l'utilisateur final.
        
        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par xcomcmdr le 05 avril 2014 à 13:19. Évalué à 1.
        
        C'est moins compliqué et bien plus raide de changer de bootloader dans l'interface EFI que de remettre "le bon MBR" avec un Live-CD.
        
        "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par Albert_ le 05 avril 2014 à 21:49. Évalué à -6.
        
        Que pbpg dise que c'est inutile a Microsoft, c'est totalement vrai mais par contre c'est bien encore une fois le meme cas de figure que avec les navigateurs internet et un abus de position dominante.
        
        Je suis persuade que c'est faisable de leur part, ils ne veulent pas le faire comme ils ne voulaient pas d'autre navigateur internet que IE6.
        
        Ils agissent comme de gros connards en ecrasant le boot loader parcequ'ils savent que personne ne va rien leur dire. Imaginer l'inverse et les cris que l'on entendrait sur le sujet.
        
        Ce comportement montre bien la mentalite de cette boite.
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par pasBill pasGates le 07 avril 2014 à 01:23. Évalué à 1.
        
        Que pbpg dise que c'est inutile a Microsoft, c'est totalement vrai mais par contre c'est bien encore une fois le meme cas de figure que avec les navigateurs internet et un abus de position dominante.
        
        Lol, tes connaissances en droit sont aussi elevees qu'en informatique visiblement.
        
        Ils agissent comme de gros connards
        
        C'est quand meme beau comme tu te plains toujours (a tort) d'etre insulte, et tu ne te genes pas une seconde pour le faire en retour.
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par Maclag le 04 avril 2014 à 22:33. Évalué à 5.
        
        J'y connais rien alors je vais sûrement dire une connerie, mais vu de ma fenêtre:
        
        -Grub2 se démerde très bien pour faire des trucs multiboot et détecte très bien les systèmes déjà installés (en tout cas jamais eu de problème chez moi).
        -Windows apparemment ne sait pas le faire et il n'y a aucune intention de changer ça.
        
        Si j'étais parachuté chef de projet (pour le plus grand malheur des ingés MS), je leur demanderais pourquoi ils ne remplacent par leur tambouille interne par Grub2 directement.
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par Albert_ le 04 avril 2014 à 22:42. Évalué à 0.
        
        Une question de licence peut etre et plus probablement ils sont trop fier opur admettre qu'ils ont fait une connerie.
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par oinkoink_daotter le 04 avril 2014 à 22:49. Évalué à 5.
        
        -Grub2 se démerde très bien pour faire des trucs multiboot
        
        Oui, mais tant qu'il est tout seul à accéder à la ressource critique "MBR". C'est assez rapidement le chaos quand tu as deux distribs avec leur boot loader l'un à côté de l'autre.
        
        La bonne solution, ce serait que l'UEFI expose une interface pour enregistrer les systèmes et eventuellement noyaux/config/etc et s'occupe du multiboot. En fait, il y a un truc qui existe mais c'est assez embryonnaire et pas vraiment utilisé.
        
        je leur demanderais pourquoi ils ne remplacent par leur tambouille interne par Grub2 directement.
        
        Ben ils te montreraient le devis, tu ferais une syncope devant la ligne "qualif", ensuite tu la mettrais devant le bénéfice obtenu (facile, il est nul) et ensuite tu passerais à autre chose (avec un petit frisson dans la colonne vertébrale).
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par pasBill pasGates le 04 avril 2014 à 23:33. Évalué à 2.
        
        Grub2, lilo, etc… vont tous te demander confirmation avant d'aller ecraser le bootloader.
        
        Et quand ils ne le font pas, ben voila ce qui arrive :
        
        https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/713031
        
        Comme le dit Colin Watson lui-meme (un dev de Grub donc) :
        
        There's no reliable way to tell whether GRUB is installed in an MBR or not
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par Anonyme le 03 avril 2014 à 20:21. Évalué à 0.
        
        Pas, c'est aussi valable que de vouloir changer le nom d'un fichier. Ca dépend du point de vue.
        
        L'utilité de booter un autre OS, c'est un truc qui se justifie facilement. Changer un nom de fichier sans donner de raison particulière non.
        
        Donc il faut accepter quand Microsoft décide de ne pas te simplifier la vie lors d'un boot, il a décidé que c'était mieux.
        
        J'accepte que Microsoft fasse ce qu'ils veullent. J'utilise pas leur produits et voila.
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par Moonz le 03 avril 2014 à 19:53. Évalué à 5.
        
        Il faut voir les objectifs du projet. systemd a ouvertement choisi de privilégier l’unification/uniformisation (/run obligatoire n’en est qu’un des aspects), une intégration forte avec le reste de l’écosystème et la maintenabilité (supporte uniquement toolchain, libs et kernel « standards » et récents) au prix de la portabilité et de la souplesse. On peut ne pas être d’accord avec la pertinence à long terme de ces choix, mais il est clair que hardcoder des chemins est totalement cohérent avec ces choix.
        
        Ils n’ont pas fait l’économie d’une tonne de #ifdef dans le code pour le plaisir de réintroduire leurs propres constantes derrière…
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par khivapia le 03 avril 2014 à 21:46. Évalué à 4.
        
        Alors oui, la probabilité que quelqu'un ait un jour besoin d'utiliser un truc dont on ne voit pas l'intérêt immédiat est, quoi,
        
        100%. C'est même la principale raison d'être d'une bonne API, de pouvoir facilement servir à des usage pour lesquelles elle n'a pas été prévue au départ.
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par oinkoink_daotter le 04 avril 2014 à 17:48. Évalué à 1.
        
        C'est EXACTEMENT ce que répond Microsoft quand tu demande pourquoi il n'est pas prévu de booter un autre OS
        
        [reference needed]
        
        Ce n'est pas à toi de décider s'il y a des raisons valables de faire quelque chose ou non. Surtout pour du code libre : après tout, il est fait pour être réutilisé.
        
        Ben si. C'est toi qui code, c'est toi qui décide. Enfin, c'est l'idée du mot libre.
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par Anonyme le 03 avril 2014 à 19:10. Évalué à -4.
        
        Ben, justement, tu n’es pas dev C. Et encore moins dev apparemment.
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par arnaudus le 03 avril 2014 à 19:15. Évalué à 1.
        
        Visiblement, toi tu l'es, par contre.
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par Anonyme le 03 avril 2014 à 19:24. Évalué à -3. Dernière modification le 03 avril 2014 à 19:24.
        
        En fait on s'en fiche de ça. Ce que je voulais te dire, c'est que quelqu'un qui n'est pas dev C et qui dit approximativement n'importe-quoi, ce n'est certes pas étonnant par contre c'est assez prétentieux.
        
        En lisant les commentaires qui succèdent au tiens, on trouve pleins de bonnes réponses qui ne peuvent qu'être confirmées… et qui confirment que les critiques négatives que tu exposes ne sont pas ou peu valables.
        
        Voilà voilà.
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par Miod in the middle le 04 avril 2014 à 09:19. Évalué à 5.
        
        Bah, le seul véritable problème me semble être
        r = get_ctty_devnr(0, &devnr); if (r < 0) return -r;
        Il est clair que cette fonction renvoie, soit un file descriptor valide (donc >= 0) en cas de succès, et un code d'erreur négatif en cas d'échec.
        
        Si get_ctty_devnr() échoue, il faut renvoyer une erreur négative, donc "r" et non pas "-r" qui sera interprété comme une valeur de fd…
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par Miod in the middle le 04 avril 2014 à 09:25. Évalué à 1.
        
        Ah, mince, je n'avais pas vu que cela avait déjà été mentionné plus bas.
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par Renault (site web personnel) le 04 avril 2014 à 09:27. Évalué à -7.
        
        Perdu, le code de get_ctty_devnr renvoie soit un code d'erreur négatif, soit 0 en cas de succès…
        Je ne vois pas où est ton descripteur de fichier retourné…
        
        Peut être que la gestion des codes d'erreurs, et de leur valeur, est explicité quelque part dans le code source, les pages du projet ou autres… En tout cas je trouve amusant les gens qui trouvent des erreurs qui n'y sont pas car ils ne prennent pas la peine de vérifier le contenu du code appelé (et ce qu'il renvoie réellement).
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par diorcety le 04 avril 2014 à 10:05. Évalué à 10. Dernière modification le 04 avril 2014 à 10:05.
        
        Ici: http://cgit.freedesktop.org/systemd/systemd/tree/src/tty-ask-password-agent/tty-ask-password-agent.c#n443
        
        Donc si get_ctty_devnr retourne un code d'erreur négatif et que tu retourne l'opposé de cette valeur, tu ne peux pas différencier une erreur d'un FD.
        
        D'ailleurs c'est tellement pas un bug que cela a été corrigé hier. https://www.mail-archive.com/systemd-devel@lists.freedesktop.org/msg18136.html
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par fearan le 04 avril 2014 à 09:31. Évalué à 3.
        
        4 return, alors qu'il y a un free(p) qui traine
        
        Pas un problème p est alloué via asprintf en cas de retour positif (une extension gnu à printf qui alloue automatiquement la chaine de caractère )
        
        Pour le reste je suis pour avoir les return au plus près de l'erreur (cela implique pour la lisibilité de garder des fonctions courtes (elle ne doivent pas dépasser un écran), sinon une tambouille au début pour vérifier les paramètres (et des return au début) et un seul return à la fin si la fonction ne peut pas tenir sur un écran.
        
        Des magic values 0700, 0600.
        
        C'est les droits POSIX, le premier rwx (read write eXecute) pour l'utilisateur uniquement (0700), et rw (read, write) pour 0600; pour ces valeurs là, je doute qu'utiliser une constante soit pertinent; aucune chance que ça change - a moins de vouloir modifier la norme POSIX, mais je crains qu'on aille au devant de gros ennuis ;) le droit d’exécution d'un répertoire indique qu'on peut le traverser.
        
        Des chemins codés en dur
        
        La par contre c'est, de mon point de vue, une erreur.
        
        Il ne faut pas décorner les boeufs avant d'avoir semé le vent
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par arnaudus le 04 avril 2014 à 10:23. Évalué à 8.
        
        C'est les droits POSIX,
        
        Oui oui je sais, tout le monde m'est tombé dessus parce qu'ils n'ont pas compris ce que je voulais dire. Mon argument, c'est que je ne vois pas de raison forte de faire un 0700 plutôt qu'un 0770 par exemple ; on pourrait très bien imaginer que pour des raisons de sécurité un autre process lancé de manière indépendante doive accéder à ce fichier, ou n'importe quoi. Bref, on peut imaginer qu'un jour, on puisse vouloir changer les permissions attribuées au fichier, et ce jour là, il faudra que le patch modifie des trucs partout dans le programme, avec de grosses possibilités de bugs ou de modifs non nécessaires, parce que le programmeur initial n'a pas indiqué la sémantique (qu'il connaissait pourtant). Juste en définissant dans un header PERM_ACCESS_PASSWD à 0700, le code n'est pas moins lisible, il n'est pas moins portable, il est juste mieux organisé avec toutes les permissions dans un seul fichier, les unes à la suite des autres : en un coup d'œil, on a l'intégralité de la logique de la gestion de permissions dans systemd.
        
        Moi, c'est comme ça que je code, et pour des appli perso qui n'ont rien à voir avec la complexité et le caractère critique de systemd. Je suis juste surpris que des programmeurs professionnels de haut niveau ne respectent pas les consignes de base qu'on donne aux étudiants, et ont du mal à avoir un regard critique sur le code des autres : dans cette discussion, il y a plein de gens qui se prétendent programmeurs C qui ne voient rien à redire au code cité. Non seulement il y avait un bug (le return -r) dû à mon avis à la structure chaotique des returns, mais il y a plein de trucs moches : les variables qui s'appellent p, r, k, etc., les codes d'erreur mélangés, les chemins en dur, etc. Je veux bien qu'en programmation C, on puisse avoir des paradigmes différents (genre, utiliser la valeur de retour pour signaler les erreurs, ce qui me gène toujours), mais si on suit les commentaires des "pros", en gros, le paradigme du C est de coder comme des porcs et surtout de se serrer les coudes entre développeurs face au petit peuple qui demande comment un tel code peut être maintenu.
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par pepp le 04 avril 2014 à 10:39. Évalué à -3.
        
        C'est assez logique.
        
        Tu opposes ton style de programmation, utilisés quand tu codes "des appli perso" et celui utilisés dans systemd ou des dév "pro" comme tu dis.
        Mais les contraintes dans les 2 cas ne sont pas exactement les mêmes.
        En l'occurence : aucune pour tes projets persos, là où les autres doivent faire des compromis : délais, qualité, sécurité, performance, nouvelles fonctionnalité, maintenabilité, etc etc.
        C'est toujours facile de prendre du code d'un autre et de trouver matière à critiquer.
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par arnaudus le 04 avril 2014 à 13:29. Évalué à 8.
        
        Mais les contraintes dans les 2 cas ne sont pas exactement les mêmes.
        En l'occurence : aucune pour tes projets persos, là où les autres doivent faire des compromis : délais, qualité, sécurité, performance, nouvelles fonctionnalité, maintenabilité, etc etc.
        
        Bah oui, justement. J'ai l'impression que les écarts aux consignes de base ne sont absolument pas justifiables par ces raisons. Pour les délais, je t'accorde que "int err_code;" prend à peu près une seconde de plus à taper que "int r;", si cette seconde t'empêche de livrer ton programme dans les temps, c'est inquiétant. Commenter le code aussi ça prend du temps, mais s'il avait été commenté, il aurait peut-être été plus clair que "return -r;" était un bug.
        
        J'en ai un peu marre de l'argument "oui mais c'est un pro, il sait ce qu'il fait, il doit bien avoir des raisons que tu es trop con pour comprendre". Pour que ça soit vrai, il faudrait pouvoir éliminer l'argument "flemme de coder proprement".
        
        C'est toujours facile de prendre du code d'un autre et de trouver matière à critiquer.
        
        Et c'est toujours formateur. Il y a une différence fondamentale entre critiquer le code des autres et prétendre que son code est parfait. C'est aussi en crtiquant les autres qu'on apprend beaucoup sur son propre code. Si je postais des bouts de code, je ne m'attendrais pas du tout à avoir des commentaires du style "ton code est parfait". Même pas "Tu codes mieux que Lennart Poettering", ce qui serait ridiculement prétentieux. Systemd fait des trucs dont je n'ai même pas idée de la complexité, la programmation est un métier, je n'ai absolument pas l'intention de prétendre que je pourrais faire mieux.
        
        Mais quand je vois les bouts de code de Lennart qu'on a disséqué ici à titre d'exercice, l'impression que ça me fait, c'est comme de voir un chef trois étoiles qui sort des chiottes sans se laver les mains avant de te servir un plat super bon. Je fais la cuisine moins bien que lui, c'est certain. Mais je sais aussi que quand on fait à bouffer, on se lave les mains en sortant des toilettes. L'un n'empêche pas l'autre.
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par pepp le 04 avril 2014 à 13:48. Évalué à -3.
        
        Puisqu'apparemment il n'existe pas de juste milieu entre les dév flemmards qui ne savent pas coder proprement et les ayatollah du code propre et des design patterns ce n'est pas la peine de discuter.
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par Anonyme le 04 avril 2014 à 14:25. Évalué à 2.
        
        Commenter le code aussi ça prend du temps, mais s'il avait été commenté, il aurait peut-être été plus clair que "return -r;" était un bug.
        
        Non, ce genre de typo, ca arrive que le bug soit commenté ou pas. Et puis on ne peut pas non plus se fier au commentaire, parfois le code est bon, et c'est le commentaire qui est faux.
        
        J'en ai un peu marre de l'argument "oui mais c'est un pro, il sait ce qu'il fait, il doit bien avoir des raisons que tu es trop con pour comprendre". Pour que ça soit vrai, il faudrait pouvoir éliminer l'argument "flemme de coder proprement".
        
        C'est pas "flemme de coder proprement" mais "flemme de coder en rajoutant de la complexité qui sert à rien par ce qu'un type sur un forum a décreté que c'est comme ca qu'on faisait du code propre et pas autrement".
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par totof2000 le 04 avril 2014 à 14:51. Évalué à 2.
        
        C'est pas "flemme de coder proprement" mais "flemme de coder en rajoutant de la complexité qui sert à rien par ce qu'un type sur un forum a décreté que c'est comme ca qu'on faisait du code propre et pas autrement".
        
        Ce n'est pas "un type sur un forum" qui a décrété ça. Ce sont des règles de bon sens que des types ayant l'habitude de développer ont appliqué, et en les appliquant ils se sont rendus compte qu'ils écrivaient du code plus lisible et plus maintenable. Et un type sur un forum a appliqué ces règles dans son code et s'est rendu compte de la même chose, et ne comprend pas que des devs soit-disant "pro" n'appliquent pas certaines de ces règles.
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par Anonyme le 04 avril 2014 à 15:01. Évalué à 0.
        
        Et un type sur un forum a appliqué ces règles dans son code et s'est rendu compte de la même chose, et ne comprend pas que des devs soit-disant "pro" n'appliquent pas certaines de ces règles.
        
        Ils appliquent d'autres regles que celles que tu as décreté comme étant les bonnes, par ce qu'ils ont l'habitude de développer, et en appliquant leurs regles ils se sont rendus compte qu'ils écrivaient du code plus lisible et plus maintenable.
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par totof2000 le 04 avril 2014 à 15:11. Évalué à 1. Dernière modification le 04 avril 2014 à 15:12.
        
        Ya qu'à regarder le code posté& ici pour se rendre compte de la lisibilité. Et pour la maintenabilité, je pense que quelqu'un qui ne fait pas partie du projet depuis longtemps ait du mal à apporter une quelconque modification dans le code. Le moindre ajout d'une ligne risque de tout casser sans qu'on sache pourquoi. Et j'insiste sur ce point vu que tu n'as pas compris : ces règles ne sont pas celles que MOI j'ai décrétées.
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par Padishah le 04 avril 2014 à 16:38. Évalué à 4.
        
        par ce qu'ils ont l'habitude de développer, et en appliquant leurs regles ils se sont rendus compte qu'ils écrivaient du code plus lisible et plus maintenable
        
        Pensent-ils seulement a ceux qui dans quelques mois|années tenteront de corriger les failles qui ne manqueront pas d'être découvertes ?
        Les extraits de codes produit ici sont hallucinants. Du code sans commentaires et avec des variable "anonymisées" (p, r, k etc.), c'est juste du code dégueulasse. Et cela concerne un projet critique et structurant pour l'écosystème Linux !
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par Anonyme le 04 avril 2014 à 17:26. Évalué à 1.
        
        Les extraits de codes produit ici sont hallucinants.
        
        Oula, ne regarde surtout pas le code de Linux, Xorg, la libc et autres alors !
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par Albert_ le 04 avril 2014 à 18:13. Évalué à 5. Dernière modification le 04 avril 2014 à 18:15.
        
        La toute petite difference c'est que ca fait presque 25 ans que le createur de linux suit le developement et la maintenance de son logiciel. Le createur de systemd a un CV bien moins bon sur le sujet de la maintenance et le suivit des ses logiciels. Lui c´est plutot du style, je developpe un nouveau jouet, je le fait manger de force et je passe a autre chose en laissant le bebe aux autres maintenant qu'il est pour ainsi dire incontournable.
        
        Voila ce qui me fait peur avec systemd.
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par Padishah le 05 avril 2014 à 19:15. Évalué à 1.
        
        Si tu as des exemples pour le kernel, la libc et Xorg, vas-y montres. Ca peut être instructif.
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par Anthony Jaguenaud le 04 avril 2014 à 15:11. Évalué à 4.
        
        Après, c'est une question d'habitude, j'ai fait sur un projet une RPP avec un américain, il a justifié de déroger aux règles de codage par : « Vous n'avez qu'à savoir codé ! »
        En quoi il n'a pas tort, car finalement les règles de codage limite l'imagination et la compréhension du langage. Et nos experts restent des éternels débutants. D'un autre côté, quand tu passes 2mns à comprendre une ligne, c'est pas forcément très pérenne à long terme pour la reprise du code.
        
        Exemples de perles rencontrées:
        
        // Copie d'une chaine on s'assure que le dernier octets et bien un zéro si ça déborde... char dest[taille]; strcpy(dest,src)[taille] = '\0'; // Dans un cas on apelle la fonction envoie_reseau et envoie_dbus dans l'autre. (a < b?envoie_reseau:envoie_dbus)(param1,param2);
        
        Moi, j'aime pas. Le compilateur sait optimiser pour nous. Et les gens qui écrivent ça, c'est généralement avec l'excuse de la performance.
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par lasher le 04 avril 2014 à 18:16. Évalué à 4.
        
        C'est parce que ce sont des gens qui ne savent pas forcément très bien comment fonctionne un compilateur. Autant mon métier m'a appris que la phrase « le compilateur va optimiser pour nous » est relativement fausse dans pas mal de cas, autant j'ai aussi appris dans quels cas le compilo est bien plus intelligent que moi, et qu'il vaut mieux écrire du code « bête », mais qui sera correctement identifié par le compilateur, que faire des trucs bizarres qui vont rendre la lecture difficile à la longue.
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par totof2000 le 04 avril 2014 à 18:32. Évalué à 4.
        
        En quoi il n'a pas tort, car finalement les règles de codage limite l'imagination et la compréhension du langage.
        
        C'est comme si tu me disais qu'apprendre à parler correctement limite l'imagination et la compréhension d'une langue.
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par Moonz le 04 avril 2014 à 19:00. Évalué à 2.
        
        De fait la poésie n’est pas toujours grammaticalement bien formée :)
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par arnaudus le 04 avril 2014 à 15:07. Évalué à 4.
        
        Non, ce genre de typo, ca arrive que le bug soit commenté ou pas. Et puis on ne peut pas non plus se fier au commentaire, parfois le code est bon, et c'est le commentaire qui est faux.
        
        Les bugs arrivent que le code soit commenté ou non. Par contre, si la fonction commençait avec
        
        /* Returns a file descriptor (positive number) or error code (negative number) */
        
        Le bug aurait été évident. Or là, ça n'est pas évident. On a pu déduire que c'était un bug, mais ça aurait aussi pu être un hack dégueu qui fonctionne.
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par Moonz le 04 avril 2014 à 16:02. Évalué à -1.
        
        Et à chaque fois que tu écris un programme en C tu commentes bien la sémantique de la valeur de retour de main ainsi que argc et argv ? Quand tu écris int tu explicites à chaque fois "c’est bien un entier signé que je veux" ?
        
        Les conventions sont là pour être utilisées… et simplifier la vie en ne répétant pas 2000 fois la même chose.
        
        [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
        
        Posté par totof2000 le 04 avril 2014 à 16:15. Évalué à 4.
        
        Hum …
        
        http://www.gnu.org/software/libc/manual/html_node/Exit-Status.html
```
Macro: int EXIT_SUCCESS

This macro can be used with the exit function to indicate successful program completion. On POSIX systems, the value of this macro is 0. On other systems, the value might be some other (possibly non-constant) integer expression.

Macro: int EXIT_FAILURE

This macro can be used with the exit function to indicate unsuccessful program completion in a general sense. On POSIX systems, the value of this macro is 1. On other systems, the value might be some other (possibly non-constant) integer expression.

[^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd

Posté par lasher le 04 avril 2014 à 18:33. Évalué à 1.

… Sauf que EXIT_SUCCESS est, aux dernières nouvelles, toujours égal à 0, et pas juste pour POSIX. Pour EXIT_FAILURE, je me range à l'avis de ce monsieur.

[^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd

Posté par totof2000 le 04 avril 2014 à 18:37. Évalué à 2.

(It's barely possible that EXIT_SUCCESS could have a value other than 0, but it's equal to 0 on every implementation I've ever heard of.)

Ca ne veut pas dire que c'est impossible.

[^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd

Posté par lasher le 04 avril 2014 à 19:43. Évalué à 2.

D'après le standard de C99 (7.1.4.3—7.1.4.4) et le standard de C11 (7.22.4.5—7.22.4.6) :

Finally, control is returned to the host environment. If the value of status is zero or EXIT_SUCCESS , an implementation-defined form of the status successful termination is returned.

(l'emphase est de moi)

EXIT_FAILURE n'a pas de valeur attitrée, et donc il faut probablement toujours l'utiliser en cas d'erreur dont on n'a pas spécifié de codes spécifiques. Je citais un commentaire sur stackoverflow, mais principalement parce que j'étais d'accord avec le monsieur qui disait en substance « si tu n'utilises jamais EXIT_FAILURE, autant utiliser 0. Mais ne serait-ce que par symétrie, si tu utilises EXIT_FAILURE, autant utiliser EXIT_SUCCESS. »

Donc si, 0 est toujours une valeur correcte pour marquer une sortie sans erreur pour exit.

[^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd

Posté par Zenitram (site web personnel) le 04 avril 2014 à 20:06. Évalué à 3.

Question stupide : comment on s'en sort si EXIT_FAILURE est 0 et EXIT_SUCCESS 1?
Ca ne semble pas interdit par la spec.
Du coup tu retournes EXIT_FAILURE et tu as une transformation "If the value of status is EXIT_FAILURE or EXIT_SUCCESS , an implementation-defined form of the status successful termination is returned. If the value of status is EXIT_FAILURE, an implementation-defined form
of the status unsuccessful termination is returned.", mal barré car il y a deux chemins pour EXIT_FAILURE…

Un truc que j'ai dû louper, mais je ne vois nul part EXIT_FAILURE interdit d'être 0 ("EXIT_FAILURE and EXIT_SUCCESS which expand to integer constant expressions"

[^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd

Posté par lasher le 04 avril 2014 à 21:02. Évalué à 5.

Question stupide : comment on s'en sort si EXIT_FAILURE est 0 et EXIT_SUCCESS 1?

Je cite le bloc de texte complet de la norme concernant exit et EXIT_FAILURE-EXIT_SUCCESS:

Finally, control is returned to the host environment. If the value of status is zero or EXIT_SUCCESS, an implementation-defined form of the status successful termination is returned. If the value of status is EXIT_FAILURE, an implementation-defined form of the status unsuccessful termination is returned. Otherwise the status returned is implementation-defined.

Donc la vraie valeur renvoyée au système par exit n'est pas nécessairement la valeur que tu lui fournis : un 0 peut être transformé en une valeur différente compréhensible par le système hôte.

Pour la question spécifique à EXIT_SUCCESS == 1; EXIT_FAILURE == 0, je n'ai rien vu dans la norme qui l'interdise, SAUF le fait qu'il est explicitement dit que EXIT_SUCCESS ou 0 en entrée signifie « succès », et que EXIT_FAILURE signifie « échec ». Donc si tu files 0 en entrée à exit, tu lui indiques « succès ». Bref, même si la norme n'indique pas explicitement que EXIT_FAILURE ne peut pas valoir 0, je pense que la formulation indique implicitement que ça entrerait en conflit avec la notion de valeur de succès. Une fois que exit a reçu sa valeur par contre, si en « interne » l'OS hôte a décidé que « succès » = 1, et « échec » = 0, c'est justement le boulot de exit de convertir les valeurs pour qu'elles soient correctement transmises au système (je ne sais pas si je suis clair).

[^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd

Posté par Zenitram (site web personnel) le 04 avril 2014 à 18:48. Évalué à 1. Dernière modification le 04 avril 2014 à 18:48.

Sauf que EXIT_SUCCESS est, aux dernières nouvelles, toujours égal à 0,

EXIT_SUCCESS "This macro expands to a system-dependent integral"
C99
"EXIT_FAILURE and EXIT_SUCCESS which expand to integer constant expressions that can be used as the argument to the exit function to return unsuccessful or successful termination status, respectively, to the host environment;"

Que ce soit 0 sur toutes les implémentations que tu as vu ne changent pas que ton code sera non conforme aux standard mis en lien. après ton lien dit "If the value of status is zero or EXIT_SUCCESS, an implementation-defined form of the status successful termination is returned", donc certes ça peut se défendre… Mais c'est quand même sacrément limite.
(je n'ai pas de lien pour C11)

Après, désolé, je comprend plus facilement EXIT_SUCCESS que 0, 0 il faut savoir tout le temps que ça signifie que c'est OK. Bref, questions sans doute de principes. Et je ne suis pas le seul à le dire (oui, ça vient de ton lien, 2 commentaires en dessous)

[^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd

Posté par Anonyme le 04 avril 2014 à 16:18. Évalué à 2.

Le bug aurait été évident.

Le bug était deja evident si on lit le code attentivement pour remarquer le - en trop. Avec ce commentaire la ca ne change rien, ca ne met pas en evidence le - qui est en trop. Moi en fait un commentaire aussi long pour un truc comme ca, je ne le lis meme pas.

On a pu déduire que c'était un bug, mais ça aurait aussi pu être un hack dégueu qui fonctionne.

Ca aurait aussi pu etre une erreur dans le commentaire. Le seul moyen d'en etre sur c'est d'aller lire le code de la fonction qui est appellée pour voir ce qu'elle retourne.

[^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd

Posté par pepp le 04 avril 2014 à 17:02. Évalué à 4.

J'ai fini par cloner le dépot systemd pour avoir d'autres exemples de sources à lire.

Du coup pour la variable "r" la réponse est simple : ils utilisent "int r" dans toutes les fonctions. Alors certes c'est moins expressif que int return_value; mais c'est cohérent sur l'ensemble du projet.

Sur le couplet "y a pas de commentaires cay pourri". On peut aussi trouver du code largement commenté dans systemd, par ex :

static int mount_points_list_umount(MountPoint **head, bool *changed, bool log_error) { MountPoint *m, *n; int n_failed = 0; assert(head); LIST_FOREACH_SAFE(mount_point, m, n, *head) { /* If we are in a container, don't attempt to read-only mount anything as that brings no real benefits, but might confuse the host, as we remount the superblock here, not the bind mound. */ if (detect_container(NULL) <= 0) { /* We always try to remount directories * read-only first, before we go on and umount * them. * * Mount points can be stacked. If a mount * point is stacked below / or /usr, we * cannot umount or remount it directly, * since there is no way to refer to the * underlying mount. There's nothing we can do * about it for the general case, but we can * do something about it if it is aliased * somehwere else via a bind mount. If we * explicitly remount the super block of that * alias read-only we hence should be * relatively safe regarding keeping the fs we * can otherwise not see dirty. */ mount(NULL, m->path, NULL, MS_REMOUNT|MS_RDONLY, NULL); } /* Skip / and /usr since we cannot unmount that * anyway, since we are running from it. They have * already been remounted ro. */ if (path_equal(m->path, "/") #ifndef HAVE_SPLIT_USR || path_equal(m->path, "/usr") #endif ) continue; /* Trying to umount. We don't force here since we rely * on busy NFS and FUSE file systems to return EBUSY * until we closed everything on top of them. */ log_info("Unmounting %s.", m->path); if (umount2(m->path, 0) == 0) { if (changed) *changed = true; mount_point_free(head, m); } else if (log_error) { log_warning("Could not unmount %s: %m", m->path); n_failed++; } } return n_failed; }

(arf, bien sûr la fonction que je cite n'utilise par 'int r' :) )
En tout cas, ils ne sont pas opposés aux commentaires par principe (ou pour justifier de facturer du support).

Enfin le style général est également cohérent (accolades, alignements, assert, etc).

Dernière chose, que je trouve bien plus importante que les commentaires dans le code d'ailleurs, les messages de commits ont l'air complets et utiles.

Si vous considérez cette codebase comme crade, je veux bien un exemple d'un projet (sérieux, pas un hello world de 15 lignes) propre.

[^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd

Posté par totof2000 le 04 avril 2014 à 17:05. Évalué à 1.

J'a&vais précisé que d'autres parties de systemd étaient bien plus propres. Ca dopit dépendre de qui l'a développé, et si un contributeur externe a nettoyé le code.

Ce code me parait bien plus "propre" et lisible que celui que j'ai copié ici (je n'ai pas eu le temps de le regarder en détail). Si tout le code de systemd était comme ça, ce serait bien mieux.

[^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd

Posté par pepp le 04 avril 2014 à 17:26. Évalué à 1.

D'après git blame:
* tty-ask-password-agent.c
- auteur principal: Lennart Poettering
- fin 2010/début 2011

Pour le code que j'ai cité ci dessus umount.c:
- auteur principal: Lennart Poettering
- 2010 -> 2013

Les commentaires semblent venir de modifications récentes.

On dirait que le code est écrit sans (trop de) commentaire au départ, par contre quand des modifications sont faites, pour un bugfix ou un cas particulier non prévu au départ, un commentaire précise pourquoi.

[^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd

Posté par Anonyme le 04 avril 2014 à 12:08. Évalué à -1.

Bref, on peut imaginer qu'un jour, on puisse vouloir changer les permissions attribuées au fichier, et ce jour là, il faudra que le patch modifie des trucs partout dans le programme, avec de grosses possibilités de bugs ou de modifs non nécessaires, parce que le programmeur initial n'a pas indiqué la sémantique (qu'il connaissait pourtant). Juste en définissant dans un header PERM_ACCESS_PASSWD à 0700, le code n'est pas moins lisible, il n'est pas moins portable, il est juste mieux organisé avec toutes les permissions dans un seul fichier, les unes à la suite des autres : en un coup d'œil, on a l'intégralité de la logique de la gestion de permissions dans systemd.

Bravo et le jour ou tu as besoin de changer la permission sur le fichier, tu modifies la constante en oubliant qu'elle est aussi utilisée pour les permissions d'un autre fichier qui ne doit pas avoir ses permissions modifiées.

Et je vois pas l'interet de regrouper en un seul endroit toutes les permissions, surtout avec des noms aussi peu claires que "PERM_ACCESS_PASSWD" ou tu n'as aucune idée de quel fichier ca parle. Si tu veux voir toutes les permissions d'un coup tu fais un "ls -lR /run/systemd". Et si tu veux voir exactement comment elles sont gerées, tu lis le code, ce que tu devrais faire aussi si il y avait des constantes puisque tu ne peux pas deviner comment elles sont utilisées précisement.

[^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd

Posté par Anonyme le 04 avril 2014 à 12:30. Évalué à 0.

Moi, c'est comme ça que je code, et pour des appli perso qui n'ont rien à voir avec la complexité et le caractère critique de systemd. Je suis juste surpris que des programmeurs professionnels de haut niveau ne respectent pas les consignes de base qu'on donne aux étudiants, et ont du mal à avoir un regard critique sur le code des autres : dans cette discussion, il y a plein de gens qui se prétendent programmeurs C qui ne voient rien à redire au code cité.

Par ce que les consignes données aux étudiants, c'est des conseils sur une bonne facon de faire du code, qui aident pour apprendre, mais certainement pas des regles à respecter au pied de la lettre quand on sait ce qu'on fait. Par exemple beaucoup de profs disent qu'ils ne faut absolument jamais utiliser de goto, mais c'est faux, il y a pleins de cas ou cela peut etre bien utilisé.

Et il y a des profs qui disent qu'il faut toujours utiliser des constantes, et c'est sans doute une bonne regle à respecter quand on apprend à programmer. Mais quand on a compris l'interet des constantes et dans quel cas ca ne servait à rien on est pas obligés de respecter cette regle de facon systematique.

De toute facon un prof n'est pas un dieu qui connait LA bonne facon de faire du code. Par ce qu'il n'y a pas une seule bonne facon de faire, et chacun peut avoir son propre style. Et puis il peut aussi se tromper.

[^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd

Posté par Albert_ le 04 avril 2014 à 12:57. Évalué à 5.

Je ne vais pas critiquer la qualite du code (c'est du C et j'y connais pas grand chose tellement ca fait longtemps que je n'y ai pas touche) par contre ca ne choque personne le manque de commentaires. A moins que en postant le code cela ait ete nettoye je trouve ca aberrant de ne pas mettre une seule ligne d'explication. Enfin c'est probablement parceque je suis en train de faire de l'archeologie de code non documente que cela me parle un peu…

[^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd

Posté par totof2000 le 04 avril 2014 à 13:07. Évalué à 6.

ca ne choque personne le manque de commentaires.

Moi ça me choque; je suis en train de chercher du code faisant plus ou moins la même chose pour donner une idée de ce que j'appele "code propre" (au moins plus propre que ça) et le code que j'ai vu est beaucoup mieux commenté. Sans être parfait, il est beaucoup plus lisible.

Sinon, si on choisit bien les noms de fonctions et que l'on utilise des constantes appropriées, les commentaires ne sont pas forcément indispensables.

[^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd

Posté par Anonyme le 04 avril 2014 à 14:39. Évalué à 2.

Moi ca ne me choque pas. Je prefere largement un code avec très peu de commentaires, sauf aux endroits ou il y a un truc particulier pas simple à comprendre, qu'un code bourré de commentaires.

En general avec le code bourré de commentaires:
- on ne voit plus les trucs particuliers, puisqu'il y a des commentaires partout
- on a vite fait d'updater le code en oubliant de mettre à jour le commentaire, qui devient alors faux
- on se met à lire les commentaires au lieu de lire le code, ce qui peut nous induire en erreur quand le code ne fait pas exactement ce que dit le commentaire

Et puis en cas de doute sur la raison de la présence d'une ligne, il y a 'git blame' qui permet de voir le message de commit qui peut aider à comprendre.

[^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd

Posté par Albert_ le 04 avril 2014 à 14:47. Évalué à 2.

Je n'ai pas demande des commentaires a toute les lignes du code mais la il y un ou deux endroits ou il y a un chouilla de doc, sur un code de plusieurs centaines de lignes.

Tu peux penser que tout est evident dans ce code mais j'ai comme un doute sur le sujet. Cela n'engage que moi naturellement mais bon je suis pas mal implique dans la recuperation de code et le premier probleme auquels nous sommes confrontes avec mes collegues c'est : "mais putain il a voulu faire quoi a cet endroit, il aurait pas pu mettre un peu de doc?".

La durabilite du code c'est une des grandes problematiques actuelles. Le mouvement open-source apporte une partie de la reponse mais si le code est crade ou cache cela ne sert a peu pres a rien.

[^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd

Posté par lasher le 04 avril 2014 à 18:11. Évalué à 1.

Oui oui je sais, tout le monde m'est tombé dessus parce qu'ils n'ont pas compris ce que je voulais dire.

Mais non, on a bien compris que t'aimes pas les valeurs numériques juste parce qu'elles sont numé…

[…] on peut imaginer qu'un jour, on puisse vouloir changer les permissions attribuées au fichier, et ce jour là, il faudra que le patch modifie des trucs partout dans le programme, avec de grosses possibilités de bugs ou de modifs non nécessaires […]

Ah. Je euh. Oui. Effectivement, tu aurais dû commencer par là, parce que je fais partie de ceux qui n'avaient pas compris ton raisonnement. :-) Maintenant, je ne connais pas le code autour, mais je me dis que ce genre de trucs doit être sans doute « isolé » niveau fonctionnalité, et qu'il y a de fortes chances que ce soit le seul endroit où tu aies à changer les valeurs.

[^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd

Posté par gnx le 03 avril 2014 à 16:59. Évalué à 3.

Vers la ligne 102

if (accept_cached) { packet = strdup("c"); n = 1; } else asprintf(&packet, "*\002%c%s%n", (int) (strlen(message) + 1), message, &n); if (!packet) { r = -ENOMEM; goto finish; }

Bien qu'avant il y ait char *packet = NULL;, rien ne garantit d'après le man de asprintf qu'en cas d'erreur, asprintf n'ait pas changé la valeur de packet par quelque chose de différent de NULL => Boum. Ça commence bien.

Il faut tester le retour de asprintf.

[^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd

Posté par Anthony Jaguenaud le 03 avril 2014 à 17:09. Évalué à 0.

Il faut tester le retour de asprintf

Non, sous Linux malloc n'échoue jamais (voir partie 6). Enfin sauf si un boulet demande au noyau d'allouer réellement les pages demandées…

[^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd

Posté par gnx le 03 avril 2014 à 17:21. Évalué à 5.

D'une part :

Il se peut qu'il y ait d'autres causes d'échec de asprintf.

Et d'autre part, t'en parleras à Lennart, alors :

C'est dans ses règles de codage ;

C'est verifié dans les autres appels de fonctions du même genre (et même dans le bout de code que j'ai cité, c'est bien ce que fait le test de packet pour le strdup.

Non, là, ce qu'il a fait, c'est qu'il a vraiment voulu tester que asprintf avait bien fonctionné, mais comme c'est un malin, il a fait un seul test commun à strdup et asprintf (les 2 branches du if). Sauf que ça ne marche pas comme ça.

[^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd

Posté par ckyl le 03 avril 2014 à 17:22. Évalué à 5.

~~Non, sous Linux malloc n'échoue jamais (voir partie 6). Enfin sauf si un boulet demande au noyau d'allouer réellement les pages demandées…~~

Non, sous Linux, par défaut, malloc n'échoue jamais (voir partie 6). Enfin sauf si un boulet demande au noyau d'allouer réellement les pages demandées…

[^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd

Posté par Guillaume Denry (site web personnel) le 03 avril 2014 à 21:02. Évalué à 2.

C'est parfait ! Comme ça, ça donne du code vraiment portable !

[^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd

Posté par Anthony Jaguenaud le 03 avril 2014 à 23:34. Évalué à 4.

C'est parfait ! Comme ça, ça donne du code vraiment portable !

Bah c’est pas grave, systemd n’est pas prévu pour fonctionner avec autre chose que Linux.

[^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd

Posté par fravashyo (site web personnel) le 03 avril 2014 à 17:21. Évalué à -10.

j'ai gagné un temps impressionnant au démarrage.

le truc qui ne sert pas à grand chose à l'heure de l'hibernation.

Ce journal confirme vraiment que les dev de systemd ce sont des abrutis du même tonneau que ceux de gnome.

« I approve of any development that makes it more difficult for governments and criminals to monopolize the use of force. » Eric Raymond

[^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd

Posté par Misc (site web personnel) le 03 avril 2014 à 17:34. Évalué à 6.

Je ne suis pas sur qu'insulter les développeurs soient un usage productif de ton temps. mais c'est juste moi, hein.

[^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd

Posté par fravashyo (site web personnel) le 03 avril 2014 à 21:20. Évalué à -8.

non mais ça fait un bien fou. Je vous le conseille. Et c'est un juste retour des choses vis à vis des attitudes de parfaits despotes qu'ont ces ~~développeurs~~ fossoyeurs des écosystèmes Unix.

« I approve of any development that makes it more difficult for governments and criminals to monopolize the use of force. » Eric Raymond

[^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd

Posté par Misc (site web personnel) le 03 avril 2014 à 22:30. Évalué à 3.

Je suis pas sur que ça te fasse un bien fou.

Déjà, d'un point de vue purement du système d'init, tu changes rien. Ou plutôt, si, tu renforces l'idée que les gens qui refusent systemd sont colériques et n'ont pas d'arguments.
Bon, moi, je suis largement en faveur de systemd, j'ai déjà largement expliqué pourquoi, j'ai montré je pense qu'il y a des raisons techniques, etc, donc je devrait me réjouir.

Mais même pour toi, si tu cherches un peu sur le web, tu va tomber sur des articles bien fait qui vont te dire que le plus à plaindre, c'est toi :

http://youarenotsosmart.com/2010/08/11/catharsis/

Ensuite, peut être que tu estimes que tu es quelqu'un de calme dans la vie, et que ta qualité de vie est correcte, etc, etc. Mais peut être pas.

Mais si c'est pas le cas, je doute que ça soit la faute de systemd.

Quand à être des despotes, je pense que tu as choisi le jour ou tu as choisi de dépendre du travail des autres et d'avoir des gens indépendants de ta capacité à payer ou pas en prenant des logiciels données gratuitement. À un moment, faut pas l'oublier.

[^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd

Posté par Zenitram (site web personnel) le 03 avril 2014 à 22:38. Évalué à -4.

despotes

Par curiosité : démontres qu'ils t'imposent quelque chose.
Oups, plus personne, car ils n'imposent rien à personne, ils sont choisis par d'autres (ceux que tu as choisis au passage comme responsable des choix, donc au final le responsable du choix c'est… toi. Tu es libre de changer!)
Par contre, je te vois bien en esclavagiste qui demande aux autres de faire comme toi tu veux plutôt que de mettre la main à la pate.

Qui parle de despotisme? Zut alors. Toujours les mêmes bêtises sorti par les anti-systemd pas foutus de faire autre chose que critiquer (genre maintenir une distro)

[^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd

Posté par khivapia le 04 avril 2014 à 09:29. Évalué à 8.

En toute amitié (virtuelle), tu ne voudrais pas arrêter de faire à la fois les questions et les réponses, surtout dans le même post ? Ça fait un effet vraiment bizarre, pour ne pas dire agressif ou carrément psyQuelqueChose.

[^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd

Posté par Zenitram (site web personnel) le 03 avril 2014 à 17:52. Évalué à 0. Dernière modification le 03 avril 2014 à 17:53.

abrutis

Tout de suite l'insulte (non argumenté, car même si on a l'hibernation, ça arrive de rebooter quand même, et ce n'est pas parce que toi tu ne t'en sers pas que les autres doivent subir), ça donne le niveau des anti-systemd.

[^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd

Posté par fravashyo (site web personnel) le 03 avril 2014 à 21:27. Évalué à -3. Dernière modification le 03 avril 2014 à 21:29.

oui c'est vrai, je me suis laissé emporter, d'autant plus qu'avec le bagage technique qu'ils ont, ce sont loin d'être des abrutis bien entendu. « Sombres connards » aurait été sans doute plus approprié.

ça arrive de rebooter quand même

oui, à peu près tous les mois :
~ $ uptime 21:26:21 up 35 days

« I approve of any development that makes it more difficult for governments and criminals to monopolize the use of force. » Eric Raymond

[^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd

Posté par oinkoink_daotter le 04 avril 2014 à 18:00. Évalué à 3.

car même si on a l'hibernation

Encore faut-il qu'elle marche. Tout le monde ne fait pas tourner linux sur un thinkpad de 5 ans d'age /o\

[^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd

Posté par Christophe Chailloleau-Leclerc le 03 avril 2014 à 21:08. Évalué à 4.

Enfin, en même temps, ma machine démarre plus vite qu'elle ne sort d'hibernation, alors…

[^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd

Posté par fravashyo (site web personnel) le 03 avril 2014 à 21:23. Évalué à 1.

ma sortie de veille est instantanée, après le blanc qui lave plus blanc, on a le boot systemd qui démarre plus vite que vite. Par contre ça n'ouvrira pas mon bureau tel qu'il était avant de passer en veille, c'est à dire reprendre les fichiers textes sur lesquels je travaille là où ils étaient, l'explorateur de fichiers ouverts sur mes dossiers de travail en cours, avec les onglets etc

« I approve of any development that makes it more difficult for governments and criminals to monopolize the use of force. » Eric Raymond

[^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd

Posté par Shuba le 03 avril 2014 à 21:26. Évalué à 3.

Pour ce genre de fonctionnalité tu peux utiliser un environnement de bureau moderne.

[^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd

Posté par Christophe Chailloleau-Leclerc le 03 avril 2014 à 21:55. Évalué à 4.

Je peux te faire une vidéo comparative si tu veux, je me fout de systemd ou autre (en tout cas du point de vue polémique), je ne lave pas plus blanc que blanc, je constate juste que mon boot est 2 à 3 fois plus rapide que ma sortie d'hibernation (15 à 20s), et l'extinction doit être au moins 5 fois plus rapide que la mise en hibernation (15 à 20s)… Et par conséquent, je n'utilise pas l'hibernation, j'éteins mon PC.
Quand j'ai découvert l'hibernation au début, c'était le paradis ; c'était au moins 10 fois plus rapide, je n'éteignais plus jamais ma machine. Maintenant, le matériel a beaucoup évolué, et le boot est très grandement accéléré, entre autres grâce aux SSD, et au moins dans certains cas (dont le mien), ça n'a plus vraiment d'intérêt (hormis éventuellement l'aspect préservation de la session, effectivement, mais je m'en passe plutôt bien).
- [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
  
  Posté par Anonyme le 03 avril 2014 à 16:23. Évalué à 2.
  
  Et quel est le problème avec ce bug ?
  
  systemd a besoin des cgroups pour fonctionner, c'est pas nouveau.
  - [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
    
    Posté par Anthony Jaguenaud le 03 avril 2014 à 16:58. Évalué à 2. Dernière modification le 03 avril 2014 à 16:59.
    
    En soit c'est bug et ça ce n'est pas dramatique, ça se corrige.
    
    Le problème c'est que le logiciel plante. Pour un system d'init, ça semble peu robuste. Si par erreur tu compiles ton noyau et n'inclus pas les cgroup, erreur bête, ben ton PC ne démarre pas correctement. Ce qui semble génant, d'autant que le cas est géré proprement ailleurs dans le code.
    
    [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
    
    Posté par Anonyme le 03 avril 2014 à 17:29. Évalué à 2.
    
    Si par erreur tu compiles ton noyau et n'inclus pas les cgroup, erreur bête, ben ton PC ne démarre pas correctement.
    
    Oui, et si par erreur tu compiles ton noyau et n'inclus pas le driver pour ton disque, ton PC démarre pas non plus. Donc rien de nouveau, si tu compiles ton noyau en incluant pas ce qu'il faut, il est possible que ca ne boot pas, avec ou sans systemd.
    
    [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
    
    Posté par Anthony Jaguenaud le 03 avril 2014 à 17:32. Évalué à 5.
    
    Sauf que dans un cas le noyau te dit : "Heu je ne peux pas monter root" et dans l'autre ton init se vautre sans rien te dire, puisqu'il fait un segfault.
    
    [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
    
    Posté par totof2000 le 03 avril 2014 à 17:38. Évalué à -1.
    
    Oui mais l'utilisateur n'a pas à savoir pourquoi et quand sa machine se vautre. C'est réservé aux développeurs. L'utilisateur, quand il voit des caractères s'afficher sur sa machine, il a peur (même si c'est un sysadmin dont c'est le boulot de décoder ces messages cabalistiques). Donc pour cacher ça à l'utilisateur et à l'admin, on a inventé le splash screen et le mode quiet au boot. Très pratique et très utile sur un serveur.
    
    [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
    
    Posté par khivapia le 03 avril 2014 à 18:03. Évalué à 4.
    
    L'utilisateur qui a recompilé son noyau et mal configuré les pilotes disques est un utilisateur, certes un peu avancé, mais certainement pas un développeur (il ne s'agit que de configuration !)… Ou alors il faut absolument être développeur pour recompiler un logiciel à partir des sources ?
    
    Idem pour l'utilisateur qui a oublié d'inclure les cgroups.
    
    [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
    
    Posté par totof2000 le 03 avril 2014 à 18:06. Évalué à 3.
    
    man ironie … ;)
    
    [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
    
    Posté par khivapia le 03 avril 2014 à 21:48. Évalué à 2.
    
    Oups j'avais lu trop vite /o\
    
    [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
    
    Posté par Arathor le 03 mai 2014 à 15:24. Évalué à 1.
    
    Pour faire passer l’ironie sur internet, on a inventé les smileys… :)
    
    [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
    
    Posté par Misc (site web personnel) le 03 avril 2014 à 23:04. Évalué à 2.
    
    Je le refait "est ce qu'il faut être développeur pour utiliser make et faire des choix des options de compilations pour un programme d'un million de ligne de code C", je pense qu'il faut bien se rendre compte que oui, ça aide beaucoup. En fait, c'est comme "est ce qu'il faut être mécano pour changer un moteur", la réponse est sans doute que non, mais ça aide beaucoup si il y a des emmerdes. et des emmerdes, ça arrive plus souvent qu'on croit.
    
    Ceci dit, c'est vrai que l'option est à 'Y' par défaut, mais le doc dit "say N if unsure", cf
    
    https://git.kernel.org/cgit/linux/kernel/git/davem/net.git/tree/init/Kconfig#n855
    
    [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
    
    Posté par Domi le 03 avril 2014 à 23:37. Évalué à 3.
    
    Parles pour toi. Je suis un utilisateur, et je veux savoir pourquoi mon PC se vautre s'il se vautre. Ceci pour une raison très simple: si je ne sais pas pourquoi il se vautre, je n'ai aucun moyen de pouvoir le réparer ou signaler le bug.
    
    Aux agents des services secrets qui lisez ce message, veuillez considérer que défendre votre nation contre ces ennemis interieurs et extérieurs implique de suivre l'exemple de Snowden.
    
    [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
    
    Posté par Anonyme le 03 avril 2014 à 18:13. Évalué à 2.
    
    Effectivement, mais ca ne change pas grand chose, dans les 2 cas ca ne fonctionne pas.
    
    Ca serait mieux si systemd gerait correctement ce cas la, mais ca n'a rien d'un bug critique. Et Lennart ne semble pas etre contre un patch qui ameliore les choses. Donc en fait je vois pas quel est le problème et ce que le lien vers ce bug était censé montrer.
    
    [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
    
    Posté par Maclag le 03 avril 2014 à 22:07. Évalué à 7.
    
    Le titre du journal même est assez explicite:
    
    "Quand l'intransigeance d'**un** développeur tourne au ridicule"
    
    C'est plus le rapport d'une anecdote qu'une charge contre systemd. La charge contre systemd, elle vient dans les commentaires, ce n'est pas l'objet du journal.
    
    Ce que souligne l'auteur, c'est le comportement absurde (ridicule en fait, le mot était bien trouvé) d'un membre du projet qui entre en confrontation avec des dévs du noyau, et forcément ça peut ternir l'image du projet alors que le reste des dévs systemd ont l'air plutôt ouverts à l'idée de foutre la paix aux dévs noyaux et ne pas charger leur option "debug".
    
    Après, je ne sais pas comment ça se passe en interne, mais je trouve plutôt drôle que ce Kay Sievers déclare ne pas vouloir discuter le sujet dans Bugzilla parce que "ce n'est pas un bug", mais ne participe pas non plus en fait à la discussion sur la mailing-list de systemd. Je vois plusieurs hypothèses pour expliquer ça:
    -il est borné comme une autoroute et donc refuse ne serait-ce que de discuter la question, ou il boude
    -il s'est fait prié de la mettre en veilleuse en message privé
    -autre?
    Toujours est-il qu'il s'agit bien d'un mauvais comportement individuel, mais vu que "systemd", les commentaires se devaient de partir en attaque directe.
    
    [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
    
    Posté par Anonyme le 03 avril 2014 à 22:54. Évalué à 0.
    
    Après, je ne sais pas comment ça se passe en interne, mais je trouve plutôt drôle que ce Kay Sievers déclare ne pas vouloir discuter le sujet dans Bugzilla parce que "ce n'est pas un bug", mais ne participe pas non plus en fait à la discussion sur la mailing-list de systemd. Je vois plusieurs hypothèses pour expliquer ça:
    -il est borné comme une autoroute et donc refuse ne serait-ce que de discuter la question, ou il boude
    -il s'est fait prié de la mettre en veilleuse en message privé
    -autre?
    
    Ou peu etre qu'il n'a juste pas encore eu le temps de répondre / il est occupé à autre chose. La discussion sur la ML n'a été ouverte que aujourd'hui.
    
    [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
    
    Posté par Anthony Jaguenaud le 03 avril 2014 à 23:50. Évalué à 3.
    
    C'est plus le rapport d'une anecdote qu'une charge contre systemd. La charge contre systemd, elle vient dans les commentaires, ce n'est pas l'objet du journal.
    
    Moi ce qui m’a surpris, c’est la réaction le Lennart que je traduirai par : « Quoi ? personne n’a essayé sans les cgroup ? »
    Après, ils ont une suite de tests automatique, si j’ai bien compris, donc ajouter un test ou au moins ça vautre pas et hop c’est réglé.
    
    [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
    
    Posté par Zenitram (site web personnel) le 03 avril 2014 à 17:56. Évalué à 5.
    
    , il est possible que ca ne boot pas, avec ou sans systemd.
    
    Malgré tout le respect que j'ai envers les dév de systemd (et bon, virer les cgroups c'est quand même gros et ça se voit au moindre test), un message d'erreur lors de tests de ce qui est nécessaire est quand même plus sympa qu'un crash.
    
    [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
    
    Posté par J Avd le 03 avril 2014 à 19:55. Évalué à 3.
    
    Dites c'est moi ou ça pinouille sec dans les commentaires ?
    La solution c'est de proposer un patch et de clore cette discussion.
    Je suis pas dev mais dès que je vois un truc moche dans du code je propose une modification et c'est rarement rejeté.
    Crowdsourcing guys!
    
    "Gentoo" is an ancient african word, meaning "Read the F*ckin' Manual". "Gentoo" also means "I am what I am because you all are freaky n3rdz"
    
    [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
    
    Posté par totof2000 le 03 avril 2014 à 21:47. Évalué à -7.
    
    La solution, c'est plutôt, lorsqu'on se prétend développeur, d'écrire un code propre et maintenable avant de diffuser.
    
    [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
    
    Posté par Zenitram (site web personnel) le 03 avril 2014 à 21:51. Évalué à 3.
    
    Balance ton code, qu'on rigole : il y a aura toujours des gens pour dire que ce n'est pas propre pour ci ou ça.
    Toujours.
    
    [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
    
    Posté par totof2000 le 03 avril 2014 à 21:58. Évalué à -2.
    
    Je ne cherche pas le code parfait mais là c'est assez moche et difficile à maintenir, digne du code que j'écrivais quand j'étais étudiant.
    
    Il faudra un jour que les développeurs comprennent qu'un code qui marche ne suffit pas, il faut qu'il soit maintenable. Et dans le fait d'être maintenable, il faut penser au fait qu'il doit être assez facilement lisible pour quelqu'un qui ne sait pas forcément ce que tu veux faire.
    
    Pour ceux qui trouvent ce code pas si moche que ça, je vous conseille d'aller lire le livre "coder proprement" de Robert C. Martin chez Pearson. C'est un livre plutôt orienté Java, mais beaucoup des conseils qui y sont donnés sont applicables à tous les langages. Il y a même des exemples de réécriture complet de code un peu comme celui que j'ai montré ici.
    
    [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
    
    Posté par Zenitram (site web personnel) le 03 avril 2014 à 22:01. Évalué à 1.
    
    Je ne cherche pas le code parfait mais là c'est assez moche et difficile à maintenir, digne du code que j'écrivais quand j'étais étudiant.
    
    Balance ton code, encore une fois.
    Je ne m'inquiette pas, il y aura toujours quelqu'un pour dire "là c'est assez moche et difficile à maintenir, digne du code que j'écrivais quand j'étais étudiant" avec 36 raisons qui vont bien (pour la personne qui le dit).
    
    Il faudra un jour que les développeurs comprennent qu'un code qui marche ne suffit pas, il faut qu'il soit maintenable.
    
    Faut croire pour le moment que ça l'est.
    Que ça te plaise ou pas.
    
    Et dans le fait d'être maintenable, il faut penser au fait qu'il doit être assez facilement lisible pour quelqu'un qui ne sait pas forcément ce que tu veux faire.
    
    Il y aura toujours une personne pour dire que ce n'est pas lisible.
    
    Tu ne fais que confirmer la règle.
    en attendant, eux, ils montrent leur code, et leur code est utilisé, avec plein de gens qui commitent, et maintenu. Eux.
    
    [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
    
    Posté par totof2000 le 03 avril 2014 à 22:13. Évalué à -3.
    
    Je ne peux pas te montrer le code que j'ai écrit ces derniers temps vu que je ne l'ai pas écrit pour moi et qu'il n'était pas libre. Ce n'étit pas du C mais du Perl. Je ne pense pas que ce soit du code parfait, mais il était lisible pour ceux qui l'ont repris après (et qui n'étaient pas des développeurs Perl aguerris).
    
    Le code que j'écris fonctionne en général. Dans le cas ou il faut le maintenir pour ajouter des fonctionnalités, ou corriger un bug (je l'ai dit, mon code n'est pas parfait), ceux qui le font s'en sortent très bien.
    
    [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
    
    Posté par Zenitram (site web personnel) le 03 avril 2014 à 22:34. Évalué à -3. Dernière modification le 03 avril 2014 à 22:34.
    
    Je ne peux pas te montrer le code
    
    Donc pratique de dire qu'on fait du bon code quand on ne le montre pas.
    Tu serais quand même le premier à écrire du code que personne ne pourrait critiquer tellement il est bien écrit et lisible. On est toujours pas mauvais dans ce domaine, les autres sont toujours nuls.
    
    Le code que j'écris fonctionne en général. Dans le cas ou il faut le maintenir pour ajouter des fonctionnalités, ou corriger un bug (je l'ai dit, mon code n'est pas parfait), ceux qui le font s'en sortent très bien.
    
    Pareil pour ceux qui travaillent sur systemd.
    CQFD.
    
    [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
    
    Posté par robin le 04 avril 2014 à 00:53. Évalué à 6.
    
    Est ce qu'un jour tu arrêteras les attaques gratuites ? C'est de plus en plus pénible de te lire.
    Ceci dit, bonne nuit quand même :)
    
    bépo powered
    
    [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
    
    Posté par Zenitram (site web personnel) le 04 avril 2014 à 07:33. Évalué à -6.
    
    Bizarre que tu dises ça à moi qui justement critique que la personne fait des attaques gratuites à une autre, et pas à la première personne qui fait les attaques gratuites.
    Celui qui réagit en premier aux attaques gratuites se prend "tu attaques gratuitement" d'un second qui oublit de le dire à la personne raison de la réaction (si cette personne n'avait pas attaqué gratuitement, je n'aurai rien dit), hum.
    
    2 poids, 2 mesures.
    
    [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
    
    Posté par robin le 04 avril 2014 à 10:43. Évalué à 6.
    
    Mon commentaire n'était pas relié à ce thread en particulier, mais à tes messages en général.
    
    Je sais que tu es persuadé que tu n'attaques jamais le premier, mais je vais te parler d'une expérience personnelle. Voici le scénario : le ton monte un peu entre ma mère et moi. Je me sens attaqué, et je me défends. Ma mère s'est senti attaqué en retour et s'est défendu. Résultat, la situation s'est envenimé, alors que nous pensions tout les deux nous être défendu, et nous pensions que c'était l'autre qui avais porté la première attaque. Ce que j'en retiens, c'est qu'en se défendant de manière trop agressive, on peut détériorer fortement une situation.
    
    Ce que je te demande c'est d'être un peu modéré dans ta défense, car elle peut être prise pour une attaque.
    
    bépo powered
    
    [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
    
    Posté par totof2000 le 04 avril 2014 à 12:03. Évalué à 5.
    
    Personnellement, ton avis sur mon code, je m'en fiche royalement. Ce qui m'intéresse c'est l'avis de ceux qui ont repris ce code, et de ceux qui utilisent le code en question pour se simplifier la vie. S'ils ont des critiques à faire sur mon code je suis prêt à les écouter pour écrire du code encore meilleur la prochaine fois.
    Si je pouvais te montrer le code que j'écris (en gros s'il m'appartenait), je le ferais sans hésiter, surtout si tu es ammené à utiliser le code en question ou à le maintenir.
    
    Moi, mon avis, c'est que ceux qui me critiquent sur la critique du code sont ceux justement qui écrivent du code crade, mais qui ne veulent pas se remettre en question. Ils pensent que d'autres sont là pour nettoyer leur code. A mon avis ce sont des gens qui ne veulent pas écrire de code propre, soit disant pour "gagner du temps". mais le temps passé à écrire du code propre se récupère très vite dans la vie d'un projet.
    
    [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
    
    Posté par totof2000 le 04 avril 2014 à 12:12. Évalué à 5.
    
    Ah, au fait : mon attaque n'est pas "gratuite" comme tu peux le penser.
    
    Je n'attaque pas : je constate : un composant essentiel d'un système sur lequel je peux être ammené à faire tourner des services sensibles (c'est mon boulot) peut potentiellement être buggé en raison d'un code "sale". Ce n'est pas une hypothèse farfelue : on a disuté ici de bugs qui n'ont pas été vu potentiellement à cause de code mal écrit. Tu prétends peut-être que je n'ai pas de légitimité à critiquer systemd ? Ben si, parce que des distributions Linux quer j'utilise ( pour des besoins pro - et pour lesquelles mon employeur ou mon client paient pour l'avoir, donc ce n'est pas gratuit) risquent de se trouver compromises. Si je n'utilisais pas ces distributions professionnelement, je m'en ficherais de systemd. Je resterais sous NetBSD, ou j'utiliserais Linux sans rien dire.
    
    En retour, un tas de personnes se mettent à me dire 'circulez, ya rien à voir, t'es pas le développeur de systemd, tu n'as pas à critiquer le code' ou même 'mon,tre moi le code que tu écris avant de critiquer'. Pourquoi ? Comme dis plus haut, si tu étais utilisateur ou mainteneur de mon code, je le montrerais, tu le verrais, tu pourrais le critiquer et même m'insulter si tu voyais des anomalies ou erreurs qu'un étudiant ne commetrais même pas. Là par rapport à moon code tu n'es rien, ni un utilisateur, ni un développeur. Donc ton avis ….
    
    [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
    
    Posté par khivapia le 04 avril 2014 à 09:30. Évalué à 4.
    
    pratique de dire qu'on fait du bon code quand on ne le montre pas.
    Il n'en fait pas, il a même précisé au-dessus qu'il ne faisait pas du code parfait, juste qu'il mettait en place des pratiques meilleures que celles sous-tendues par le code actuellement développé.
    
    [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
    
    Posté par xcomcmdr le 04 avril 2014 à 08:06. Évalué à 1.
    
    Le code que j'écris fonctionne en général.
    
    code qui fonctionne ne veut pas forcément dire code lisible.
    
    "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
    
    [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
    
    Posté par totof2000 le 04 avril 2014 à 12:14. Évalué à 2.
    
    Effectivement, mais un code qui ne fonctionne pas (qui ne fait pas ce pourquoi il a été écrit) a beau être lisible, ça ne sert pas à grand chose :) Ce n'est pas le seul critère permettant de juger d'un "bon code", mais ç'est quand même un critere essentiel.
    
    [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
    
    Posté par khivapia le 04 avril 2014 à 09:27. Évalué à 2.
    
    Balance ton code, qu'on rigole
    
    Ce n'est pas parce que ce qu'on fait soi-même n'est pas parfait qu'il ne faut pas chercher à s'améliorer. Surtout sur un truc aussi critique qu'un système d'init (aux sens fiabilité, sécurité, maintenabilité à long terme vu qu'on n'en change pas tous les 4 matins, etc.)…
    L'essentiel est d'être dans une démarche de progression, de tendre vers la perfection, même si comme tu dis on ne l'atteint que rarement.
    
    [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
    
    Posté par xcomcmdr le 04 avril 2014 à 08:10. Évalué à 3.
    
    La solution, c'est plutôt, lorsqu'on se prétend développeur, d'écrire un code propre et maintenable avant de diffuser.
    
    Ouais, je suis sur que les premières versions de Linux étaient tout aussi propres et maintenables que le Linux d'aujourd'hui… ou pas.
    
    "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
    
    [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
    
    Posté par Batchyx le 03 avril 2014 à 22:01. Évalué à 1.
    
    Toi t'a jamais contribué à un projet Red Hat …
    
    … moi non plus, mais c'est pas faute d'avoir essayé.
# Bug

Posté par barmic le 03 avril 2014 à 14:37. Évalué à 6.

Que quelque chose de vrillé emballe les logs inutilement est un comportement auquel on doit s'attendre

Autant Kay Sievers a l'air d'un aigri, autant là il n'a pas complètement tord. Oui dmesg pourrait peut-être plus fiable, mais systemd ne devrait pas pousser le noyau dans ce genre de cas limite.

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
- [^] # Re: Bug
  
  Posté par dguihal le 03 avril 2014 à 15:03. Évalué à 7.
  
  Et c'est bien quelque chose qui a été identifié et qui a de bonnes chances d'être corrigé :
  
  http://lkml.iu.edu//hypermail/linux/kernel/1404.0/01537.html
- [^] # Commentaire supprimé
  
  Posté par Anonyme le 03 avril 2014 à 15:25. Évalué à 10. Dernière modification le 03 avril 2014 à 15:25.
  
  Ce commentaire a été supprimé par l’équipe de modération.
  - [^] # Re: Bug
    
    Posté par totof2000 le 03 avril 2014 à 15:27. Évalué à 3.
    
    Pourquoi développer un autre programme ? Autant réécrire le noyau dans systemd, ce sera mieux.
    - [^] # Re: Bug
      
      Posté par zebra3 le 03 avril 2014 à 15:40. Évalué à 6.
      
      Il ne manquera plus qu'un bon éditeur de texte, à moins que vimd ne soit prévu ?
      
      Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
      - [^] # Re: Bug
        
        Posté par CrEv (site web personnel) le 03 avril 2014 à 15:42. Évalué à 4.
        
        emacsd tu veux dire ?
        
        [^] # Re: Bug
        
        Posté par zul (site web personnel) le 03 avril 2014 à 15:54. Évalué à 9.
        
        Mon dieu, surtout pas! La rencontre des deux systèmes d'exploitation systemd et emacs pourraient provoquer une catastrophe sans précédent, peut être la création d'un super trou noir ou je ne que sais quoi de pire :)
        
        [^] # Re: Bug
        
        Posté par barmic le 03 avril 2014 à 16:01. Évalué à 5.
        
        peut être la création d'un super trou noir
        
        ou pire l'année du desktop systemd !
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: Bug
        
        Posté par windu.2b le 03 avril 2014 à 16:23. Évalué à 10.
        
        peut être la création d'un super trou noir ou je ne que sais quoi de pire :)
        
        Une réaction en chaîne qui pourrait déchirer le tissu même du continuum espace-temps, provoquant la destruction totale de l'Univers ?
        (Hypothèse la plus pessimiste, je te l'accorde : le cataclysme pourrait être plus localisé et affecter uniquement notre galaxie.)
        
        [^] # Re: Bug
        
        Posté par vlamy (site web personnel) le 03 avril 2014 à 16:39. Évalué à 10.
        
        Une réaction en chaîne qui pourrait déchirer le tissu même du continuum espace-temps, provoquant la destruction totale de l'Univers ?
        (Hypothèse la plus pessimiste, je te l'accorde : le cataclysme pourrait être plus localisé et affecter uniquement notre galaxie.)
        
        C'est vous le doc, Doc !
- [^] # Re: Bug
  
  Posté par Tom D le 03 avril 2014 à 15:40. Évalué à 2.
  
  Il me semble aussi… utiliser "systemd.debug" au lieu de "debug" n'est pas vraiment intéressant si de toutes façons ça bloque le boot lorsqu'on l'utilise…
  - [^] # Re: Bug
    
    Posté par barmic le 03 avril 2014 à 15:53. Évalué à 3.
    
    L'intérêt c'est que tu ne l'utilise pas (sauf quand tu veux vérifier que dmesg est bien corrigé).
    
    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
    - [^] # Re: Bug
      
      Posté par totof2000 le 03 avril 2014 à 16:04. Évalué à -2.
      
      Bah, je croyais qu'on utilisait pas un système qui bug …
      - [^] # Re: Bug
        
        Posté par 🚲 Tanguy Ortolo (site web personnel) le 03 avril 2014 à 16:07. Évalué à 10.
        
        Tu ne confondrais pas plutôt avec un clavier qui se blo
# Beaucoup de bruit pour rien

Posté par Anonyme le 03 avril 2014 à 16:22. Évalué à 10.

Au bout de quelques échanges assez vifs, Kay Sievers a fermé le ban (et le
ticket bugzilla!) en déclarant qu'il ne s'agissait en aucun d'un bug (en tout
cas, pour lui, ça ne concerne pas systemd).

Pas exactement. Il a expliqué que bugzilla n'est pas fait pour les discussions, et demandé d'en parler plutot sur la mailing list. Ce qui ne me semble pas forcement une mauvaise idée: reserver bugzilla pour suivre les taches en cours ou il y a réellement quelquechose à faire, et utiliser la mailing list pour les discussions ou tout le monde n'est pas encore tombé d'accord sur ce qu'il fallait faire.

Et sinon des desaccords entre differentes personnes sur des projets open source, il y en a tous les jours, ca n'a rien d'exceptionnel. Sauf que la ca concerne systemd donc t'as des gens qui sont la pour profiter de chaque occasion pour sortir un "ca traduit bien un état d'esprit de la part des développeurs de systemd".
- [^] # Re: Beaucoup de bruit pour rien
  
  Posté par totof2000 le 03 avril 2014 à 16:32. Évalué à -5.
  
  "t'as des gens qui sont la pour profiter de chaque occasion pour sortir un "ca traduit bien un état d'esprit de la part des développeurs de systemd"."
  
  Ca traduit bien l'état d'esprit des fanboys systemd.
  - [^] # Re: Beaucoup de bruit pour rien
    
    Posté par 🚲 Tanguy Ortolo (site web personnel) le 03 avril 2014 à 16:43. Évalué à 3.
    
    Du point de vue de la méta-discussion, c'est vilain comme remarque, parce que ça donne envie de tenter une amorce de récursivité, mais c'est trop compliqué pour trouver une formulation appropriée pour cela… :-(
    - [^] # Re: Beaucoup de bruit pour rien
      
      Posté par totof2000 le 03 avril 2014 à 16:48. Évalué à 3.
      
      ça donne envie de tenter une amorce de récursivité,
      
      C'était le but, il ne faut pas prendre ma remarque au premier degré.
      - [^] # Re: Beaucoup de bruit pour rien
        
        Posté par 🚲 Tanguy Ortolo (site web personnel) le 03 avril 2014 à 17:24. Évalué à 5.
        
        Je m'en doutais, seulement je n'ai pas réussi à continuer, d'où la déception…
      - [^] # Re: Beaucoup de bruit pour rien
        
        Posté par PachaFonk le 03 avril 2014 à 17:32. Évalué à 10.
        
        Aller, je me lance:
        
        t'as des gens qui sont la pour profiter de chaque occasion pour sortir un "ca traduit bien un état d'esprit de la part des développeurs de systemd"."
        
        Ca traduit bien l'état d'esprit des fanboys systemd.
        
        Ca traduit bien l'état d'esprit des haters de fanboys systemd.
# Kay Sievers qu'est si vert à pourtant raison

Posté par calandoa le 03 avril 2014 à 19:48. Évalué à 8.

« Que quelque chose de vrillé emballe les logs inutilement est un comportement auquel on doit s'attendre »

Il a tout à fait raison. J'ai par exemple connu le cas où systemd redémarrerait en continu Network Manager à cause d'un problème avec le wpa supplicant (ce qui est d'autant plus logique que je n'utilisait pas le Wi-Fi), rajoutant un paquet d'erreurs dans les logs chaque seconde et donc donc une petite dizaine de Go en qq jours, jusqu'à mettre le système à genou et l'empêcher de booter. Un vrai plaisir de comprendre la cause.

Après, il est vrai que systemd peut aussi inventer d'autres problèmes retors pour tout niquer, donc peut être qu'il pourrait généraliser et dire :
« Que quelque chose de vrillé foute la merde est un comportement auquel on doit s'attendre »

Et puis comme il faut appeler un chat un chat :
« Que systemd foute la merde est un comportement auquel on doit s'attendre »
- [^] # Re: Kay Sievers qu'est si vert à pourtant raison
  
  Posté par Batchyx le 03 avril 2014 à 22:22. Évalué à 3.
  
  Pour connaître comment Network Manager cause à wpa_supplicant, ton post me provoque un déluge de WTF.
  
  Heureusement, j'utilise ni Systemd ni Network Manager, et même pas l'API D-Bus de wpa_supplicant (qui, j'imagine, n'est pas trop en faute ici, de toute façon son code est plus joli que systemd), donc je vais pas avoir envie de comprendre pourquoi Network Manager s'arrête lorsqu'un appel D-Bus foire, alors qu'un appel D-Bus, ça peut foirer tout le temps.
- [^] # Re: Kay Sievers qu'est si vert à pourtant raison
  
  Posté par gnumdk (site web personnel) le 04 avril 2014 à 09:14. Évalué à -2.
  
  rajoutant un paquet d'erreurs dans les logs chaque seconde et donc donc une petite dizaine de Go
  en qq jours
  
  Mauvais admin, changer d'admin.
  ou: Mauvase distrib, changer de distrib.
- [^] # Commentaire supprimé
  
  Posté par Anonyme le 05 avril 2014 à 12:19. Évalué à 4. Dernière modification le 05 avril 2014 à 12:20.
  
  Ce commentaire a été supprimé par l’équipe de modération.
  - [^] # Re: Kay Sievers qu'est si vert à pourtant raison
    
    Posté par Shuba le 05 avril 2014 à 15:02. Évalué à 3.
    
    En l'occurence la le problème apparait avant même que syslogd ne soit lancé. Ça fait partie des grosses avancées de systemd d'ailleurs, il y a une gestion des logs dès les tout premiers instants du démarrage.
    
    Par contre du coup il faut être prudent et éviter de bourriner /dev/kmsg, mais le bug en question a été résolu côté systemd. Que le kernel se protège contre ce genre de problème est une bonne chose en soit, le kernel ne devant pas faire confiance à l'userspace.
# 200 ème commentaire !

Posté par Mali (site web personnel) le 04 avril 2014 à 12:27. Évalué à -10. Dernière modification le 04 avril 2014 à 12:28.

\o/
- [^] # Re: 200 ème commentaire !
  
  Posté par totof2000 le 04 avril 2014 à 17:09. Évalué à 0.
  
  Encore un petit effort et tu seras à 300.
  - [^] # Re: 200 ème commentaire !
    
    Posté par Anthony Jaguenaud le 04 avril 2014 à 17:11. Évalué à 2.
    
    Encore 53.
    - [^] # Re: 200 ème commentaire !
      
      Posté par Anthony Jaguenaud le 04 avril 2014 à 17:12. Évalué à 2.
      
      Encore 52.
      - [^] # Re: 200 ème commentaire !
        
        Posté par Anthony Jaguenaud le 04 avril 2014 à 21:51. Évalué à 1.
        
        Encore 3.
        
        [^] # Re: 200 ème commentaire !
        
        Posté par BAud (site web personnel) le 04 avril 2014 à 21:55. Évalué à 0.
        
        2
        
        [^] # Re: 200 ème commentaire !
        
        Posté par totof2000 le 05 avril 2014 à 16:07. Évalué à 3.
        
        Encore 49 et c'est 400.
# Theodore T'So a fait un update

Posté par Domi le 04 avril 2014 à 13:18. Évalué à -4.

Ts’o and Linus And The Impotent Rage Against systemd

"…a lot of the fear and uncertainty over systemd may not be so much about systemd, but the fear and loathing over radical changes that have been coming down the pike over the past few years, many of which have been not well documented, and worse, had some truly catastrophic design flaws that were extremely hard to fix."
…
Nous avons donc un développeur du kernel qui est très compétent et qui éprouve des difficultés à comprendre et à utiliser systemd et policykit dans son système. Nous en tant que simples utilisateurs ne devrions pas nous sentir concerné par ces technologies qui sont extrêmement complexes et built-to-be-broken (construites pour être cassées) ?
…
"…Kay Sievers et Lennart Poettering ont souvent le même style de réponse aux critiques que les développeurs de GNOME [lire d'autres développeurs de Red Hat] — partez, vous n'avez aucune idée, nous savons mieux que vous, et de plus nous avons les privilèges pour déposer le code et vous ne l'avez pas, donc foutez le camp."

De façon prévisible, les fans se ruent à la défense de systemd dans les commentaires, ils nous expliquent comment systemd est merveilleusement documenté et supporté, et quel paradis calme et fasciste la liste d'emails de systemd est, et à quel point les développeurs répondent à chaque bug, requête et soumission de patch.

Il y a 2 jours, nous avons vu Linus Torvalds (the creator of Linux and maintainer of the Linux kernel), partir dans une tirade contre - oui vous avez deviné – des développeurs de systemd en raison de leur réponse atroce à un bug de systemd qui plante le kernel et empêche de pouvoir le déboguer… un problème pour Kay car Red Hat a également l'écume à la bouche pour avoir leur implémentation de D-BUS basée sur le noyau, sans doute pleine de bogues et de défauts de sécurité mise en œuvre et incluse dans nos noyaux. D'autres développeurs étaient si irrités qu'ils ont suggéré de simplement déclencher une panique du noyau et d'arrêter le système quand systemd est détecté en cours d'utilisation.
…
Cependant même la tirade de Linus, et la longue discussion des utilisateurs qui l'a suivie, manque complètement ce qui est en train d'arriver à Linux.
…
Red Hat est une corporation qui pèse des milliards de dollars et qui a des liens étroits avec les militaires US (leur plus grand client), et donc inévitablement avec la NSA (une organisation militaire), etc. À ce conflit d'intérêt vient s'ajouter qu'ils sont partenaires de Google, Apple, et d'autres corporations trop grandes pour être imaginables et dont les mains sont dans la boue. LEs développeurs de Red Hat contrôlent de façon dictatoriale l'ingénierie de base de Linux, y compris des composants comme udev, udisks, xorg, dbus, systemd, etc., utilisés par toutes les principales distributions Linux, ainsi que d'autre composants de bureau communs tels que GNOME et GTK. (As Ts’o put it, “we have commit privs and you don’t”.) Ces ont de simples faits qui curieusement ne sont jamais discutés. Du point de vue de beaucoup de développeurs, ces développeurs de Red-Hat on constamment introduits des technologies fermées, trop complexes, et en rupture de sécurité dans Linux depuis des années, et ils ont un long et fatigant historique de sabotage du développement du kernel, créant des bogues et des problèmes sans fin pour les développeurs du kernel, ce que souvent ils refusent catégoriquement de régler. Linus les connaît bien - vraiment?

Pourtant, le mythe continue que Linux n'est en quelque sorte pas subrepticement développé comme un produit du complexe militaro-industriel , et que son génie de base repose sur les contributions ouvertes et libres. Des discussions comme celle-ci tournent autour de tout ce que les bugs de la journée sont, et ne parviennent pas à évaluer complètement ce qui semble être des dommages intentionnels et systémiques fait pour l'écosystème Linux, principalement par les développeurs de Red Hat .

Réveillez-vous, crétins - et ceci vous comprend Linus (qui aime à s'appeler lui-même crétin). Commencer à dire les choses comme elles sont, et commencer à vous attaquer aux problèmes systémiques réels dans l'ingénierie de Linux - à savoir que des chemises brunes comme Kay Sievers et Lennart Poettering sont juste l'avant-garde d'une réalité beaucoup plus laide. Sinon, vous essayez juste de vider l'océan avec une pelle - vos actions sont inutiles et vouées à l'échec. Se mettre en colère ne va pas aider - commencez à être intelligent, et commencez à développer un système d'exploitation réellement libre et ouvert, en sortant vous-savez-qui de la boucle. Si vous ne pouvez pas ou ne voulez pas le faire , alors vous pouvez tout aussi bien leur abandonner Linux entièrement, qui est à peu près le cas déjà.

Aux agents des services secrets qui lisez ce message, veuillez considérer que défendre votre nation contre ces ennemis interieurs et extérieurs implique de suivre l'exemple de Snowden.
- [^] # Re: Theodore T'So a fait un update
  
  Posté par gnumdk (site web personnel) le 04 avril 2014 à 13:54. Évalué à 7.
  
  Merde, Alain Soral tient un blog à propos de Linux?
  - [^] # Re: Theodore T'So a fait un update
    
    Posté par Domi le 04 avril 2014 à 15:56. Évalué à -10.
    
    Faut changer de dealer dans ton cas!
    
    Le fait que l'armée US est le plus gros client de Red-Hat n'est pas une nouveauté, ni celui que grâce à cela et des corporations comme Goggle, toutes impliquée dans le scandale de la NSA, Red-Hat est devenue une multinationale qui pèse des milliards de dollars et qui ne poursuit que son propre intérêt, pas celui de linux.
    
    Au moins avec systemd leur plan est clair: prendre le contrôle de GNU-Linux pour le transformer en un GNU-systemd OS similaire à windows, hyper compliqué, mal documenté et cassé par design comme le démontre ce bug et d'autres. Ils ne s'en cache même pas:
    
    Aux agents des services secrets qui lisez ce message, veuillez considérer que défendre votre nation contre ces ennemis interieurs et extérieurs implique de suivre l'exemple de Snowden.
    - [^] # Re: Theodore T'So a fait un update
      
      Posté par sanao le 08 avril 2014 à 21:45. Évalué à 2.
      
      Pour un gars qui lutte contre "l'impérialisme américain", tu pourrais au moins utiliser le mot "entreprise" et non "corporation".
- [^] # Re: Theodore T'So a fait un update
  
  Posté par Maclag le 04 avril 2014 à 17:20. Évalué à 7.
  
  Précision qui me semble importante parce que le titre du commentaire et son contenu prêtent à confusion:
  
  Il ne s'agit absolument pas de la position de T'So, mais d'une reprise de ses dire pour élaborer une théorie euh… dont chacun jugera de la pertinence.
# Réponse de Lennart

Posté par Shuba le 04 avril 2014 à 20:31. Évalué à 5.

Lennart Poettering a répondu sur Google+, expliquant que le flood de /dev/kmesg était corrigé côté systemd, mais qu'il pense qu'avoir du rate limiting dans le kernel serait une bonne chose.

Cependant il insiste sur le fait que l'option debug de la ligne de commande du noyau doit être interprétée par systemd, car elle indique potentiellement l'intention d'un utilisateur de débugger son démarrage, le problème pouvant se situer au niveau du noyau ou de systemd.

Le message a été partagé par Greg Kroah-Hartmann, ce qui a attiré une réaction énervée de Linus (il faut dire que Lennart n'est pas toujours poli dans son message), qui voit là un signe de non coopération des développeurs de systemd avec les autres projets.

Personnelement je suis plutôt de l'avis de Lennart sur le fait que l'option debug doit permettre de débugger systemd également, mais je trouve que la situation aurait pu ne pas être problématique si un dialogue constructif s'était ouvert dès le début, en lieu et place de l'agressivité de Kay Sievers.
- [^] # Re: Réponse de Lennart
  
  Posté par Anonyme le 04 avril 2014 à 21:24. Évalué à 1.
  
  si un dialogue constructif s'était ouvert dès le début, en lieu et place de l'agressivité de Kay Sievers
  
  Il y a eu de l'agressivité des 2 cotés, pas uniquement de Kay.
- [^] # Re: Réponse de Lennart
  
  Posté par Batchyx le 04 avril 2014 à 21:26. Évalué à 4.
  
  C'est complètement idiot comme raisonnement. Si j'ai envie de déboguer mon noyau, je débogue mon noyau. Si j'ai envie de déboguer systemd, je débogue systemd. Si j'ai envie de déboguer les deux, je débogue les deux.
  
  Si ma souris clignote et marche que toutes les demi secondes, j'ai envie de déboguer le noyau. Si mon driver foire l'initialisation du périph une fois sur deux, j'ai envie de déboguer mon driver. Dans les deux cas, j'en ai strictement rien à foutre de systemd, j'aurai plutôt envie de lui fermer sa gueule.
  
  Les gens qui déboguent sont en général des gens intelligents, qui savent faire la distinction entre des bugs noyau, des bug d'un système init et des bugs des deux. Décider à leur place ce qui est mieux pour eux c'est les prendre pour des gros cons. Après faut pas s'étonner que les développeurs se sentent offensés et qu'ils attaquent les mainteneurs de systemd.
  - [^] # Re: Réponse de Lennart
    
    Posté par Shuba le 04 avril 2014 à 21:52. Évalué à 2.
    
    À mon avis il va y avoir deux catégories de personnes voulant débugger: les gens qui effectivement s'y connaissent et ont déjà une idée de l'origine de leur problème, et là je suis d'accord avec toi ils vont ne vouloir avoir qu'un seul debug à la fois (ce qui est possible). Mais par contre d'autres seront moins versés dans la technique, auront un problème et demanderont de l'aide. On leur conseillera alors sans doute de mettre debug dans la kernel command line, et ça peut être utile d'obtenir des infos non uniquement du kernel.
    
    D'ailleurs si on en croit les commentaires de Linus sur le fil google+ de GKH, ça ne constitue pas vraiment le cœur du problème à la base:
    
    What I mind is people closing bugs and not admitting mistakes. If Kay had even said "sorry, the excessive output was a bug in systemd, it's already fixed in current -git", that would have been a valid reason to close the bug.
    
    Par contre le passif entre Kay et Linus (ce n'est pas la première fois que Kay ferme abruptement un bug sans plus d'explications) pousse Linus à vouloir un autre comportement par défaut afin d'éviter la récurrence de ce genre de problème:
    
    Side explanatory note: and it's because of that known history of abusive behavior that I would prefer systemd now use "systemd.debug".
    - [^] # Re: Réponse de Lennart
      
      Posté par Batchyx le 05 avril 2014 à 11:04. Évalué à 3.
      
      On leur conseillera alors sans doute de mettre debug dans la kernel command line, et ça peut être utile d'obtenir des infos non uniquement du kernel.
      
      Et leur dire de mettre "debug systemd.debug", c'est trop compliqué ?
      
      D'ailleurs si on en croit les commentaires de Linus sur le fil google+ de GKH, ça ne constitue pas vraiment le cœur du problème à la base
      
      Pour Linus ce n'est pas un problème, mais d'autres mainteneurs ne sont pas de cet avis. Certains voulait désactiver par défaut la possibilité pour l'userspace de pourrir le buffer de log du noyau.
      - [^] # Re: Réponse de Lennart
        
        Posté par Shuba le 05 avril 2014 à 15:06. Évalué à 0.
        
        Et leur dire de mettre "debug systemd.debug", c'est trop compliqué ?
        
        Non effectivement c'est possible, mais il faut alors que ce genre d'information se propage pour que ça devienne utile.
        
        Certains voulait désactiver par défaut la possibilité pour l'userspace de pourrir le buffer de log du noyau.
        
        Tu penses au patch qui voulait ne plus exposer "debug" sur la commandline, ou au patch sur le rate-limiting, ou à autre chose que j'ai loupé?
        
        [^] # Re: Réponse de Lennart
        
        Posté par khivapia le 07 avril 2014 à 10:38. Évalué à 2.
        
        Non effectivement c'est possible, mais il faut alors que ce genre d'information se propage pour que ça devienne utile.
        
        Tu veux dire qu'il faut faire une documentation des options de debug ?
        
        [^] # Re: Réponse de Lennart
        
        Posté par Domi le 08 avril 2014 à 01:58. Évalué à -10.
        
        Pour info, n'importe quel paramètre peut être rajouté à la ligne de commande du noyau. Si le noyau connaît le paramètre il l'interprète, autrement il ne fait que le passer à l'environnement. Cela peut être très pratique pour passer des paramètres au système d'init.
        
        Aux agents des services secrets qui lisez ce message, veuillez considérer que défendre votre nation contre ces ennemis interieurs et extérieurs implique de suivre l'exemple de Snowden.
        
        [^] # Re: Réponse de Lennart
        
        Posté par totof2000 le 08 avril 2014 à 09:48. Évalué à 8.
        
        CE N'EST PAS LA PEINE DE CRIER, NOUS NE SOMMES PAS SOURDS !!!!
- [^] # Re: Réponse de Lennart
  
  Posté par gnx le 04 avril 2014 à 21:40. Évalué à 9.
  
  Poettering :
  
  We are putting together an OS here after all, not just a kernel, and a kernel is just one component of the OS among many, and ultimately an implementation detail. We are writing an OS here for the general purpose, not just a toy for a clique of kernel developers.
  
  J'en ai rencontrés des mecs imbus d'eux-même, mais celui-ci vaut le détour. Quel abruti…
  - [^] # Re: Réponse de Lennart
    
    Posté par xcomcmdr le 04 avril 2014 à 21:56. Évalué à 1.
    
    C'est tellement beau, j'en ai le clavier que se blo
    
    "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
  - [^] # Re: Réponse de Lennart
    
    Posté par Maclag le 04 avril 2014 à 22:46. Évalué à 10.
    
    Ce qui est drôle, c'est que ça vient du même mec qui disait à quel point il était heureux de bosser sur le noyau Linux en particulier en laissant tomber POSIX parce que le noyau Linux est tellement plus puissant avec tellement plus de fonctionnalités.
    
    Un détail d'implémentation un peu particulier, donc…
    - [^] # Re: Réponse de Lennart
      
      Posté par Anonyme le 04 avril 2014 à 23:34. Évalué à 2.
      
      Ben il n'a pas dit qu'il n'était pas content du noyau Linux.
- [^] # Re: Réponse de Lennart
  
  Posté par Shuba le 04 avril 2014 à 22:01. Évalué à 3.
  
  Et le même Greg Kroah Hartmann de tenter de calmer les ardeurs (toujours le même fil google+, mais il semblerait qu'on ne puisse pas faire de lien vers un commentaire..):
  
  So we have 1 bug that was already fixed, and 2 patches created out of all of this. A rather productive result in my opinion in the end. We've had worse outcomes for much crazier arguments in the past. We're growing up!
  
  Traduction:
  
  Donc nous avons un bug qui était déjà réparé, et deux patchs qui ressortent de cette discussion. A résultat plutôt productif finalement. Nous avons eu de moins bonnes conséquences sur des disputes autrement plus musclées. Nous grandissons!
- [^] # Re: Réponse de Lennart
  
  Posté par Maclag le 04 avril 2014 à 22:43. Évalué à 4.
  
  Personnelement je suis plutôt de l'avis de Lennart sur le fait que l'option debug doit permettre de débugger systemd également, mais je trouve que la situation aurait pu ne pas être problématique si un dialogue constructif s'était ouvert dès le début, en lieu et place de l'agressivité de Kay Sievers.
  
  Sinon, dans la liste de discussion systemd, quelqu'un proposait de laisser "debug" au noyau, pas parce que c'est logique mais parce que c'est historiquement comme ça et à part chez les "nouveaux", c'est tout simplement le comportement attendu. Il propose aussi, en plus d'une option systemd.debug, d'introduire un nouvelle option "dbg" qui servirait à activer plusieurs debug en même temps:
  dbg "seul": déclenche debug et tous les trucs.debug
  dbg=ks : kernel et systemd
  et ainsi de suite, une lettre par sous-système
  
  Ça me semble être un excellent compromis et à vrai dire dbg=… serait certainement moins emmerdant à taper qu'un ensemble d'options à rallonge.
  - [^] # Re: Réponse de Lennart
    
    Posté par claudex le 04 avril 2014 à 23:08. Évalué à 5.
    
    Personnellement, je n'aime le fait qu'un nom et son abréviation ait des significations différentes. Je trouve ça très perturbant quand on ne connait pas et qu'on doit rentrer dans la doc.
    
    « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
- [^] # Re: Réponse de Lennart
  
  Posté par Zenitram (site web personnel) le 04 avril 2014 à 22:48. Évalué à -3. Dernière modification le 04 avril 2014 à 22:52.
  
  mais je trouve que la situation aurait pu ne pas être problématique si un dialogue constructif s'était ouvert dès le début
  
  Euh… Attend, tu enfonces un gars et pas l'autre la.
  Parce que bon, un mec qui dit "utilisse 'systemd.debug' parce que moi je veux garder 'debug' et je n'imagine même pas un instant utiliser 'kernel.debug'", c'est un peu un trolleur de permière classe à la sauce "fait ce que je dis, pas ce que je fais".
  
  Que les développeurs du kernel utilisent un espace de nom avant d'aller faire la morale aux autre de ne pas utiliser d'espace de noms : "debug" pour debugger tout ce qui bouge, "kernel.debug" pour débugger le kernel uniquement, "systemd.debug" pour debugguer systemd uniquement est bien plus logique qu'un logiciel (qu'il soit le kernel ou pas, on s'en fout, même Microsoft n'ose pas s'attribuer comme ça des choses sans espaces de nom dans la base de registre) qui dit qu'il prend "debug" pour lui et que les autres doivent utiliser un espace de nom.
  Ou que si c'est pour des raisons historique, qu'il en fasse part et argumente que c'est à cause de l'histoire et pas un truc bourrin "c'est comme ça, c'est à nous".
  
  Le non constructif est des deux côtés, après chacun dans son coin voit ce qu'il fait du problème.
  
  Edit: argh maglag dit la même chose "dbg=ks" que c'est pas mal, il ya 26 lettres :)
  - [^] # Re: Réponse de Lennart
    
    Posté par Shuba le 04 avril 2014 à 23:14. Évalué à 1.
    
    Effectivement en relisant le rapport de bug le rapporteur n'est pas des plus polis, il tend à vouloir donner des ordres plutôt que des suggestions. My bad.
  - [^] # Re: Réponse de Lennart
    
    Posté par Batchyx le 05 avril 2014 à 00:46. Évalué à 8.
    
    Ben oui ça va être pratique tiens, de rajouter kernel.root=truc kernel.ro kernel.bootwait kernel.nfs= kernel.console=kernel.netconsole... kernel.ehci_hcd.disable_uhci_hack C'est pas comme si la ligne de commande du noyau avait une taille maximale, et que, comme son nom l'indique pas, cette ligne de commande est passé dans argv[1] au noyau, et sert à euh … donner des paramètres au noyau. Aller lire /proc/cmdline et l'interpréter pour soi est quand même de la grosse bidouille (autant qu'utiliser kmsg comme remplaçant à journald) et fallait pas s'étonner que l'abus finisse par tout faire péter.
    
    Mais bon, c'est vraiment de la merde Linux, quand je passe l'option --debug à KDE, ça débogue pas MediaInfo.
  - [^] # Re: Réponse de Lennart
    
    Posté par totof2000 le 05 avril 2014 à 12:43. Évalué à 10.
    
    Euh… Attend, tu enfonces un gars et pas l'autre la.
    Parce que bon, un mec qui dit "utilisse 'systemd.debug' parce que moi je veux garder 'debug' et je n'imagine même pas un instant utiliser 'kernel.debug'", c'est un peu un trolleur de permière classe à la sauce "fait ce que je dis, pas ce que je fais".
    
    Et alors ? Linus est chez lui dans son noyau (ce qui n'est pas le cas des développeurs de systemd) et il fait ce qu'il veut. Si Poettering et sa bande ne sont pas contents, ils forkent le noyau, comme ça ils auront leur OS complètement sous leur contrôle et feront ce qu'ils veulent.
    
    C'est un état d'esprit courant aujourd'hui, et qui malhereusement se transmet aussi dans le monde du développement libre : "je fais ce que je veux, ou je veux, je laisse trainer mes déchets et mes affaires partout chez les autres, et tant pis s'ils ne sont pas contents C'est moi donc je me permet de le faire".
    - [^] # Re: Réponse de Lennart
      
      Posté par Domi le 08 avril 2014 à 02:06. Évalué à -4.
      
      C'est bien ce qu'ils vont faire, ce n'est qu'une question de temps avant que RH ne forke le noyau. Cela sera sans doute une très bonne chose autant pour RH que pour GNU/Linux.
      
      Aux agents des services secrets qui lisez ce message, veuillez considérer que défendre votre nation contre ces ennemis interieurs et extérieurs implique de suivre l'exemple de Snowden.
      - [^] # Re: Réponse de Lennart
        
        Posté par Plombier le 15 avril 2014 à 14:08. Évalué à -2.
        
        Salut, je partage l'avis de Domi, tout n'est qu'une question de temps avant qu'ils ne se mettent vraiment à l'oeuvre.
        Le plombier
# I forget just why I taste

Posté par sp00k le 05 mai 2014 à 01:05. Évalué à 1.

Bonsoir tout le monde,

N'étant pour ma part pas un développeur chevronné, je ne saurais que dire des remarques sur le code.

Par contre, ce qui me semble évident à la lecture de ce journal, que ce soit pour des raisons techniques ou pas, c'est que le mauvais esprit ou la mauvaise foi n'ont rien à faire dans une équipe, que ce soit pour du LL ou dans une autre équipe…

On peut toujours retrouver à dire du code d'un autre, pour de bonnes ou pour de mauvaises raisons.

Ce qui me désole après des années à avoir suivi linuxfr (1), c'est que je pense qu'un débat technique n'était pas nécessaire. Je suis peut être trop tombé dans le fonctionnel, mais je n'imagine à aucun moment quelqu'un de mon équipe se comporter comme ça.

Je ne fais pas parti des gens qui écrivent du libre (même si j'aurais bien aimé et j'essaye de participer à la ML debian), pourtant j'essaye d'en diffuser les idées. Je serais bien incapable d'écrire des logiciels de qualité, mais pour moi le libre est avant tout un idéal: respect, plaisir, partage.

Et dans cet idéal, les gens "géniaux" tout comme les gens bêtes (comme moi) ont leur part à jouer, quelque soit leur idéaux. Je trouve ça dommage de perdre autant de temps à cause de ce genre de comportement trop élitiste, même si finalement ce sont grâce à eux que le LL avance.

Portez vous bien,
Bisous, Louis.

(1) Je lis linuxfr depuis des années et j'ai du me recréer un compte à force de lire comme une moule sans poster…
- [^] # Re: I forget just why I taste
  
  Posté par Anonyme le 05 mai 2014 à 10:07. Évalué à 2.
  
  pour moi le libre est avant tout un idéal: respect, plaisir, partage.
  
  Et désaccords. On est pas obligés d'etre d'accord avec tout le monde et on a le droit de le dire.
  
  Je trouve ça dommage de perdre autant de temps à cause de ce genre de comportement trop élitiste
  
  Le temps perdu, c'est surtout en trolls lancés sur les sites de news, avec les gens qui sautent sur la moindre occasion pour critiquer systemd.
  
  Au final, le problème a été réglé assez rapidement, et c'est assez normal que tout le tombe soit pas immediatement d'accord sur tout et qu'il y ait quelques clashs de temps en temps.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.