karchnu a écrit 414 commentaires

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.

Si tu cherches un nom de domaine vraiment pas cher (0€ TTC), tu peux te diriger vers net libre qui fournit un nom de domaine en .netlib.re. C'est gratuit et basé sur du soft libre. Il n'y a pas de conditions arbitraires pour garder le nom de domaine (comme un trafic minimal, ce qui est demandé par le .tk par exemple) donc aucune crainte à ce niveau.

Combo 1er avril + vendredi. Ça fait pas bon ménage.

À la mise à jour (gratuite et à mon initiative), mon shell continue de fonctionner exactement de la même manière, ma distribution est stable, les outils ne changent pas (ou très rarement).

Et je comprends tout à fait la frustration de bosser avec powershell, les commandes ne sont clairement pas aussi simples et intuitives… et XML. XML rah ! La seule (selon moi fausse) bonne idée est de passer des références dans les pipes au lieu de tout copier.

Les news sont quasiment du niveau d'un message de commit avec quelques images de leur interface graphique. En quoi ça aide à comprendre le projet dans son ensemble ?

Oui, chacun fait comme il veut pour coder son projet. Pour un OS, partir avec un minimum de doc est par contre indispensable. Dire qu'il y a pire ailleurs n'est pas un argument.

Oui, les développeurs sont arrogants, quand on dit en gras dans une page we will not replicate the mistakes made by others c'est assez limite.

--

Mais oui, comme toi, je suis assez content qu'on ait ce projet sous la main, pour voir ce que ça pourrait apporter de développer un OS from scratch avec un langage moderne qui apporte réellement des avantages, en permettant de debug plus facilement, de repérer voire éliminer certaines catégories de bugs, etc.