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.
En fait, dans ce cas de figure, si ça permet au groupe de survivre, alors il est probable que le comportement perdure au contraire des autres qui ne permettent pas la survie, et qui donc vont pas se transmettre à la génération suivante, vu que par définition, il n'y en a pas.
Je sais pas dans quel mesure est ce que l'instinct dépend des gènes, je prends sans doute trop à cœur la théorie de Dawkins décrite dans http://fr.wikipedia.org/wiki/Le_Gène_égoïste ( mais bon, d’après wikipedia, je viens de découvrir qu'il y a des gens qui trouvent que ça fait extrême droite de citer ça )
Le désir de servilité et de soumission. Pour une raison que j'ignore (et que je perçois régulièrement en moi), les
gens ont envie - voire besoin - d'avoir des maîtres.
C'est pas tant d'avoir des maitres que d'avoir quelqu'un ou quelque chose d'autre pour ne plus avoir à supporter la responsabilité, et tout l'inconfort que ça engendre. Je pense qu'on se sent mieux sans sans arrêt avoir la tension d'un choix à faire, sans se dire "la, j'ai personne pour m'aider, si je me plante, c'est ma faute". Il y a eu des études sur le fait que trop de choix paralyse les gens, donc je pense qu'on a évolué pour éviter ça, en se reposant sur d'autres.
Les animaux utilisant plus l'instinct et ayant moins une vision "high level" ne souffre sans doute pas de ce problème. Mais nous avons des capacités cognitives différentes, et on atteint leur limite avec la complexité d ela vie en société.
Et je pense que c'est aussi du à notre éducation, à savoir qu'on perçoit bien que la vie était plus simple quand on était plus jeune, et qu'on cherche à retrouver ce confort.
Donc il y a une forme de pression à un niveau inconscient à revenir vers ça ( enfin je crois, renseigne toi auprès d'un sociologue, d'un psy et d'un philosophe ( non, c'est pas une blague ou il rentre dans un bar )).
Et ces gens justifient leur choix avec des arguments de toutes sortes, d'une futilité outrageante devant les
inconvénients du dit choix, mais ils sont là et zélés.
Pareil. Le cerveau n'aime pas avoir à gérer 2 choix totalement discordant, ça s'appelle une dissonance cognitive. Donc on va choisir les arguments qui appuient nos croyances, car se remettre en question est désagréable, vu qu'on se repose des questions qu'on a déjà "classé", et on cherche à éviter la tension à nouveau. Regarde les études sur des choses comme le biais de confirmation ( confirmation bias ), comme expliquer sur http://youarenotsosmart.com/2010/06/23/confirmation-bias/ ou http://youarenotsosmart.com/2010/05/19/fanboyism-and-brand-loyalty/
Si, l'ipod a été un des premiers appareils a proposer un disque dur de taille conséquente, et Tim Cook ayant eu la bonne idée d'organiser une pénurie mondial en rachetant tout le stock de disque, cela a laissé à Apple une avance assez formidable.
En pratique, non, car sauf si les OEMs trouvent assez de codeurs avec assez de temps, ils vont toujours faire des pilotes à l'arrache ( khof pilote windows dans ndiswrapper khof pilote nvidia khof ). Et les mêmes problèmes ( "pas envie de filer de doc" "pas envie de faire des pilotes propres à linux", "pas envie de maintenir les pilotes longtemps" ) vont toujours être la, et ça va pas améliorer des masses le support, autrement qu'en apparence.
Quand aux soucis d'interopérabilité, les gens vont juste porter des codecs proprios sous linux, et je pense pas que ça soit une victoire pour le libre.
Donc pour moi, je pense que ça soit très attirant.
En fait, je vois 3 pcs de marques apple, et 5 pcs non apple ( dont 2 eepcs ). Je dirait pas que ça migre en masse, perso, juste que les gens voient les bécanes et s'en souviennent. IE, c'est la visibilité qui fait qu'on croit qu'il y a quelque chose.
Mais c'est souvent Adobe Reader, ce super logiciel qui est en passe de dépasser ie6 dans le top des softs moisis.
Faut pas se leurrer, le but est pas de remplacer evince et co sur linux, mais bien de faire à acrobat reader ce qui a été fait à IE sur windows et companie.
[^] # 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 :)
[^] # Re: Explication
Posté par Misc (site web personnel) . En réponse au journal Pourquoi je suis libriste intégriste.. Évalué à 3.
En fait, dans ce cas de figure, si ça permet au groupe de survivre, alors il est probable que le comportement perdure au contraire des autres qui ne permettent pas la survie, et qui donc vont pas se transmettre à la génération suivante, vu que par définition, il n'y en a pas.
Je sais pas dans quel mesure est ce que l'instinct dépend des gènes, je prends sans doute trop à cœur la théorie de Dawkins décrite dans http://fr.wikipedia.org/wiki/Le_Gène_égoïste ( mais bon, d’après wikipedia, je viens de découvrir qu'il y a des gens qui trouvent que ça fait extrême droite de citer ça )
# Explication
Posté par Misc (site web personnel) . En réponse au journal Pourquoi je suis libriste intégriste.. Évalué à 9.
C'est pas tant d'avoir des maitres que d'avoir quelqu'un ou quelque chose d'autre pour ne plus avoir à supporter la responsabilité, et tout l'inconfort que ça engendre. Je pense qu'on se sent mieux sans sans arrêt avoir la tension d'un choix à faire, sans se dire "la, j'ai personne pour m'aider, si je me plante, c'est ma faute". Il y a eu des études sur le fait que trop de choix paralyse les gens, donc je pense qu'on a évolué pour éviter ça, en se reposant sur d'autres.
Les animaux utilisant plus l'instinct et ayant moins une vision "high level" ne souffre sans doute pas de ce problème. Mais nous avons des capacités cognitives différentes, et on atteint leur limite avec la complexité d ela vie en société.
Et je pense que c'est aussi du à notre éducation, à savoir qu'on perçoit bien que la vie était plus simple quand on était plus jeune, et qu'on cherche à retrouver ce confort.
Donc il y a une forme de pression à un niveau inconscient à revenir vers ça ( enfin je crois, renseigne toi auprès d'un sociologue, d'un psy et d'un philosophe ( non, c'est pas une blague ou il rentre dans un bar )).
Pareil. Le cerveau n'aime pas avoir à gérer 2 choix totalement discordant, ça s'appelle une dissonance cognitive. Donc on va choisir les arguments qui appuient nos croyances, car se remettre en question est désagréable, vu qu'on se repose des questions qu'on a déjà "classé", et on cherche à éviter la tension à nouveau. Regarde les études sur des choses comme le biais de confirmation ( confirmation bias ), comme expliquer sur http://youarenotsosmart.com/2010/06/23/confirmation-bias/ ou http://youarenotsosmart.com/2010/05/19/fanboyism-and-brand-loyalty/
[^] # Re: iMac
Posté par Misc (site web personnel) . En réponse au journal Self serving. Évalué à 4.
Si, l'ipod a été un des premiers appareils a proposer un disque dur de taille conséquente, et Tim Cook ayant eu la bonne idée d'organiser une pénurie mondial en rachetant tout le stock de disque, cela a laissé à Apple une avance assez formidable.
Un très joli coup en fait.
[^] # Re: en vrai
Posté par Misc (site web personnel) . En réponse au journal Self serving. Évalué à 4.
En pratique, non, car sauf si les OEMs trouvent assez de codeurs avec assez de temps, ils vont toujours faire des pilotes à l'arrache ( khof pilote windows dans ndiswrapper khof pilote nvidia khof ). Et les mêmes problèmes ( "pas envie de filer de doc" "pas envie de faire des pilotes propres à linux", "pas envie de maintenir les pilotes longtemps" ) vont toujours être la, et ça va pas améliorer des masses le support, autrement qu'en apparence.
Quand aux soucis d'interopérabilité, les gens vont juste porter des codecs proprios sous linux, et je pense pas que ça soit une victoire pour le libre.
Donc pour moi, je pense que ça soit très attirant.
[^] # Re: AppleFr
Posté par Misc (site web personnel) . En réponse au journal Self serving. Évalué à 2.
En fait, je vois 3 pcs de marques apple, et 5 pcs non apple ( dont 2 eepcs ). Je dirait pas que ça migre en masse, perso, juste que les gens voient les bécanes et s'en souviennent. IE, c'est la visibilité qui fait qu'on croit qu'il y a quelque chose.
[^] # Re: Lecteur pdf
Posté par Misc (site web personnel) . En réponse à la dépêche Firefox et Thunderbird : appelez le 15. Évalué à 6.
Mais c'est souvent Adobe Reader, ce super logiciel qui est en passe de dépasser ie6 dans le top des softs moisis.
Faut pas se leurrer, le but est pas de remplacer evince et co sur linux, mais bien de faire à acrobat reader ce qui a été fait à IE sur windows et companie.
[^] # Re: On voit donc que gnome 3 est au top des environnements utilisés
Posté par Misc (site web personnel) . En réponse au sondage Avez-vous migré vers Gnome 3 ?. Évalué à 2.
Perso, j'ai pas fait gaffe du tout à ce détail