Zenitram a écrit 29459 commentaires

Faut pas déconner : C'est réel, la vraie vie, que le courant te lâche plus souvent qu'un malloc à NULL.

La priorité est clairement la gestion des coupures de courant (ou simplement un crash de l'OS, même Linux).

Ce genre de "robustesse" a effectivement un coût, ce que pas mal de commentateurs semblent ignorer.

Je crois surtout qu'il y a pas mal de commentateurs qui programment de temps en temps, et "ont le temps". A moins qu'ils disent des choses qu'ils ne font pas (qui montre son code?). Mais je constate quand même qu'en ce samedi on a plus de monde qui "assume" et dit que oui, c'est une connerie de gérer les malloc/realloc à NULL. Ouf! Ca fait du bien de lire ça, plus réaliste.

Dans l'exemple cité, il n'y a pas de fuite mémoire (ça crashe).
Ce n'est pas le problème.

Je suis d'accord qu'il faut faire attention aux fuites mémoire car ça fait chier tout le monde. Mais je persiste à penser qu'une personne n'a pas forcément à penser à "tout" comme elle fait une appli "toute petite et sans quelqu'un pour payer". Après, si quelqu'un paye parce que ça vaut le coup… Perso, le mec qui me fait du code "super secure" pour un prototype par exemple "parce qu'il faut toujours bien coder", je le paye moitié moins car 50% du temps est pour son plaisir (soit l'affaire prend et j'ai des sous pour refaire une passe "plus propre" après quelques refactoring, soit ça part à la poubelle et on s'en fout du realloc à NULL)

C'est une raison pour ne pas améliorer l'application ?

Ce n'est pas le soucis non plus. Personne n'a dit, il me semble, qu'il ne fallait surtout pas le faire. Perso, ce que j'ai dit c'est que c'est pas le plus important (ça crashe, ça libère tout et tu as vraiment des problèmes énormes sur ton OS pour n'avoir rien à foutre de ce programme "à la con". On ne parle toujours pas de fuite mémoire). Envoie un patch, tu as fait le boulot. Mais je trouve limite de demander que le code pour un programme "à la con" soit 100% parfait surtout si on ne paye rien (oui toujours l'argent… Si vous acceptez de travailler gratos, faites-moi signe)

C'est comme la sécurité : pas la peine de faire une triple authentification pour accéder à des données non sensibles. Il faut savoir s'adapter suivant l'importance de la chose. Dire "il faut toujours faire", c'est un peu gros.

Dans le sens où… Je crois qu'on peut reprendre la même phrase pour udev et systemd…

Et accessoirement te conformer à l'API.

Quand tu as ce genre d'erreur pour des petites demande de création mémoire comme un bête outil de l'exemple, que l'outil soit conforme ou pas à l'API est le dernier de tes soucis… à la limite si tu demandais un realloc(100*1000*1000), je comprendrai que tu rales que ce ne soit pas pris en compte, mais la : le programmeur a juste autre chose à foutre que de blinder de test un programme dans le but d'arriver à un niveau de logiciel de pilotage d'avion, alors que c'est juste un petit programme. Après, si tu sponsorises ce genre de développement, il sera sans doute content de le faire pour toi. En attendant : tout le monde (à part les gens qui n'ont rien à voir dans l'histoire : ni utilisateur ayant un crash ou une perte mémoire car il a été démontré que ce n'est pas possible, ni le dév') s'en fout!

C'est malin, comme on fait pour troller alors? :)
Je suis d'accord pour dire que ce serait mieux un truc moins "envahissant", mais ce truc a un avantage : il existe et répond au besoin. initd existe mais ne répond pas/plus au besoin et le projet X répond au besoin tout en étant modulaire mais n'existe pas…

Si il y avait un choix (aussi utilisable) en micro noyau, je pense qu'on serait nombreux à apprécier

Pareil pour systemd. Non, le système actuel n'est pas une solution viable, on change, c'est pour une raison. Je te laisse proposer ta version qui fait autant de choses que systemd (les perfs, la synchro, les configs communes à toutes les distros, ce sont des choses à faire).

Mais pourquoi faire compliqué alors que l'on peut faire simple, puissant et portable ?

Les logs textes ne sont ni simples (amuses toi à automatiser le bordel…), ni puissant (les grep sur du texte, c'est d'une lenteur, sponsorisé par Intel?), ni portable (format non précis, traductions).

On est donc bien d'accord : il faut virer ces formats pas simples pas puissant pas portable, donc virer les logs "texte" tels qu'ils sont fait maintenant.

Après, je sais, c'est dur de perdre son boulot, quand l'outil qui remplace permet de diviser par deux le nombre d'admins qui n'ont plus besoin de faire des scripts à la con… Si RedHat fait ça, tu crois que c'est pour le plaisir, ou ça va devenir un argument de vente sur le nombre d'admin par machine?

Ca devient ridicule comme argument

Le binaire pas lisible par l'être humain n'en est pas moins ridicule. Il s'agit d'une simple conversion, ça ne tue personne. parait même que c'est déjà disponible, donc du coup tu peux greper dessus.

Bref, ce qui est ridicule est d'arriver à de tels "arguments" contre journald. C'est que finalement il ne doit pas y avoir trop de raisons d'être contre…

Et si j'ai pas d'outils pour faire la traduction ?

Et si tu n'as pas d'outils pour afficher 0x41 en "A" sur ton écran?

C'est totalement absurde de choisir le format binaire pour des logs, sa doit être lut par des humains !

0x41 n'est pas lisible par des humains, tu as déjà des outils de traduction. un de plsu ou de moins…
Non, ce n'est pas absurde, à moins que tu trouves sympa de lire des 0 et des 1 (et encore, c'est déjà une traduction d'un été électrique)

Ce qui est absurde est plutôt de vouloir se cantonner à une format "binaire" unique pour tout même ce qui n'est pas adapté. Bientôt des flux vidéos et audio en XML?

Et la langue ce n'est pas le problème, un grep marchera quand même, par contre un grep sur le format binaire c'est possible mais tout de suite moins efficace.

Ah oui? Ta vie doit être chiante si tu t'amuse à implémenter un parsing grep avec les centaines de langues pour dire "mercredi"… Non, les gens ne sont pas avec une seule langue sur terre, y compris sur des serveurs. Je te défie de me faire une ligne de grep qui parsera tous les logs de la terre pour la même erreur (rien qu'avec une date, mais si je te parle de faire un grep sur un message d'erreur précis, bon courage pour trouver toutes les traductions sur toutes les machines).

Ton grep, il marche pour toi, mais n'est pas maintenable à plusieurs.

Ca a l'air de bien marcher pour pas mal de monde… Donc c'est bon pour systemd, qui remplit sa mission malgré les 1% de râleurs.

Un WM qui gère une zone de notification, est-ce vraiment KISS? ;-)

Et ta machine n'a pas d'administrateur ? Personne n'en fait la maintenance ?

L'avantage des distros Linux, si on reste dans les repos, c'est que l'admin, c'est le mainteneur de la distro qui fait ça gratos pour toi. L'utilisateur n'a rien à faire.

Oui, bon, la, un script bash start/stop, même si c'est pas sexy, ne devrait pas te faire peur alors, l'argument ne tient plus.

Linux c'est le noyau. Il fait son taff de noyau.

Il fait plein d'autres choses. Débat sur ce que fait un noyau.
Mais c'est Linux, donc on accepte le "bloat" qu'on refuse à systemd.

Deux poids, deux mesures…

Mais c'est un effet assez classique, d'où l'importance d'une première version utilisable

Heureusement qu'un certain Linux T. n'a pas attendu que son OS soit sans aucun bug avant de le sortir…

On m'a fait constater que la plupart des problèmes avaient été corrigés depuis les dernières fois où j'avais été contraint d'utilisé java.

C'est une critique sur les gens : regarder une fois, et garder sa critique en étant persuadé que rien n'a changé en 10 ans. Si on fait la même chose pour Linux? Ca ferait peur…

Il se trouve que je suis aussi un développeur et j'ai j'ai codé un petit jouet que j'ai envie de démarrer sur ma machine.

Et dire que sous Windows il suffit de mettre un bête lien dans le répertoire "démarrage" au simple niveau de l'utilisateur… Bien plus simple qu'init.d ou systemd! Pourquoi faire simple quand on peut faire compliqué :).

Car l'interface la plus universelle est le texte.

Tu as bien de la chance de comprendre les centaines de langues dans le monde. Pour info, les logs ne sont pas toujours en anglais (et pourquoi l’anglais devrait avoir la primauté d'ailleurs?)

Sinon c'est un surplus non nécessaire, surtout pour les logs qui sont avant-tout lus par des humains, et non des programme.

Et d'après toi, le texte est codé comment? Je vais t'aider : un programme transforme le texte qui n'est qu'un code binaire en une suite de pixels que tu peux lire.
Si il doit faire une petite phase de traduction en plus, ça ne va pas le tuer ton programme d'affichage.

Une faille sur la version n, c’est pas grave, on la corrige sur la n + 3, et on continue. Sauf que pour des grosses boites, il faut être sûr que le changement de version n’induira pas d’effet de bord.

Si une grosse boite a besoin de la version n, elle n'aura aucun problème à payer pour le patch. Ceux qui ne corrigent pas sont les mainteneurs principaux, mais la beauté du libre est qu'une grosse boite peut patcher aussi, ou un autre prestataire. Tu es libre.

PS : je trouve certes que Mozilla joue un jeu dangereux avec ce non support de vieilles version car il y a plein d'admins prosélytistes qui se retrouvent dans la merde (et eux ne peuvent pas décider de lacher le fric pour payer le patch), mais c'est un choix de la part de Mozilla. Les "grosses boites" comme tu dis ont vachement de mal à sortir leur portefeuille, c'est aussi leur choix, je comprend que Mozilla laisse tomber. Surtout que le monde évolue, et comprend plein de boites qui ont compris qu'il vaut mieux coder des sites standards et faire des projet en "release often" et du coup ça passe vachement mieux maintenant.

Tiens, des arguments qui tiennent la route et qui ne parlent pas de résistance au changement ou je ne sais quelle autre connerie

"Ca n'apporte rien", c'est pas une connerie non plus de personnes ne voulant pas s’intéresser à la chose mais ayant leur avis définitif?
Quand je parle de résistance au changement, c'est quand le "oh c'est nul systemd" vient de personnes n'acceptant pas que systemd répond à un problème, ou qui trouvent que des scripts bash c'est plutôt bien (la, c'est à mourir de rire, c'est vraiment une résistance au changement, les scripts bash sont tout sauf facilement maintenables) --> C'est "c'est pas bien" par défaut, c'est ça la résistance au changement.

Encore une fois, si systemd est pris par les distros aussi rapidement, il faut peut-être se poser des questions plutôt que de dire que ça n'apporte rien.

Je vais prendre la grosse tête à force d'être cité.

Bon, pour une des questions, j'aurai bien une réponse :

Si il y a autant de gens qui savent ce qui ne va pas dans systemd, pourquoi ne travaillent-ils pas ensemble pour faire quelque chose qui va?

On te répondra certainement que c'est parce que le système actuel est parfait, mais bon, ma réaction serait d'être surpris que si c'est parfait, il n'y a pas de raison de faire systemd par les autres, pas logique. Moi j'ai plutôt l'impression que :
- Dès que ça a du succès (Windows, Ubuntu, systemd…), on est jaloux
- Résistance au changement
- Troller en sortant n'importe quoi comme idée de critique est plus rigolo que de se mettre autour d'un table, mettre le plus de monde possible d'accord (partie la plus dure), et coder. Lennart a réussi à mettre pas mal de monde d'accord et a codé. Lui. (2 sur 3, certes, mais 2 de mieux que les autres. Je ne sais pas si il y a eu une table avant)

L'avantage d'un fichier texte, c'est sa robustesse : si après un problème il est mal fermé, on peut tout de même en lire le début, tandis qu'un fichier binaire risque d'être corrompu et inutilisable.

ah, c'est nouveau…
Binaire != mettre des champs "temporaires" au début.
Un fichier binaire est pareillement robuste qu'un fichier texte si il a le même principe (que des "append")
Ce sont des préjugés sur les fichiers binaires qui sont sans fondements.

Pourquoi pas. Mais c'est pas lisible plus que ça par un être humain, et ça prend de la place (en plus de sa taille variable). En plus, tu sais si c'est en octal, décimal ou hexa?
Ca serait, de mon point de vue, les inconvénients du binaire mélangés aux inconvénient du texte, sans aucun avantage. Bref, je ne vois pas l’intérêt. Encore une fois, le binaire, il lui suffit d'un traducteur simple, tout comme il est simple de dire que 0x41 c'est "A" : c'est de l'affichage.

Je pense que toutes les distributions devraient continuer à maintenir les deux systèmes.

C'est sympa de te dévouer à la tâche, ta candidature est acceptée sur les centaines de distros à maintenir.

et techniques (problème avec l'utilisation de partition chiffrés, vpn, dépendances, linux only, services en doublon )

Ces problèmes ne sont-ils pas simplement un manque de fonctionnalités dû à la jeunesse de la chose? Ca peut évoluer, comme tout nouveau logiciel qui fait bouger les choses. Si ont attend de répondre à tous les besoins avant de commencer à déployer, on ne déploie plus jamais rien et on meurt face à la compétition.
Pour le "linux only", udev est linux only et ne pose pas de problème philosophique aux critiqueurs, donc ce n'est pas un argument.