karchnu a écrit 393 commentaires

Devoir intégrer du code à tmux parce que systemd, c'est normal ça ? Pas besoin d'aller chercher bien loin. Les programmes gérés par systemd doivent être modifiés, soit pour gérer les dépendances entre les process, soit pour [raison aléatoire]. Les plus réfractaires diront que le code est horrible, mais surtout il y a besoin de code, c'est beaucoup plus ça le problème : du code spécifique à systemd dans des programmes.

« Linux is bloated » : http://www.linux-mag.com/id/7536/

Si Linux est maintenu, c'est avant tout parce qu'il y a un nombre hallucinant de développeurs dessus, pas parce qu'il a été conçu pour être facilement maintenable.

Donc ce n'est pas un problème de sécurité.

Ton exemple n'est pas bon non plus. Un utilisateur des machines de la fac peut vouloir lancer un processus de manière légitime (quelque-chose qui s'exécutera pendant un petit moment). Tu prends l'exemple du minage bitcoin, je prend l'exemple d'un étudiant qui veut juste faire son travail et lancer une compilation ou un ensemble de scripts. Sur cet exemple (bien plus répandu que du minage de bitcoin) c'est simple actuellement, avec le nouveau comportement c'est pénible. Donc pour la fac non, ça ne fonctionne pas. Je sais que l'exemple a été dit plusieurs fois pour montrer à quel point on en aurait besoin, mais c'est faux et non viable.

Là encore, tu assimiles l'init à ce qui lance et tue tes applications, ok, c'était fait comme ça dans sysvinit. Soit.

Le runlevel est quelque-chose de particulier, et changer de runlevel ne peut être simplement comparé à démarrer et arrêter un processus qui est une tâche bien plus courante que de changer volontairement de runlevel (autre qu'au démarrage / arrêt de la machine).

Sous OpenBSD par exemple la gestion du runlevel est simple, et qui peut se résumer à : tu as un level où tu as tous les droits, un level de fonctionnement normal, il n'est pas possible de revenir au niveau « tous les droits » si tu es en mode « normal ». C'est simple, ça répond exactement aux besoins.

En aucun cas on ne va utiliser le runlevel pour simplement redémarrer une application ! C'est pas fait pour. Changer de niveau c'est un changement d'état de fonctionnement de ta machine, ce n'est pas annodin. Le système d'init, s'il gère aussi le runlevel, peut être amené à tuer des processus dans le but de ne pas induire des erreurs dans le fonctionnement. C'est pas tout à fait la même chose que de dire « c'est lui qui gère le démarrage et l'arrêt des processus ». D'ailleurs, tu n'indiques pas de commande à ton processus d'init pour qu'il démarre tes services, tu réutilises simplement ses scripts.

Oui, les développeurs font ce qu'ils veulent. Ai-je dis le contraire ?

Il suffit de forker, oui, c'est bien ce qui est fait et c'est bel et bien ce dont nous parlons. Cela ne va pas sans peine non plus, se mettre à maintenir plus de programmes sous prétexte que les développeurs en upstream cassent la compatibilité (ou arrêtent de maintenir le programme) reste une charge supplémentaire, donc les réactions parfois exaspérées des mainteneurs est légitime. Donc oui, le fork est une possibilité, mais c'est aussi un peu facile de juste s'en remettre à ça pour dégager une responsabilité.

La partie windows n'est simplement en rien compatible avec les BSD, en revanche la partie linux ne nécessite pas forcément de gros changements pour fonctionner puisque le fonctionnement du système a de forte similitudes par rapport aux BSD, du moins jusqu'à maintenant. Puisque tout passe à systemd, les développeurs principaux ne gèrent plus l'ancien fonctionnement, et donc il faut faire l'effort de créer une branche à part. Ça va à l'encontre de la philosophie « on ne répare pas si ce n'est pas cassé ». C'est plus ou moins ce qu'il s'est passé pour dbus.

Je ne suis pas expert, faut demander aux développeurs pour en savoir plus et voir d'autres exemples.

Et en quoi c'est un problème de sécurité le fait de laisser un processus utilisateur tourner ? S'il n'a pas le droit de faire quelque-chose, c'est déjà géré. Empêcher de faire tourner un programme qui n'a pas de privilèges ce n'est pas de la sécurité, c'est juste pénible pour l'utilisateur.

OpenBSD. J'aime la philosophie du projet, ça colle avec ma vision du monde. Il y a moins de features que sur FreeBSD, mais je fais avec, je n'ai pas de gros besoins. Pour ce qui est du système de fichiers, FFS me va très bien, je n'ai pas regardé ailleurs. Côté configuration, je ne sais pas si on peut faire plus simple qu'OpenBSD ! Mais peut-être avons-nous des critères différents. :)

Petit retour d'expérience personnelle.

Pour ma part c'est fait. Je n'ai rarement eu un système aussi stable, un fonctionnement aussi prévisible et une documentation aussi claire. Tout n'est pas parfait, mais je n'ai aucune régression par rapport à mon usage (firewall, vpn, http et quelques appli web, smtp, dns, dhcp…). Pour quiconque cherche une alternative à Linux pour ses serveurs, FreeBSD ou OpenBSD peuvent répondre parfaitement aux attentes. Pour le firewall cela est même bien plus pratique (packet filter, ♥).

Les gens de BSD n'en veulent pas du tout de systemd, mais suite à des problèmes de compatibilité dans des logiciels - puisqu'ils sont tous modifiés pour coller à la vision du monde de systemd - ils souhaitent développer une API de compatibilité. C'est uniquement pour ne pas avoir à redévelopper des outils qu'ils utilisent depuis toujours. Ça s'arrête là.

Et les gens qui n'apprécient pas systemd sont si virulents c'est aussi en partie parce qu'il modifie le comportement de plein de programmes qui fonctionnaient et étaient utilisés par différents systèmes. Du coup même si on n'a pas systemd sur sa machine, on est touché par les modifications.

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.

nohup n'indique rien du tout à l'init, vrai. L'outil qui te sert à démarrer ta machine (init) n'a pas vraiment besoin de gérer les processus par après. systemd le fait, mais ce n'est pas le rôle de l'init.

nohup n'indique rien au gestionnaire de services / démons, vrai. Là on rajoute une meta donnée supplémentaire juste pour savoir si le processus doit rester en vie après la fin d'une session utilisateur. On ne peut pas dire qu'on soit sur la voie de la simplicité, surtout avec des commandes toujours spécifiques à systemd.

Visiblement systemd. Tout ce dont nous parlons jusqu'à présent c'est bel et bien du fonctionnement qui est normal pour un processus. Par défaut il se fait tuer lorsqu'on se déconnecte (du terminal, pas de la session). Donc « ce qui est amélioré » c'est juste que même lorsqu'on a décidé de laisser un processus fils continuer après la mort du père (le terminal), il se fera tuer si on quitte la session.

Ça n'apporte strictement rien. Les quelques (rares) programmes qui continuent de fonctionner sans qu'on n'ait à utiliser nohup, et où ça n'a pas trop de sens (ex: firefox) doivent être patchés au cas par cas, ce n'est en aucun cas un patch à appliquer à tous les programmes dont leur fonction est de continuer après la mort du terminal. nohup est là pour justement permettre à des applications de survivre, et ça fonctionne comme ça sur tous les unix-like du monde. Rien ne justifie de faire une exception sous linux.

Bug de tmux ? En quoi ? Parce qu'il n'intègre pas du code spécifique à un système d'init en upstream ?

En parcourant un peu le document on se rend compte de quelques approximations, mais c'est quand même une très bonne approche et un bon début pour un néophyte. Bravo ! :)

Peut-être que je n'ai pas assez fait de C++ pour voir à quel point c'est génial, mais j'ai l'impression que le code assembleur que tu présentes est plus simple que le code C++. L'expressivité d'un langage ne lui permet-il pas justement de simplifier sa compréhension et d'exprimer de manière plus synthétique et plus sémantique un problème donné ? Avec le C++ j'ai l'impression qu'on répond à un problème technique par une complexité au niveau du langage, justifiée par la résolution d'un problème technique.

Le résultat est très verbeux, peut-on faire plus simple ? Comment se gère ce problème dans les autres langages ?

Ce n'est pas une erreur de cible. C'est une menace. Toi qui achète, n'oublie pas que même si c'est tentant de rejoindre tous tes petits copains qui ont arrêté de se faire pigeonner depuis des plombes, si tu le fais on va venir te faire financièrement du mal. Et puis pense aux petits artistes, ne deviens pas un de ces vaut-riens qui osent tuer la créativité ! Et n'oublies pas, les blockbusters du moments que tu peux acheter en toute légalité (argument de vente, quand on n'a rien d'intéressant à proposer) chez nous !

Tout d'abord, bravo pour la dépêche qui est bien rédigée et assez complète ! :)

Ensuite, j'aimerai savoir s'il sera possible de faire tourner wayland facilement sur ces nouvelles versions d'Ubuntu. Je sais qu'ils partent vers Mir, mais sera-t-il possible de sélectionner l'un ou l'autre à la connexion, comme on le ferait avec un environnement de bureau ?

Je pense qu'on est tous d'accord là dessus, tant que cela n'est pas utilisé pour justifier l'inaction.

Cela correspond assez bien à l'idée que l'auteur a des nouveaux contributeurs.

LinuxFR tu l'aimes ou tu le quittes.

Tu as oublié la catégorie des gens qui expliquent à Bortzmeyer ce qu'est le DNS. Ceux-là ont une place particulière dans mon cœur.

Je pense comprendre pourquoi Snappy : on souhaite fournir des applications avec des dépendances non testées, qui seront presque gérées directement par l'équipe de développement et non par l'équipe de mainteneurs. Du coup, on fournit plus rapidement le programme aux utilisateurs. Le problème engendré par ceci a été dit dans d'autres commentaires, la sécurité en prend un coup (violent).

Mais quitte à vouloir faire ceci, pourquoi s'embarrasser de dépendances aux bibliothèques installées sur le poste de l'utilisateur ? Pourquoi ne pas simplement repartir de la base, et fournir non pas des paquets qui indiquent plein de bibliothèques dont ils dépendent mais directement un binaire qui est déjà compilé statiquement ? Cela me semble beaucoup plus simple, pour un résultat identique si ce n'est mieux : plus de soucis de dépendances du tout. Certes, les binaires seront imposants, mais toujours moins que télécharger plusieurs fois les mêmes bibliothèques.

Même avec le titre Tout ça c'est bien beau mais dans quel but ? vous n'avez pas indiqué quel était le but du projet. Il ne reste que le titre pour deviner ce que cela peut être… un hébergement laissé ouvert pour que des gens viennent y mettre leurs services ?

Je t'invite à relire la news associée à netlibre et ses très nombreux commentaires qui portent sur ton questionnement en y apportant les réponses adéquates.

Le prix n'est qu'un argument, la simplicité, le fait que ce soit libre, sans engagement, et sans limites arbitraires font que cela a un intérêt. Cela ne veut pas dire que pour toi ça aura de l'intérêt, mais pas besoin de dénigrer le travail pour autant.

Relier son nom de domaine à son fournisseur d'accès ? Curieux comme procédé. Tu changes de fournisseur tu changes de nom ? Pas pratique.

Netlibre n'a rien de révolutionnaire, mais c'est basé sur du code libre, c'est simple, c'est gratuit, ça ne coupera pas ton nom de domaine sous un prétexte stupide de nombre de visiteurs, et tu peux venir casser la croute avec son développeur si t'as envie d'en savoir plus. Pour moi c'est une bonne raison de drop no-ip.