Plus je relit ce que tu demandes, plus ça me semble embrouillé, mais ça doit être moi. Tu parles d'inittab et tu dis que c'est normal que systemd supporte ça alors qu'on parle de multiseat. Bien que ça soit exact, c'est pas exactement la même chose. Si je te dit "gdm supporte le multiseat, tu peux aller sur le terminal avec ctl alt f1", tu va pas être d'accord. Donc gardons le multiseat à la définition communément prise pour gdm, à savoir avoir 2 fois le matos ( 2 cartes graphiques, 2 moniteurs, 2 claviers, 2 souris )
Le souci principal pour gdm, c'est pas de pas supporté d'être lancé 2 fois ( comme j'ai dit, gdmflexiserver montre bien que c'est faisable, ne serais ce que via le flag -n ). Le souci, c'est pas de lancer xorg 2 fois ( pareil, c'est trivial à faire à la main, je viens de le refaire ). Le souci, c'est "je branche une clé usb, qui va la voir sur son bureau".
Lancer xorg avec une config spécifique ( genre qui pointe sur l'adaptateur pci de la carte ), ça se fait. Lancer gdm en lui faisant croire qu'il est dans Xnest, ça se fait aussi. ( ou même sans ça, lancer 2 fois gdm avec un prefix différent ) C'est d'ailleurs le premier lien. Voir mieux, lancer xorg sur un periph usb, ça se fait ( http://0pointer.de/blog/projects/multi-seat )
La ou ça devient touchy, c'est le partage de la puce 3d. Sauf que sauf erreur de ma part, ça n'a rien a voir avec le multiseat tel que la plupart des gens l'entendent, vu que l'idée, c'est d'avoir 2 claviers, 2 souris, 2 écrans. La, tu es dans le même cas que quelqu'un avec une carte nvidia optimus, avec 2 puces. Sauf erreur de ma part, c'est pas très bien supporté pour le moment.
Donc la solution serait de gérer le client local comme si c'était un client distant. Ie, d'avoir un xorg dédié à faire tourner virtualgl ( pas besoin de gdm pour ça, vu que personne ne se connecte en local dessus ), et de faire tourner gdm sur l'autre puce, et d'utiliser un client ( par exemple vnc ) pour lancer les applis comme si c'était un thin client.
Et si par exemple c'était dans la partie "Development Topics" slides 31 à 37 qui liste les limitations, les
améliorations et les éléments qui sont en cours d'études et de développement, il se passerait quoi ?
la même chose, à savoir que tu piges de travers l'anglais comme ça t'arrange, et que tu t'arrêtes juste à ce que tu crois être vrai ( comme montré par les autres trucs que j'ai posté )
Ben justement non j'en ai aucun.
Alors pour quoi tu nous prends pour des truffes en disant :
"il me semble que les distributions serveurs (comme Suse Entreprise ou Red Hat) envisagent très sérieusement de ne PAS passer à systemd"
Que ce soit chez Suse ou chez Red Hat ca joue à ni oui ni non. Même le support
(payant) RH est pas foutu de répondre à la question "dans RH7 ca sera systemd ou sysinit ou les deux".
Le support ne parle jamais des produits en cours de développement, et c'est pareil dans toutes les boites que j'ai fait, on laisse la relation client aux commerciaux ( ensuite, peut être que tu as bossé dans des boites différentes ). Bien que je ne soit pas juriste, je pense qu'il y a des gens qui craignent que ce genre de réponse soit "legally binding", et que ces gens sont plus juristes que toi et moi.
Le fait que ArchLinux et Mageia ait fait le pas en tant que distrib ne prouve rien au niveau de
l'utilisabilité du bigniou par des sysadmins.
Je suis sysadmin, c'est marqué sur mon contrat de travail et j'ai un serveur face à moi qui tourne avec systemd ( en mageia 2 ). Techniquement, je peux te sortir d'autres sysadmins, d'autres serveurs, ce qui fait qu'on pourras passer au pluriel.
Mais c'est sans doute pas assez rigoureux comme preuve, y a sans doute des tests pour dire "la, il arrive à s'en servir".
Le fait que Solaris soit passé à smf est la preuve qu'on peut survivre à un changement de système d'init.
Bug 774126 : si on se logue trop tôt sur une interface série le getty crashe définitivement. Il existe une
solution mais elle est trop complexe pour être backportée
Si on se logue trop tôt et qu'on utilise NIS. Et comme tu dit, c'est corrigé dans une nouvelle version systemd. Quand à backporter la feature, c'est sans doute parce que la politique est la même qu'ailleurs, à savoir juste les bugfixes, pas les features. Et la, c'est une feature ( à savoir un type de service "idle" )
Bug 779434 : pas de splash dans le boot kernel, pas de /var. Systemd refuse de monter le /var si plymouthd a un
fichier de lock qui traine dessus. COOOL
Tu as lu de travers. C'est plus "si quelqu'un a encore un file handle ouvert, alors on peut pas démonter le fs". Ce qui est le comportement standard de sysvinit et de tout les autres. Et d'après le bug, c'est plymouthd qui bloque.
Bug 780006 : Un boot pas à pas dans systemd ? Vous plaisantez bien sur. De..bug ? Jamais entendu parlé.
Un boot pas à pas dans un système prévu pour lancer les choses en même temps est ma foi un concept des plus intéressant. Pour débugguer ce genre de souci, il y a plusieurs façon. Tu peux utiliser le système de bootchart ( histoire d'avoir un graph détaillé ), tu peux avoir le graph des dépendances. En pratique, le mode pas à pas, ça va rarement servir à débloquer des soucis autre que "tel soft ne se lance pas, il faut que je le passe".
Mais le bug parle de systemd.confirm_spawn, qui va faire grosso modo la même chose que "press I for interactive mode" du boot classique d'un RH. Ensuite, visiblement, il y a un certain nombre de bugs corrigés upstream, et je ne doute pas que Frederic va tester et backporter si besoin.
Bug 780441 : L'automount NFS ne marche pas (pas chez Fedora non plus) - mais on a presque fini d'avoir une bonne
idée sur comment contourner le problème. (N.B : ce bug a une priorité P5 - none. Autmount NFS ? Ca interresse
quelqu'un ? )
C'est pas un souci de systemd, c'est un souci de nfs sur Suse, et Fedora 18 propose les unités pour nfs. Au passage, ça marche sans souci avec automount sur Mageia.
Bug 767394 : Un disque plein ? C'est un scandale ! Je me casse… (signé systemd).
Je ne peux que redire "si c'est marqué systemd quelque part, ça veut pas dire que c'est un souci de systemd". En l'occurrence, quelqu'un a rempli le systéme monté en ramfs sur un livecd ( donc avec aufs ). Donc l'oom killer a fini par tuer tout les process, en terminant par le pid 1. Comme dit dans le bug report, tu t'attends à quoi ? La backtrace est une backtrace kernel, le message est "kernel panic".
Donc sur les 5 bugs que tu donnes, il y a :
1 bug qui n'est pas un bug systemd mais le comportement normal du kernel
1 bug qui vient du script d'init nfs et d'un mauvais ordre pour les divers choses à lancer
1 bug ou la feature existe, mais possède des bugs corrigés dans la versions récentes de systemd
1 bug ou systemd se comporte comme les init classiques, due à un bug plymouthd
1 bug corrigé dans les versions récentes de systemd pour les gens qui utilisent nis, un port série et qui veulent pas attendre
Donc je compte 2 bugs déjà corrigés, 2 bug à corriger ailleurs ( nfs, plymouthd ), et 1 "why did you expect".
Ok respect, ça rends le produit totalement inutilisable d'avoir 2 bugs que le dev d'opensuse n'a pas eu le temps de backporter. En aucun cas ça va être prêt pour une release qui n'est pas encore annoncé, et en aucun cas ça va marcher sur tout les autres cas ( genre ceux ou tu as pas des ports séries avec du nis )
Je terminerais sur tes 3 boites avec sysadmins ( un échantillon donc statistiquement représentatif, et bien sur, aucunement influencé par toi, surtout au vue de ta propension à sortir des trucs crédibles sauf quand on creuse plus de 30 secondes ) et donc :
a) Il y a beaucoup de boulot et de tests à faire pour s'assurer que tout fonctionne.
Comme avec chaque version majeur. Est ce qu'ils ont eu des tonnes de boulot avec upstart sur les RHEL 6 ? J'ai loupé les émeutes qu'il y a du y avoir à ce sujet mais bon, c'est la même chose non ?
Sinon, quand tu payes la souscription RHEL ou SLES, c'est aussi pour que le distributeur fasse les tests ( sauf bien sur pour les horreurs homegrowns dont tu as parlé la dernière fois ).
b) Certaines choses (certains fs chiffrés, demande de mot de passe à l'init par service, templates etc.) ne sont
pas possible avec systemd.
En effet, c'est à dessein pour certains. Le mot de passe à l'init, une riche idée quand le systéme est sequentielle car ton serveur se bloque en attendant de rentrer le mot de passe, c'est pas du tout fragile au possible. Je pense au passage que c'était pas possible non plus avec upstart qui dans mon souvenir lance les trucs en parallèle. Quand aux templates, j'ai deja du dire que ç'est prévu par systemd, et la dernière fois, tu as sorti un exemple super compliqué pour dire "regarde, dans ce cas totalement trop compliqué, je sais pas comment faire mais j'ai pas le droit d'en dire plus, donc ça invalide tout"
c) Systemd n'est pas fini/normalisé et du coup même si ils trouvent des parades aujourd'hui
rien ne prouve qu'elles seront encore valables dans dix jours (spéciale dédicace udev)
Formidable ça. Parce que upstart ou l'init classique sysinit, c'était normalisé ? Le seule chose vraie qu'on peut dire, c'est que sysvinit était "fini" dans le sens ou il y avait plus d'évolution dessus. Normalisé, systemd suit la LSB, donc les scripts d'init doivent marcher encore. Bie sur, tu va trouver sans doute des cas de scripts hors lsb qui ne marche pas, et dire "bah ça marche pas".
Y en a qui ont plus ? Ou moins ? ( je doit reconnaitre que je me suis jamais posé la question )
Enfin l'idée est surtout qu'il y a un ordre de magnitude moins d'avis à donner sur /. que sur linuxfr, au moins pour moi. Genre 5 pour 2 semaines vs 100 /j. Même si quelqu'un a que 10 point, ça fait beaucoup plus.
Ensuite, peut être qu'on peut parler du 99% de gens qui n'ont pas le karma requis pour vivre au dessus du seuil de pauvreté karmique, mais bon…
Je pense que ta maitrise de l'anglais doit te jouer des tours, car "Red Hat Enterprise Linux Roadmap: Part 1", ça ne se traduit pas vraiment pas "truc qu'on envisage". Si c'était "stuff that we are looking at", ou une expression similaire, ouais, peut être.
Pour les non initiés aux rpms, ça définit une variable "with_systemd" qui est utilisé par la suite dans le fichier pour savoir si on embarque un fichier .service ou un script d'init. Notons l'idiome "si la valeur de la variable fedora est supérieur ou égale" à 16, suivi de "ou si la variable rhel est supérieur ou égale à 7", laissant supposer que pour une fedora supérieur à 16 ou une rhel supérieur à 7, systemd serait utilisé ( je laisse le reste du fichier spec à titre d'exercice ).
Sachant que le fichier spec est celui utilisé par le projet openshift, projet lancé par RH, et que les commits sont fait par des gens de la boite, on peut donc supposer qu'ils ont fait des déductions un chouia plus éclairé que les tiennes, basés sur des informations un chouia mieux sourcés ( au moins concernant le produit de leur employeur ).
La, on voit une construction un chouia plus complexe avec le contre intuitif bcond_without ( qui rajoute l'option pour désactiver une option, donc qui l'active par défaut ), et le fait qu'il y a aussi des unités systemd prévu dans un paquet pour RHEL 7.
Je pourrais sans doute continuer pendant des heures, mais je vais pas m'acharner sur le sujet, je suis sur que tu as des tas d'arguments et de témoignage de gens qui sont super proche du pdg de RH qui ont dit "faut pas mettre systemd, kaane m'a dit que ça pue".
Sinon, tu noteras en pratique que ni Suse, ni Red Hat ne communique pour le moment sur la sortie des produits tout court, ou sur aucune feature. Red Hat en a parlé lors de sa conférence annuelle, et Suse a du faire pareil et basta.
Est ce que ça veut dire qu'ils vont abandonner toutes les fonctionnalités du monde ? Non, je crois pas.
La ou tu vois une défiance envers systemd ( ie, la ou tu interprète les faits pour ne pas remettre en cause ta vision myopique de la chose ), je vois juste du bon sens de ne pas faire de foin sur un version de leurs distributions qui ne sont pas encore fini.
Suse a visiblement un cycle de 3 ans, mais on peut supposer que le rachat et la réorganisation de Novell par Attachmate a pu fortement perturbé ça, ce qui laisse encore du temps pour une release en 2013. ( mais bien sur, tu peux sans doute continuer à croire que systemd a totalement tout mis en l'air, et que même si Arch et Mageia ont fait la migration avec 3 bouts de ficelle sans soucis majeurs, c'est impossible que des boites avec plus de moyens fassent de même )
Ah, on me dit dans l'oreille que c'est pas parce qu'il y a marqué systemd dans un rapport de bug que c'est un bug sur systemd et que ta liste est utilisé juste pour du FUD. Dommage, presque crédible.
C'est ce que fait slashdot. Si tu participes aux commentaires d'un article, toute la modération s'efface. mais tu as aussi 5 votes de temps en temps, et pas 100 par jours comme ici.
Dans ce cas, ça va juste être remplacé par un "chut" moins cordiale et moins silencieux. Je doute que ça améliore l'ambiance. Ensuite, j'aurais tendance à dire qu'il suffit juste de pas dire n'importe quoi pour pas finir à 0. C'est pas si dur vu que plein de gens y arrivent. S'en foutre de la note, c'est pas mal aussi comme façon de vivre sa vie sans souci.
( je l'utilise sur un script maison qui dumpe les offres de jobs, ça marche assez bien et je trouve ça drole de faire un select sur du csv, mais je précise que bien sur c'est pas une solution entreprise ready, ça supporte pas encore xquery )
C'est un peu expliqué dans le lien donné par le journal, sinon un moteur de recherche doit pouvoir te redonner les raisons.
Globalement, il y a des raisons techniques de complexité des algos pour la recherche, le stockage, etc, le fait de pouvoir avoir des indexes, etc. Par exemple, si tu veux pouvoir donner accès que à certaines metadonnées, avoir un format binaire sera plus rapide qu'une regexp pour trier tout ça ( et c'est sans doute la raison de la présence de plugin de log dans mysql/postgresql pour rsyslog ). Dans systemd, les infos affichés par systemctl status sont obtenus par le journal, et je pense qu'il est important d'avoir un accés indexé aux infos ( et pas relire les megaoctets de logs pour afficher les infos )
Ensuite, il y a le fait de vouloir pouvoir avoir du binaire dans les logs ( dump en cas d'erreur etc, etc ).
Il y a aussi des discussions sur http://lwn.net/Articles/468381/ , mais bon, vu qu'il suffit d'avoir rsyslog pour avoir les logs au format texte, j'ai du mal à voir le souci pour les gens.
Au vue de la discussion sur comment faire les choses au mieux pour l'intégration de systemd et nfsutils https://bugzilla.redhat.com/show_bug.cgi?id=699040 , je pense que tu as du tombé sur un bug dans les fichiers service.
Donc n'hésite pas à ouvrir un bug report.
Pour ton premier exemple, je pense que tu peux juste déclencher une action "bloquer le lid switch" via dbus quand tu as du courant ( en écoutant upower ou le demon kivabien en fonction du bureau ) et en envoyant via dbus un inhibitor kivabien sur logind : http://www.freedesktop.org/wiki/Software/systemd/inhibit
Et je pense qu'on manque d'un framework haut niveau pour dbus, surtout vu l'importance que ça prends. Quelque chose du style du shell, ou tu peux réagir à des events, et en déclencher d'autres via des pipes.
J'aime bien les théories du complot, mais j'ai pris gout à des théories plus sophistiqués et qui tiennent pas avec des bouts de ficelles et ou on voit en 3 lignes le truc, donc tu m'excuseras de faire 2/3 remarques sur tes croyances.
Que Redhat a tout intérêt a contrôler cette brique de base du système, oui!
L'init classique des distros rpms, tu crois que ça venait d'ou ?
Le paquet initscript de mandriva, c'etait un fork de celui de fedora….
Au passage, je te ferait remarquer la présence de la dite société dans
Que Redhat ne voit pas d'inconvenient a en faire une dependence de plein d'autres projets, les rendent doucement
Linux-only, oui!
Plein ? Pour le moment, c'est la gestion de l’énergie dans gnome.
Les gens réclament des interfaces freedesktop, mais c'est exactement de ça qu'il s'agit, à savoir d'une interface freedesktop , celle de logind pour remplacer l'interface via consolekit, qui n'était pas portable sur netbsd ou openbsd, ou windows, ou le hurd, donc la portabilité était déjà absente. Ou celle via upower, qui devait être sans doute aussi trés linux only. J'ai vérifié, y a grosso modo 10 000 lignes de code C dans systemd-logind. Pour comparaison, telepathy-gabble (qui traine à coté sur mon disque ) fait 99 000 lignes de code.
De ce que je voit, le but est d'avoir un démon qui gère "je suis connecté, j'ai besoin de bloquer le suspend". Rien de transcendantalement complexe à refaire.
Que Redhat trouve très bien que les projects "concurrents" perdent du temps a redevelopper des dependences/libs
pour remplacer systemd au lieu d'investir du temps et de l'argent sur autre chose, oui!
Systemd est :
- en GPL/MIT
- avec le code source dispo
- avec de la doc ( en plus du code ) sur l'interface utilisé
- développé de manière ouverte
Ça ne prone pas en faveur d'une tentative de maximiser le temps perdu pour les autres projets.
En fait, c'est la le noeud de la théorie. Si les gens utilisent systemd, alors ç'est en faveur de RH car d'aprés toi, ça donne du controle, donc RH devrait tout faire tout pour. Mais si les gens passent du temps à éviter systemd et à la refaire, alors c'est selon toi aussi en la faveur de la boite car ils perdent du temps.
Mais attends, y a mieux. RH pourrait prendre le code d'un concurrent ( genre celui d'upstart ) et le mettre dans son produit, comme ça, la charge de maintenance est pas pour eux, et donc ils y gagnent sur le long terme.
OU RH pourrait garder du vieux code, comme ça, ils peuvent vendre du support sur un truc qui ne bouge pas, donc les couts sont réduits, donc ils y gagnent.
En fait, pousser systemd partout, pousser systemd juste sur Fedora, garder init, pousser upstart, dans tout les cas, on peut trouver un moyen de dire que RH va y gagner. À partir de la, si pour tout X, Y est vrai, est ce qu'on peut pas simplement déduire qu'il y a pas de relation de cause à effet entre X et Y ?
Y a un agent dans gnome, un dans gnome-shell, un pour kde. Par agent d'authentification, faut comprendre "popup qui demande le mot de passe", y a rien de compliqué.
Moi sur une Fedora, j'ai un rpm polkit-gnome, mais il y a aussi polkit-kde, polkit-qt, lxpolkit pour que le look and feel colle.
C'est quoi ça, taper Ctrl + Alt + Fx pour aller sur une autre console et se loguer en tant que quelqu'un d'autre ?
Le bouton "changer d'utilisateur" dans gnome/kde ou autre, qui va verrouiller ta session, couper la musique et s'assurer que l'autre personne puisse accéder aux clés usb en local pendant que tu es pas en face, entre autre. une feature que windows xp propose depuis le début, au passage.
Et tu connais des administrateurs qui utilisent ces possibilités ?
template issue de la config puppet du projet mageia, pour dire "tel personnes dans tel groupe ldap ont le droit de lancer virt-manager pour couper les bécanes ou de les relancer sans avoir les droits root". S
inon, tu as aussi des gens qui laissent les utilisateurs faire les updates sans mot de passes via packagekit ( sauf erreur de ma part, c'est le cas au boulot même si j'ai pas la bécane sous la main pour vérifier ).
En general, la configuration du réseau va aussi dans le systéme d'init, tout comme le chargement des modules, l'application des sysctl, etc, etc. Le réseau est pas unifié sous systemd, mais le reste l'est déja plus, et ça, ça aide pour les ISVs a mon avis. Et les admins. Même si une distro n'est pas d'accord avec systemd, reprendre les interfaces, ça peut faire un pas en avant vers moins de différences gratuites.
D'avoir quelqu'un qui maintient, et pas juste quelqu'un qui fait de la compilation. Si tu regardes bien, Linuxmint ne fait pas de mises à jours de sécurité autre que celle de Canonical, et ils savent pas coder propre ( CVE-2012-1566 comme je le dit si souvent ).
On parle pas des fondements d'unix, on parle du système d'init qui est moisi car justement, on estime que sa seule fonction et interface, c'est de lancer le soft et advienne que pourra. On a donc rajouter par dessus un système de scripts qui fait une chose , copier celui du voisin avec divers variations, et ça donne les soucis que j'ai listé.
Et c'est bien parce que init ne fait qu'une chose, à savoir lancer un programme qui va lancer des scripts qui va lancer d'autres scripts que c'est le merdier.
Systemd a une autre approche, ou on considère que le boot, c'est un ensemble d'unité qui doit être lancé et orchestré pour avoir un système qui marche. Ou on se dit que monter un fs, c'est autant un truc de boot que de lancer sympa ( dont le script lance 4 demons à la suite par exemple ).
Ça remets en cause ta vision des idées d'unix, sans doute. Mais ça corrige les problèmes que tu as nié, et c'est pas négligeable.
Être en userland, ça rends pas les choses portables par magie. Il est ou le port BSD de iptables, ou le port linux de la commande jail ?
Systemd utilise des APis propre à linux ( comme les cgroups, udev, mais encore d'autres comme l'api pour charger des modules, selinux ( de façon optionnel ), le systeme de namespace de linux et divers API, une liste avait été posté ). Il est donc aussi dépendant de linux que shorewall ou NetworkManager puisse l'être.
Sauf que dans le cas de nm, personne ne se précipite pour faire le taf ( curieusement ) alors que le dev accepte les patchs. Donc oui, râler sur "on refuse les patchs", c'est joli. Mais en pratique, personne ne fait le taf quand même. Autant arrêter l'hypocrisie. Sans cgroups, systemd ne marche pas. Donc y a aucun sens à faire le portage tant que ça manque sur les autres noyaux.
Excuse moi, mais ça fait 40 ans maintenant que UNIX et Linux gère naturellement et sans aucun problème ses daemons !
Dit pas de la merde. La gestion des daemons, c'est pas "sans aucun problème". J'ai donné 15 fois les exemples, mais je vais les redonner, même si je sais que ça va pas rentrer.
Tu prends apache, qui va forker une paire de fois avant de lancer un cgi ( donc un autre process ) en perl qui va lancer encore des softs ( genre imagemagick ) en tache de fond. Si le cgi claque, tu va perdre la trace du process qui va devenir un zombie. C'est pas ce que j'appelle sans souci.
Tu prends bind, qui s'éteint de façon asynchrone, et qui requiert de rajouter sleep dans restart ( et donc interdit de faire "stop"/"start" en shell ). C'est pas sans souci.
Tu prends un soft mal codé ( genre sympa qui attends que pgsql soit up avant de continuer ) ou malconfiguré ( genre mcollective avec daemonize = 0 qui du coup passe pas en background et qui bloque le boot de ta bécane ). C'est pas sans souci.
Tout ça, c'est des exemples que j'ai vu il y a moins de 3 ans sur des distros modernes sur des serveurs en production. Et en pratique, quand tu regardes le code des softs, tu vois que personne ne sait exactement comment lancer un daemon proprement ( genre, aller sur /, faire un double fork, écrire le pid, se détacher du terminal, etc ), donc forcément, des softs qui font de la merde, y en a des tonnes, et à moins d'avoir vécu sur un igloo loin du monde réel ou isolé du travail au jour le jour sur une distro, tu peux pas dire "ça marche depuis 40 ans" et garder ta crédibilité.
Ça fait 40 ans que le système d'init est écrit dans un langage ( le shell, pas le bash ) sans espace de nommage, sans tests, sans gestion avancé des chaines, sans tableau, sans gestion du parallélisme, ou le fait de lire un fichier requiert de faire un fork/exec. C'est des bouts de ficelles. Apple a refait le système d'init. Solaris l'a refait. Ubuntu l'a refait. Gentoo l'a refait. Personne ne se dit vraiment "y a une raison" ?
inetd, ça reste une blague. Tu veux sans doute dire "xinetd", déjà, et sauf erreur de ma part, xinetd gère pas les sockets unix ( exemple cups, exemple mysql, exemple ldap pour ne citer que 3 qui me viennent à l'esprit ).
Euh non, ça veut pas dire qu'on a toujours besoin. Le mot clé noauto, il est pas la pour faire joli et n'avoir aucun effet. Il y a quand même une époque ou il fallait monter à la main les cdroms et les disquettes, et c'était dans /etc/fstab.
Les plus chanceux pouvait passer par un patch kernel ( genre automount, mis dans le kernel mandrake ), ou via autofs. D'ailleurs, c'est encore dans la config par défaut d'autofs.
Et donc, la solution est de garder la compatibilité avec l'ancien systéme ( en l'occurence consolekit ) car 1) ça pue pas 2) ça peut encore évoluer vers un nouveau paradigme ?
Ce qui est bien, c'est que quand systemd fait trop de choses, ça pue, et quand ça en fait pas assez et ça prends pas en compte des concepts non définis et non existants pour le moment, ça pue quand même. Donc tout le monde est d'accord pour dire qu'il y a un juste milieu, sauf que personne ne le code ou ne l'explicite ( voir même ne le défend, car la, c'est "on pourrait trouver des exemples", mais pas besoin d'en donner, ni même de faire remarquer qu'on peut toujours rajouter une API autre par la suite si besoin )
Quel pourcentage d'utilisateurs font du multiseat par rapport à quel pourcentage de temps ils vont devoir consacrer à
cette fonctionnalité ?
En fait, c'est plus "combien de personnes qui demandent ça sur linuxfr vont consacrer du temps à faire du code ou contribuer". Et qu'on me dise pas "ça prends du temps". Oui, ça prends du temps, mais si les gens veulent pas le prendre, faut pas râler si d'autres ( en l'occurrence les devs upstreams ) font le même choix.
[^] # Re: C'est mort
Posté par Misc (site web personnel) . En réponse au journal GNOME systemd : et la guerre ne fait que commencer. Évalué à 2.
Plus je relit ce que tu demandes, plus ça me semble embrouillé, mais ça doit être moi. Tu parles d'inittab et tu dis que c'est normal que systemd supporte ça alors qu'on parle de multiseat. Bien que ça soit exact, c'est pas exactement la même chose. Si je te dit "gdm supporte le multiseat, tu peux aller sur le terminal avec ctl alt f1", tu va pas être d'accord. Donc gardons le multiseat à la définition communément prise pour gdm, à savoir avoir 2 fois le matos ( 2 cartes graphiques, 2 moniteurs, 2 claviers, 2 souris )
Le souci principal pour gdm, c'est pas de pas supporté d'être lancé 2 fois ( comme j'ai dit, gdmflexiserver montre bien que c'est faisable, ne serais ce que via le flag -n ). Le souci, c'est pas de lancer xorg 2 fois ( pareil, c'est trivial à faire à la main, je viens de le refaire ). Le souci, c'est "je branche une clé usb, qui va la voir sur son bureau".
Lancer xorg avec une config spécifique ( genre qui pointe sur l'adaptateur pci de la carte ), ça se fait. Lancer gdm en lui faisant croire qu'il est dans Xnest, ça se fait aussi. ( ou même sans ça, lancer 2 fois gdm avec un prefix différent ) C'est d'ailleurs le premier lien. Voir mieux, lancer xorg sur un periph usb, ça se fait ( http://0pointer.de/blog/projects/multi-seat )
La ou ça devient touchy, c'est le partage de la puce 3d. Sauf que sauf erreur de ma part, ça n'a rien a voir avec le multiseat tel que la plupart des gens l'entendent, vu que l'idée, c'est d'avoir 2 claviers, 2 souris, 2 écrans. La, tu es dans le même cas que quelqu'un avec une carte nvidia optimus, avec 2 puces. Sauf erreur de ma part, c'est pas très bien supporté pour le moment.
Donc la solution serait de gérer le client local comme si c'était un client distant. Ie, d'avoir un xorg dédié à faire tourner virtualgl ( pas besoin de gdm pour ça, vu que personne ne se connecte en local dessus ), et de faire tourner gdm sur l'autre puce, et d'utiliser un client ( par exemple vnc ) pour lancer les applis comme si c'était un thin client.
Mais je suppose que ça réponds pas à ton besoin ?
[^] # Re: Pourquoi du binaire
Posté par Misc (site web personnel) . En réponse au journal Documentation du format du Journal. Évalué à 8.
la même chose, à savoir que tu piges de travers l'anglais comme ça t'arrange, et que tu t'arrêtes juste à ce que tu crois être vrai ( comme montré par les autres trucs que j'ai posté )
Alors pour quoi tu nous prends pour des truffes en disant :
"il me semble que les distributions serveurs (comme Suse Entreprise ou Red Hat) envisagent très sérieusement de ne PAS passer à systemd"
Le support ne parle jamais des produits en cours de développement, et c'est pareil dans toutes les boites que j'ai fait, on laisse la relation client aux commerciaux ( ensuite, peut être que tu as bossé dans des boites différentes ). Bien que je ne soit pas juriste, je pense qu'il y a des gens qui craignent que ce genre de réponse soit "legally binding", et que ces gens sont plus juristes que toi et moi.
Je suis sysadmin, c'est marqué sur mon contrat de travail et j'ai un serveur face à moi qui tourne avec systemd ( en mageia 2 ). Techniquement, je peux te sortir d'autres sysadmins, d'autres serveurs, ce qui fait qu'on pourras passer au pluriel.
Mais c'est sans doute pas assez rigoureux comme preuve, y a sans doute des tests pour dire "la, il arrive à s'en servir".
Le fait que Solaris soit passé à smf est la preuve qu'on peut survivre à un changement de système d'init.
Si on se logue trop tôt et qu'on utilise NIS. Et comme tu dit, c'est corrigé dans une nouvelle version systemd. Quand à backporter la feature, c'est sans doute parce que la politique est la même qu'ailleurs, à savoir juste les bugfixes, pas les features. Et la, c'est une feature ( à savoir un type de service "idle" )
Tu as lu de travers. C'est plus "si quelqu'un a encore un file handle ouvert, alors on peut pas démonter le fs". Ce qui est le comportement standard de sysvinit et de tout les autres. Et d'après le bug, c'est plymouthd qui bloque.
Un boot pas à pas dans un système prévu pour lancer les choses en même temps est ma foi un concept des plus intéressant. Pour débugguer ce genre de souci, il y a plusieurs façon. Tu peux utiliser le système de bootchart ( histoire d'avoir un graph détaillé ), tu peux avoir le graph des dépendances. En pratique, le mode pas à pas, ça va rarement servir à débloquer des soucis autre que "tel soft ne se lance pas, il faut que je le passe".
Mais le bug parle de systemd.confirm_spawn, qui va faire grosso modo la même chose que "press I for interactive mode" du boot classique d'un RH. Ensuite, visiblement, il y a un certain nombre de bugs corrigés upstream, et je ne doute pas que Frederic va tester et backporter si besoin.
C'est pas un souci de systemd, c'est un souci de nfs sur Suse, et Fedora 18 propose les unités pour nfs. Au passage, ça marche sans souci avec automount sur Mageia.
Je ne peux que redire "si c'est marqué systemd quelque part, ça veut pas dire que c'est un souci de systemd". En l'occurrence, quelqu'un a rempli le systéme monté en ramfs sur un livecd ( donc avec aufs ). Donc l'oom killer a fini par tuer tout les process, en terminant par le pid 1. Comme dit dans le bug report, tu t'attends à quoi ? La backtrace est une backtrace kernel, le message est "kernel panic".
Donc sur les 5 bugs que tu donnes, il y a :
1 bug qui n'est pas un bug systemd mais le comportement normal du kernel
1 bug qui vient du script d'init nfs et d'un mauvais ordre pour les divers choses à lancer
1 bug ou la feature existe, mais possède des bugs corrigés dans la versions récentes de systemd
1 bug ou systemd se comporte comme les init classiques, due à un bug plymouthd
1 bug corrigé dans les versions récentes de systemd pour les gens qui utilisent nis, un port série et qui veulent pas attendre
Donc je compte 2 bugs déjà corrigés, 2 bug à corriger ailleurs ( nfs, plymouthd ), et 1 "why did you expect".
Ok respect, ça rends le produit totalement inutilisable d'avoir 2 bugs que le dev d'opensuse n'a pas eu le temps de backporter. En aucun cas ça va être prêt pour une release qui n'est pas encore annoncé, et en aucun cas ça va marcher sur tout les autres cas ( genre ceux ou tu as pas des ports séries avec du nis )
Je terminerais sur tes 3 boites avec sysadmins ( un échantillon donc statistiquement représentatif, et bien sur, aucunement influencé par toi, surtout au vue de ta propension à sortir des trucs crédibles sauf quand on creuse plus de 30 secondes ) et donc :
Comme avec chaque version majeur. Est ce qu'ils ont eu des tonnes de boulot avec upstart sur les RHEL 6 ? J'ai loupé les émeutes qu'il y a du y avoir à ce sujet mais bon, c'est la même chose non ?
Sinon, quand tu payes la souscription RHEL ou SLES, c'est aussi pour que le distributeur fasse les tests ( sauf bien sur pour les horreurs homegrowns dont tu as parlé la dernière fois ).
En effet, c'est à dessein pour certains. Le mot de passe à l'init, une riche idée quand le systéme est sequentielle car ton serveur se bloque en attendant de rentrer le mot de passe, c'est pas du tout fragile au possible. Je pense au passage que c'était pas possible non plus avec upstart qui dans mon souvenir lance les trucs en parallèle. Quand aux templates, j'ai deja du dire que ç'est prévu par systemd, et la dernière fois, tu as sorti un exemple super compliqué pour dire "regarde, dans ce cas totalement trop compliqué, je sais pas comment faire mais j'ai pas le droit d'en dire plus, donc ça invalide tout"
Formidable ça. Parce que upstart ou l'init classique sysinit, c'était normalisé ? Le seule chose vraie qu'on peut dire, c'est que sysvinit était "fini" dans le sens ou il y avait plus d'évolution dessus. Normalisé, systemd suit la LSB, donc les scripts d'init doivent marcher encore. Bie sur, tu va trouver sans doute des cas de scripts hors lsb qui ne marche pas, et dire "bah ça marche pas".
[^] # Re: Autre idée
Posté par Misc (site web personnel) . En réponse au journal Rendre publics les votes sur les commentaires. Évalué à 3.
Y en a qui ont plus ? Ou moins ? ( je doit reconnaitre que je me suis jamais posé la question )
Enfin l'idée est surtout qu'il y a un ordre de magnitude moins d'avis à donner sur /. que sur linuxfr, au moins pour moi. Genre 5 pour 2 semaines vs 100 /j. Même si quelqu'un a que 10 point, ça fait beaucoup plus.
Ensuite, peut être qu'on peut parler du 99% de gens qui n'ont pas le karma requis pour vivre au dessus du seuil de pauvreté karmique, mais bon…
[^] # Re: Pourquoi du binaire
Posté par Misc (site web personnel) . En réponse au journal Documentation du format du Journal. Évalué à 10.
Je pense que ta maitrise de l'anglais doit te jouer des tours, car "Red Hat Enterprise Linux Roadmap: Part 1", ça ne se traduit pas vraiment pas "truc qu'on envisage". Si c'était "stuff that we are looking at", ou une expression similaire, ouais, peut être.
Et donc pour que tout le monde puisse juger de tes sources, j'invite les gens à voir les fameux vagues slides sur :
http://rhsummit.files.wordpress.com/2012/03/burke_rhel_roadmap.pdf , voir la conf sur
http://videos.cdn.redhat.com/2012-summit-bestof-04.ogg , vers la 37eme minute.
Mais j'aurais tendance à dire qu'il y a d'autres choses qui font penser que systemd va se retrouver dans RHEL 7, comme :
https://github.com/openshift/origin-server/blob/master/broker/openshift-origin-broker.spec
Notons les lignes 13 et consorts :
%if 0%{?fedora} >= 16 || 0%{?rhel} >= 7
%define with_systemd 1
%else
%define with_systemd 0
%endif
Pour les non initiés aux rpms, ça définit une variable "with_systemd" qui est utilisé par la suite dans le fichier pour savoir si on embarque un fichier .service ou un script d'init. Notons l'idiome "si la valeur de la variable fedora est supérieur ou égale" à 16, suivi de "ou si la variable rhel est supérieur ou égale à 7", laissant supposer que pour une fedora supérieur à 16 ou une rhel supérieur à 7, systemd serait utilisé ( je laisse le reste du fichier spec à titre d'exercice ).
Sachant que le fichier spec est celui utilisé par le projet openshift, projet lancé par RH, et que les commits sont fait par des gens de la boite, on peut donc supposer qu'ils ont fait des déductions un chouia plus éclairé que les tiennes, basés sur des informations un chouia mieux sourcés ( au moins concernant le produit de leur employeur ).
On peut aussi regarder ailleurs, par exemple, en prenant au hasard des checkouts qui traineraient sur le disque ( ce qui est mon cas ), et tomber sur :
http://pkgs.fedoraproject.org/cgit/abrt.git/tree/abrt.spec
La, on voit une construction un chouia plus complexe avec le contre intuitif bcond_without ( qui rajoute l'option pour désactiver une option, donc qui l'active par défaut ), et le fait qu'il y a aussi des unités systemd prévu dans un paquet pour RHEL 7.
Ou on peut aussi aller en prendre au pif parmi les paquets Fedora maintenus par des gens de RH, comme au hasard, libvirt :
http://pkgs.fedoraproject.org/cgit/libvirt.git/tree/libvirt.spec#n145
Un commentaire court mais sans équivoque.
Je pourrais sans doute continuer pendant des heures, mais je vais pas m'acharner sur le sujet, je suis sur que tu as des tas d'arguments et de témoignage de gens qui sont super proche du pdg de RH qui ont dit "faut pas mettre systemd, kaane m'a dit que ça pue".
Sinon, tu noteras en pratique que ni Suse, ni Red Hat ne communique pour le moment sur la sortie des produits tout court, ou sur aucune feature. Red Hat en a parlé lors de sa conférence annuelle, et Suse a du faire pareil et basta.
Est ce que ça veut dire qu'ils vont abandonner toutes les fonctionnalités du monde ? Non, je crois pas.
La ou tu vois une défiance envers systemd ( ie, la ou tu interprète les faits pour ne pas remettre en cause ta vision myopique de la chose ), je vois juste du bon sens de ne pas faire de foin sur un version de leurs distributions qui ne sont pas encore fini.
Suse a visiblement un cycle de 3 ans, mais on peut supposer que le rachat et la réorganisation de Novell par Attachmate a pu fortement perturbé ça, ce qui laisse encore du temps pour une release en 2013. ( mais bien sur, tu peux sans doute continuer à croire que systemd a totalement tout mis en l'air, et que même si Arch et Mageia ont fait la migration avec 3 bouts de ficelle sans soucis majeurs, c'est impossible que des boites avec plus de moyens fassent de même )
D'ailleurs, quand je vois la page du bugzilla sur le kernel, je me demande si Suse ne va pas abandonner linux, car bon, ça fait peur, y a 200 bugs ouverts :
https://bugzilla.novell.com/buglist.cgi?query_format=specific&order=relevance+desc&bug_status=__open__&product=openSUSE+12.2&content=kernel
Ou lacher yast ( 167 bugs ) :
https://bugzilla.novell.com/buglist.cgi?query_format=specific&order=relevance+desc&bug_status=__open__&product=openSUSE+12.2&content=yast
Ah, on me dit dans l'oreille que c'est pas parce qu'il y a marqué systemd dans un rapport de bug que c'est un bug sur systemd et que ta liste est utilisé juste pour du FUD. Dommage, presque crédible.
[^] # Re: Pourquoi du binaire
Posté par Misc (site web personnel) . En réponse au journal Documentation du format du Journal. Évalué à 6.
On peut, mais par defaut, ça ne le fait pas.
Donc ouais, "on peut coder tel truc", sauf que quand il s'agit de faire autre chose que de poster sur linuxfr, y a plus personne.
[^] # Re: Autre idée
Posté par Misc (site web personnel) . En réponse au journal Rendre publics les votes sur les commentaires. Évalué à 4.
C'est ce que fait slashdot. Si tu participes aux commentaires d'un article, toute la modération s'efface. mais tu as aussi 5 votes de temps en temps, et pas 100 par jours comme ici.
[^] # Re: On est pas a l'ecole
Posté par Misc (site web personnel) . En réponse au journal Rendre publics les votes sur les commentaires. Évalué à 5.
Dans ce cas, ça va juste être remplacé par un "chut" moins cordiale et moins silencieux. Je doute que ça améliore l'ambiance. Ensuite, j'aurais tendance à dire qu'il suffit juste de pas dire n'importe quoi pour pas finir à 0. C'est pas si dur vu que plein de gens y arrivent. S'en foutre de la note, c'est pas mal aussi comme façon de vivre sa vie sans souci.
[^] # Re: Pourquoi du binaire
Posté par Misc (site web personnel) . En réponse au journal Documentation du format du Journal. Évalué à 5.
bah suffit de le faire en perl, ou est le problème :)
http://search.cpan.org/~hmbrand/DBD-CSV-0.36/lib/DBD/CSV.pm
( je l'utilise sur un script maison qui dumpe les offres de jobs, ça marche assez bien et je trouve ça drole de faire un select sur du csv, mais je précise que bien sur c'est pas une solution entreprise ready, ça supporte pas encore xquery )
[^] # Re: Pourquoi du binaire
Posté par Misc (site web personnel) . En réponse au journal Documentation du format du Journal. Évalué à 6.
C'est un peu expliqué dans le lien donné par le journal, sinon un moteur de recherche doit pouvoir te redonner les raisons.
Globalement, il y a des raisons techniques de complexité des algos pour la recherche, le stockage, etc, le fait de pouvoir avoir des indexes, etc. Par exemple, si tu veux pouvoir donner accès que à certaines metadonnées, avoir un format binaire sera plus rapide qu'une regexp pour trier tout ça ( et c'est sans doute la raison de la présence de plugin de log dans mysql/postgresql pour rsyslog ). Dans systemd, les infos affichés par systemctl status sont obtenus par le journal, et je pense qu'il est important d'avoir un accés indexé aux infos ( et pas relire les megaoctets de logs pour afficher les infos )
Ensuite, il y a le fait de vouloir pouvoir avoir du binaire dans les logs ( dump en cas d'erreur etc, etc ).
Il y a aussi des discussions sur http://lwn.net/Articles/468381/ , mais bon, vu qu'il suffit d'avoir rsyslog pour avoir les logs au format texte, j'ai du mal à voir le souci pour les gens.
# Promesse de stabilité
Posté par Misc (site web personnel) . En réponse au journal Documentation du format du Journal. Évalué à 10.
Visiblement, ça a été rajouté :
http://www.freedesktop.org/wiki/Software/systemd/InterfacePortabilityAndStabilityChart
Aussi bien le format binaire que le format d'export.
[^] # Re: C’est pas encore ça…
Posté par Misc (site web personnel) . En réponse au journal GNOME systemd : et la guerre ne fait que commencer. Évalué à 2.
Au vue de la discussion sur comment faire les choses au mieux pour l'intégration de systemd et nfsutils
https://bugzilla.redhat.com/show_bug.cgi?id=699040 , je pense que tu as du tombé sur un bug dans les fichiers service.
Donc n'hésite pas à ouvrir un bug report.
[^] # Re: Le problème…
Posté par Misc (site web personnel) . En réponse au journal GNOME systemd : et la guerre ne fait que commencer. Évalué à 3.
Pour ton premier exemple, je pense que tu peux juste déclencher une action "bloquer le lid switch" via dbus quand tu as du courant ( en écoutant upower ou le demon kivabien en fonction du bureau ) et en envoyant via dbus un inhibitor kivabien sur logind :
http://www.freedesktop.org/wiki/Software/systemd/inhibit
Et je pense qu'on manque d'un framework haut niveau pour dbus, surtout vu l'importance que ça prends. Quelque chose du style du shell, ou tu peux réagir à des events, et en déclencher d'autres via des pipes.
[^] # Re: C'est mort
Posté par Misc (site web personnel) . En réponse au journal GNOME systemd : et la guerre ne fait que commencer. Évalué à 1.
gdmflexiserver marche encore sur ma machine, il te faut quoi de plus pour du multiseat ?
[^] # Re: Alors
Posté par Misc (site web personnel) . En réponse au journal GNOME systemd : et la guerre ne fait que commencer. Évalué à 10.
J'aime bien les théories du complot, mais j'ai pris gout à des théories plus sophistiqués et qui tiennent pas avec des bouts de ficelles et ou on voit en 3 lignes le truc, donc tu m'excuseras de faire 2/3 remarques sur tes croyances.
L'init classique des distros rpms, tu crois que ça venait d'ou ?
Le paquet initscript de mandriva, c'etait un fork de celui de fedora….
Au passage, je te ferait remarquer la présence de la dite société dans
Plein ? Pour le moment, c'est la gestion de l’énergie dans gnome.
Et le mainteneur Solaris explique bien que le code est déjà linux only
https://mail.gnome.org/archives/desktop-devel-list/2012-October/msg00081.html
Les gens réclament des interfaces freedesktop, mais c'est exactement de ça qu'il s'agit, à savoir d'une interface freedesktop , celle de logind pour remplacer l'interface via consolekit, qui n'était pas portable sur netbsd ou openbsd, ou windows, ou le hurd, donc la portabilité était déjà absente. Ou celle via upower, qui devait être sans doute aussi trés linux only. J'ai vérifié, y a grosso modo 10 000 lignes de code C dans systemd-logind. Pour comparaison, telepathy-gabble (qui traine à coté sur mon disque ) fait 99 000 lignes de code.
Alors peut être que les gens voudraient avoir une interface différente, et ça a été discuté sur https://bugzilla.gnome.org/show_bug.cgi?id=680689
De ce que je voit, le but est d'avoir un démon qui gère "je suis connecté, j'ai besoin de bloquer le suspend". Rien de transcendantalement complexe à refaire.
Systemd est :
- en GPL/MIT
- avec le code source dispo
- avec de la doc ( en plus du code ) sur l'interface utilisé
- développé de manière ouverte
Ça ne prone pas en faveur d'une tentative de maximiser le temps perdu pour les autres projets.
En fait, c'est la le noeud de la théorie. Si les gens utilisent systemd, alors ç'est en faveur de RH car d'aprés toi, ça donne du controle, donc RH devrait tout faire tout pour. Mais si les gens passent du temps à éviter systemd et à la refaire, alors c'est selon toi aussi en la faveur de la boite car ils perdent du temps.
Mais attends, y a mieux. RH pourrait prendre le code d'un concurrent ( genre celui d'upstart ) et le mettre dans son produit, comme ça, la charge de maintenance est pas pour eux, et donc ils y gagnent sur le long terme.
OU RH pourrait garder du vieux code, comme ça, ils peuvent vendre du support sur un truc qui ne bouge pas, donc les couts sont réduits, donc ils y gagnent.
En fait, pousser systemd partout, pousser systemd juste sur Fedora, garder init, pousser upstart, dans tout les cas, on peut trouver un moyen de dire que RH va y gagner. À partir de la, si pour tout X, Y est vrai, est ce qu'on peut pas simplement déduire qu'il y a pas de relation de cause à effet entre X et Y ?
[^] # Re: Alors
Posté par Misc (site web personnel) . En réponse au journal GNOME systemd : et la guerre ne fait que commencer. Évalué à 2.
Y a un agent dans gnome, un dans gnome-shell, un pour kde. Par agent d'authentification, faut comprendre "popup qui demande le mot de passe", y a rien de compliqué.
Moi sur une Fedora, j'ai un rpm polkit-gnome, mais il y a aussi polkit-kde, polkit-qt, lxpolkit pour que le look and feel colle.
[^] # Re: Alors
Posté par Misc (site web personnel) . En réponse au journal GNOME systemd : et la guerre ne fait que commencer. Évalué à 4.
Consolekit gère aussi les permissions.
https://wiki.archlinux.org/index.php/ConsoleKit
Le bouton "changer d'utilisateur" dans gnome/kde ou autre, qui va verrouiller ta session, couper la musique et s'assurer que l'autre personne puisse accéder aux clés usb en local pendant que tu es pas en face, entre autre. une feature que windows xp propose depuis le début, au passage.
Moi, et je le prouve :
http://svnweb.mageia.org/adm/puppet/modules/libvirtd/templates/50-template-libvirt-remote-access.pkla?revision=985&view=markup
template issue de la config puppet du projet mageia, pour dire "tel personnes dans tel groupe ldap ont le droit de lancer virt-manager pour couper les bécanes ou de les relancer sans avoir les droits root". S
inon, tu as aussi des gens qui laissent les utilisateurs faire les updates sans mot de passes via packagekit ( sauf erreur de ma part, c'est le cas au boulot même si j'ai pas la bécane sous la main pour vérifier ).
[^] # Re: C'est mort
Posté par Misc (site web personnel) . En réponse au journal GNOME systemd : et la guerre ne fait que commencer. Évalué à 3.
En general, la configuration du réseau va aussi dans le systéme d'init, tout comme le chargement des modules, l'application des sysctl, etc, etc. Le réseau est pas unifié sous systemd, mais le reste l'est déja plus, et ça, ça aide pour les ISVs a mon avis. Et les admins. Même si une distro n'est pas d'accord avec systemd, reprendre les interfaces, ça peut faire un pas en avant vers moins de différences gratuites.
[^] # Re: C'est mort
Posté par Misc (site web personnel) . En réponse au journal GNOME systemd : et la guerre ne fait que commencer. Évalué à 3.
D'avoir quelqu'un qui maintient, et pas juste quelqu'un qui fait de la compilation. Si tu regardes bien, Linuxmint ne fait pas de mises à jours de sécurité autre que celle de Canonical, et ils savent pas coder propre ( CVE-2012-1566 comme je le dit si souvent ).
Et systemd supporte le multiseat : http://www.freedesktop.org/wiki/Software/systemd/multiseat
Tu noteras aussi https://bugzilla.gnome.org/show_bug.cgi?id=655380
[^] # Re: C'est mort
Posté par Misc (site web personnel) . En réponse au journal GNOME systemd : et la guerre ne fait que commencer. Évalué à 9.
On parle pas des fondements d'unix, on parle du système d'init qui est moisi car justement, on estime que sa seule fonction et interface, c'est de lancer le soft et advienne que pourra. On a donc rajouter par dessus un système de scripts qui fait une chose , copier celui du voisin avec divers variations, et ça donne les soucis que j'ai listé.
Et c'est bien parce que init ne fait qu'une chose, à savoir lancer un programme qui va lancer des scripts qui va lancer d'autres scripts que c'est le merdier.
Systemd a une autre approche, ou on considère que le boot, c'est un ensemble d'unité qui doit être lancé et orchestré pour avoir un système qui marche. Ou on se dit que monter un fs, c'est autant un truc de boot que de lancer sympa ( dont le script lance 4 demons à la suite par exemple ).
Ça remets en cause ta vision des idées d'unix, sans doute. Mais ça corrige les problèmes que tu as nié, et c'est pas négligeable.
[^] # Re: Alors
Posté par Misc (site web personnel) . En réponse au journal GNOME systemd : et la guerre ne fait que commencer. Évalué à 10.
Être en userland, ça rends pas les choses portables par magie. Il est ou le port BSD de iptables, ou le port linux de la commande jail ?
Systemd utilise des APis propre à linux ( comme les cgroups, udev, mais encore d'autres comme l'api pour charger des modules, selinux ( de façon optionnel ), le systeme de namespace de linux et divers API, une liste avait été posté ). Il est donc aussi dépendant de linux que shorewall ou NetworkManager puisse l'être.
Sauf que dans le cas de nm, personne ne se précipite pour faire le taf ( curieusement ) alors que le dev accepte les patchs. Donc oui, râler sur "on refuse les patchs", c'est joli. Mais en pratique, personne ne fait le taf quand même. Autant arrêter l'hypocrisie. Sans cgroups, systemd ne marche pas. Donc y a aucun sens à faire le portage tant que ça manque sur les autres noyaux.
[^] # Re: C'est mort
Posté par Misc (site web personnel) . En réponse au journal GNOME systemd : et la guerre ne fait que commencer. Évalué à 10.
Tu prends apache, qui va forker une paire de fois avant de lancer un cgi ( donc un autre process ) en perl qui va lancer encore des softs ( genre imagemagick ) en tache de fond. Si le cgi claque, tu va perdre la trace du process qui va devenir un zombie. C'est pas ce que j'appelle sans souci.
Tu prends bind, qui s'éteint de façon asynchrone, et qui requiert de rajouter sleep dans restart ( et donc interdit de faire "stop"/"start" en shell ). C'est pas sans souci.
Tu prends un soft mal codé ( genre sympa qui attends que pgsql soit up avant de continuer ) ou malconfiguré ( genre mcollective avec daemonize = 0 qui du coup passe pas en background et qui bloque le boot de ta bécane ). C'est pas sans souci.
Tout ça, c'est des exemples que j'ai vu il y a moins de 3 ans sur des distros modernes sur des serveurs en production. Et en pratique, quand tu regardes le code des softs, tu vois que personne ne sait exactement comment lancer un daemon proprement ( genre, aller sur /, faire un double fork, écrire le pid, se détacher du terminal, etc ), donc forcément, des softs qui font de la merde, y en a des tonnes, et à moins d'avoir vécu sur un igloo loin du monde réel ou isolé du travail au jour le jour sur une distro, tu peux pas dire "ça marche depuis 40 ans" et garder ta crédibilité.
Ça fait 40 ans que le système d'init est écrit dans un langage ( le shell, pas le bash ) sans espace de nommage, sans tests, sans gestion avancé des chaines, sans tableau, sans gestion du parallélisme, ou le fait de lire un fichier requiert de faire un fork/exec. C'est des bouts de ficelles. Apple a refait le système d'init. Solaris l'a refait. Ubuntu l'a refait. Gentoo l'a refait. Personne ne se dit vraiment "y a une raison" ?
[^] # Re: C'est mort
Posté par Misc (site web personnel) . En réponse au journal GNOME systemd : et la guerre ne fait que commencer. Évalué à 4.
inetd, ça reste une blague. Tu veux sans doute dire "xinetd", déjà, et sauf erreur de ma part, xinetd gère pas les sockets unix ( exemple cups, exemple mysql, exemple ldap pour ne citer que 3 qui me viennent à l'esprit ).
Tu peux aussi lire http://0pointer.de/blog/projects/inetd.html ou http://0pointer.de/blog/projects/socket-activation.html pour voir ou sont les différences.
[^] # Re: C'est mort
Posté par Misc (site web personnel) . En réponse au journal GNOME systemd : et la guerre ne fait que commencer. Évalué à 6.
Euh non, ça veut pas dire qu'on a toujours besoin. Le mot clé noauto, il est pas la pour faire joli et n'avoir aucun effet. Il y a quand même une époque ou il fallait monter à la main les cdroms et les disquettes, et c'était dans /etc/fstab.
Les plus chanceux pouvait passer par un patch kernel ( genre automount, mis dans le kernel mandrake ), ou via autofs. D'ailleurs, c'est encore dans la config par défaut d'autofs.
[^] # Re: API disponible
Posté par Misc (site web personnel) . En réponse au journal GNOME systemd : et la guerre ne fait que commencer. Évalué à 6.
Et donc, la solution est de garder la compatibilité avec l'ancien systéme ( en l'occurence consolekit ) car 1) ça pue pas 2) ça peut encore évoluer vers un nouveau paradigme ?
Ce qui est bien, c'est que quand systemd fait trop de choses, ça pue, et quand ça en fait pas assez et ça prends pas en compte des concepts non définis et non existants pour le moment, ça pue quand même. Donc tout le monde est d'accord pour dire qu'il y a un juste milieu, sauf que personne ne le code ou ne l'explicite ( voir même ne le défend, car la, c'est "on pourrait trouver des exemples", mais pas besoin d'en donner, ni même de faire remarquer qu'on peut toujours rajouter une API autre par la suite si besoin )
[^] # Re: C'est mort
Posté par Misc (site web personnel) . En réponse au journal GNOME systemd : et la guerre ne fait que commencer. Évalué à 2.
En fait, c'est plus "combien de personnes qui demandent ça sur linuxfr vont consacrer du temps à faire du code ou contribuer". Et qu'on me dise pas "ça prends du temps". Oui, ça prends du temps, mais si les gens veulent pas le prendre, faut pas râler si d'autres ( en l'occurrence les devs upstreams ) font le même choix.