Ma foi, parce que peut être, y a des gens qui veulent avoir une interface graphique capable de gerer le wifi, etc ?
Mais si tu aimes pas nm, tu as connman, tu as wicd, et pareil, ils tournent pas sur les bsd.
Donc à la fin, c'est "est ce que les gens sur un système bsd (autre que celui d'apple) veulent tous gérer le wifi à la mano en cli" ?
Perso, nm marche sur mon portable et me taper wpa_supplicant à la main, ça va 5 minutes ( surtout vu que j'ai besoin d'une authentification à 2 facteurs pour le wifi au travail ), tout comme devoir faire les 3/4 commandes pour un wifi classique, ça me ferait chier ( à commencer par me connecter en root ).
En fait, c'est la même diffrence qu'entre java et python. java, faut rajouter toujours le même boilerplate pour les trucs simple, genre un hello world.
Ou la différence du xml et un DSL parfaitement prévu pour. Si tu commences à faire du copier coller, y a 2 choses :
- tu va jamais avoir besoin de toucher à ça, donc tu gaspilles juste de l'espace et tu rajoutes du bruit, autant faire un système qui retire tout ( ce que gentoo ou plf ont fait, par exemple )
- tu va devoir toucher au code un jour, et la, bah tu as juste des centaines de copies, et tu as fait de la merde
Dans mon souvenir, oui, et c'est Frederic Crozat qui a bossé dessus ( entre autre ). Il y a une page sur l'état sur le wiki : http://en.opensuse.org/SDB:Systemd
Ça fait 20 ans que les BSD et les systèmes Linux existent, et c'est quand la dernière fois qu'il y a eu des gens autour de la table pour discuter de standard communs entre les 2 ?
Quand tu vois que les gens sont pas capable de se mettre d'accord sur les conventions d'appel, sur la présence ou pas de fonction de manipulation de chaines ( strnlen ), sur la version de gcc, ou sur justement les initscripts, et les apis, je vois pas ce que Lennart va changer à ça.
D'ailleurs, la dernière fois qu'il a fait un soft portable ( genre avahi ), y a eu un gsoc pour coder un truc compatible sous une license BSD : http://wiki.freebsd.org/MulticastDNS
Donc oui, ce que les BSDistes veulent, c'est pas du code GPL, c'est des interfaces.
Grande nouvelle, y en a :
En même temps, la discussion, même basé sur des arguments faux, reste pertinente dans le sens ou ça a un rapport avec le sujet. Et le commentaire, même faux, n'est pas inutile car il permet de présenter des contre vérités ce qui permet de les dissiper.
( sinon, pour avoir +10, faut aussi faire des blagues, ça marche bien )
IE, tu peux interagir avec les processes sans souci, le cgroup dans systemd n'est la que pour dire "tel process a lancé ces 15 processes". Ensuite, oui, si tu lances les processes en dehors de systemd, bah, il va rien pouvoir faire. Tout comme si tu lances un soft a la main, l'initscript va sans doute faire de la merde. Ensuite, tu peux utiliser selinux, chroot, lxc pour isoler les processes, mais tu va pas demander quand même à isoler un process mais vouloir que tout le monde puisse y toucher.
je te conseille aussi de lire la doc de systemd sur les montages ( genre, le montage en non auto ), et aussi d'avoir ton vocabulaire au point, tu crées pas une carte réseau, tu crées au mieux une interface réseau ( la carte réseau étant pour moi un objet physique ). Quand à lancer la couche tcp/ip, tu veux sans doute dire "demander un ip" ? ( parce que la couche tcp/ip, elle est déja la, sinon ton vpn tourne sans doute pas ).
Donc si ton souci c'est "j'ai une config trop compliqué pour la config par défaut de network-manager, alors systemd est merdique", j'ai le sentiment que tu confonds un peu tout.
Quand à avoir un script d'init par machine, que dire à part que c'est soit déjà le cas ( si tu veux un truc propre ), soit pas une chose que systemd va changer, car tu peux encore déposer ton script compatible LSB dans /etc/init.d comme avant. La preuve, c'est que tout n'a pas été migré sur une fedora 17.
Enfin, si tu lit la page de man systemd.service, tu verras qu'il y a :
ExecReload=
Commands to execute to trigger a configuration reload in the
service.
Donc tu peux juste lancer le kill -SIGHUP qui va bien, ou lancer apachectl, ou ce que tu veux, pas besoin de rajouter un support dbus totalement fantasmé de ta part.
Et donc, ton histoire de rajouter du boilerplate sachant que systemd est sorti depuis au moins 1 an, tu va sans doute pouvoir trouver du boilerplate et des exceptions pour montrer ce que tu avances ? ( car affirmer, c'est une chose, mais avec des preuves, ça serait sans doute plus crédible, et ça serait pas de trop )
J'aime assez le coté péremptoire de ton commentaire qui fait croire que tu t'y connais sur systemd, suivi par "je n'investirais pas de temps à apprendre systemd". Faut savoir, tu connais systemd sur le bout des doigts pour expliquer comment dbus est obligatoire pour le debug ( ie, tu as eu à débugguer ? ), ou tu n'y connais rien et tu es juste un raleur aigri ?
Je penche pour le second, personnellement, mais je te laisse le bénéfice du doute.
En fait, je penche pour le second parce que tu sembles tourner les choses pour un bon FUD.
"pour avoir les fonctions qu'on a pas pour le moment, faut faire du boulot". En effet c'est logique, si tu veux des trucs qu'un script shell fournit pas, faut le refaire autrement. Mais sinon, les scripts marchent encore. Service marche encore.
Et contrairement à ce que tu crois, y a pas mal de distro qui font plus d’exécution séquentielle. RHEL, ubuntu ont upstart. Mandriva/Mageia a un système qui lance tout en même temps depuis 2006 ( pinit ). Et la plupart font de la gestion automatique de l'ordre via un système de tags LSB.
En fait, tu oublie aussi que les paquets des distros sont migrés, donc le travail de refonte est déjà fait ( comme les migrations à python 3 ou gcc 4, en fait ).
Pour la pérennité, prends au moins des trucs qui ont disparus ( genre oss, genre ipchains ), car selinux est la depuis facile 10 ans, et il n'a pas changé des masses, il a surtout eu des features en plus. Dbus existe depuis au moins 5 ans, et pareil, les changements sont pas révolutionnaires. Certes, hal a disparu.
Et sinon, comme tu avoues bien que faire des scripts d'init, c'est chiant, tu te rends bien compte que tu valides le point de vue des packageurs qui pousse à migrer à systemd ?
D'autre part, RHEL 6 tourne avec upstart, et visiblement, ça n'a pas l'air de déranger grand monde ( vu que personne n'en parle et j'ai pas entendu de grand cri ), et le support de sysV par systemd est au même niveau que celui d'upstart ( ie, ça se lance directement les scripts de /etc/init.d )
Enfin, sachant que oracle avait déjà décidé de prendre son temps pour la certif de RHEL 6 ( http://blog.vishalgupta.com/2011/09/19/oracle-11gr2-on-rhel6/ ), donc j'ai l'impression qu'une version d'oracle non supporté sur RHEL est un événement déjà arrivé.
Moi, quand je relit ton histoire, je vois juste un client qui collabore avec son fournisseur sur un produit pas encore sorti, et ça me semble relativement positif comme façon de faire. Et à te lire, tu en reviendrais presque à le regretter, voir à imaginer des luttes de pouvoir qui n'existent pas. On pourrais même croire que tu sous entends que RH ne va pas pousser les bugfixes upstream, ou qu'il y a pas moyen de supporter proprement les scripts shell avec autre chose que sysV ( voir même que tes scripts magiques feraient des trucs si magiques que ça marcherais pas )
Tu serais pas un peu aigri et totalement subjectif ?
Selon toi, le plus gros problème de systemd, c'est que les gens jugent pas le soft mais l'idée qu'ils se font d'un des auteurs sur la base d'extrait de discussions qu'ils ont pas suivi, mais dont il garde une sous partie qui leur semble choquante, c'est ça ?
Perso, je dirais pas que c'est un problème de systemd, plus un problème de gens.
Encore une fois, les technos linux only et bsd only abondent depuis des années. Samba utilise sendfile sur linux et pas sur bsd, personne trouve rien à redire. Nufw ne tourne que sur netfilter donc Linux, personne ne trouve rien à redire ( et dieu sait que mon patron, créateur du soft, a trollé pf plus d'une fois ).
NetworkManager tourne pas sur freebsd, wicd non plus, et je doute que connman soit dispo. Et pourtant, personne n'a jamais dit "faut pas coder ces outils". Ni personne n'a dit "je vais aller faire des patches".
Bluez tourne pas ( que je sache ) sur Openbsd, c'est pareil, ou sont les gens pour crier au complot de Nokia et Intel ?
Le montage des vpns marchent très bien ( en tout cas avec openvpn ), donc je vois pas ou serait le souci. Tu as 1 unité par vpn, ça démare quand le réseau se lance, ça se relance si ça tombe ( systéme de watchdog ), et conceptuellement, je sais pas trop ce qu'un autre vpn changerais ( genre, un daemon ipsec, ça reste un daemon ). Au pire, l'intégration est la même qu'avec les autres logiciels.
Quand aux fs chiffrés, si le souci est "systemd ne peux pas monter automatiquement un truc qui demande une intervention manuel" ( cf exemple donné plus tard ), je vois pas ce qu'un logiciel peut faire contre ça. Si un truc a besoin d'une intervention à la main, oui, tu va pas pouvoir faire grand chose pour automatiser ça. Et marqué le fs en "noauto" devrait suffire à régler le souci. Une fois que tu montes ça à la main ( avec ton mot de passe tapé ), systemd va réagir, si je comprends bien la doc de systemd.mount :
Mount points created at runtime independent on unit files or /etc/fstab
will be monitored by systemd and appear like any other mount unit in
systemd.
Donc soit je comprends de travers les soucis ( car la description est des plus lapidaires ), soit on n'a pas répondu comme il faut à tes questions.
Ma foi, j'aimerais bien voir un mail ou il est marqué "vous passerez à systemd ou on butte le chien", si possible en anglais, et qui a décidé par exemple opensuse ou mageia à le faire. ( parce que globalement, c'est ce que tu décrit, et j'ai pas vu passer ce genre de mail, les gens ont choisit volontairement de basculer que je sache ).
Par exemple, pour Opensuse, est ce que quelqu'un s'est plaint de pression de la part d'une autre boite ? Est ce que tu as , genre, des preuves, des mails publiques ?
Tu fais aussi abstraction des discussions qu'il y a eu sur Fedora, sur Mageia, sur openwrt en toute transparence sur le passage ( ce qui ma foi, ne me parait pas faire preuve de beaucoup de rigueur dans l'hégémonie, mais bon, c'est bien connu que soit on est d'accord avec une décision technique, soit les devs et les packageurs sont des cryptofachistes doublés d'incapables de voir la vérité et de coder ).
Tu fais abstraction du fait que les devs de arch ont discuté de ça. Tu fais abstraction du fait que quand Fedora est passé à upstart, personne n'a ralé ( alors que upstart n'est pas compatible bsd, dépend de dbus, change les outils en ligne de commandes, n'utilise pas du tout de shell et fait juste moins de choses que systemd ). Et que upstart avait prévu de remplacer cron, at ( http://upstart.ubuntu.com/faq.html#replace-cron ), ce qui n'a fait bondir personne.
Au passage, personne n'a suivi, alors que pourtant, RHEL 6 utilise upstart.
Donc tu peux sans doute expliquer pourquoi un truc utilisé par Ubuntu, RHEL/Centos, et Fedora pendant un temps est vu comme moins hégémonique qu'un truc utilisé au début juste par Fedora ?
En fait, c'est simple, les distributions l'utilisent car elles pensent que c'est sur le long terme plus facile à maintenir. Il y a moins de code à faire pour lancer un demon, ça permet des choses choupis, c'est moderne. Les raisons que j'estime pleinement valable de pas y passer sont soit d'ordre du minimalisme ( exemple, lfs et co ), soit de l'ordre de la diversité, soit de l'ordre de la portabilité ( exemple debian ).
La plupart des distribs ne sont pas dans ce cas la. La diversité, c'est un cout à la QA, à la compilation et à la gestion et tente d'être diminué avec plus ou moins de bonheur. Autant offir X WM, ça va, autant offrir par exemple X serveurs webs et espérer une intégration fine, c'est plus dur ( d'ailleurs, c'est pour ça que la plupart le font pas, et propose juste une intégration avec apache, et pas X fichiers de conf pour nginx, lighttpd, pour php en fastcgi, en demon avec fpm, etc ). Et dans le cas d'un truc comme un système d'init qui touche tout le monde c'est simplement trop complexe.
La portabilité, ça a un cout aussi, et la plupart des distribs ne sont pas prêtes à le payer. EN fait, il y a que Debian ( et Arch ) qui tente de tourner sur autre chose qu'un noyau Linux. Pour les autres, avant, les initscripts n'étaient pas compatible avec les BSDs, et était fait par la distro, maintenant, ça ne va pas changer. Donc globalement, ça, à part pour Debian, ça change rien.
Enfin je pense que la plupart des distributions ne souffrent pas des soucis de lfs, vu que la plupart ont besoin déjà de tout un tas de trucs. Donc c'est déja un souci qui est maitrisé, et qui n'affecte pas trop l'utilisateur ( ie, les deps de systemd sont déjà toutes dans les distros, donc le surcout est mineur du point de vue packaging ).
Et moi, en tant que packageur de longue date, je pense que le format de fichier de systemd est beaucoup plus facile à écrire, à comprendre et à vérifier qu'un script shell à base de boilerplate et de copier coller, et qu'il fait juste des tas de trucs en plus. Systemd gére aussi de façon élégante des cas à la con comme "lancer plusieurs fois un service", "gérer des services à la con comme bind qui utilise un canal de com à part pour se couper" ou d'autres exemples que je sort à chaque fois ( bla bla sympa bla bla 5 services bla bla bloquant bla bla postgresql pas lancé bla bla ).
Et je suis aussi sensible à l'idée "on pousse le fichier upstream", car ç'est la façon la plus simple de collaborer, ce qui est la base du logiciel libre. Ça a relativement bien marché pour les menus en .desktop ( pour ceux qui sont assez vieux pour se souvenir du merdier infame que c'était avant ), je vois pas pourquoi ça ne marcherais pas pour les services. Et autant j'ai rarement confiance dans un script d'init qui vient d'upstream ( qui va toujours faire 3 fois trop de trucs, et qui va tourner correctement sur 1 distro ), autant, un fichier de config, je pense que ça peut passer.
Donc tout ce qui peut réduire la charge de travail d'un packageur est la bienvenue.
Et ça, c'est mon avis en tant que mec du coté distro.
On pourrait aussi noter que c'est pas pertinent sur le noyau, mais personne ne vient défendre le bien fondé de hurd dans ce genre de discussion ( car oui, un soft qui fait du routage et filtrage réseau, tout en gérant la carte son, la video, le chiffrement du filesystéme, des acls, la gestion de l'energie avec une pile wifi et des dizaines d'autres, ça fait plus que "juste une chose" )
En fait, d'une part, je pense que Mandriva n'est plus si européenne depuis un bout de temps ( vu que le coeur vient surtout du brésil et ou de la russie ), et d'autre part, des distributions comme Mageia ou Debian sont très largement européenne également. Les membres fondateurs et actif sont trés largement de ce coté de l'océan, et dans mon souvenir, l'allemagne a le plus de DD au monde mais ça a du/pu changer. Ubuntu aussi en fait, vu que le plus gros bureau de Canonical est à Londres.
Je doit reconnaitre que j'aime aussi le fait de dire "Gnome 3.X" pour ne pas dire 3.4, histoire de pas faire "vieux". Une charmante attention pour la personne attentive que je suis.
Au yeux de celui qui forke, c'est toujours justifié, la question est plus "est ce que le fork va tenir la route" ( perso, j'aurais tendance à dire "non" ). Car c'est bien joli de forker, mais faut le maintenir. C'est pas faire le git clone le souci, c'est les 500 git commit et push par la suite.
Avant, rien n'était compatible, chaque distro avait son système d'init, son système de paquet, sa version de chaque composant, donc son abi.
maintenant c'est pareil.
C'est moi ou d'une part, les gens cherchent du sang et du drame la ou il y en a pas, et les gens ont la mémoire aussi courte que le slip d'un stripteaser dans un casino de las vegas ?
Il y a eu un summer of code pour résoudre le souci ( de la même façon que debian avait résolu le souci des menus avant la norme freedesktop ).
En gros, tu as un format de base ( genre le format .ini de systemd ), et tu peux générer un script d'init pour debian kfreebsd, pour le hurd, etc.
Ensuite, comme systemd utilise quand même des fonctionnalités difficiles à émuler partout ( genre les cgroups, l'intégration de selinux, le filtrage des appels systèmes des programmes lancés, le fait de lancer les applis dans un chroot avec montage particulier de certains répertoire ), je suis pas sur que ça puisse vraiment transposer tout dans un script shell, sauf à se retrouver avec un truc comme autoconf.
En même temps, c'est un problème que des gens ne veulent pas voir résolu, car ça impliquerais de collaborer au lieu de bosser dans son coin. Voir même, de renoncer à des trucs.
[^] # Re: les autres Unices...
Posté par Misc (site web personnel) . En réponse au journal yet another journal about systemd. Évalué à 2.
Ma foi, parce que peut être, y a des gens qui veulent avoir une interface graphique capable de gerer le wifi, etc ?
Mais si tu aimes pas nm, tu as connman, tu as wicd, et pareil, ils tournent pas sur les bsd.
Donc à la fin, c'est "est ce que les gens sur un système bsd (autre que celui d'apple) veulent tous gérer le wifi à la mano en cli" ?
Perso, nm marche sur mon portable et me taper wpa_supplicant à la main, ça va 5 minutes ( surtout vu que j'ai besoin d'une authentification à 2 facteurs pour le wifi au travail ), tout comme devoir faire les 3/4 commandes pour un wifi classique, ça me ferait chier ( à commencer par me connecter en root ).
[^] # Re: Trop d'honneurs...
Posté par Misc (site web personnel) . En réponse au journal yet another journal about systemd. Évalué à 5.
En fait, c'est la même diffrence qu'entre java et python. java, faut rajouter toujours le même boilerplate pour les trucs simple, genre un hello world.
Ou la différence du xml et un DSL parfaitement prévu pour. Si tu commences à faire du copier coller, y a 2 choses :
- tu va jamais avoir besoin de toucher à ça, donc tu gaspilles juste de l'espace et tu rajoutes du bruit, autant faire un système qui retire tout ( ce que gentoo ou plf ont fait, par exemple )
- tu va devoir toucher au code un jour, et la, bah tu as juste des centaines de copies, et tu as fait de la merde
Donc dans les 2 cas, ça pose problème.
[^] # Re: Trop d'honneurs...
Posté par Misc (site web personnel) . En réponse au journal yet another journal about systemd. Évalué à 4.
Genre ça : http://www.h-online.com/open/news/item/Debian-testing-a-systemd-to-sysvinit-converter-1670713.html
[^] # Re: Tout le monde n'est pas d'accord
Posté par Misc (site web personnel) . En réponse à la dépêche openSUSE 12.2 officiellement disponible. Évalué à 4.
ça date un peu, en 6 mois, les choses ont peut être pu changer, et tout a déjà été discuté 100 fois.
[^] # Re: Systemd
Posté par Misc (site web personnel) . En réponse à la dépêche openSUSE 12.2 officiellement disponible. Évalué à 3.
Dans mon souvenir, oui, et c'est Frederic Crozat qui a bossé dessus ( entre autre ). Il y a une page sur l'état sur le wiki :
http://en.opensuse.org/SDB:Systemd
En fait, c'est la depuis la 12.1 :
http://news.opensuse.org/2011/12/22/systemd-%E2%80%93-boot-faster-and-cleaner-with-opensuse-12-1/
[^] # Re: les autres Unices...
Posté par Misc (site web personnel) . En réponse au journal yet another journal about systemd. Évalué à 10.
Ça fait 20 ans que les BSD et les systèmes Linux existent, et c'est quand la dernière fois qu'il y a eu des gens autour de la table pour discuter de standard communs entre les 2 ?
Quand tu vois que les gens sont pas capable de se mettre d'accord sur les conventions d'appel, sur la présence ou pas de fonction de manipulation de chaines ( strnlen ), sur la version de gcc, ou sur justement les initscripts, et les apis, je vois pas ce que Lennart va changer à ça.
D'ailleurs, la dernière fois qu'il a fait un soft portable ( genre avahi ), y a eu un gsoc pour coder un truc compatible sous une license BSD :
http://wiki.freebsd.org/MulticastDNS
Donc oui, ce que les BSDistes veulent, c'est pas du code GPL, c'est des interfaces.
Grande nouvelle, y en a :
http://www.freedesktop.org/wiki/Software/systemd/InterfacePortabilityAndStabilityChart
[^] # Re: Questions
Posté par Misc (site web personnel) . En réponse au journal Linux from scratch face à udev. Évalué à 3.
En même temps, la discussion, même basé sur des arguments faux, reste pertinente dans le sens ou ça a un rapport avec le sujet. Et le commentaire, même faux, n'est pas inutile car il permet de présenter des contre vérités ce qui permet de les dissiper.
( sinon, pour avoir +10, faut aussi faire des blagues, ça marche bien )
[^] # Re: Questions
Posté par Misc (site web personnel) . En réponse au journal Linux from scratch face à udev. Évalué à 6.
Tu sembles avoir une vision faussé de ce que font les cgroups.
Je te conseille de lire ça http://0pointer.de/blog/projects/cgroups-vs-cgroups.html
puis de voir la doc de lxc, puis de voir que lxc utilise les cgroups, mais que les cgroups ne sont pas lxc.
IE, tu peux interagir avec les processes sans souci, le cgroup dans systemd n'est la que pour dire "tel process a lancé ces 15 processes". Ensuite, oui, si tu lances les processes en dehors de systemd, bah, il va rien pouvoir faire. Tout comme si tu lances un soft a la main, l'initscript va sans doute faire de la merde. Ensuite, tu peux utiliser selinux, chroot, lxc pour isoler les processes, mais tu va pas demander quand même à isoler un process mais vouloir que tout le monde puisse y toucher.
je te conseille aussi de lire la doc de systemd sur les montages ( genre, le montage en non auto ), et aussi d'avoir ton vocabulaire au point, tu crées pas une carte réseau, tu crées au mieux une interface réseau ( la carte réseau étant pour moi un objet physique ). Quand à lancer la couche tcp/ip, tu veux sans doute dire "demander un ip" ? ( parce que la couche tcp/ip, elle est déja la, sinon ton vpn tourne sans doute pas ).
Donc si ton souci c'est "j'ai une config trop compliqué pour la config par défaut de network-manager, alors systemd est merdique", j'ai le sentiment que tu confonds un peu tout.
Quand à avoir un script d'init par machine, que dire à part que c'est soit déjà le cas ( si tu veux un truc propre ), soit pas une chose que systemd va changer, car tu peux encore déposer ton script compatible LSB dans /etc/init.d comme avant. La preuve, c'est que tout n'a pas été migré sur une fedora 17.
Enfin, si tu lit la page de man systemd.service, tu verras qu'il y a :
ExecReload=
Commands to execute to trigger a configuration reload in the
service.
Donc tu peux juste lancer le kill -SIGHUP qui va bien, ou lancer apachectl, ou ce que tu veux, pas besoin de rajouter un support dbus totalement fantasmé de ta part.
Et donc, ton histoire de rajouter du boilerplate sachant que systemd est sorti depuis au moins 1 an, tu va sans doute pouvoir trouver du boilerplate et des exceptions pour montrer ce que tu avances ? ( car affirmer, c'est une chose, mais avec des preuves, ça serait sans doute plus crédible, et ça serait pas de trop )
[^] # Re: la guerre de s unices
Posté par Misc (site web personnel) . En réponse au journal udev forké. Évalué à 5.
J'aime assez le coté péremptoire de ton commentaire qui fait croire que tu t'y connais sur systemd, suivi par "je n'investirais pas de temps à apprendre systemd". Faut savoir, tu connais systemd sur le bout des doigts pour expliquer comment dbus est obligatoire pour le debug ( ie, tu as eu à débugguer ? ), ou tu n'y connais rien et tu es juste un raleur aigri ?
Je penche pour le second, personnellement, mais je te laisse le bénéfice du doute.
En fait, je penche pour le second parce que tu sembles tourner les choses pour un bon FUD.
"pour avoir les fonctions qu'on a pas pour le moment, faut faire du boulot". En effet c'est logique, si tu veux des trucs qu'un script shell fournit pas, faut le refaire autrement. Mais sinon, les scripts marchent encore. Service marche encore.
Et contrairement à ce que tu crois, y a pas mal de distro qui font plus d’exécution séquentielle. RHEL, ubuntu ont upstart. Mandriva/Mageia a un système qui lance tout en même temps depuis 2006 ( pinit ). Et la plupart font de la gestion automatique de l'ordre via un système de tags LSB.
En fait, tu oublie aussi que les paquets des distros sont migrés, donc le travail de refonte est déjà fait ( comme les migrations à python 3 ou gcc 4, en fait ).
Pour la pérennité, prends au moins des trucs qui ont disparus ( genre oss, genre ipchains ), car selinux est la depuis facile 10 ans, et il n'a pas changé des masses, il a surtout eu des features en plus. Dbus existe depuis au moins 5 ans, et pareil, les changements sont pas révolutionnaires. Certes, hal a disparu.
Et sinon, comme tu avoues bien que faire des scripts d'init, c'est chiant, tu te rends bien compte que tu valides le point de vue des packageurs qui pousse à migrer à systemd ?
[^] # Re: la guerre de s unices
Posté par Misc (site web personnel) . En réponse au journal udev forké. Évalué à 4.
En fait, le support est passé à 10 ans, comme indiqué sur Linuxfr :
https://linuxfr.org/news/le-support-de-redhat-enterprise-linux-passe-a-10-ans
D'autre part, RHEL 6 tourne avec upstart, et visiblement, ça n'a pas l'air de déranger grand monde ( vu que personne n'en parle et j'ai pas entendu de grand cri ), et le support de sysV par systemd est au même niveau que celui d'upstart ( ie, ça se lance directement les scripts de /etc/init.d )
Enfin, sachant que oracle avait déjà décidé de prendre son temps pour la certif de RHEL 6 ( http://blog.vishalgupta.com/2011/09/19/oracle-11gr2-on-rhel6/ ), donc j'ai l'impression qu'une version d'oracle non supporté sur RHEL est un événement déjà arrivé.
Moi, quand je relit ton histoire, je vois juste un client qui collabore avec son fournisseur sur un produit pas encore sorti, et ça me semble relativement positif comme façon de faire. Et à te lire, tu en reviendrais presque à le regretter, voir à imaginer des luttes de pouvoir qui n'existent pas. On pourrais même croire que tu sous entends que RH ne va pas pousser les bugfixes upstream, ou qu'il y a pas moyen de supporter proprement les scripts shell avec autre chose que sysV ( voir même que tes scripts magiques feraient des trucs si magiques que ça marcherais pas )
Tu serais pas un peu aigri et totalement subjectif ?
[^] # Re: les autres Unices...
Posté par Misc (site web personnel) . En réponse au journal yet another journal about systemd. Évalué à 7.
Selon toi, le plus gros problème de systemd, c'est que les gens jugent pas le soft mais l'idée qu'ils se font d'un des auteurs sur la base d'extrait de discussions qu'ils ont pas suivi, mais dont il garde une sous partie qui leur semble choquante, c'est ça ?
Perso, je dirais pas que c'est un problème de systemd, plus un problème de gens.
Encore une fois, les technos linux only et bsd only abondent depuis des années. Samba utilise sendfile sur linux et pas sur bsd, personne trouve rien à redire. Nufw ne tourne que sur netfilter donc Linux, personne ne trouve rien à redire ( et dieu sait que mon patron, créateur du soft, a trollé pf plus d'une fois ).
NetworkManager tourne pas sur freebsd, wicd non plus, et je doute que connman soit dispo. Et pourtant, personne n'a jamais dit "faut pas coder ces outils". Ni personne n'a dit "je vais aller faire des patches".
Bluez tourne pas ( que je sache ) sur Openbsd, c'est pareil, ou sont les gens pour crier au complot de Nokia et Intel ?
[^] # Re: linuxfr: doc officielle de systemd
Posté par Misc (site web personnel) . En réponse au journal yet another journal about systemd. Évalué à 4.
Le montage des vpns marchent très bien ( en tout cas avec openvpn ), donc je vois pas ou serait le souci. Tu as 1 unité par vpn, ça démare quand le réseau se lance, ça se relance si ça tombe ( systéme de watchdog ), et conceptuellement, je sais pas trop ce qu'un autre vpn changerais ( genre, un daemon ipsec, ça reste un daemon ). Au pire, l'intégration est la même qu'avec les autres logiciels.
Quand aux fs chiffrés, si le souci est "systemd ne peux pas monter automatiquement un truc qui demande une intervention manuel" ( cf exemple donné plus tard ), je vois pas ce qu'un logiciel peut faire contre ça. Si un truc a besoin d'une intervention à la main, oui, tu va pas pouvoir faire grand chose pour automatiser ça. Et marqué le fs en "noauto" devrait suffire à régler le souci. Une fois que tu montes ça à la main ( avec ton mot de passe tapé ), systemd va réagir, si je comprends bien la doc de systemd.mount :
Donc soit je comprends de travers les soucis ( car la description est des plus lapidaires ), soit on n'a pas répondu comme il faut à tes questions.
[^] # Re: RH
Posté par Misc (site web personnel) . En réponse au journal yet another journal about systemd. Évalué à 10.
Ma foi, j'aimerais bien voir un mail ou il est marqué "vous passerez à systemd ou on butte le chien", si possible en anglais, et qui a décidé par exemple opensuse ou mageia à le faire. ( parce que globalement, c'est ce que tu décrit, et j'ai pas vu passer ce genre de mail, les gens ont choisit volontairement de basculer que je sache ).
Par exemple, pour Opensuse, est ce que quelqu'un s'est plaint de pression de la part d'une autre boite ? Est ce que tu as , genre, des preuves, des mails publiques ?
Tu fais aussi abstraction des discussions qu'il y a eu sur Fedora, sur Mageia, sur openwrt en toute transparence sur le passage ( ce qui ma foi, ne me parait pas faire preuve de beaucoup de rigueur dans l'hégémonie, mais bon, c'est bien connu que soit on est d'accord avec une décision technique, soit les devs et les packageurs sont des cryptofachistes doublés d'incapables de voir la vérité et de coder ).
Tu fais abstraction du fait que les devs de arch ont discuté de ça. Tu fais abstraction du fait que quand Fedora est passé à upstart, personne n'a ralé ( alors que upstart n'est pas compatible bsd, dépend de dbus, change les outils en ligne de commandes, n'utilise pas du tout de shell et fait juste moins de choses que systemd ). Et que upstart avait prévu de remplacer cron, at ( http://upstart.ubuntu.com/faq.html#replace-cron ), ce qui n'a fait bondir personne.
Au passage, personne n'a suivi, alors que pourtant, RHEL 6 utilise upstart.
Donc tu peux sans doute expliquer pourquoi un truc utilisé par Ubuntu, RHEL/Centos, et Fedora pendant un temps est vu comme moins hégémonique qu'un truc utilisé au début juste par Fedora ?
[^] # Re: Trop d'honneurs...
Posté par Misc (site web personnel) . En réponse au journal yet another journal about systemd. Évalué à 5.
Pour systemd :
http://patrakov.blogspot.fr/2011/01/writing-systemd-service-files.html
Pour un initscript mandriva
http://wiki.mandriva.com/en/Development/Howto/Initscripts
Pour gentoo :
http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=2&chap=4#doc_chap4
Je suis sur que tu peux trouver pareil pour le reste.
# Parce que les distributions et les users, c'est 2 choses différentes
Posté par Misc (site web personnel) . En réponse au journal yet another journal about systemd. Évalué à 10.
En fait, c'est simple, les distributions l'utilisent car elles pensent que c'est sur le long terme plus facile à maintenir. Il y a moins de code à faire pour lancer un demon, ça permet des choses choupis, c'est moderne. Les raisons que j'estime pleinement valable de pas y passer sont soit d'ordre du minimalisme ( exemple, lfs et co ), soit de l'ordre de la diversité, soit de l'ordre de la portabilité ( exemple debian ).
La plupart des distribs ne sont pas dans ce cas la. La diversité, c'est un cout à la QA, à la compilation et à la gestion et tente d'être diminué avec plus ou moins de bonheur. Autant offir X WM, ça va, autant offrir par exemple X serveurs webs et espérer une intégration fine, c'est plus dur ( d'ailleurs, c'est pour ça que la plupart le font pas, et propose juste une intégration avec apache, et pas X fichiers de conf pour nginx, lighttpd, pour php en fastcgi, en demon avec fpm, etc ). Et dans le cas d'un truc comme un système d'init qui touche tout le monde c'est simplement trop complexe.
La portabilité, ça a un cout aussi, et la plupart des distribs ne sont pas prêtes à le payer. EN fait, il y a que Debian ( et Arch ) qui tente de tourner sur autre chose qu'un noyau Linux. Pour les autres, avant, les initscripts n'étaient pas compatible avec les BSDs, et était fait par la distro, maintenant, ça ne va pas changer. Donc globalement, ça, à part pour Debian, ça change rien.
Enfin je pense que la plupart des distributions ne souffrent pas des soucis de lfs, vu que la plupart ont besoin déjà de tout un tas de trucs. Donc c'est déja un souci qui est maitrisé, et qui n'affecte pas trop l'utilisateur ( ie, les deps de systemd sont déjà toutes dans les distros, donc le surcout est mineur du point de vue packaging ).
Et moi, en tant que packageur de longue date, je pense que le format de fichier de systemd est beaucoup plus facile à écrire, à comprendre et à vérifier qu'un script shell à base de boilerplate et de copier coller, et qu'il fait juste des tas de trucs en plus. Systemd gére aussi de façon élégante des cas à la con comme "lancer plusieurs fois un service", "gérer des services à la con comme bind qui utilise un canal de com à part pour se couper" ou d'autres exemples que je sort à chaque fois ( bla bla sympa bla bla 5 services bla bla bloquant bla bla postgresql pas lancé bla bla ).
Et je suis aussi sensible à l'idée "on pousse le fichier upstream", car ç'est la façon la plus simple de collaborer, ce qui est la base du logiciel libre. Ça a relativement bien marché pour les menus en .desktop ( pour ceux qui sont assez vieux pour se souvenir du merdier infame que c'était avant ), je vois pas pourquoi ça ne marcherais pas pour les services. Et autant j'ai rarement confiance dans un script d'init qui vient d'upstream ( qui va toujours faire 3 fois trop de trucs, et qui va tourner correctement sur 1 distro ), autant, un fichier de config, je pense que ça peut passer.
Donc tout ce qui peut réduire la charge de travail d'un packageur est la bienvenue.
Et ça, c'est mon avis en tant que mec du coté distro.
[^] # Re: esprit Unix
Posté par Misc (site web personnel) . En réponse à la dépêche Le point sur udev et systemd. Évalué à 9.
On pourrait aussi noter que c'est pas pertinent sur le noyau, mais personne ne vient défendre le bien fondé de hurd dans ce genre de discussion ( car oui, un soft qui fait du routage et filtrage réseau, tout en gérant la carte son, la video, le chiffrement du filesystéme, des acls, la gestion de l'energie avec une pile wifi et des dizaines d'autres, ça fait plus que "juste une chose" )
[^] # Re: ?
Posté par Misc (site web personnel) . En réponse au journal Le journal. Évalué à 2.
Comme avant, en oubliant les faits et en ne gardant que l'émotionnel.
Voir http://youarenotsosmart.com/2010/06/23/confirmation-bias/
[^] # Re: La conclusion
Posté par Misc (site web personnel) . En réponse à la dépêche Le point sur udev et systemd. Évalué à 10.
C'est surtout qu'il y a toujours du monde pour dire "faudrait faire" et plus personne pour dire "j'ai fait ça".
[^] # Re: La conclusion
Posté par Misc (site web personnel) . En réponse à la dépêche Le point sur udev et systemd. Évalué à 10.
Une personne dont le login est E316 serait un utilisateur conservateur
# Petite précision
Posté par Misc (site web personnel) . En réponse au journal openSuSE 12.2 officiellement disponible. Évalué à 5.
En fait, d'une part, je pense que Mandriva n'est plus si européenne depuis un bout de temps ( vu que le coeur vient surtout du brésil et ou de la russie ), et d'autre part, des distributions comme Mageia ou Debian sont très largement européenne également. Les membres fondateurs et actif sont trés largement de ce coté de l'océan, et dans mon souvenir, l'allemagne a le plus de DD au monde mais ça a du/pu changer. Ubuntu aussi en fait, vu que le plus gros bureau de Canonical est à Londres.
Je doit reconnaitre que j'aime aussi le fait de dire "Gnome 3.X" pour ne pas dire 3.4, histoire de pas faire "vieux". Une charmante attention pour la personne attentive que je suis.
[^] # Re: Pas compris
Posté par Misc (site web personnel) . En réponse au journal udev forké. Évalué à 4.
Au yeux de celui qui forke, c'est toujours justifié, la question est plus "est ce que le fork va tenir la route" ( perso, j'aurais tendance à dire "non" ). Car c'est bien joli de forker, mais faut le maintenir. C'est pas faire le git clone le souci, c'est les 500 git commit et push par la suite.
[^] # Re: la guerre de s unices
Posté par Misc (site web personnel) . En réponse au journal udev forké. Évalué à 8.
Avant, rien n'était compatible, chaque distro avait son système d'init, son système de paquet, sa version de chaque composant, donc son abi.
maintenant c'est pareil.
C'est moi ou d'une part, les gens cherchent du sang et du drame la ou il y en a pas, et les gens ont la mémoire aussi courte que le slip d'un stripteaser dans un casino de las vegas ?
[^] # Re: la guerre de s unices
Posté par Misc (site web personnel) . En réponse au journal udev forké. Évalué à 6.
Il y a eu un summer of code pour résoudre le souci ( de la même façon que debian avait résolu le souci des menus avant la norme freedesktop ).
En gros, tu as un format de base ( genre le format .ini de systemd ), et tu peux générer un script d'init pour debian kfreebsd, pour le hurd, etc.
Ensuite, comme systemd utilise quand même des fonctionnalités difficiles à émuler partout ( genre les cgroups, l'intégration de selinux, le filtrage des appels systèmes des programmes lancés, le fait de lancer les applis dans un chroot avec montage particulier de certains répertoire ), je suis pas sur que ça puisse vraiment transposer tout dans un script shell, sauf à se retrouver avec un truc comme autoconf.
[^] # Re: la guerre de s unices
Posté par Misc (site web personnel) . En réponse au journal udev forké. Évalué à 10.
En même temps, c'est un problème que des gens ne veulent pas voir résolu, car ça impliquerais de collaborer au lieu de bosser dans son coin. Voir même, de renoncer à des trucs.
[^] # Re: Et ?
Posté par Misc (site web personnel) . En réponse au journal Le principe KISS appliqué à la gestion des sauvegardes.. Évalué à 4.
Il gère aussi les certificats, le chiffrement, la déduplication, il fait peut être plus que 2 choses :)