Le NIH s'applique peut être à SysVinit et pas à systemd :p
Mais je ne pense pas que ça soit la raison principale en effet de garder Upstart. Ce qu'on voit, c'est que si Debian passe à systemd (et donc fait le taf d'intégration), alors Ubuntu va suivre. Sans ça, ça aurait du être le taf d'Ubuntu, et je pense que Canonical n'avait juste pas les moyens humains de faire ça alors qu'ils ont des projets à finir.
Ça reviens à une bête question de ressource. Et le fait d'avoir des bugs non corrigés depuis longtemps dans Upstart, d'avoir finalement peu de code poussés dedans ne sont que d'autres symptômes d'une même cause.
En attendant que la QA de Debian (et de RHEL 7) fasse le taf, Ubuntu a tout à gagner.
Alors en fait, j'ai cherché ( car oui, je ne discute pas sans recherche minimum ), et j'ai trouvé divers choses.
Alors il y a virt-sandbox-service, qui est un wrapper entre libvirt et systemd. La dépendance est à la fois assez faiable ( car ça fait des unités systemd, rien de complexe à refaire sous upstart ) mais elle existe.
En fait, je savais même pas que c'était fortement lié à systemd avant de regarder en détail.
Tu as aussi des trucs comme fleet ( https://github.com/coreos/fleet ) du projet coreos, qui permet d'avoir un systemd sur le réseau ( ie, activation à la volée, ce genre de choses ).
Je pense qu'il y a surtout une question de marketing. IE, quand tout le monde a migré vers upstart, personne n'a rien dit parce qu'on a pas mis ça en avant, et parce que personne n'a eu le style de Lennart pour dire "les trucs sont de la merde, le mien est bien".
Quand Apple change un truc, ils vont le vendre bien, donc les gens acceptent. Lennart, lui, il compte juste sur la qualité du produit, et visiblement, ça ne suffit pas à réduire les peurs des gens. Il faut ensuite rajouter les pseudos experts qui postent pour dire "si systemd crash, l'os crash" pour avoir un panic.
Aucun n'a vérifié ce qui se passe, personne n'a lu le code pour voir qu'en pratique, systemd ne fait pas paniquer le kernel.
Donc oui, si systemd crash, il ne réponds plus, mais la machine tourne encore, les processes aussi, vu que systemd tourne en boucle en faisant "pause" pour éviter le kernel panic. Donc au final, ça reviens à être bien moins catastrophique. Et pour être franc, je me demande si il n'est pas possible de relancer automatiquement systemd pour plus de HA. ( le code n'est pas la, mais je ne sais pas si on peut le rajouter facilement et de façon robuste ).
Ou alors juste sur les rapports de IDC, ou Unix représente 16% du marché, et est prévu pour chuter à 9% ( http://www.networkworld.com/news/2013/081913-unix-272728.html ). L'article explique aussi que les déploiements de db sur linux ou windows dépassent ceux sur unix. Si c'est pas de la prod, je ne suis pas vraiment sur de savoir ce que c'est.
Digital et Compaq ont disparu et leur unix de même, SCO/Caldera aussi. Je sais même pas ce que Xenix est devenu, et Irix existe plus que dans Jurassic park ( dans le film, pas dans le sens ou c'est un dinosaure ).
HP-UX, AIX et Solaris sont encore la en effet, et je dirais bien que seul Solaris arrive à faire des trucs, poussé par Oracle, mais IBM dégraisse, HP aussi, et Sun s'est cassé la gueule pour se faire racheter par Oracle.
Ma maigre expérience de 18 ans d'Unix (Solaris, HPUX, AIX, NCR,
XENIX), me permets d'avoir un avis personnel et de juger que oui
Linux s'éloigne d'Unix,
ça fait bien longtemps que ça s'éloigne d'Unix. C'est même la raison de son succés, pas de procés au cul par AT&T.
Mais il faut bien voir une chose. Les Unix ont pour la plupart disparus. Et si il suffisait de suivre leur philosophie pour survivre et avoir du succès, debian kfreebsd serait pas à que dalle en terme d'usage, et l'Unix-like avec le plus de succès serait pas originaire de Cupertino.
Tu peux dire ce que tu veux sur les principes d'Unix, mais visiblement, ils ont pas l'air de passionner les foules ni d'être une raison de choisir cette famille d'OS. ( et faut pas me dire "oui, mais le marketin de blabla", si le marketing de tout les OS plus récents est meilleur, c'est bien la lose d'être la avant et de se faire battre )
Mais je suis sur que Freebsd sera ravi d'avoir ton aide avec tes 18 ans d'xp, car il me semble évident que tu va faire quelque chose, pas juste attendre, n'est ce pas ?
Ce qui est amusant, c'est qu'est ce que tu fait si le projet upstream dépend d'un init spécial ?
La question de gnome/kde qui pourraient avoir besoin de logind est pertinente, mais il n'y a pas de réponses. Soit tu vires les paquets, soit tu fait un bug upstream ou tu patches. mais si tu patches, et que upstream n'approuve pas, il se passe quoi ?
Et si tu laisses les gens dépendre 'un init, tu va dire quoi quand quelqu'un va dire "ok, je fait que upstart, et je teste qu'avec ça" ( ou systemd )
Non, je crois plus en le fait que dire "on va mettre ça par défaut" n'implique pas que les mainteneurs trouvent le temps de tout corriger/adapter et tout faire. Enfin je pense surtout à l'équiep d-i qui est chroniquement débordé, et je ne sais pas si il y a beaucoup à corriger/adapter, mais j'exclue pas la possibilité que ça soit le cas.
De surcroit, systemd bouge quand même pas mal, et l'équipe d'anaconda a passé pas mal de temps sur ça.
Quand à une fronde des mainteneurs, non. Mais il y a eu plusieurs personnes annonçant leur intention de faire une GR de façon publique, donc je serais assez étonné que ça n'arrive pas.
Et j'annonce la bonne nouvelle: systemd sera le système d'init
par défaut dans Jessie.
modulo un GR
et surtout, modulo le point principal, des gens qui font le taf, car c'est bien joli les touchages de nouilles par mail interposés, mais ça va ps faire des patches tout seul.
Et à Canonical: HAHAHAHA!
Ça redonnait de la vigueur à Upstart, donc je vois pas en quoi c'est drole. ( pas beaucoup, pas assez, certes )
On peut imaginer que la clé soit stocké chiffré en ram, et qu'il faille utiliser le mot de passe de l'user pour la déchiffrer, ou ce genre de choses. Ou que le matos apple dépende d'une puce TPM ou autre non accessible directement et pas en ram.
Bon, son dev est un chouia parano cf http://igurublog.wordpress.com/ , lire comment Google prends le contrôle de QT, mais à part ça, y a des gens qui utilisent ?
En effet, j'avais totalement oublié le CLA de Digia. Ceci dit, la différence est aussi dans le logiciel visé, et la licence.
QT est sous LGPL, donc ta principale obligation si tu fait un logiciel proprio serait de distribuer le code de QT ( et c'est grosso modo détaillé sur la page du projet de façon assez clair ).
Tu va devoir aller voir Digia si tu veux modifier QT et ne pas distribuer les sources. Le coeur de métier de Digia étant le consulting, et la vente de service marche mieux quand le logiciel est vivant ( ie, genre quand ça bouge et qu'il faut former sans arrêt les gens, et faire des upgrades de code, et quand le soft est "gros" ), donc ils font tout pour que ça soit le cas ( aka, favoriser l'innovation ).
Unity, Upstart et d'autres sont sous GPL v3, ce qui implique aussi de distribuer le code, mais pas uniquement. Par exemple, ça implique aussi de filer les potentiels clés pour les mises à jours, la fameuse clause anti tivoization. Et je pense que la partie sur les brevets de la GPL v3 rentre dans la même catégorie d'incitation à prendre la version proprio du code.
En effet, un des marchés affichés par Canonical est les OEMs et que ça soit les OEMs de téléphones ou de télé, je pense que la plupart ont des brevets qu'ils utilisent et chérissent (surtout dans le mobile), et qu'ils veulent pas qu'on puissent modifier leur firmware, pour des questions de DRMs, etc.
Donc la ou Digia se sert du CLA de manière sans doute accessoire ( AMHA ), j'ai le sentiment que Canonical se sert des obligations de la GPL v3 de manière bien plus offensive commercialement ce qui est philosophiquement gênant ( du style "filez nous du pognon pour pas avoir à traiter avec les hippies communistes du logiciel libre" ).
Ensuite, oui, le discours flou de Canonical n'aide pas et amplifie beaucoup l'effet, alors que Digia reste très discret et au contraire, à fait preuve d'ouverture en ouvrant plus les choses que depuis l'époque de Trolltech. Et peut être que Digia fait plein de pognon grâce au CLA et mon analyse est fausse concernant Canonical.
Ils le font peut être évolués au fur et à mesure. Ils veulent peut être continuer à le vendre sous license proprio, ce qu'ils ne pourraient faire qu'avec un CLA à la Canonical ( et on a vu comment Canonical se fait descendre pour faire exactement ça ).
Peut être que le moteur dépend de logiciels ou ils ne peuvent pas filer le code ( genre, bundle avec leur offre sous windows ). Peut être qu'ils ont signés des NDAs avec nvidia/amd.
Y a des milliers de raisons de pas réussir à le libérer, en dehors de pas vouloir. Mais bien sur, peut être qu'ils s'en foutent, je dit pas non plus.
L'idée d'utiliser un signal, c'est bien pour signaler que le processus est prêt. SI on le fait sans vraiment savoir ( iequand on a lancé mais qu'on a pas vraiment vérifié ), on reviens à ce que ferait un gestionnaire de processus sans notification.
Le coup de ne pouvoir surveiller que son fils, c'est sans
utiliser les cgroup, hors, systemd l'utilise justement.
Je suis pas spécialiste des cgroups, mais waitid ( qui est utilisé par upstart pour choper l'état d'un fils ) n'est pas lié avec les cgroups. La façon dont systemd utilise les cgroups, c'est juste pour grouper les process et les limiter. Et il se sert du second pour la répartition des ressources, et du premier comme un liste de soft à tuer avec une boucle. Les primitives unix ne permettent pas autre chose, sauf erreur de ma part ( ie, surveiller un processus arbitraire, sauf via ptrace, ce qui pose un autre type de souci, et ptrace qui est utilisé justement aussi par upstart, avec aussi une implémentation avec un certain nombre de souci dans son design )
Et même, pourquoi n'exec-t-il pas erl ?
ça oui, c'est la solution théorique, et je suis d'accord qu'idéalement, c'est ce qu'il faut faire. Ensuite, il y a la pratique, et dans la pratique, il y a des options pour que ça n'arrive pas ( dans le cas de.
Bon, il a peut-être des raisons, et le coup du SIGSTOP peut
effectivement sembler bidouille dans ce cas.
Et c'est le souci. Le SIGSTOP semble séduisant pour un daemon simple, mais pour un daemon simple, il y a pas de souci.
Et ça deviens compliqué assez vite pour les programmes non triviaux, programmes non triviaux qui justement bénéficient d'autant plus de la notification car ils font plein de choses avant d'être prêt.
L'avantage du protocole de systemd, c'est qu'il est transparent si c'est fait comme il faut. sd_notify est une non opération si il n'est pas lancé avec les variables qui vont bien. Donc pas de souci de doc, pas d'interférence avec un usage ( bien que ça soit un souci d'ordre très théorique, j'ai passé du temps à voir en pratique ce qui l'utilise chez debian et j'ai trouvé surtout des softs pour utilisateur plus que système, donc le souci est pas non plus trés bloquant, on peut reconnaitre ça )
Bah, l'implémentation d'upstrart est pourrie, et ?
et ça fait 5 ans qu'elle est pourrie. Que dire de plus à part que visiblement, personne n'a revu le truc dans le détail ?
Sinon je peux continuer pour te dire pourquoi le protocole est pourri et pas juste l'implémentation. Prends par exemple un soft comme couchdb en erlang. Comme c'est de l'erlang, il faut lancer via erl avec souvent un script bash qui va mettre divers variables, etc. Du coup, comme un processus ne peut surveiller que son fils, il se passe quoi dans le cas d'un soft comme le dit couchdb qui fait pas forcément un exec à la fin ( ie, le cas très précis de couchdb avec l'option pour relancer automatiquement le soft quand il se gauffre, cf /usr/bin/couchdb ) ?
Soit le script fait le SIGSTOP mais il va faire ça avant que couchdb soit prêt, soit erl le fait, mais personne ne va le surveiller.
On peut tenter le coup aussi avec un soft qui lance 2 softs ( genre miredo-client, qui va se relancer avec moins de priviléges ). Celui qui est surveiller (le premier) est pas celui qui fait le taf (le 2eme).
Et on peut généraliser le cas avec apache, php-fpm. Du coup, le code passe de "je fait raise(sigstop) + un if" à "je mets en place un canal de comm entre le fils et moi pour que le fils me signal son état, et que moi ensuite je fasse un SIGSTOP pour signaler à mon propre père.
Avec le protocole de systemd, on se contente juste de passer la variable et le file descriptor. Le travail est beaucoup plus simple. Et point bonus, tu peux faire plus que juste dire "je suis prêt".
alors toi tu n'as pas du faire beaucoup d'empaquetage de
logiciels.
Je ne suis pas sur qu'il soit sage d'user d'un argument de ce genre sans avoir fait un minimum de vérification et vérifier avant de supposer. ( mais je reconnais que depuis que j'utilise que mon pseudo sur linuxfr, c'est beaucoup plus dur de vérifier qui je suis quand on n'a pas plus de choses pour une recherche google ). mais je te laisse le soin de vérifier quand je te dit que ça doit bien faire 10 ans que je fait des paquets rpms, que j'ai codé sur des softs comme rpmlint, que j'ai participé à divers distros voir forké une distro et bosser sur la mise en place de son systéme de build entre autres choses.
Quand tu fais réellement de l'intégration, ajouter une
dépendance n'est pas du tout anodin.
Si il y a que ça, tu peux aussi prendre les fichiers .c et .h prévu pour ça depuis le code de systemd. Moi, je trouve ça dégeu, mais si upstream insiste à pas rajouter de lien, c'est son code.
Aprés, je dit pas que c'est insurmontable, mais c'est ajouter
des milliers de fois
une charge qui pourrait être évitée (enfin, très réduite) si
systemd l'implémentait.
Encore une fois, il y a 2 logiciels dans tout debian qui supporte le dit protocole. Donc il faudrait :
1) rajouter le dit protocole dans systemd de façon correcte ( ce qui est déjà pas le cas chez upstart )
2) rajouter le support sur les milliers de paquets en question 3) patcher la documentation des milliers de paquets.
Et bien sur, résoudre les cas épineux tels que j'ai énoncé ( et sans trop me forcer )
Ensuite, c'est pas comme si Debian avait déjà fait des milliers de patchs pour tout un tas de trucs ( GFDL et la DGSF, le portage sur le Hurd, le portage pour kfreebsd ). C'est pas comme si les packageurs de Fedora ou d'autres distros doivent régulièrement faire des patchs pour tel nouvelle version de gcc ou tel options de gcc, tel lib qui a été mise à jours et qui changent 2/3 trucs.
Enfin, je continue à dire qu'il n'y a pas vraiment besoin de rajouter de protocole de notification pour la plupart des softs. Il y a plus d’intérêt à faire du on-demand avec les sockets par exemple.
il ignore l'utilisation de SIGSTOP seulement si un
flag/variable d'environnement est mis, dit que ça peut être
utilisé pour autre chose, mais là c'est dans le cas où le
process l'utilise sur lui-même
Elle relance le process tout le temps. Donc SIGSTOP ne marche plus. Tu noteras que visiblement, il n'y a pas de vérification de l'endroit d'ou viens le signal, vu que ça utilise waitid (cf le code de libnih) qui reçoit juste l'état. Donc si j'envoie un signal SIGSTOP, il est ignoré.
et introduire une dépendance à sa lib (il doit s'en foutre du
boulot de mise à jour de tous les paquets, même les plus
vieux/exotiques/etc…), …
Les logiciels marchent sans avoir besoin de signaler leur "readyness", le fait que personne ou presque n'implémente le protocole d'upstart est la preuve. Et rajouter l'appel en question , c'est surtout du taf sur les autootools que sur le code, c'est pas vraiment le plus compliqué.
Et j'ai bien regardé, j'ai trouvé 2 softs qui utilisent le dit protocole. openssh et xorg. Et c'est des patchs de Canonical dans les 2 cas. Pour un truc qui date de 2008, on peut pas dire que les foules se jettent dessus.
Je pense que logind va être difficile à éviter, vu que ça remplace consolekit.
Et je pense que l'argument de Lennart sur "la gestion des cgroups doit être dans le pid 1 si le pid 1 utilise les cgroups" me semble assez logique. Et la méthode de gestion des processus de upstart ( soit pas de fork, soit avec l'envoie de SIGSTOP, soit avec ptrace, ie 2 hacks fragiles et un truc potable mais pas complet ) ne me semble pas fiable par rapport à l'usage des cgroups pour les cas complexes.
Et comme Lennart le dit sur son g+ ( https://plus.google.com/+LennartPoetteringTheOneAndOnly/posts/ip8e1DqJdxT ), upstart n'utilise même pas son propre paradigme correctement pour les systèmes de fichiers, et n'a pas énormément bougé depuis 4 ans ( et c'est vrai que upstart a l'air de moins bouger que systemd :
et surtout que c'est reparti entre 2012 et 2013, curieusement quand systemd a commencé à prendre la place de upstart un peu partout ( y a 2/3 ans chez Fedora, et un peu partout ailleurs après ).
[^] # Re: NIH ?
Posté par Misc (site web personnel) . En réponse au journal Ubuntu passera lui aussi sur systemd. Évalué à 10.
Le NIH s'applique peut être à SysVinit et pas à systemd :p
Mais je ne pense pas que ça soit la raison principale en effet de garder Upstart. Ce qu'on voit, c'est que si Debian passe à systemd (et donc fait le taf d'intégration), alors Ubuntu va suivre. Sans ça, ça aurait du être le taf d'Ubuntu, et je pense que Canonical n'avait juste pas les moyens humains de faire ça alors qu'ils ont des projets à finir.
Ça reviens à une bête question de ressource. Et le fait d'avoir des bugs non corrigés depuis longtemps dans Upstart, d'avoir finalement peu de code poussés dedans ne sont que d'autres symptômes d'une même cause.
En attendant que la QA de Debian (et de RHEL 7) fasse le taf, Ubuntu a tout à gagner.
[^] # Re: En fait la discussion continue
Posté par Misc (site web personnel) . En réponse au journal Debian rejoint les utilisateurs de Systemd. Évalué à 5.
Alors en fait, j'ai cherché ( car oui, je ne discute pas sans recherche minimum ), et j'ai trouvé divers choses.
Alors il y a virt-sandbox-service, qui est un wrapper entre libvirt et systemd. La dépendance est à la fois assez faiable ( car ça fait des unités systemd, rien de complexe à refaire sous upstart ) mais elle existe.
Ensuite, j'ai trouvé cockpit :
http://liquidat.wordpress.com/2014/02/11/first-look-at-cockpit-a-web-based-server-management-interface/
En fait, je savais même pas que c'était fortement lié à systemd avant de regarder en détail.
Tu as aussi des trucs comme fleet ( https://github.com/coreos/fleet ) du projet coreos, qui permet d'avoir un systemd sur le réseau ( ie, activation à la volée, ce genre de choses ).
Ou netctl :
https://github.com/joukewitteveen/netctl
Et je pense qu'à terme, tu va avoir kde/gnome qui vont utiliser logind, qui s'appuie sur la gestion de cgroups de systemd.
Donc oui, la question est pas que théorique.
[^] # Re: je suis le seul ou quoi ?
Posté par Misc (site web personnel) . En réponse au journal Debian rejoint les utilisateurs de Systemd. Évalué à 10.
Je pense qu'il y a surtout une question de marketing. IE, quand tout le monde a migré vers upstart, personne n'a rien dit parce qu'on a pas mis ça en avant, et parce que personne n'a eu le style de Lennart pour dire "les trucs sont de la merde, le mien est bien".
Quand Apple change un truc, ils vont le vendre bien, donc les gens acceptent. Lennart, lui, il compte juste sur la qualité du produit, et visiblement, ça ne suffit pas à réduire les peurs des gens. Il faut ensuite rajouter les pseudos experts qui postent pour dire "si systemd crash, l'os crash" pour avoir un panic.
Aucun n'a vérifié ce qui se passe, personne n'a lu le code pour voir qu'en pratique, systemd ne fait pas paniquer le kernel.
Voir http://cgit.freedesktop.org/systemd/systemd/tree/src/core/main.c#n115 ( le code est la depuis 2010 ).
Donc oui, si systemd crash, il ne réponds plus, mais la machine tourne encore, les processes aussi, vu que systemd tourne en boucle en faisant "pause" pour éviter le kernel panic. Donc au final, ça reviens à être bien moins catastrophique. Et pour être franc, je me demande si il n'est pas possible de relancer automatiquement systemd pour plus de HA. ( le code n'est pas la, mais je ne sais pas si on peut le rajouter facilement et de façon robuste ).
[^] # Re: je suis le seul ou quoi ?
Posté par Misc (site web personnel) . En réponse au journal Debian rejoint les utilisateurs de Systemd. Évalué à 4.
Curieusement, je pense que les divers études de cas qu'on trouve ici (
http://searchdatacenter.techtarget.com/Unix-to-Linux-migration-advice-and-case-studies )
( ou sur les sites de RH, de Suse et ailleurs ).
Ou alors juste sur les rapports de IDC, ou Unix représente 16% du marché, et est prévu pour chuter à 9% ( http://www.networkworld.com/news/2013/081913-unix-272728.html ). L'article explique aussi que les déploiements de db sur linux ou windows dépassent ceux sur unix. Si c'est pas de la prod, je ne suis pas vraiment sur de savoir ce que c'est.
[^] # Re: je suis le seul ou quoi ?
Posté par Misc (site web personnel) . En réponse au journal Debian rejoint les utilisateurs de Systemd. Évalué à 4.
Digital et Compaq ont disparu et leur unix de même, SCO/Caldera aussi. Je sais même pas ce que Xenix est devenu, et Irix existe plus que dans Jurassic park ( dans le film, pas dans le sens ou c'est un dinosaure ).
HP-UX, AIX et Solaris sont encore la en effet, et je dirais bien que seul Solaris arrive à faire des trucs, poussé par Oracle, mais IBM dégraisse, HP aussi, et Sun s'est cassé la gueule pour se faire racheter par Oracle.
[^] # Re: je suis le seul ou quoi ?
Posté par Misc (site web personnel) . En réponse au journal Debian rejoint les utilisateurs de Systemd. Évalué à 9.
ça fait bien longtemps que ça s'éloigne d'Unix. C'est même la raison de son succés, pas de procés au cul par AT&T.
Mais il faut bien voir une chose. Les Unix ont pour la plupart disparus. Et si il suffisait de suivre leur philosophie pour survivre et avoir du succès, debian kfreebsd serait pas à que dalle en terme d'usage, et l'Unix-like avec le plus de succès serait pas originaire de Cupertino.
Tu peux dire ce que tu veux sur les principes d'Unix, mais visiblement, ils ont pas l'air de passionner les foules ni d'être une raison de choisir cette famille d'OS. ( et faut pas me dire "oui, mais le marketin de blabla", si le marketing de tout les OS plus récents est meilleur, c'est bien la lose d'être la avant et de se faire battre )
Mais je suis sur que Freebsd sera ravi d'avoir ton aide avec tes 18 ans d'xp, car il me semble évident que tu va faire quelque chose, pas juste attendre, n'est ce pas ?
[^] # Re: En fait la discussion continue
Posté par Misc (site web personnel) . En réponse au journal Debian rejoint les utilisateurs de Systemd. Évalué à 1.
Ce qui est amusant, c'est qu'est ce que tu fait si le projet upstream dépend d'un init spécial ?
La question de gnome/kde qui pourraient avoir besoin de logind est pertinente, mais il n'y a pas de réponses. Soit tu vires les paquets, soit tu fait un bug upstream ou tu patches. mais si tu patches, et que upstream n'approuve pas, il se passe quoi ?
Et si tu laisses les gens dépendre 'un init, tu va dire quoi quand quelqu'un va dire "ok, je fait que upstart, et je teste qu'avec ça" ( ou systemd )
[^] # Re: En fait la discussion continue
Posté par Misc (site web personnel) . En réponse au journal Debian rejoint les utilisateurs de Systemd. Évalué à 2.
Non, je crois plus en le fait que dire "on va mettre ça par défaut" n'implique pas que les mainteneurs trouvent le temps de tout corriger/adapter et tout faire. Enfin je pense surtout à l'équiep d-i qui est chroniquement débordé, et je ne sais pas si il y a beaucoup à corriger/adapter, mais j'exclue pas la possibilité que ça soit le cas.
De surcroit, systemd bouge quand même pas mal, et l'équipe d'anaconda a passé pas mal de temps sur ça.
Quand à une fronde des mainteneurs, non. Mais il y a eu plusieurs personnes annonçant leur intention de faire une GR de façon publique, donc je serais assez étonné que ça n'arrive pas.
Et malgré un GR, je peux imaginer avoir un sous groupe faire preuve de mauvaise volonté, et bon, vu la réaction de Ian Jackson ( https://lists.debian.org/debian-ctte/2014/02/msg00344.html ), suivi de Steve Langasek ( https://lists.debian.org/debian-ctte/2014/02/msg00366.html )
Et même si Steve prends des vacances ( https://lists.debian.org/debian-ctte/2014/02/msg00359.html ), il va juste revenir encore plus en pétard.
[^] # Re: En fait la discussion continue
Posté par Misc (site web personnel) . En réponse au journal Debian rejoint les utilisateurs de Systemd. Évalué à 2.
modulo un GR
et surtout, modulo le point principal, des gens qui font le taf, car c'est bien joli les touchages de nouilles par mail interposés, mais ça va ps faire des patches tout seul.
Ça redonnait de la vigueur à Upstart, donc je vois pas en quoi c'est drole. ( pas beaucoup, pas assez, certes )
[^] # Re: Scientific Linux envisage de devenir une variante de CentOS
Posté par Misc (site web personnel) . En réponse au journal Centos devient un project Red Hat. Évalué à 4.
C'est le cas en centos 7, oui.
[^] # Re: Pour Android, c'est normal
Posté par Misc (site web personnel) . En réponse au journal L'apocalypse arrive. Évalué à 4.
Lors du CCC, c'était aussi le cas ( juste pour info ).
Donc ça fait 2 fois en 2 mois que j'ai le souci :)
( du coup, j'ai presque envie de faire ça chez moi )
[^] # Re: Pari
Posté par Misc (site web personnel) . En réponse au journal Debian à l'heure du choix. Évalué à 4.
Il dit qu'il a plus de genoux
[^] # Re: quand y en a plus, y en a encore
Posté par Misc (site web personnel) . En réponse à la dépêche 1er week-end de février, en Belgique, au FOSDEM. Évalué à 2.
devconf.cz est à partir de vendredi, bien que je ne doute pas que le jeudi voit le début des premières réunions dans les bars de Brno.
[^] # Re: Punaise
Posté par Misc (site web personnel) . En réponse au journal Toi aussi, amuses toi avec le FireWire. Évalué à 2.
On peut imaginer que la clé soit stocké chiffré en ram, et qu'il faille utiliser le mot de passe de l'user pour la déchiffrer, ou ce genre de choses. Ou que le matos apple dépende d'une puce TPM ou autre non accessible directement et pas en ram.
# Et space-fm ?
Posté par Misc (site web personnel) . En réponse au journal Quand le vaisseau tombe à l'eau, il faut trouver le poisson. Évalué à 5.
Il me semble que ça peut plaire à des gens
http://ignorantguru.github.io/spacefm/screenshots.html
Bon, son dev est un chouia parano cf http://igurublog.wordpress.com/ , lire comment Google prends le contrôle de QT, mais à part ça, y a des gens qui utilisent ?
[^] # Re: Punaise
Posté par Misc (site web personnel) . En réponse au journal Toi aussi, amuses toi avec le FireWire. Évalué à 2.
Non, je crois qu'Apple désactive le transfert en DMA quand tu utilises filevault.
Et j'ai tenté de trouver les cables kivonbien mais sans grand succès pour vérifier, ça a l'air d'être le merdier.
[^] # Re: Commentaire et questions
Posté par Misc (site web personnel) . En réponse au journal DD & Valve. Évalué à 5.
En effet, j'avais totalement oublié le CLA de Digia. Ceci dit, la différence est aussi dans le logiciel visé, et la licence.
QT est sous LGPL, donc ta principale obligation si tu fait un logiciel proprio serait de distribuer le code de QT ( et c'est grosso modo détaillé sur la page du projet de façon assez clair ).
Tu va devoir aller voir Digia si tu veux modifier QT et ne pas distribuer les sources. Le coeur de métier de Digia étant le consulting, et la vente de service marche mieux quand le logiciel est vivant ( ie, genre quand ça bouge et qu'il faut former sans arrêt les gens, et faire des upgrades de code, et quand le soft est "gros" ), donc ils font tout pour que ça soit le cas ( aka, favoriser l'innovation ).
Unity, Upstart et d'autres sont sous GPL v3, ce qui implique aussi de distribuer le code, mais pas uniquement. Par exemple, ça implique aussi de filer les potentiels clés pour les mises à jours, la fameuse clause anti tivoization. Et je pense que la partie sur les brevets de la GPL v3 rentre dans la même catégorie d'incitation à prendre la version proprio du code.
En effet, un des marchés affichés par Canonical est les OEMs et que ça soit les OEMs de téléphones ou de télé, je pense que la plupart ont des brevets qu'ils utilisent et chérissent (surtout dans le mobile), et qu'ils veulent pas qu'on puissent modifier leur firmware, pour des questions de DRMs, etc.
Donc la ou Digia se sert du CLA de manière sans doute accessoire ( AMHA ), j'ai le sentiment que Canonical se sert des obligations de la GPL v3 de manière bien plus offensive commercialement ce qui est philosophiquement gênant ( du style "filez nous du pognon pour pas avoir à traiter avec les hippies communistes du logiciel libre" ).
Ensuite, oui, le discours flou de Canonical n'aide pas et amplifie beaucoup l'effet, alors que Digia reste très discret et au contraire, à fait preuve d'ouverture en ouvrant plus les choses que depuis l'époque de Trolltech. Et peut être que Digia fait plein de pognon grâce au CLA et mon analyse est fausse concernant Canonical.
[^] # Re: Commentaire et questions
Posté par Misc (site web personnel) . En réponse au journal DD & Valve. Évalué à 3.
Ils le font peut être évolués au fur et à mesure. Ils veulent peut être continuer à le vendre sous license proprio, ce qu'ils ne pourraient faire qu'avec un CLA à la Canonical ( et on a vu comment Canonical se fait descendre pour faire exactement ça ).
Peut être que le moteur dépend de logiciels ou ils ne peuvent pas filer le code ( genre, bundle avec leur offre sous windows ). Peut être qu'ils ont signés des NDAs avec nvidia/amd.
Y a des milliers de raisons de pas réussir à le libérer, en dehors de pas vouloir. Mais bien sur, peut être qu'ils s'en foutent, je dit pas non plus.
[^] # Re: Est-ce que Valve est sponsorisée par un concurrent à Debian ?
Posté par Misc (site web personnel) . En réponse au journal DD & Valve. Évalué à 6.
Ma foi, avec les 235 personnes qui ont signés la pétition il y a 2 ans ( https://www.change.org/petitions/lennart-poettering-stop-writing-useless-programs-systemd-journal ), il y a sans doute moyen d'avoir assez d'argent pour payer la même chose.
Et si tu rajoutes les dizaines de millions d'autres qui sont contre, il y a sans doute moyen d'avoir au moins 100€ de plus.
[^] # Re: Mini précision, variable d'environnement
Posté par Misc (site web personnel) . En réponse au journal Des nouvelles de Debian et de systemd. Évalué à 6. Dernière modification le 24 janvier 2014 à 01:10.
L'idée d'utiliser un signal, c'est bien pour signaler que le processus est prêt. SI on le fait sans vraiment savoir ( iequand on a lancé mais qu'on a pas vraiment vérifié ), on reviens à ce que ferait un gestionnaire de processus sans notification.
Je suis pas spécialiste des cgroups, mais waitid ( qui est utilisé par upstart pour choper l'état d'un fils ) n'est pas lié avec les cgroups. La façon dont systemd utilise les cgroups, c'est juste pour grouper les process et les limiter. Et il se sert du second pour la répartition des ressources, et du premier comme un liste de soft à tuer avec une boucle. Les primitives unix ne permettent pas autre chose, sauf erreur de ma part ( ie, surveiller un processus arbitraire, sauf via ptrace, ce qui pose un autre type de souci, et ptrace qui est utilisé justement aussi par upstart, avec aussi une implémentation avec un certain nombre de souci dans son design )
ça oui, c'est la solution théorique, et je suis d'accord qu'idéalement, c'est ce qu'il faut faire. Ensuite, il y a la pratique, et dans la pratique, il y a des options pour que ça n'arrive pas ( dans le cas de.
Et c'est le souci. Le SIGSTOP semble séduisant pour un daemon simple, mais pour un daemon simple, il y a pas de souci.
Et ça deviens compliqué assez vite pour les programmes non triviaux, programmes non triviaux qui justement bénéficient d'autant plus de la notification car ils font plein de choses avant d'être prêt.
L'avantage du protocole de systemd, c'est qu'il est transparent si c'est fait comme il faut. sd_notify est une non opération si il n'est pas lancé avec les variables qui vont bien. Donc pas de souci de doc, pas d'interférence avec un usage ( bien que ça soit un souci d'ordre très théorique, j'ai passé du temps à voir en pratique ce qui l'utilise chez debian et j'ai trouvé surtout des softs pour utilisateur plus que système, donc le souci est pas non plus trés bloquant, on peut reconnaitre ça )
[^] # Re: Mini précision, variable d'environnement
Posté par Misc (site web personnel) . En réponse au journal Des nouvelles de Debian et de systemd. Évalué à 10.
et ça fait 5 ans qu'elle est pourrie. Que dire de plus à part que visiblement, personne n'a revu le truc dans le détail ?
Sinon je peux continuer pour te dire pourquoi le protocole est pourri et pas juste l'implémentation. Prends par exemple un soft comme couchdb en erlang. Comme c'est de l'erlang, il faut lancer via erl avec souvent un script bash qui va mettre divers variables, etc. Du coup, comme un processus ne peut surveiller que son fils, il se passe quoi dans le cas d'un soft comme le dit couchdb qui fait pas forcément un exec à la fin ( ie, le cas très précis de couchdb avec l'option pour relancer automatiquement le soft quand il se gauffre, cf /usr/bin/couchdb ) ?
Soit le script fait le SIGSTOP mais il va faire ça avant que couchdb soit prêt, soit erl le fait, mais personne ne va le surveiller.
On peut tenter le coup aussi avec un soft qui lance 2 softs ( genre miredo-client, qui va se relancer avec moins de priviléges ). Celui qui est surveiller (le premier) est pas celui qui fait le taf (le 2eme).
Et on peut généraliser le cas avec apache, php-fpm. Du coup, le code passe de "je fait raise(sigstop) + un if" à "je mets en place un canal de comm entre le fils et moi pour que le fils me signal son état, et que moi ensuite je fasse un SIGSTOP pour signaler à mon propre père.
Avec le protocole de systemd, on se contente juste de passer la variable et le file descriptor. Le travail est beaucoup plus simple. Et point bonus, tu peux faire plus que juste dire "je suis prêt".
Je ne suis pas sur qu'il soit sage d'user d'un argument de ce genre sans avoir fait un minimum de vérification et vérifier avant de supposer. ( mais je reconnais que depuis que j'utilise que mon pseudo sur linuxfr, c'est beaucoup plus dur de vérifier qui je suis quand on n'a pas plus de choses pour une recherche google ). mais je te laisse le soin de vérifier quand je te dit que ça doit bien faire 10 ans que je fait des paquets rpms, que j'ai codé sur des softs comme rpmlint, que j'ai participé à divers distros voir forké une distro et bosser sur la mise en place de son systéme de build entre autres choses.
Si il y a que ça, tu peux aussi prendre les fichiers .c et .h prévu pour ça depuis le code de systemd. Moi, je trouve ça dégeu, mais si upstream insiste à pas rajouter de lien, c'est son code.
Encore une fois, il y a 2 logiciels dans tout debian qui supporte le dit protocole. Donc il faudrait :
1) rajouter le dit protocole dans systemd de façon correcte ( ce qui est déjà pas le cas chez upstart )
2) rajouter le support sur les milliers de paquets en question 3) patcher la documentation des milliers de paquets.
Et bien sur, résoudre les cas épineux tels que j'ai énoncé ( et sans trop me forcer )
Ensuite, c'est pas comme si Debian avait déjà fait des milliers de patchs pour tout un tas de trucs ( GFDL et la DGSF, le portage sur le Hurd, le portage pour kfreebsd ). C'est pas comme si les packageurs de Fedora ou d'autres distros doivent régulièrement faire des patchs pour tel nouvelle version de gcc ou tel options de gcc, tel lib qui a été mise à jours et qui changent 2/3 trucs.
Enfin, je continue à dire qu'il n'y a pas vraiment besoin de rajouter de protocole de notification pour la plupart des softs. Il y a plus d’intérêt à faire du on-demand avec les sockets par exemple.
[^] # Re: Mini précision, variable d'environnement
Posté par Misc (site web personnel) . En réponse au journal Des nouvelles de Debian et de systemd. Évalué à 5.
L'implémentation d'upstart a un souci :
https://bazaar.launchpad.net/~ubuntu-branches/ubuntu/trusty/upstart/trusty/view/head:/init/job_process.c#L1482
Elle relance le process tout le temps. Donc SIGSTOP ne marche plus. Tu noteras que visiblement, il n'y a pas de vérification de l'endroit d'ou viens le signal, vu que ça utilise waitid (cf le code de libnih) qui reçoit juste l'état. Donc si j'envoie un signal SIGSTOP, il est ignoré.
Les logiciels marchent sans avoir besoin de signaler leur "readyness", le fait que personne ou presque n'implémente le protocole d'upstart est la preuve. Et rajouter l'appel en question , c'est surtout du taf sur les autootools que sur le code, c'est pas vraiment le plus compliqué.
Et j'ai bien regardé, j'ai trouvé 2 softs qui utilisent le dit protocole. openssh et xorg. Et c'est des patchs de Canonical dans les 2 cas. Pour un truc qui date de 2008, on peut pas dire que les foules se jettent dessus.
[^] # Re: Et maintenant ?
Posté par Misc (site web personnel) . En réponse au journal Des nouvelles de Debian et de systemd. Évalué à 1.
Ah merde, ça m'a semblé tellement logique d'avoir un nombre impair :/
[^] # Re: Et maintenant ?
Posté par Misc (site web personnel) . En réponse au journal Des nouvelles de Debian et de systemd. Évalué à 4.
Il reste encore une personne. Et bon, une fois que le tech-ctte dit un truc, faut juste attendre que quelqu'un fasse le boulot.
Il serait amusant que ça soit upstart, ne serais que pour continuer à troller :p
[^] # Re: Et pour une poignée de liens en plus
Posté par Misc (site web personnel) . En réponse au journal Des nouvelles de Debian et de systemd. Évalué à 8.
Je pense que logind va être difficile à éviter, vu que ça remplace consolekit.
Et je pense que l'argument de Lennart sur "la gestion des cgroups doit être dans le pid 1 si le pid 1 utilise les cgroups" me semble assez logique. Et la méthode de gestion des processus de upstart ( soit pas de fork, soit avec l'envoie de SIGSTOP, soit avec ptrace, ie 2 hacks fragiles et un truc potable mais pas complet ) ne me semble pas fiable par rapport à l'usage des cgroups pour les cas complexes.
Et comme Lennart le dit sur son g+ ( https://plus.google.com/+LennartPoetteringTheOneAndOnly/posts/ip8e1DqJdxT ), upstart n'utilise même pas son propre paradigme correctement pour les systèmes de fichiers, et n'a pas énormément bougé depuis 4 ans ( et c'est vrai que upstart a l'air de moins bouger que systemd :
https://www.ohloh.net/p/systemd
vs
https://www.ohloh.net/p/upstart
et surtout que c'est reparti entre 2012 et 2013, curieusement quand systemd a commencé à prendre la place de upstart un peu partout ( y a 2/3 ans chez Fedora, et un peu partout ailleurs après ).