ookaze a écrit 271 commentaires

  • [^] # Re: le principe "KISS" est-il devenu obsolète?

    Posté par  . En réponse au lien Grandeur et décadence de Linux (et j'ajoute: sic transit Linux regnum). Évalué à 0.

    Est-ce que le principe de (relative) simplicité qui prévalait auparavant est devenu obsolète? Ou alors c'est ma réticence au "changement" qui m'aveugle?

    Le principe de simplicité qui prévalait auparavant non seulement prévaut toujours mais s'accompagne d'autres avantages, je crains donc que ce ne soit la seconde proposition qui soit la bonne.

    Bon,ceci étant dit, s'il faut en passer par là pour simplifier la tâche des développeurs du noyau, pour avoir un système plus universel, prenant en charge une plus grande diversité d'architectures, un meilleur support matériel, un système plus optimisé et économe en ressources, c'est un sacrifice auquel je consentirais de bonne grâce.
    Mais est-ce bien le but poursuivi?

    C'est une partie du but poursuivi, bien qu'en réalité il y en a d'autres bien plus importants et essentiels. Par exemple :
    - systemd n'a pas servi à simplifier la tâche des développeurs du noyau, si ce n'est pour trouver des dysfonctionnements dans celui-ci. Ce n'était pas possible auparavant, car on attribuait le problème aux différents systèmes utilisés, systemd a permis de révéler ces problèmes dans le noyau qui s'en trouve meilleur aujourd'hui ;
    - les systèmes peuvent désormais démarrer dans le même état à coup sûr (hors problème matériel) s'ils sont bien configurés, contrairement à auparavant où un système, sans rien changer, pouvait voir sa configuration de carte réseau changer au redémarrage, ou encore sa disposition des disques si le BIOS avait subi la moindre modification, ou simplement en insérant une clé USB. Pour l'utilisateur lambda, c'est beaucoup mieux. La plupart des utilisateurs/administrateurs avaient des problèmes dont ils n'ont jamais cherché ou trouvé la cause, parce que beaucoup trop compliqué à investiguer. Les administrateurs des distributions ont forcément eu le cas avec la quantité d'utilisateurs qui remontent des problèmes. Même moi qui crée mes OS entièrement, je savais que même avec tous mes scripts personnalisés, les serveurs avaient toujours une chance de ne pas redémarrer correctement avant systemd ;
    - les problèmes pouvaient survenir rien que par le fait que les anciens systèmes d'init ne géraient pas les événements, or le noyau Linux s'était adapté depuis bien longtemps avec udev et encore avant avec son prédécesseur (dont j'ai oublié le nom), il envoie des événements que les systèmes d'init ignoraient joyeusement, et c'était une misère pour gérer le démarrage et des choses simples comme connecter une clé USB et la voir prise en compte. Un exemple du KISS respecté, il est plus simple de simplement brancher sa clé USB que d'encore aller exécuter des commandes ensuite pour y avoir accès ;
    - les systèmes sont beaucoup plus sécurisés qu'auparavant. Il est maintenant possible de vraiment cloisonner simplement ses démons, son poste de travail pour l'utilisateur, et même en multiseat ou en multi-sessions. Une de mes hantises sur les serveurs était qu'il était très facile de placer des malwares dans les scripts d'init sans que cela ne soit détecté (hors utilisation d'IDS) ;
    - les fonctionnalités de qualité de vie, d'optimisation, de sécurité, de performance, etc. du noyau Linux sont enfin utilisées et améliorées puisque vraiment utilisées, grâce à systemd. Les détracteurs se contentent de dire "mais si on peut faire" mais ne font jamais en réalité, d'où le fait que seul systemd a permis de remonter des dysfonctionnements sur ces options du noyau ;
    - rien que monter un VPN (avec wireguard récemment) est devenu d'une simplicité sans comparaison avec ce qui se faisait ;

    Lorsqu'on a eu les mains dans le cambouis comme moi (je fais mes propres OS, le même travail que font les distributions) depuis plus de 20 ans, il est évident du pourquoi de l'adoption de systemd par quasiment toutes les distributions, qui souvent utilisaient des binaires pour tenter de faire démarrer de manière cohérente leurs OS. Lorsque systemd est arrivé il y a plus de 10 ans, je l'ai accueilli sans hésiter, j'ai sauté sur les toutes premières versions de développement. Il faut dire que je maintenais tout seul simpleinit-msb jusque-là (j'avais abandonné l'abomination qu'est sysvinit en quelques mois d'utilisation), en espérant trouver mieux. Je n'y croyais pas trop au départ mais j'espérais fortement que systemd tienne ses promesses, et non seulement il les a tenues mais il a pu s'insérer comme une référence.

  • [^] # Re: ... ma distribution est en fait mon OS

    Posté par  . En réponse au sondage La dernière fois que j’ai compilé un noyau Linux, c’était parce que…. Évalué à 1.

    C'est uniquement que ça me demande moins de travail inutile.
    J'ai recompilé chaque version sortie pendant des années, mais cela ne servait à rien. La plupart du temps, ces compilations étaient faites pour rien puisque je ne reboote pas derrière. Les serveurs principaux peuvent tourner des mois sans rebooter. Seuls les apports en sécurité me font rebooter essentiellement les frontaux.

  • # Bientôt 20 ans que LFS m'a lancé

    Posté par  . En réponse à la dépêche Linux From Scratch 9.0 : pourquoi pas vous ?. Évalué à 10.

    Cela fait plus de 19 ans que je connais LFS, et c'est à partir de là que j'ai créé mon OS, à la base un LFS pur jus, qui a rapidement évolué en mon OS personnel.
    Suite à une perte énorme d'années d'archives sous Windows XP, qui ne fonctionnait jamais surtout quand j'en avais besoin (pour regarder des vidéos par exemple, j'avais opté pou un LiveCD Linux spécialisé vidéo qui utilisait MPlayer, j'ai oublié son nom, lisait tous les formats et fonctionnait tout le temps), j'avais décidé de tout passer sous Linux. J'avais déjà une Red Hat que j'avais achetée, mais je cassais tout le temps le système de paquets en installant des logiciels non disponibles en les compilant moi-même, parfois en créant des paquets. Donc j'ai voulu tenter Debian, mais rien que l'installateur était déjà trop rigide pour moi, avec des problèmes rédhibitoires comme le système d'init par exemple. J'ai évolué vers Gentoo, que j'ai installé un moment, mais là je cassais encore tout, et la dépendance à Python 2 n'a pas aidé à l'époque.
    Ceux qui se rappellent de cette époque se souviendront qu'il était difficile d'utiliser les fonctions avancées des cartes graphiques comme celles de NVidia ou le concurrent (dont j'ai oublié le nom, maintenant AMD) sur une distribution classique (même Gentoo), et étant contributeur MythTV à l'époque, j'en avais besoin encore plus pour les cartes d'acquisition TV (c'est toujours le cas aujourd'hui).
    Finalement, je suis tombé sur LFS suite à discussion avec d'autres connaisseurs, et je ne suis plus jamais revenu en arrière.
    Je n'ai plus jamais eu le moindre souci, j'ai pu quitter cette horreur de sysvinit très tôt, passant à simpleinit-msb et le maintenant moi-même durant des années, cherchant un successeur, et j'ai basculé sur systemd dès la toute première version sortie, après avoir testé l'init d'Ubuntu qui s'est révélé une catastrophe ingérable.
    Cela fait plus de 18 ans maintenant que j'ai mon OS. Je suis toujours LFS pour me mettre à jour si nécessaire, parfois je suis en avance par rapport à eux. Donc merci LFS.

    La plupart des gens ne comprennent pas ce qu'est LFS, mais avec une analogie c'est plus simple à comprendre : une distribution c'est le poisson fournit par le pêcheur, LFS c'est le pêcheur qui vous apprend à pêcher.

    J'utilise des outils pour gérer ma distribution, certains datent de l'époque comme nALFS qui n'existe plus et que j'ai fait évoluer, il y a sans doute des centaines d'heures incluses dans mes fichiers XML qui décrivent comment construire tous mes LiveCD d'installation pour mes 6 types de machines. La somme de connaissances acquises est vertigineuse durant toutes ces années où j'ai pu être totalement autonome.
    Encore merci LFS (qui doit avoir plus de 20 ans aujourd'hui).

  • # ... ma distribution est en fait mon OS

    Posté par  . En réponse au sondage La dernière fois que j’ai compilé un noyau Linux, c’était parce que…. Évalué à 1.

    Cela fait plus de 18 ans que je compile mon propre OS, à la base basé sur LFS, puis modifié à ma sauce en fonction des machines sur lesquelles je le place (6 types différents aujourd'hui).
    La dernière fois que j'ai compilé des noyaux (un par machine) correspond à la dernière version de la 5.1.
    La règle que j'applique aujourd'hui est que je place la dernière version EOL du noyau qui précède la stable actuelle. Cela m'évite de compiler plusieurs versions mineures.
    Surtout que je ne reboote pas les machines de toutes façons, excepté les plus sensibles comme les frontaux de sécurité, ou s'il y a un problème de sécurité nécessitant un reboot.
    C'est d'ailleurs le seul cas où je compile tout de suite la dernière version stable : quand il y a un problème de sécurité. J'ai dû compiler une 5.1 ou une 5.0 en catastrophe suite à la dernière faille liée aux pipelines prédictifs des processeurs Intel.
    Mais bon, je suis une exception.

  • # Un marronnier ?

    Posté par  . En réponse au message Linux dépassé ?. Évalué à 1.

    Cela fait plus de 10 ans que je n’avais pas entendu cette question.
    À l’époque, PowerShell venait de sortir, et mes détracteurs sous Windows venaient me dire que c’était super PowerShell, que c’était 100 fois mieux que le shell sous Linux.
    Je ne voyais pas en quoi ce truc compliqué était plus efficace pour le boulot d’un administrateur système. Mais bon, ils m’annonçaient déjà la mort de Linux à l’époque aussi, et le fait qu’il était dépassé. Finalement, plus de 10 ans après, mon intuition était la bonne et c’est plutôt le PowerShell qui est complètement inadapté et inutile face à un bash, à tel point que c’est MS qui doit émuler les API système Linux sur son OS serveur pour utiliser bash plutôt que PS.
    Pire encore, le PowerShell n’a même pas pris le pas sur des Python ou même le Javascript (via Node.js ou autre), qui a complètement détruit le moindre intérêt que pouvait avoir le PowerShell (prototypage, outil rapide en langage interprété).
    Est-ce que cette question est un marronnier annuel sorti par les jeunes qui débutent et ne comprennent rien aux enjeux de ces différents outils informatiques ?
    Déjà à l’époque je pensais qu’il fallait avoir zéro expérience et peu de compréhension de l’informatique pour dire des bêtises pareilles (c’était le cas de tous les power user Windows que je connaissais, ils ne comprenaient rien), alors imaginez aujourd’hui.

    En général mon intuition ne me trompe pas en informatique donc je lui fais entièrement confiance, comme quand j’ai découvert Linux en 1991 (en pensant que ça allait tout bouffer) ou systemd à ses débuts (en pensant que ça allait tout bouffer, alors que je cherchais depuis des mois un remplaçant à simpleinit-msb que je maintenais tout seul). C’est pourquoi à l’époque j’ai fini par dire « on verra qui avait raison dans quelques années ». Et on a vu. Mais apparemment, il y a des gens aujourd’hui qui croient que tout le monde découvre le produit en même temps qu’eux. Je ne comprends pas cette façon de penser, les gens ont perdu la notion du temps qui passe ? Ils ne comprennent plus qu’un produit sorti il y a plus de 10 ans ne se comporte pas comme s’il venait de sortir et que sa pertinence a eu le temps d'être validée ou non ?

  • [^] # Re: Parti pour du trollage?

    Posté par  . En réponse au journal Sortie de Devuan ASCII 2.0. Évalué à 6.

    Passer à systemd en revanche c'est une changement assez radical qui demande énormément plus de sacrifices. Et je peux comprendre que tout le monde n'aie pas envie de réapprendre le métier d'adminsys juste parce qu'il parait que c'est mieux fait avec systemd.

    Personnellement je n'ai rien réappris, tout est venu parfaitement naturellement et j'ai juste élargi mon champ de connaissance. J'utilise même désormais des outils que je n'utilisais pas auparavant car trop difficiles à implémenter et à maintenir de manière correcte, comme les cloisonnements et limitations diverses des services.

    Devuan pourrait intéresser de grosses structures utilisant massivement Debian et où une formation de tous les adminsys à systemd risquerait d'être longue et coûteuse.

    Pourquoi est-ce que j'ai toujours l'impression d'être un génie quand je lis ce genre de commentaires sur systemd ? Ou que tous les sysadmins sont nuls et stupides ?
    On a l'impression que systemd c'est OpenOffice et sysvinit c'est MS Word, et que les sysadmins ont appris à se servir de MS Word et non pas d'un traitement de texte. Personnellement j'ai appris à me servir du traitement de texte, et donc la formation n'a pas été longue ou coûteuse et entièrement autodidacte.
    Il faut dire aussi que je maîtrisais mieux le système d'initialisation et les init que toutes ces personnes qui se plaignent de systemd, ce qui est aussi le cas de ceux qui ont conçu systemd d'ailleurs. Et pourtant je n'ai pas l'impression que nous soyions des génies.

  • [^] # Re: Stallman refuse des patchs dans emacs?

    Posté par  . En réponse au journal De l'autarcie du projet GNU, ou comment Emacs ne veut pas devenir EmacOs. Évalué à 8.

    Ce commentaire est au mieux bourré d’illusion de savoir, au pire c’est de la propagande pure et simple. Avec une dérive bien marquée : ça commence par le projet GNU et la FSF vont échouer (en tout sauf dans leurs objectifs apparemment) et ça finit par dire qu’ils ont tous deux échoués… Il a juste fallu le temps de lire le commentaire pour que cela arrive.

    La propagande est flagrante, puisque tout doit être changé, mais on ne sait jamais pourquoi.
    Ah si, les techniques classiques en étant très vague, en déplaçant le débat vers un sujet sans intérêt ou superficiel, comme ça l’interlocuteur met ce qu’il veut là-dedans, du moment que c’est négatif, et sera d’accord puisque cela vient de lui.
    Des trucs du style :
    – « […] plus tant de monde que cela » : c’est qui ce « monde », de qui parle-t-on ?
    – « perdent régulièrement en crédibilité » : à propos de quoi, et auprès de qui ?
    – « aujourd’hui c’est totalement dépassé » : à quel sujet et pour qui ?
    - « Hiérarchiser ses combats et ses moyens est la meilleure façon d’aboutir à ses objectifs » : ah bon ?
    - « la FSF patine dans la semoule depuis 30 ans avec GNU » : qu’est-ce que cela signifie ?
    - « Sans objectifs clairs, sans jalons, le projet GNU ne pourra jamais atteindre sa cible » : belle tautologie. Et s’il a des objectifs clairs comme c’est le cas, le projet GNU pourra donc atteindre sa cible ? Est-ce même une cible atteignable ou juste un seuil à dépasser ? Je demande mais le projet GNU semble avoir déjà atteint sa cible initiale ;
    - « le projet GNU n’a aucune cohérence » : ah ouais quand même !

    J’ai quand même dû aller vérifier que ce commentaire ne tentait pas de me gaslighter en allant vérifier sur le site de GNU. Et je confirme, on est dans du gaslighting, donc soit ce message est de la propagande anti-GNU, soit son auteur vit dans un monde utopique. Je préfère la réalité, qui se rappelle toujours à notre bon souvenir.

  • [^] # Re: Mais ça suffit avec Stallman !

    Posté par  . En réponse au journal De l'autarcie du projet GNU, ou comment Emacs ne veut pas devenir EmacOs. Évalué à 3.

    Bel exemple de sophisme argumentum ad personam.
    Je resterai néanmoins rattaché à la vision de RMS s'agissant du sujet qui est en l'occurrence la politique liée au LL et non pas la politique concernant les libertés et droits individuels.

  • [^] # Re: Ha les intégristes du libre...

    Posté par  . En réponse au journal De l'autarcie du projet GNU, ou comment Emacs ne veut pas devenir EmacOs. Évalué à 7.

    On peut être d’accord avec le projet et contester les moyens pour y parvenir. La GPL, c’est quand même une license assez restrictive - la plus restrictive possible parmi les licenses libres, en fait. Le résultat, c’est qu’il y a des gens qui font du logiciel libre sous la contrainte.

    Qui représentes-tu ? Qui sont ces gens ?
    De mon point de vue d’utilisateur de LL voire de contributeur, la licence GPL ne m’est jamais apparue comme restrictive, elle m’est apparue comme la plus idéale.
    Si des gens font du LL sous la contrainte, il faut chercher qui les contraint. Ce qui est sûr c’est que ce n’est pas la licence qui les contraint, mais probablement le choix de ces personnes, par exemple de profiter d’autres LL dans un but privateur.

    Mon avis est qu’il est plus pertinent de viser le même projet sociétal, mais par d’autres moyens: en montrant que ça marche, et en expliquant aux gens et aux entreprises ce qu’ils ont à gagner à faire du libre. Et c’est super de prouver qu’on peut le faire sans même avoir besoin d’outils légaux comme la GPL.

    Grand bien t’en fasse. En ce qui me concerne, quand j’ai vu les progrès fulgurants du LL en 20 ans grâce à la GPL, je vais rester du côté de RMS.
    Lui au moins a obtenu un résultat, et il mène sa barque sans se laisser dévoyer de son dogme par ses nombreux détracteurs. Et pour l’instant, l’Histoire lui donne raison.

    Cela marche de mieux en mieux dans ce sens là. Avec tout le code libéré récement par Microsoft, les efforts de Google et d’Apple sur Blink et WebKit, le compilateur clang, les noyaux BSD qui sont de plus en plus utilisés, etc. Et Linux aussi, qui utilise la GPL mais dont les contributeurs ne sont pas pressés de la faire respecter.

    Qu’est-ce que cela signifie que les contributeurs de Linux ne sont pas pressés de faire respecter la licence GPL ?
    Certains la font respecter à coup de procès, c’est ce qui compte, qu’est-ce que la rapidité vient faire là-dedans, et qui fixe le seuil de rapidité ? Toi ? Et MS n’a pas libéré de code, son code n’est pas plus libre que celui qu’il avait libéré dans les années 2000 :
    ça reste de l’Open Source, pas du LL.

    Il y a d’autres projets qui ont une approche stricte de la GPL, et n’hésitent pas à attaquer des boîtes ou des gens en justices pour obtenir la publications de modifications. Sur le long terme, cette approche n’est pas viable (l’entreprise ou la personne va publier ses sources, puis se dépécher de trouver ou d’écrire un projet sous une license moins restrictive au mieux, ou en closed source au pire). Et ça ne fait pas vraiement avancer les choses vers le projet sociétal de départ, sauf pour les quelques utilisateurs de emacs sous GNU/Hurd.

    C’est quoi le long terme ? Parce que cette approche a été viable sur plus de 20 ans, et l’informatique n’a encore que quelques décennies. Et quand les développeurs de LL écrivent de nouveaux logiciels, c’est sous GPL en général.
    Je trouve triste de lire quelque chose de manifestement faux (approche non viable sur le long terme) en présentant en exemple une entreprise qui délibérément viole la licence GPL (contredisant le discours précédent qui compte sur la bonne volonté des entreprises) pour ensuite réaliser ce qu’elle aurait pu faire depuis le départ (donc la volonté de violer la licence GPL était préméditée). Donc la licence GPL ne serait pas viable à long terme parce qu’elle protège efficacement contre les privateurs ! Ça m’a tout l’air de parfaitement faire avancer les choses vers le projet social (et non pas sociétal) du GNU.

    Mon expérience m'a montré qu'un grand nombre de logiciels propriétaires concurrents de LL ont disparu depuis, alors que le LL est toujours là. Et ce dans tant de domaines que l'on peut quasiment en faire une règle, en tout cas c'est ce que je fais désormais.

  • [^] # Re: A faire une fois dans sa vie

    Posté par  . En réponse à la dépêche Linux From Scratch 7.10 : Vous êtes aux commandes. Évalué à 2.

    À une époque c’est ce qu’on disait de la compilation du noyau… Qui le fait encore aujourd’hui — et qui a encore une vraie raison de le faire ?

    Tous ceux qui, comme moi, sont sous LFS (ou plutôt un gros dérivé depuis le temps, perso ça fait plus de 15 and que je suis sous LFS) comme OS principal, donc avec des OS optimisés pour chaque type de machine, kernel compris. Je n'ai pas du tout la même configuration de noyau Linux sur mon frontal, que sur mon serveur principal, mon Raspberry Pi, mes machines de bureau ou encore mon media center MythTV. Même les architectures diffèrent entre les machines : arm, x86, x86_64, x32.

  • # TAFTA : toujours bien vivant

    Posté par  . En réponse à la dépêche Revue de presse de l'April pour la semaine 35 de l'année 2016. Évalué à 7.

    J’inscris ma réflexion ici pour voir si elle se réalise dans l’avenir, même si je n’ai absolument aucun doute sur le fait que ma « prédiction » soit correcte.
    Le TAFTA, l’accord complètement en défaveur des peuples et des nations, puisque géré dans le plus grand des secrets, est toujours bien actif. Une règle simple pour évaluer le bien-fondé d’une action est que lorsque l’on veut faire le bien, on n’a pas besoin de se cacher.
    Que ce sujet complètement opaque sorte au grand jour comme ayant quasiment échoué (mais pas complètement, notez bien), alors que de plus en plus de gens commencent à se poser des questions sur ce truc d’intérêt public géré par nos politiques dans le plus grand secret, et que donc cela devient vraiment impopulaire, n’est pas étonnant. Encore moins alors que les élections françaises (soutenu par Hollande et le PS, mais en fait par tous les autres aussi, car ils sont tous européistes), allemandes (soutenu par Merkel et son parti) et américaines (soutenu par Clinton et les Démocrates) approchent.
    Il faut donc faire croire aux électeurs qu’après tout ce n’est pas grave puisque ça va mourir.
    Évidemment, ce n’est qu’une manœuvre, et les grands médias français (et allemands et américains) sont là pour bien l’asséner, après tout, la propagande et la manipulation, c’est leur boulot depuis longtemps.
    Le TAFTA ressortira comme par surprise comme bien vivant sitôt ces échéances passées, et que les peuples ont légué leur pouvoir à leurs maîtres.

  • [^] # Re: systemd, le nouveau Multics

    Posté par  . En réponse au journal Attention avec systemd, Tmux ne survit plus après la fermeture de la session.. Évalué à 3.

    J'aimerais vraiment avoir ta source. Parce que dans mon souvenir, les gens de *BSD se sentaient plutôt coincés par systemd qui est devenu une dépendance de pleins d'application dans le userspace. Je n'ai absolument pas vu qu'ils voulaient systemd. Mais, qu'ils sont contraints de faire une couche de compatibilité.

    Il faut savoir de quoi on parle avant de venir raconter n'importe quoi, là ce sont carrément des mensonges que tu racontes, comme je le montre ci-après.
    Les gens de *BSD ne se sont jamais sentis coincés par systemd, mais par les API de logind à fournir pour diverses applications de plus haut niveau, des API demandées depuis très longtemps et que personne n'a jamais daigné fournir. Ben oui, systemd écoute les autres développeurs.
    Et puisque tu n'as absolument pas vu que les *BSD voulaient un équivalent à systemd, je te renvoies vers la présentation de J. Hubbard (rien que ça), en espérant qu'il soit une source assez fiable https://www.phoronix.com/scan.php?page=news_item&px=MTg0ODE .

  • [^] # Re: systemd, le nouveau Multics

    Posté par  . En réponse au journal Attention avec systemd, Tmux ne survit plus après la fermeture de la session.. Évalué à -2.

    C'est pas en 400k lignes de C pour remplacer du shell scripting hyper-immaintenable ? Je suis déçu.

    Mon petit doigt me dit que bash, pour gérer le langage des shell scripts, a besoin de plus de LOC que systemd pour gérer ses fichiers d'init. Bref, probablement un argument fallacieux en plus d'inverser complètement la réalité.

    PS : voici 152 lignes un exemple de boot non maintenable

    Clairement inmaintenable, surtout qu'il fait appel à plusieurs autres binaires et contient une inclusion (source) d'un autre fichier qui peut contenir tout et n'importe quoi (dont d'autres inclusion), et sans lequel ce script ne fonctionne plus. Mais évidemment, si on ne parcourt pas le fichier, on ne peut pas s'en rendre compte.

  • [^] # Re: systemd, le nouveau Multics

    Posté par  . En réponse au journal Attention avec systemd, Tmux ne survit plus après la fermeture de la session.. Évalué à 1.

    Enfin systemd fait tout pour ce placer entre le noyau et un programme utilisateur. Ce qui ajoute un deuxième point critique au système, le premier étant le noyau (monolithique, lui aussi). Tout ceci montre que systemd est d'une complexité beaucoup plus grande que ce qui est nécéssaire, comme le montre les alternatives fonctionnelles.

    Cela ne veut rien dire, il y a toujours un init (PID 1) entre le noyau et les process utilisateur dans un OS multi-utilisateur, surtout si l'on veut que les process soient gérés correctement.
    On peut le faire avec du shell mais les fonctionnalités seront loin d'être les mêmes.
    Donc il n'y a absolument rien de montré ici. Et les alternatives fonctionnelles ont des manques énormes.
    Tous ces init sont très bien dès lors qu'on a des environnements figés, comme de l'embarqué dédié à une tâche spécifique avec un noyau configuré pour.

  • [^] # Re: Ne pas utiliser, recompiler… ou changer une option.

    Posté par  . En réponse au journal Attention avec systemd, Tmux ne survit plus après la fermeture de la session.. Évalué à 1.

    Un bootscript tu le réutilises, c'est fait pour démarrer ou arrêter ton programme. Mais ton programme init va pas décider de ce qui doit ou non rester en vie après le démarrage, de ce que j'ai pu en voir jusqu'à présent c'est spécifique à systemd ça. Je n'ai vu aucun système d'init qui tue une application parce que tu ne lui as pas dit qu'il fallait la garder en vie. Je ne suis pas fondamentalement contre ce genre de système, juste ça n'a rien à voir avec l'init.

    C'est faux évidemment, sysvinit s'occupe de lancer ou de tuer tes applications en fonction du runlevel choisi.
    Et évidemment, une majorité de sysadmin très vocaux contre systemd ne le savent pas, parce que tout simplement, mon expérience a montré qu'une majorité de sysadmin ne comprend rien au système d'init et tous ses écueils, et le groupe contre systemd semble entièrement inclus dans ce groupe.
    Ce qui n'est pas étonnant au final, vu qu'il faut vraiment ne pas avoir eu à gérer sysvinit correctement (indice : c'est impossible de le gérer correctement) pour ne pas voir l'immense avancée avec systemd.
    Les bootscripts qui outrepassent complètement le comportement normal de sysvinit sont déjà un exemple flagrant. Normalement, tout devrait se faire dans inittab avec sysvinit. Et si l'init ne tuait jamais rien, cela signifierait qu'en cas de passage au runlevel 0 ou 6, il se contente d'éteindre sans avertir les applications, bonjour le massacre.

  • [^] # Re: systemd, le nouveau Multics

    Posté par  . En réponse au journal Attention avec systemd, Tmux ne survit plus après la fermeture de la session.. Évalué à 2.

    Donc si j'utilise tmux, je dois prévoir que je vais devoir changer la config d'un autre logiciel…

    Pas du tout, tu peux aussi lancer la commande adéquate pour que cela fonctionne comme avant (systemd-run et passer ta session en linger, si c'est autorisé par l'admin).

    Ce qui me dérange avec systemd, c'est qu'il se mêle de ce qui ne le regarde pas.

    Il se mêle exactement de ce qui le regarde, à savoir gérer les process utilisateur.
    Je pense que ce qui gêne le plus les utilisateurs qui gueulent, c'est qu'auparavant, ils pouvaient tromper le sysadmin, et maintenant ils ne pourront plus.

    Un peu comme NetworkManager qui va toucher aux réseaux, sans te demander, et sur des éléments qu'il n'a pas mis lui-même en place.
    La première chose que je fais sur une machine ddont le réseau déconne, c'est de virer NetworkManager. Avec systemd, j'ai rarement le choix.

    C'est le boulot de NetworkManager de toucher aux réseaux, c'est même dans son nom. Si on n'aime pas on vire, c'est tout.

    Si des admin-sys craignent des pprocessus sans contrôles, il peuvent installer des vm pour leurs utilisateurs.

    Ils peuvent aussi utiliser cette option de systemd, ce qui est infiniment plus simple et moins consommateur de ressources que d'installer des VM pour les utilisateurs.

    Bref, la solution que tu proposes pour faire fonctionner tmux proprement est compliquée. La solution simple est de virer cette fonctionnalité de systemd. Ceux qui la veulent sauront la mettre en place.

    La solution proposée par les dévs de systemd est extrêmement simple, et cette fonctionnalité est présente dans systemd depuis de nombreuses versions, a une réelle utilité, et ne gêne personne : il n'y a aucune raison de l'enlever. Et oui, ceux qui l'utilisaient auparavant savaient changer "#KillUserProcesses=no" en "KillUserProcesses=yes" dans /etc/systemd/logind.conf.

  • [^] # Re: systemd, le nouveau Multics

    Posté par  . En réponse au journal Attention avec systemd, Tmux ne survit plus après la fermeture de la session.. Évalué à 2.

    Ce post de blog est extrêmement intéressant.
    Hélas, il est floué peu après le début.
    C’est amusant de lire qu’une « demi-vérité est pire qu’un mensonge » (sophisme, puisqu’une demi-vérité est un mensonge, mais bon), et de lire ensuite « modern BSD systems continue to manage just fine by way of incremental improvements to the pre-existing components », alors que FreeBSD (il me semble, ou est-ce OpenBSD ?) a annoncé la nécessité de développer son propre systemd car les systèmes ne sont plus gérables en l’état.

    Ceci dit, l’analyse est intéressante, parce que les points indiqués sont vrais. Mais le premier point est parfaitement connu, et la volonté est bien d’utiliser un script shell pour les cas à la marge, comme les daemons qui se comportent mal. Et AMHA ce sera une réelle avancée pour tout le monde, parce que tous les daemons qui se comportent mal seront immédiatement visibles par tous les sysadmins. La volonté n’est surtout pas d’ajouter des fonctions spécifiques pour ces daemons, mais de faire en sortent que leurs développeurs les corrigent. Et on a déjà commencé à voir de nombreuses améliorations depuis la naissance de systemd, donc c’est un point extrêmement positif. J’ai vu des améliorations dans gdm, mysql/mariadb, apache, les process pour NFS entre autres.

    L’assistance des utilisateurs (en général des mainteneurs de distribution ou des sysadmins) est une bonne chose selon moi. Rien n’empêche d’utiliser d’autres moyens plus sioux si on en a l’habitude ou l’envie, mais gueuler sur « systemctl edit » parce que ça assiste le sysadmin n’a aucun sens.
    Mais c’est normal puisque l’auteur n’a absolument pas compris les nombreuses bonnes raisons pour l’utilisation de « systemctl edit », des raisons qui sont essentiellement liées au déploiement de distributions. Ce n’est pas non plus la panacée évidemment.

    Hélas, l’auteur commence à tomber ensuite dans le déraisonnable et même carrément le mensonge, lorsque l’auteur dit qu’avec sysvinit, il était capable de dire exactement quels services allaient être démarrés. Je n’ai jamais vu le moindre sysadmin capable de prédire cela avec sysvinit, c’est même spécifiquement la raison pour laquelle tout sysadmin sain d’esprit rebootait le serveur au moins une fois lorsqu’il modifiait la séquence de démarrage, pour être sûr que ça allait bien exécuter les scripts jusqu’au bout. Et je n’ai pas dit « lancer les services » mais « exécuter les scripts ». Parce qu’avec sysvinit, ce n’est pas parce que le script d’init était lancé et renvoyait un code retour OK (voire un bel OK vert à l’écran) que le service était vraiment lancé ou n’avait pas planté après coup.

    L’auteur parle de sécurité, mais ensuite ose venir se demander pourquoi systemd ne veut plus lancer de shell (/bin/sh) avant de lancer chaque daemon. Cet argument est d’une telle mauvaise foi : un daemon n’a absolument pas besoin d’un shell pour être lancé, c’est complètement contre-productif. L’auteur sera incapable de justifier pourquoi il faudrait lancer un shell, surtout qu’avec sysvinit, les daemon sont censés être lancés dans l’inittab, sans aucun shell. Donc il renverse la question pour dire que systemd est pas bien parce qu’il ne veut pas lancer de process inutiles. Et souvent ce n’est pas que /bin/sh, mais beaucoup d’autres process lancés (augmentant la surface d’attaque de tout script init), juste pour un daemon qui n’en a que faire. Le pire, c’est que sur son BSD, ça ressemble plus à systemd qu’à sysvinit.

    Bref, il y a des critiques valides, mais rien qui ne soit pas déjà connu ou pris en compte par les dévs de systemd. Il est triste aussi de constater que ce qui est le plus critiqué et le plus critiquable, c’est que systemd écoute les utilisateurs et rajoute des options qu’ils demandent, lorsqu’ils estiment que c’est un cas pertinent (suffisamment répandu pour ajouter une option).

  • [^] # Re: systemd, le nouveau Multics

    Posté par  . En réponse au journal Attention avec systemd, Tmux ne survit plus après la fermeture de la session.. Évalué à -10.

    Cela t'a l'air simple… mais je n'ai absolument rien compris.

    Ce n'est pas grave, c'est parce que tu n'as pas le niveau, c'est visible par ce que tu dis ci-dessous.

    Tout à l'heure ma session graphique à planté. Heureusement que mes tmux n'ont pas été coupés par systemd.
    Heureusement que je n'utilise pas cette version de systemd…

    La version de systemd que tu utilises possède déjà le mécanisme décrié, c'est juste que l'option n'est pas activée par défaut dans le fichier de configuration.
    Eh oui, la seule chose qui a changé dans cette version de systemd en ce qui concerne cette fonctionnalité, c'est une option d'un fichier de configuration qui est passé de Yes à No. Lorsque l'on utilise tmux, je pense que l'on est capable d'aller modifier une option dans un fichier de configuration.

  • [^] # Re: Ne pas utiliser, recompiler… ou changer une option.

    Posté par  . En réponse au journal Attention avec systemd, Tmux ne survit plus après la fermeture de la session.. Évalué à 3.

    N'est-ce pas contradictoire ?

    Non, puisque cela concerne uniquement la minorité de personnes qui va aller regarder ses logs (par quelque moyen que ce soit, par exemple via un outil de monitoring).
    Les utilisateurs que j'ai décrit, évidemment, n'iront pas voir.

    BTW: As-tu déja utilisé nohup, dans le cadre de sysadmin ? J'imagine que non… Généralement, c'est pour faire nohup mon_script_exceptionnel_que_je_n_veux_pas_interrompre, donc bref une manipulation exceptionnelle (genre un dump de DB, reconstruction raid, etc), pas pour lancer un daemon (ça c'est parfaitement la responsabilité job d'init).

    Je n'ai jamais utilisé nohup dans le cadre de sysadmin. Et cela simplement parce que nohup, lorsque je l'utilisais, se révélait toujours être une catastrophe, car bien souvent, on oublie de mettre quelquechose dans le journal, et c'est difficile à gérer. J'ai très vite découvert screen, et donc nohup n'avait plus aucune utilité pour moi depuis ce jour. Surtout pour faire des choses comme des dumps de DB ou des reconstructions de RAID, je préfère avoir clairement en visuel le retour de ces fonctions. Si je suis en local ou quasi local sur le serveur, pas besoin de nohup ou screen, mais si je suis à distance sur une connexion peu fiable (comme internet), dans ce cas, effectivement, j'utilise screen. Même pour des reconstructions de RAID logiciel sur Linux, ça s'effectue en tâche de fond et je n'ai jamais eu besoin de nohup.

    Bref "indiquer clairement à init que les process qui restent sont voulus" c'est faire "nohup"… Avec ce comportement par défaut ça sera "systemd-spawn-machinchose --flag-super-important nohup mon_script", ça c'est le progrès… Aussi un "soit-disant sysadmin" utilise généralement différentes versions d'OS et différents OS, tu peux imaginer un peu le casse tête (?).

    systemd-run --scope --user , cela n'a rien de compliqué, et un sysadmin digne de ce nom ne s'amuse pas à balancer des process en nohup sur différentes versions d'OS et donc sur plusieurs serveurs en même temps. Il faudrait que ces serveurs soient extrêmement mal gérés pour avoir besoin de faire autant de tâches manuelles non prévues. C'est quand même censé être rare d'avoir à lancer ce genre de trucs. Sur l'unique machine où j'ai un screen en permanence, il est lancé une fois au boot dans une session. Je n'ai besoin que d'un seul screen pour gérer plusieurs serveurs, et je n'ai donc plus besoin de nohup.

    De plus, nohup n'indique rien du tout à l'init, l'init reste incapable de faire la différence avec un process qui se comporte mal. Au contraire de systemd-run.
    Et des process vandales, j'en ai vu aussi bien à l'école que dans des grandes entreprises, avec par exemple des tonnes de process java zombies qui tuaient à petit feu les performances des serveurs à chaque redémarrage de l'application (obligatoire puisque grosse appli enterprise-ready Java pourrie comme bien souvent). Des problèmes qui parfois datent de plusieurs années et qu'aucun sysadmin ne remarque (j'espère par manque d'expérience).

  • [^] # Re: Bug ferme chez tmux

    Posté par  . En réponse au journal Attention avec systemd, Tmux ne survit plus après la fermeture de la session.. Évalué à -2.

    Je pense qu'indépendemment du fait qu'il était documenté ou non, c'est toujours une mauvaise idée de changer brusquement un comportement connu et attendu des utilisateurs depuis 30 ans si ça n'apporte pas une amélioration drastique.

    Le problème, c'est que pour qu'il y ait un changement, il faut que la nouvelle solution soit visible. Cette possibilité était présente depuis les débuts de logind, or personne ne l'utilisait, parce que c'était déjà configurable, mais on laissait l'option par défaut à No en upstream. Et je pense tout simplement que personne n'en avait rien à faire et a repoussé à plus tard.

    L'équipe de systemD ne peut pas prétendre ne pas savoir que des tonnes d'utilisateurs gardent volontairement des sessions tmux/screen ou des process tourner via nohup, notemment quand ils sont dans un environnement hostile en terme de connection.

    Comment se fait-il que tant d'utilisateurs utilisent tmux/screen ou laissent tourner des process via nohup ? Peut-être dans les écoles, mais sinon je ne vois pas.
    Screen c'est très utile pour développer à distance chez soi, donc sur des postes utilisateur. nohup c'est quasiment toujours du hack.
    Tout le monde ne compile pas tout son OS comme moi, et j'utilise principalement screen pour cela.
    En tout cas, l'équipe de systemd est parfaitement au courant de l'existence de screen/tmux, à tel point que toutes les informations pour continuer à les utiliser avec le nouveau comportement par défaut, se retrouvent dans les man de logind et de systemd-run, et clairement indiqués dans la NEWS systemd.
    Comme d'habitude, la personne qui a remonté le "bug" dans Debian instable, soit possède un niveau de compréhension trop faible pour une utilisation de screen, soit utilise la mauvaise foi pour forcer la main aux mainteneurs. Et ça a marché puisque les mainteneurs ont ramené l'option comme avant. C'est triste, mais pas si grave, les sysadmins qui ont maintenant eu vent de l'option, pourront l'activer sur leurs serveurs.

    Donc je trouve raisonnable que l'option "par défaut" reste le même et que les administrateurs changent cette option dans les finalement très rares cas où ils ont une exprérience régulière de process qui bouffent des ressources indéfiniment.

    Non, ce n'est pas raisonnable selon moi. Un utilisateur moyen (la majorité) aurait une expérience améliorée avec cette nouvelle option par défaut, et est incapable de la modifier, tout simplement parce qu'en général tout cela le dépasse et il laisse aux autres le soin de lui choisir la meilleur solution (et il n'utilise pas screen de toutes façons). En revanche, ceux qui maîtrisent un peu plus sont parfaitement capables d'utiliser les moyens palliatifs ou de modifier l'option de manière générale.

  • [^] # Re: Ne pas utiliser, recompiler… ou changer une option.

    Posté par  . En réponse au journal Attention avec systemd, Tmux ne survit plus après la fermeture de la session.. Évalué à 2.

    Je pose simplement la question de savoir si cette décision apportera une plusvalue en ce qui concerne une amélioration de la qualité des applications. J'en doute très fortement car je prends comme hypothèse que masquer des problème engendre une non-correction des bugs de la part des programmeurs, et je justifie cela non pas par leur fainéantise innée, mais parce que ces bugs ne seront tout simplement pas rapportés par les utilisateurs. Bref, dans le long terme, c'est une mauvaise décision selon moi :-)

    En fait ce commentaire indique que la décision est excellente à court comme à long terme. En effet, aucun utilisateur n'est capable de remonter des problèmes survenus après la fermeture de sa session. Car l'immense majorité des utilisateurs, après s'être déconnecté, ne va pas se reconnecter ensuite pour voir s'il n'y aurait pas des mauvais comportements dans les logs ou des process fantômes, le seul endroit où ce comportement sera visible.
    Les mauvais comportements seront au contraire désormais un peu plus visibles, car on pourra désormais voir ces process mourir dans les logs de l'utilisateur.
    Cette décision apporte une énorme plus-value : elle permet d'indiquer clairement à l'init que les process qui restent actifs sont voulus ainsi, alors qu'auparavant, il n'était pas possible de faire la distinction avec des mauvais comportements de process, puisque c'était un hack pour tromper les autres init.

    La plus grosse contradiction dans toute cette affaire, c'est que les soi-disant sysadmins qui se plaignent que systemd n'est pas fait pour leurs serveurs, sont les mêmes qui se plaignent de ce changement de comportement par défaut, alors qu'il est parfaitement adapté aux serveurs justement.

  • [^] # Re: Question

    Posté par  . En réponse au journal Bash dans Windows. Évalué à 2.

    Comme pour Mac : ne pas se faire chier avec les limites de Linux genre support matériel pour le matos de moins de 2 ans, bibliothèque logicielle plus que limitée (non, le monde ne se limite pas au repo de logiciels libres de la distro), bref avoir le meilleur des deux mondes.

    Donc le support matériel non fourni par un constructeur (ce qui est plutôt l'exception de nos jours) est une limite de Linux ?

    Le jour où il y a un équivalent de Visual Studio (par exemple, mais bon nombre personne ont des applis pros qui tournent que sous Mac ou Windows, ou simplement des jeux avec DirectX) sous Linux, on en reparle de passer à Linux en OS.

    Il y a aussi bon nombre d'applis pro qui ne tournent que sous Linux, mais à quoi ça sert d'avoir un équivalent de Visual Studio sous Linux, vu qu'il y a déjà mieux ?

    Sérieux, un peu d'ouverture, regardez vos voisins, ils ne sont pas sous Linux et ce n'est pas à cause de la vente liée ou autre excuse.

    Dans la grande entreprise où je me trouve en ce moment, mes voisins développeurs développent tous pour Linux et aucun n'utilise Visual Studio pour développer, pourtant leurs postes de développement sont sous Windows (oui c'est stupide).

  • [^] # Re: ce sera rétro compatible ce truc ?

    Posté par  . En réponse au journal Bash dans Windows. Évalué à 10.

    Je ne jugerai pas PowerShell vu que je ne le connais que très peu et n’ai pas envie de le connaître plus (parce que je n’en passe pas moins).
    Mais la comparaison donnée est d’un ridicule qui ne peut venir que d’une méconnaissance totale des outils GNU ou d’une mauvaise foi.
    Pour révéler la puissance manifestement non accessible à tous du shell fichier, il suffit de voir que l’exemple donné peut s’écrire en GNU :
    find . -size +20M | wc -l
    Ce qui a l’avantage d’être beaucoup plus compréhensible et plus concis que les deux exemples donnés, sans compter que c’est surement plus rapide (on ne lance pas un interpréteur awk, rien que ça).

    Je dis ça parce que le truc sur Windows 10 c’est un Wine inversé en fait : appels systèmes Linux convertis en appels système Windows. Malheureusement, ça ne concerne apparemment que les outils en ligne de commande et n’est même pas encore stable pour tous les outils GNU d’Ubuntu.

  • [^] # Re: il te manque un flush quelque part.

    Posté par  . En réponse au message systemd/journld ne capture pas tous les messages de la STDOUT. Évalué à 1.

    Par contre systemd devrait peut-être être plus loquace sur ce sujet et logguer un truc du style "plus de 1000 messages reçus de xxxx durant la dernière mn, je blackliste". Ca éviterait certainement de se prendre la tête pendant des heures à chercher à comprendre ce qui se passe (surtout que ça doit etre un détail d'implémetation parmi tant d'autres caché au fin fond de la doc, ou peut-être même pas documenté).

    Je trouve amusant de lire une telle réponse à un post qui cite le man de journald. Une réponse à priori négative comme quoi ce "détail d'implémentation", qui est en fait une protection parfaitement voulue et demandée, n'est peut-être pas documenté. Cette option est non seulement documentée, mais possède plusieurs options de contrôle qui lui sont propres.
    Un minimum d'expérience en administration pousse tout de suite vers du "rate limiting", mais surtout, envoyer autant de messages par secondes ne me paraît pas très sain si le seul objectif est de tester que les logs partent bien dans le journal. Si l'objectif était autre, j'ai dû rater cette information.
    En fait, journald se comporte comme les autres daemons de log, mais comme le résultat est plus simple à consulter avec journald, on repère vite des choses qui passaient inaperçues auparavant.

  • [^] # Re: Des infos

    Posté par  . En réponse à la dépêche Bassel Khartabil, développeur du libre, secrètement condamné à mort par le gouvernement syrien. Évalué à 0.

    La crédulité dans le monde du Libre me navre, vraiment.
    Une femme (SJW) vient dire un truc et pouf, pas besoin de réfléchir ou de confronter, tout ce qu’elle dit est vrai. Je ne prends pas les choses assénées par des gens suspicieux pour argent comptant, je vais vérifier et confronter.
    Le discours même de l’activiste qui parle de ce prisonnier soi-disant acteur du Libre m’a mis la puce à l’oreille : il n’est fondé sur rien, présente le gouvernement syrien comme des « méchants » (ça suffit pour provoquer l’émotion chez les esprits faibles, ce qui empêche de réfléchir, technique bien connue de manipulation, entre autres par les SJW, Neo Cons…), parle de choses censées être secrètes comme si elle les connaissait parfaitement.
    Bref, son texte est déjà suspicieux (j’en ai eu vent au départ sur LWN), mais alors en plus, les liens qu’elle donne sont éloquents (en ce qui me concerne).
    C’est une véritable campagne de propagande qui s’est mise en place, avec tout l’attirail habituel dont le story-telling, ce qui est très étrange pour un développeur lambda. Quand on suit ces nombreux liens, on se rend compte que le monsieur n’a quasiment rien contribué au Libre, mais en revanche, avait des connexions avec le management chez Google, Facebook et cie, et a monté une association qui se comportait exactement comme un lieu pour l’espionnage d’État, où principalement des étrangers se rendaient régulièrement.
    Son arrestation coïncide avec la guerre qu’à financé et outillé les É.-U., enfin, la « coalition internationale » dont la France (financé Daesh, ISIS, « sortis de nulle part » sauf pour ceux qui étaient informés) contre la Syrie en 2012.
    Quand en plus le monsieur est cité en bonne position dans un classement contenant de nombreux Neo Cons et autres membres d’états tortionnaires (mais « gentils » quand même comme l’occupant israélien ou les néonazis en Ukraine), ça n’est plus, pour moi, un ensemble de coïncidences.
    Le déploiement de moyens est sans commune mesure par rapport aux autres activistes emprisonnés, donc j’évite de toucher cette affaire.
    Mais surtout, je trouve indécent ce déploiement de force alors qu’il y a des gens qui meurent en Syrie depuis 2012 et qu’il y a mieux à faire que se concentrer sur une personne. Mais bon, si c’est véritablement un espion et qu’il a été arrêté en connaissance de cause, tout ce remue-ménage se tient parfaitement et est même parfaitement logique.
    On n’en fait pas autant pour des gens emprisonnés en France en dépit de la « liberté d’expression » (qui est une exception et pas la règle dans tous les pays qui la prônent, France y compris) pour avoir révélé des failles informatiques ou des chercheurs en cryptographie emprisonnés aux É.-U. pour les mêmes raisons.