SSH est un protocole assez simple si tu le regarde. Le serveur doit certes supporter plusieurs canals de différent types, comme des flux, des pty, des forward dynamique de ports et du transfert de fichier, mais au final, le couteau suisse, c'est le client OpenSSH. Par exemple le proxy SOCKS est entièrement fait coté client.
De toute façon, il y a déjà plusieurs implémentations d'SSH alternatives: dropbear et celle de twisted, donc la question se pose pas.
Certains scripts debian utilise par exemple start-stop-daemon et c'est pas spécifié dans la lsb
Si il n'y avais que ça … Debian en à strictement rien à foutre de la LSB. Normalement, si un script d'init LSB se rend compte que le programme qu'il est censé lancer n'est pas installé, il est censé retourner un code d'erreur bien particulier: 5. Les politiques Debian force les scripts d'init à retourner 0 dans ce cas, pour pas que ça balance des erreurs partout lorsque un paquet est enlevé mais pas purgé.
Et vu que c'est un problème politique, il suffit pas de patcher.
Enfin ça, c'est si ton affirmation "il manque quoi" n'est pas juste une formule rhétorique, car la, tu sembles plus dire que y a des problèmes, mais c'est pas urgent alors personne devrait bosser dessus.
Oui les scripts d'init ont des problèmes, puisqu'ils ne sont pas parfait. Encore que leur problème principal est politique: personne ne veut les maintenir, alors que c'est pas bien compliqué. On pourrai très bien leur enlever de la duplication, ou les rendre plus LSB-compliant, mais pour un résultat qui ne casse pas des briques et qui n'apportera pas beaucoup de fonctionnalités.
Enfin bref, c'est qu'un système d'init quoi. Ça sert qu'a démarrer des services. Même si tu nous sort le meilleur système d'init au monde, ça ne fera juste que … démarrer des services.
Parce qu'il y a tous les jours des nouveaux logiciels et donc des nouveaux scripts init à écrire.
J'en doute pas. Par contre, je vois pas comment je peux aider à écrire des nouveaux scripts d'init pour des paquets Debian qui n'existent pas encore.
Et les scripts actuelles ne marchent pas si bien que ça.
J'ai plus de problèmes avec les services en eux-mêmes qu'avec leur script d'init. Mais corriger des scripts d'init reste plus facile que de corriger des services ;)
il y a certains scripts qui prennent en compte SELinux et d'autres pas (pour les mêmes actions), c'est un bug de la part de qui ?
Supporter SELinux n'est pas qu'une affaire de script d'init. En fait je suis même pas sûr qu'il faille normalement gérer SELinux dans les scripts d'init.
Par exemple, sous Debian, tu te retrouve avec du code dupliqué dans plusieurs scritps
Si tu peux pas corriger ça sans casser la LSB, je vois pas trop comment tu peux faire; Un script LSB est quand même censé être quasiment auto-suffisant et de ne rien dépendre d'autre que des helpers dans /lib/lsb/.
Ce que tu demande n'est pas de maintenir les script SysvInit, mais d'écrire un autre système d'init. Et ça je trouve ça inutile, il y a d'autres problèmes plus urgents à régler avant, autre que de nettoyer du code qui sert que pendant la première minute de démarrage.
Il me semble que le temps passé à en discuter ici servirait bien mieux votre cause si, par exemple, vous vous proposiez de maintenir SysVinit sous Debian
Moi je veux bien contribuer, c'est pas comme si je récrivait jamais les scripts d'init de mes systèmes et que des gens me payait pas pour en faire.
Mais plus sérieusement: il leur manque quoi à ces scripts ? Ils sont la pour des cas d'utilisations généraux, et ils marchent. Mis à part les nettoyer un peu, il y a pas grand chose à faire.
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.
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.
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.
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.
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.
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 …
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.
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.
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.
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.
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.
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é.
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.
Et un plantage noyau ça a tendance à se remarquer un peu plus qu'un plantage de process en userspace.
Référence nécéssaire.
Si tu a un sombre code qui fait un OOPS gentil alors que tu sais même pas à quoi sert le driver, si tu ne regarde pas le dmesg, tu risque pas de le voir, et ton système semblera fonctionner normalement, sauf peut-être à l'arrêt du système, quand des gens chercheront à verrouiller le lock que le code crashé avait obtenu … Par contre je nie pas la présence de plantages méchants récursifs que même la détection de plantage récursif ne voit pas.
Enfin bref, les plantages en userspace et en kernel space sont globalement aussi visible les un que les autres.
Indépendamment de si tu veux faire intégrer ton code ou pas, séparer ton code en plusieurs changements testables indépendamment est une bonne pratique logicielle, ce n'est pas pour te faire chier que les dev noyau te demandent de découper ton code. C'est notamment pour qu'il puisse reverter tes changements séparément s'ils pètent tout.
Et même si tu en a rien à foutre de contribuer upstream ou de la qualité de ton code, séparer en plusieurs commits te facilitera grandement la mise à jour de tes patch avec les nouvelles releases d'upstream.
La, tu passes une étape, et tu commence à dire "systemd fait pas ça", avec ça étant décrit dans la dépêche.
Prend moi pour un idiot qui sait pas lire, en plus. Déjà, Nulle part j'ai indiqué que l'autre service ne doit pas avoir accès à Internet. En fait, je veux que l'autre service ai accès à Internet.
Même s'il ne doit pas avoir accès à Internet, si j'ai besoin de lui dire explicitement de rejoindre un certain namespace, ça pète l'abstraction. Moi je veux que "le service truc n'ai pas accès à Internet" (mais qu'il puisse accéder au service machin, qui, il se trouve, utilise des sockets TCP bindées sur localhost en sous-main, les abstractions, il n'y a pas que systemd qui en fait). Si je doit prendre en compte l'implémentation de systemd et du moyen de communication entre les deux services, j'ai pas fini. Dans ce cas, l'abstraction est nulle à chier, ce que je me tue à dire.
Il y a plein de manière d'empêcher un service d'accéder à Internet. Il y en a aucune de parfaite, chacune ayant ses défaut. Systemd en à choisi une, mais ne fait absolument aucune abstraction de ces défauts.
Enfin bref, je me répète, mais c'est une "Leaky abstraction" ( http://www.joelonsoftware.com/articles/LeakyAbstractions.html ). L'abstraction c'est joli, mais quand c'est mal fait ça fait plus de mal que de bien. Ou bien on vire l'abstraction, ou bien on l'améliore. Et merci pour les hommes de pailles ou on me fait dire que je réclame les deux à la fois.
[^] # Re: L'avis d'un mainteneur.
Posté par Batchyx . En réponse au journal Chronique des dinosaures rétrogrades. Évalué à 2.
SSH est un protocole assez simple si tu le regarde. Le serveur doit certes supporter plusieurs canals de différent types, comme des flux, des pty, des forward dynamique de ports et du transfert de fichier, mais au final, le couteau suisse, c'est le client OpenSSH. Par exemple le proxy SOCKS est entièrement fait coté client.
De toute façon, il y a déjà plusieurs implémentations d'SSH alternatives: dropbear et celle de twisted, donc la question se pose pas.
[^] # Re: Pourquoi continuer à discuter sur ce sujet éculé ?
Posté par Batchyx . En réponse au journal Dépèche de ouf en préparation !!!!. Évalué à 4.
Si il n'y avais que ça … Debian en à strictement rien à foutre de la LSB. Normalement, si un script d'init LSB se rend compte que le programme qu'il est censé lancer n'est pas installé, il est censé retourner un code d'erreur bien particulier: 5. Les politiques Debian force les scripts d'init à retourner 0 dans ce cas, pour pas que ça balance des erreurs partout lorsque un paquet est enlevé mais pas purgé.
Et vu que c'est un problème politique, il suffit pas de patcher.
Oui les scripts d'init ont des problèmes, puisqu'ils ne sont pas parfait. Encore que leur problème principal est politique: personne ne veut les maintenir, alors que c'est pas bien compliqué. On pourrai très bien leur enlever de la duplication, ou les rendre plus LSB-compliant, mais pour un résultat qui ne casse pas des briques et qui n'apportera pas beaucoup de fonctionnalités.
Enfin bref, c'est qu'un système d'init quoi. Ça sert qu'a démarrer des services. Même si tu nous sort le meilleur système d'init au monde, ça ne fera juste que … démarrer des services.
[^] # Re: Pourquoi continuer à discuter sur ce sujet éculé ?
Posté par Batchyx . En réponse au journal Dépèche de ouf en préparation !!!!. Évalué à 1.
J'en doute pas. Par contre, je vois pas comment je peux aider à écrire des nouveaux scripts d'init pour des paquets Debian qui n'existent pas encore.
J'ai plus de problèmes avec les services en eux-mêmes qu'avec leur script d'init. Mais corriger des scripts d'init reste plus facile que de corriger des services ;)
Supporter SELinux n'est pas qu'une affaire de script d'init. En fait je suis même pas sûr qu'il faille normalement gérer SELinux dans les scripts d'init.
Si tu peux pas corriger ça sans casser la LSB, je vois pas trop comment tu peux faire; Un script LSB est quand même censé être quasiment auto-suffisant et de ne rien dépendre d'autre que des helpers dans /lib/lsb/.
Ce que tu demande n'est pas de maintenir les script SysvInit, mais d'écrire un autre système d'init. Et ça je trouve ça inutile, il y a d'autres problèmes plus urgents à régler avant, autre que de nettoyer du code qui sert que pendant la première minute de démarrage.
[^] # Re: Pourquoi continuer à discuter sur ce sujet éculé ?
Posté par Batchyx . En réponse au journal Dépèche de ouf en préparation !!!!. Évalué à -4.
Moi je veux bien contribuer, c'est pas comme si je récrivait jamais les scripts d'init de mes systèmes et que des gens me payait pas pour en faire.
Mais plus sérieusement: il leur manque quoi à ces scripts ? Ils sont la pour des cas d'utilisations généraux, et ils marchent. Mis à part les nettoyer un peu, il y a pas grand chose à faire.
[^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
Posté par Batchyx . En réponse au journal Systemd vs Linux, quand l'intransigeance d'un développeur tourne au ridicule.... Évalué à 2.
L'emplacement de la partition n'a pas changé, hein …
Ç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 Batchyx . En réponse au journal Systemd vs Linux, quand l'intransigeance d'un développeur tourne au ridicule.... Évalué à 3.
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().
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.
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: Réponse de Lennart
Posté par Batchyx . En réponse au journal Systemd vs Linux, quand l'intransigeance d'un développeur tourne au ridicule.... Évalué à 3.
Et leur dire de mettre "debug systemd.debug", c'est trop compliqué ?
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: Ca traduit bien un état d'esprit de la part des développeurs de systemd
Posté par Batchyx . En réponse au journal Systemd vs Linux, quand l'intransigeance d'un développeur tourne au ridicule.... É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 Batchyx . En réponse au journal Systemd vs Linux, quand l'intransigeance d'un développeur tourne au ridicule.... Évalué à 2.
En C++, c'est à toi de choisir si tu veux des énums stricts ou des énums du C.
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 Batchyx . En réponse au journal Systemd vs Linux, quand l'intransigeance d'un développeur tourne au ridicule.... É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: Réponse de Lennart
Posté par Batchyx . En réponse au journal Systemd vs Linux, quand l'intransigeance d'un développeur tourne au ridicule.... É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_hackC'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: Ca traduit bien un état d'esprit de la part des développeurs de systemd
Posté par Batchyx . En réponse au journal Systemd vs Linux, quand l'intransigeance d'un développeur tourne au ridicule.... É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 Batchyx . En réponse au journal Systemd vs Linux, quand l'intransigeance d'un développeur tourne au ridicule.... É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: Réponse de Lennart
Posté par Batchyx . En réponse au journal Systemd vs Linux, quand l'intransigeance d'un développeur tourne au ridicule.... É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: Ca traduit bien un état d'esprit de la part des développeurs de systemd
Posté par Batchyx . En réponse au journal Systemd vs Linux, quand l'intransigeance d'un développeur tourne au ridicule.... É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 Batchyx . En réponse au journal Systemd vs Linux, quand l'intransigeance d'un développeur tourne au ridicule.... É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 Batchyx . En réponse au journal Systemd vs Linux, quand l'intransigeance d'un développeur tourne au ridicule.... É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
getaddrinfosurcoucou.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 Batchyx . En réponse au journal Systemd vs Linux, quand l'intransigeance d'un développeur tourne au ridicule.... É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 :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: Kay Sievers qu'est si vert à pourtant raison
Posté par Batchyx . En réponse au journal Systemd vs Linux, quand l'intransigeance d'un développeur tourne au ridicule.... É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: Ca traduit bien un état d'esprit de la part des développeurs de systemd
Posté par Batchyx . En réponse au journal Systemd vs Linux, quand l'intransigeance d'un développeur tourne au ridicule.... Évalué à 1.
Toi t'a jamais contribué à un projet Red Hat …
… moi non plus, mais c'est pas faute d'avoir essayé.
[^] # Re: Sécurité: Contournement de kASLR par Brad Spengler (grsecurity)
Posté par Batchyx . En réponse à la dépêche Sortie de Linux 3.14. Évalué à 1.
Référence nécéssaire.
Si tu a un sombre code qui fait un OOPS gentil alors que tu sais même pas à quoi sert le driver, si tu ne regarde pas le
dmesg, tu risque pas de le voir, et ton système semblera fonctionner normalement, sauf peut-être à l'arrêt du système, quand des gens chercheront à verrouiller le lock que le code crashé avait obtenu … Par contre je nie pas la présence de plantages méchants récursifs que même la détection de plantage récursif ne voit pas.Enfin bref, les plantages en userspace et en kernel space sont globalement aussi visible les un que les autres.
[^] # Re: Sécurité: Contournement de kASLR par Brad Spengler (grsecurity)
Posté par Batchyx . En réponse à la dépêche Sortie de Linux 3.14. Évalué à 10.
Indépendamment de si tu veux faire intégrer ton code ou pas, séparer ton code en plusieurs changements testables indépendamment est une bonne pratique logicielle, ce n'est pas pour te faire chier que les dev noyau te demandent de découper ton code. C'est notamment pour qu'il puisse reverter tes changements séparément s'ils pètent tout.
Et même si tu en a rien à foutre de contribuer upstream ou de la qualité de ton code, séparer en plusieurs commits te facilitera grandement la mise à jour de tes patch avec les nouvelles releases d'upstream.
[^] # Re: Ah bon?
Posté par Batchyx . En réponse au journal Le mouvement des néo-hippies. Évalué à 5.
Non, on est mardi. Mardi 1ᵉʳ Avril.
# C'est vieux et abandonné, mais ...
Posté par Batchyx . En réponse au message Cherche OS libre dont l'interface ressemble à celle de Windows.. Évalué à 1.
XPDE: http://xpde.holobit.net/
C'est vieux, abandonné, pas fini et sans doute plus packagé, mais ça fait ce que tu veux.
[^] # Re: De plus en plus complexe, le système d'init...
Posté par Batchyx . En réponse à la dépêche Spéciale Lennart Poettering : nouvelles versions de systemd et PulseAudio. Évalué à -3.
Prend moi pour un idiot qui sait pas lire, en plus. Déjà, Nulle part j'ai indiqué que l'autre service ne doit pas avoir accès à Internet. En fait, je veux que l'autre service ai accès à Internet.
Même s'il ne doit pas avoir accès à Internet, si j'ai besoin de lui dire explicitement de rejoindre un certain namespace, ça pète l'abstraction. Moi je veux que "le service truc n'ai pas accès à Internet" (mais qu'il puisse accéder au service machin, qui, il se trouve, utilise des sockets TCP bindées sur localhost en sous-main, les abstractions, il n'y a pas que systemd qui en fait). Si je doit prendre en compte l'implémentation de systemd et du moyen de communication entre les deux services, j'ai pas fini. Dans ce cas, l'abstraction est nulle à chier, ce que je me tue à dire.
Il y a plein de manière d'empêcher un service d'accéder à Internet. Il y en a aucune de parfaite, chacune ayant ses défaut. Systemd en à choisi une, mais ne fait absolument aucune abstraction de ces défauts.
Enfin bref, je me répète, mais c'est une "Leaky abstraction" ( http://www.joelonsoftware.com/articles/LeakyAbstractions.html ). L'abstraction c'est joli, mais quand c'est mal fait ça fait plus de mal que de bien. Ou bien on vire l'abstraction, ou bien on l'améliore. Et merci pour les hommes de pailles ou on me fait dire que je réclame les deux à la fois.