Les variables d'environnement sont hérités par les processus fils, pas par les processus parents. Tout au plus, tu peux bidouillé en écrivant /etc/profile ou en faisant des trucs avec pam.
(ou tu peux faire un module moche dans le kernel pour écraser l'env des softs existants)
Non, la tu parles de cgroups tout court, à aucun moment tu ne parles de selinux dans ta réponse. Quand aux histoires de hiérarchies des cgroups, c'est une chose que le dev des cgroups veut revoir pour justement éviter l'explosion de complexité, cf par exemple le dernier linuxmag ou il est interviewé. Systemd utilise le concept de slices pour faire une abstraction sur tout ça.
Fedora a écrit un wrapper qui a son tour lance HAProxy - sinon
c'est la guerre au moment des reloads.
Je vais coller le fichier unit qu'on voit le fameux wrapper :
Je ne sais pas quel distribution tu utilises pour faire du systemd avec un wrapper haproxy, mais ça doit pas être Fedora à vue de nez. Y a pas de mention du wrapper dans le changelog du paquet, pas de patch.
Si vous avez déjà vos politiques cgroups et selinux, vous
pouvez prier qu'elles soient compatibles avec systemd,
parce que l'alternative est probablement de redéfinir des
politiques à partir de 0…
Tu bullshites ( comme d'hab sur certains sujets, donc je vais pas passer du temps à te répondre ). Sur une distro RHEL 6, pour avoir un programme lancé par init, tu va utiliser ça par exemple:
init_daemon_domain(ahcpd_t, ahcpd_exec_t)
Sur une fedora 20, avec systemd, tu va utiliser:
init_daemon_domain(ahcpd_t, ahcpd_exec_t)
La réécriture est en effet si douloureuse qu'on pourrais croire qu'il y a rien à faire à part recompiler la policy. Mais peut être que tu veux dire qu'il faut rajouter des autorisations quand on rajoute des fonctions ( car peut être que "compatible avec systemd", tu veux dire "compatible avec l'activation par socket" ce qui est totalement différent, et qui reviens à dire "selinux requiert de tout refaire de 0 si jamais on rajoute une feature sur un soft", ce qui est n'importe quoi ).
Certains logiciels (dont l'excellent HAProxy) ne peuvent tout
simplement être lancés par systemd
[root@liliana misc]# systemctl status haproxy
haproxy.service - HAProxy For TCP And HTTP Based Applications
Loaded: loaded (/usr/lib/systemd/system/haproxy.service; disabled)
Active: active (running) since dim. 2013-12-01 23:10:03 CET; 988ms ago
Process: 9018 ExecStart=/usr/sbin/haproxy -D -f /etc/haproxy/haproxy.cfg -p /run/haproxy.pid (code=exited, status=0/SUCCESS)
Process: 9015 ExecStartPre=/usr/sbin/haproxy -c -q -f /etc/haproxy/haproxy.cfg (code=exited, status=0/SUCCESS)
Main PID: 9019 (haproxy)
CGroup: /system.slice/haproxy.service
└─9019 /usr/sbin/haproxy -D -f /etc/haproxy/haproxy.cfg -p /run/haproxy.pid
déc. 01 23:10:03 liliana.example.com systemd[1]: Started HAProxy For TCP And HTTP Based Applications.
Oups, tu peut remplir un bug pour Fedora, car visiblement, la fedora 20 que j'ai a l'air de réussir à le lancer, et visiblement, ç'est un bug que ça marche.
Ensuite peut être que tu veux dire "haproxy n'utilise pas le démarrage par socket ou à la demande", ce qui est différent de "ne marche pas avec systemd". Mais bon, comme tout le reste de ta prose est assez souvent de la même acabit, je vais laisser quelqu'un d'autre te répondre ( ou ne pas passer de temps dessus, car ça ne vaut pas le temps passé à l'exercice ).
Tu aurais aussi pu cliquer sur le premier, qui pointe sur le 3eme. ( et vers d'autres articles de qualités comme "apt vs yum, what is the best one", et sans doute d'autres )
Le 3eme date de 2011, donc ça reste un document qui parle des premières versions de systemd, et qui n'abordent pas les features rajoutés par la suite ( genre les fonctions de sécurités de coupure du réseau, systemd-nspawn, etc).
Donc les arguments techniques ( car on va éviter ceux sur "propagande de RH avec tout son argent" en pointant la doc de systemd sur freedesktop , ç'est assez peu convaincant ) sont les suivants suivi de mon rebuttal :
L'argument est assez mal construit. Soit il veut dire qu'il y a déjà des outils come monit/runit, et auquel cas, je dirais que /bin/init le fait aussi, soit il veut dire que la feature est déjà utilisé avant, et auquel cas je dirait qu'il s'agit juste de coder ce qui est utilisé.
"collecting information on daemon crashes". C'est vrai, init ne le fait pas, et dans la philosophie d'avant, c'est fait par le kernel sous la forme de la création d'un coredump quelque part sur le FS. Ce que systemd fait, c'est d'enregistrer le coredump dans journald, et de sauver divers infos. Et ça n'implique pas de ne pas faire les choses à coté si quelqu'un le veux aussi, tout comme systemd n'implique pas de retirer les appels à chroot et/ou setuid bien que le faisant également ( appels parfois mal fait par les daemons, quand le logiciel ne fait pas de chdir avant ou d'initgroups, mais bon, on le saurait si la réécriture du code sans arrêt implique de faire des erreurs de temps en temps )
keeping control with cgroups. L'argument est faible, car pour lui, on a pas besoin d'utiliser les cgroups car on peut juste utiliser les cgroups. Je suppose qu'il veut dire "y a pas besoin d'utiliser les cgroups dans le binaire d'init car on peut juste demander à tout les scripts de le faire directement". Mais la, curieusement, il ne dit pas "good luck making the author conform to a single standard", alors que visiblement, c'est ce qui arriverais.
delayed on demand. La, l'auteur dit que ça sert à rien ( car la ram sur sa workstation est suffisante et/ou la swap sert à ça ), et si jamais ça venait à servir, on peut déjà le faire via xinetd ( car soyons sérieux, inetd est un peu merdique à utiliser, et je mentirais si je faisait la comparaison en le prenant comme base ). Le fait que par exemple xinetd ne supporte pas les sockets unix, le fait que ça supporte pas les scripts d'init classiques, c'est des détails d'implémentation. Détail que personne n'a codé depuis que xinetd existe mais sans doute parce que ça sert à rien ( le fait que cups s'en serve, que X11 sur mac s'en serve et que j'ai une dizaine d'autres trucs sur mon laptop montre peut être que ça sert pas à rien ). L'auteur loupe aussi que ç'est pas juste "économiser de la ram", mais surtout assurer la parallélisation par design.
"dependency based service management". La, le mec semble vivre dans un monde à part, car "on range les choses dans un ordre arbitraire", ça n'a rien à voir avec la gestion de dépendance. Par exemple, la gestion de dépendance, ça implique que la transaction échoue si une dep échoue. Chose que sysvinit ne fait pas. Mais je peux reconnaitre que je voit fort peu d'usage en local ( à part "postfix a besoin que ldap soit up sinon il rejette les mails" et ce genre de choses ). Et bien sur, le mec n'a pas lu la doc de systemd, car l'option --ignore-dependencies existe. Donc la partie sur "l'admin doit pouvoir faire ce qu'il veut" est factuellement incorrect.
la partie sur autofs est light sur les détails. Je ne pige pas exactement ce qu'il veut dire, car je voit moi que les unités sont pour la plupart lancé après local-fs.target, donc le souci ne semble pas vraiment se poser dans mon cas d'usage. Mais bon, je ne m'y connais pas en autofs, à part que autofs sur linux fait jurer mon coloc à intervalles régulier. Je vais donc laisser le bénéfice du doute.
listening on hardware change. Que je sache, ç'est fait via udev. Et donc ça rentre dans "c'est déjà fait ailleurs". Donc c'est un peu creux comme argument, surtout parce qu'il est pas détaillé des masses. Au passage, upstart va bien plus loin que systemd et gère les choses de façons bien plus poussé, comme le montre un des développeurs : http://ifdeflinux.blogspot.fr/2013/04/upstart-user-sessions-in-ubuntu-raring.html ( c'est vers la fin ).
enfin, l'argument qui tue : "dbus, c'est orienté desktop, car c'est dans le nom". Il y a aucun example de ce qu'il propose de mieux comme les sunrpc de nfs, java rmi, ou faire ça en xml-rpc par dessus le réseau, en soap ? Je suis pas sur que ça soit mieux, tout le monde rale sur soap, sunrpc est inutilisé ( et semble un peu compliqué à utiliser ). Mais encore une fois, sans argument, j'aurais tendance à dire que c'est un détail. Après tout, d'autres composants ( nm, upstart, bluez, wpa_supplicant pour ne citer qu'eux) passent aussi par dbus donc ça a une certaine logique de se baser sur ce que les autres font.
Donc au final, les arguments sont très discutables. Certains sont incorrects ( le 5 ), d'autres sont assez peu explicites ( le 6, le 8, le 1 ), d'autres sont pas très clairs car ça demande à réutiliser des choses existantes ce qui est le cas ( le 3, le 7 ). Il reste donc le 2 et le 4, à savoir la gestion des crashs, qui n'obligent à rien ( et qui reste une feature pour journald, donc hors du pid 1 ) et la partie sur le démarrage à la demande.
Grosso modo, je pense que la discussion et les arguments ont été exposés en détails et les gens considèrent la position comme étant final ( ie, les pages sont complètes ).
Celle de systemd est déclaré final : http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708#538
et celle de openrc :
bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708#558
Donc depuis fin novembre, je pense que c'est bon, et la phase suivante peut commencer ( malgré la tentative de Ian jackson de relancer le débat en parlant de sécurité ).
Le caractère essential du package sysvinit me semble raisonnable
Pour les gens qui n'ont pas lu le lien, je le colle :
"Essential is defined as the minimal set of functionality that must be available and usable on the system at all times, even when packages are in the "Unpacked" state. "
IE, essential est utilisé pour les trucs qu'on ne peut pas retirer, et qu'on estime donc faire parti de la base sur laquelle on peut s'appuyer. Donc ça impose le support des scripts d'init aux DDs. Le choix oui, mais pas pour les DDs, sauf si par choix on veut dire "faire tout ce que les utilisateurs veulent".
Faudrait avoir plus qu'un rêve, genre avoir la possibiltié de faire la chose, si seulement les sources des distributions étaient disponibles, et si seulement le code pouvait donner le droit de faire ce qu'on veut (ou presque) avec ..
Si il y a autant de gens qui cherchent à remplacer
NetworkManager, systemd, udev ou dbus, il faudrai peut-être
regarder pourquoi.
bah, systemd est lui même censé remplacé sysvinit, et contrairement à systemd, sysvinit a été remplacé par : openrc, upstart, launchd, smf, parmi tant d'autres.
Au contraire, j'attends de voir qui remplace udev ou dbus.
Par exemple, qui utilise eudev, en dehors de gentoo ?
Et en fait, au vue de l'activité des derniers mois, ou on voitsoit des commits qui sont globalement une synchro du travail de l'original, ou rien à part de la doc, ou sont tout les gens qui veulent remplacer udev ?
Ou sont tout les gens qui poussent à faire des distros basé sur mdev ? Ou sont les gens qui ont cherché à garder devfsd en vie ? Tout ces howtos pour avoir une distro avec un /dev statique et tout les avantages si innombrale qu'on comprends pas comment on peut s'en passer ?
Il me semble que IBM édite aussi une version de Linux mais
pousse plus son AIX sur les grosses machines.
IB n'édite pas de version de Linux, ils proposent du RHEL, voir du SLES, en fonction de ce que les clients demandent. Si jamais les clients venaient à demander en masse autre chose, je suis sur qu'IBM le ferait sans souci.
D'une part, du fait d'avoir des développeurs en grand nombre. Je peux citer par exemple les contributeurs à gcc, à Linux, à gnome, etc, etc. Des logiciels que tout le monde utilise sans le savoir sont des contributions directs de salariés de la boite, comme par exemple kvm. Tu retrouves les gens dans les projets comme coreutils ( http://git.savannah.gnu.org/cgit/coreutils.git ). Tu peux avoir plus de détails sur http://community.redhat.com/software/
Ensuite, le fait d'avoir pris le magma primal qu'est le corpus de logiciels libres disponibles et d'en avoir fait un produit fini. Plein de boite le font, je ne dit pas le contraire, mais RH a réussi à s'en tirer de façon des plus honorables. La documentation traduite, écrit par des personnes à temps plein, a beaucoup aidé pour la perception du logiciel libre. De même, le fait de faire de la QA un peu plus formel que "si personne ne signale de bug alors c'est bon", de faire des revues de sécurités sur le code, de faire certifier les OS pour divers gouvernements, etc. Ou simplement de proposer du support, des roadmaps sur leurs produits.
Et troisièmement, le fait de ne pas s'opposer à la communauté, mais d'en faire parti. Par exemple, avoir monté des choses comme l'OIN pour tous et pas juste pour leur propre pomme, d'envoyer des avis légaux sur les procés sur les brevets logiciels afin d'aider à établir une jurisprudence en faveur du libre, d'être sponsor pour la Linux Fondation, pour pycon et d'autres, d'avoir aidé à monter la fondation Openstack, d'avoir proposé des briques comme libvirt ( sur lequel repose quand même pas mal de projet d'IaaS du moment ).
Pour quiconque l'ayant utilisé en server, c'est une plaie!
C'est une affirmation qui manque fortement de substance, et je suis sur que ton propos gagnerais en solidité si il était moins lapidaire. Mais sinon, il semble qu'il y a plein de gens satisfait de RHEL sur les serveurs, en partie de part la stabilité de la chose.
Sinon, moi, j'ai une Fedora sur un serveur, et je suis content d'avoir des choses comme selinux, comme systemd, comme des versions récentes de divers composants. Peut être qu'il y a des gens qui sont content d'avoir hadoop sans installer à la main ( cf https://fedoraproject.org/wiki/Releases/20/ChangeSet ) ou sans avoir à prendre des dépôts non officiels.
Je ne compare pas le développeur propriétaire à un esclavagiste, je donne un contre exemple au fait que l'argument de la diversité est valable.
Soit je donne un exemple ou une majorité de gens estime que la diversité passe en arrière plan, soit j'en trouve un ou tout le monde estime que la diversité passe en arrière plan. Si j'avais choisi le premier cas, je pense que la discussion virer sur le fait que ça soit discutable. Donc du coup, il a fallu prendre le 2eme, avec effectivement le risque que quelqu'un comprenne de travers et voit une comparaison direct alors que ce n'est pas le cas. On noteras que j'ai fait l'effort de pas donner le nazisme.
Je répète, l'argument "il faut garder la diversité des licences" est vide et creux de sens. Celui "les développeurs doivent pouvoir faire ce qu'ils veulent dans la limite de la loi" est déjà plus défendable.
le tout ensuite est de savoir ce qu'on estime juste et équitable, et savoir si on veut autoriser les choses en dehors de ce qu'on estime juste et équitable.
Mais dans ce cas, c'est le droit du développeur à choisir que tu veux défendre, pas le fait de garder la diversité parce que la diversité est vu comme bien.
La biodiversité à tout prix en gardant les licences propriétaires, c'est un peu de la connerie. C'est comme dire qu'il faut garder une diversité en se disant qu'il y a de la place pour les esclavagistes au nom de la diversité des approches en matière de travail.
Mais tu peux défendre la liberté des gens à avoir un rapport de force en leur faveur ( ie, je garde le code pour tel ou tel raison ), parce que tu estimes que c'est légitime, que le créateur a des droits, etc.
C'est pas trés dur à voir. Si jamais les plateformes libres ( ce qui dans le cas présent représente une distro, on va dire Debian pour la peine ) prends l'ascendance sur les plateformes proprios ( on va dire OS X ), alors le modèle consistant à vendre la version OS X va s'écrouler. Tout comme les gens finançant une version Windows gratuite avec l'argent que tu te fait sur la version OS/2 ( exemple hypothétique pour bien dédramatiser ).
Tu peux vouloir te dire "il faut pas que le libre prenne le pas sur le propriétaire", mais dans ce cas, faut le dire clairement "je ne veux pas que le logiciel libre soit majoritaire, car je pense que le logiciel propriétaire… "suivi de tout les arguments que tu veux en faveur du propriétaire et pourquoi c'est meilleur pour tous ( et pas juste toi, car bien sur, avoir plus de pouvoir en ta faveur est bien mieux pour toi, comme dans tout rapport de force, mais comme dans tout rapport de force, c'est dur d'argument pour dire qu'il est mieux que ça soit inégal en sa faveur ).
On peut dire que tu vends le service de compilation sur windows.
Bien sur, le dit modèle va s'écrouler le jour ou les dites plateformes vont s'écrouler, et donc au final, tu n'as aucun intérêt financier à ce que ça n'arrive, ce qui est quelque part génant dans le fond.
Et sur tout le courant des gens voulant revenir à une aristocratie, avec parfois des idées un peu puantes ( à base de "l'intelligence est essentiellement génétique", etc ). Il y a un petit gout de Ayn Rand, du paternalisme digne de la révolution industrielle, etc, etc. J'invite les gens à lire et à commenter :)
Je pense que comme toutes les distributions, Ubuntu a des outils de verification, et le souci, c'est plus que les mainteneurs de la communauté s'en foutent ( alors que je pense que Canonical fait gaffe à ça pour main ).
Donc la solution, c'est de s'impliquer pour les aider. Pour mageia, il y a une règle, si le paquet est pas installable au moment de la release, il est viré. Ça motive beaucoup plus les gens à les corriger :)
Tu peux dire à yum de ne jamais expirer les métadonnées, et de le faire à la main avec yum makecache.
L'idée de faire ça automatiquement, c'est que ça évite les erreurs cons du style "j'ai fait ça mais ça me dit "package not found" car l'index n'est pas bon". Et au final, ça améliore la perception de ta distribution ( vu que tu élimines une classe d'erreur ) et ça réduit les appels au support ( que ça soit pro comme communautaire, la problématique est la même ).
Ensuite, je comprends que c'est pas un choix qui plait à tout le monde, que ça reste plus chiant en terme de ressources, mais faut bien faire un choix par défaut.
Tu mets un poids à chaque dépot, et en fonction du poids dans un range arbitraire ( http://linux.die.net/man/5/apt_preferences ), ça prends ou pas la priorité sur les autres dépots lors de la résolution de dépendances.
Donc de 0 à 100, y a un range, de 500 à 990, de 990 à 1000, et au delà aussi. Genre si je donne un note de 1200, alors le dépôt prends le pas sur tout les autres, même si ça fait revenir en arrière, sauf si le paquet vient du même dépot, auquel cas il va le mettre à jour.
Si le dépôt a par exemple 50, alors tu installes, mais il mets pas à jour si ç'est déjà sur place.
Etc, etc.
Alors tu peux faire ça par distribution, mais aussi par paquet.
Et à la fin, quand tu as compris ce que tu veux faire et comment le faire sur tes 15 dépôts, tu peux faire un cul de chouette, car si tu piges le pinning, tu piges le jeu aussi.
j'aurais tendance à dire qu'un serveur foireux sur une debian ou une rh, ça dit beaucoup plus sur l'admin que sur la distribution. Globalement, aucune n'a 0 bug, je peux citer des cas chiants sur chacune ( genre par exemple, l'intégration selinux de debian a des bugs, j'ai soumis 4 patchs et du coté RHEL, j'ai trouvé des bugs dans augeas et postfix qui sont corrigé en 6.5 avec l'upgrade en 1.0, par exemple ).
Des serveurs qui ont sans arrêt des emmerdes, j'ai jamais croisé, ou quand j'ai croisé, c'était rarement la faute de la distribution.
[^] # Re: Juste une question
Posté par Misc (site web personnel) . En réponse au journal Systemd va gagner une console système, un bootsplash et un login-screen. Évalué à 2.
Non.
Les variables d'environnement sont hérités par les processus fils, pas par les processus parents. Tout au plus, tu peux bidouillé en écrivant /etc/profile ou en faisant des trucs avec pam.
(ou tu peux faire un module moche dans le kernel pour écraser l'env des softs existants)
[^] # Re: GNU/SystemD/Linux
Posté par Misc (site web personnel) . En réponse au journal Systemd va gagner une console système, un bootsplash et un login-screen. Évalué à 6.
Non, la tu parles de cgroups tout court, à aucun moment tu ne parles de selinux dans ta réponse. Quand aux histoires de hiérarchies des cgroups, c'est une chose que le dev des cgroups veut revoir pour justement éviter l'explosion de complexité, cf par exemple le dernier linuxmag ou il est interviewé. Systemd utilise le concept de slices pour faire une abstraction sur tout ça.
Je vais coller le fichier unit qu'on voit le fameux wrapper :
Il n'y a pas de wrapper pour lancer haproxy, ça lance direct le binaire :
Je ne sais pas quel distribution tu utilises pour faire du systemd avec un wrapper haproxy, mais ça doit pas être Fedora à vue de nez. Y a pas de mention du wrapper dans le changelog du paquet, pas de patch.
[^] # Re: GNU/SystemD/Linux
Posté par Misc (site web personnel) . En réponse au journal Systemd va gagner une console système, un bootsplash et un login-screen. Évalué à 8.
Tu bullshites ( comme d'hab sur certains sujets, donc je vais pas passer du temps à te répondre ). Sur une distro RHEL 6, pour avoir un programme lancé par init, tu va utiliser ça par exemple:
Sur une fedora 20, avec systemd, tu va utiliser:
La réécriture est en effet si douloureuse qu'on pourrais croire qu'il y a rien à faire à part recompiler la policy. Mais peut être que tu veux dire qu'il faut rajouter des autorisations quand on rajoute des fonctions ( car peut être que "compatible avec systemd", tu veux dire "compatible avec l'activation par socket" ce qui est totalement différent, et qui reviens à dire "selinux requiert de tout refaire de 0 si jamais on rajoute une feature sur un soft", ce qui est n'importe quoi ).
Oups, tu peut remplir un bug pour Fedora, car visiblement, la fedora 20 que j'ai a l'air de réussir à le lancer, et visiblement, ç'est un bug que ça marche.
Ensuite peut être que tu veux dire "haproxy n'utilise pas le démarrage par socket ou à la demande", ce qui est différent de "ne marche pas avec systemd". Mais bon, comme tout le reste de ta prose est assez souvent de la même acabit, je vais laisser quelqu'un d'autre te répondre ( ou ne pas passer de temps dessus, car ça ne vaut pas le temps passé à l'exercice ).
[^] # Re: GNU/SystemD/Linux
Posté par Misc (site web personnel) . En réponse au journal Systemd va gagner une console système, un bootsplash et un login-screen. Évalué à 8.
Tu aurais aussi pu cliquer sur le premier, qui pointe sur le 3eme. ( et vers d'autres articles de qualités comme "apt vs yum, what is the best one", et sans doute d'autres )
Le 3eme date de 2011, donc ça reste un document qui parle des premières versions de systemd, et qui n'abordent pas les features rajoutés par la suite ( genre les fonctions de sécurités de coupure du réseau, systemd-nspawn, etc).
Donc les arguments techniques ( car on va éviter ceux sur "propagande de RH avec tout son argent" en pointant la doc de systemd sur freedesktop , ç'est assez peu convaincant ) sont les suivants suivi de mon rebuttal :
L'argument est assez mal construit. Soit il veut dire qu'il y a déjà des outils come monit/runit, et auquel cas, je dirais que /bin/init le fait aussi, soit il veut dire que la feature est déjà utilisé avant, et auquel cas je dirait qu'il s'agit juste de coder ce qui est utilisé.
"collecting information on daemon crashes". C'est vrai, init ne le fait pas, et dans la philosophie d'avant, c'est fait par le kernel sous la forme de la création d'un coredump quelque part sur le FS. Ce que systemd fait, c'est d'enregistrer le coredump dans journald, et de sauver divers infos. Et ça n'implique pas de ne pas faire les choses à coté si quelqu'un le veux aussi, tout comme systemd n'implique pas de retirer les appels à chroot et/ou setuid bien que le faisant également ( appels parfois mal fait par les daemons, quand le logiciel ne fait pas de chdir avant ou d'initgroups, mais bon, on le saurait si la réécriture du code sans arrêt implique de faire des erreurs de temps en temps )
keeping control with cgroups. L'argument est faible, car pour lui, on a pas besoin d'utiliser les cgroups car on peut juste utiliser les cgroups. Je suppose qu'il veut dire "y a pas besoin d'utiliser les cgroups dans le binaire d'init car on peut juste demander à tout les scripts de le faire directement". Mais la, curieusement, il ne dit pas "good luck making the author conform to a single standard", alors que visiblement, c'est ce qui arriverais.
delayed on demand. La, l'auteur dit que ça sert à rien ( car la ram sur sa workstation est suffisante et/ou la swap sert à ça ), et si jamais ça venait à servir, on peut déjà le faire via xinetd ( car soyons sérieux, inetd est un peu merdique à utiliser, et je mentirais si je faisait la comparaison en le prenant comme base ). Le fait que par exemple xinetd ne supporte pas les sockets unix, le fait que ça supporte pas les scripts d'init classiques, c'est des détails d'implémentation. Détail que personne n'a codé depuis que xinetd existe mais sans doute parce que ça sert à rien ( le fait que cups s'en serve, que X11 sur mac s'en serve et que j'ai une dizaine d'autres trucs sur mon laptop montre peut être que ça sert pas à rien ). L'auteur loupe aussi que ç'est pas juste "économiser de la ram", mais surtout assurer la parallélisation par design.
"dependency based service management". La, le mec semble vivre dans un monde à part, car "on range les choses dans un ordre arbitraire", ça n'a rien à voir avec la gestion de dépendance. Par exemple, la gestion de dépendance, ça implique que la transaction échoue si une dep échoue. Chose que sysvinit ne fait pas. Mais je peux reconnaitre que je voit fort peu d'usage en local ( à part "postfix a besoin que ldap soit up sinon il rejette les mails" et ce genre de choses ). Et bien sur, le mec n'a pas lu la doc de systemd, car l'option --ignore-dependencies existe. Donc la partie sur "l'admin doit pouvoir faire ce qu'il veut" est factuellement incorrect.
la partie sur autofs est light sur les détails. Je ne pige pas exactement ce qu'il veut dire, car je voit moi que les unités sont pour la plupart lancé après local-fs.target, donc le souci ne semble pas vraiment se poser dans mon cas d'usage. Mais bon, je ne m'y connais pas en autofs, à part que autofs sur linux fait jurer mon coloc à intervalles régulier. Je vais donc laisser le bénéfice du doute.
listening on hardware change. Que je sache, ç'est fait via udev. Et donc ça rentre dans "c'est déjà fait ailleurs". Donc c'est un peu creux comme argument, surtout parce qu'il est pas détaillé des masses. Au passage, upstart va bien plus loin que systemd et gère les choses de façons bien plus poussé, comme le montre un des développeurs :
http://ifdeflinux.blogspot.fr/2013/04/upstart-user-sessions-in-ubuntu-raring.html ( c'est vers la fin ).
enfin, l'argument qui tue : "dbus, c'est orienté desktop, car c'est dans le nom". Il y a aucun example de ce qu'il propose de mieux comme les sunrpc de nfs, java rmi, ou faire ça en xml-rpc par dessus le réseau, en soap ? Je suis pas sur que ça soit mieux, tout le monde rale sur soap, sunrpc est inutilisé ( et semble un peu compliqué à utiliser ). Mais encore une fois, sans argument, j'aurais tendance à dire que c'est un détail. Après tout, d'autres composants ( nm, upstart, bluez, wpa_supplicant pour ne citer qu'eux) passent aussi par dbus donc ça a une certaine logique de se baser sur ce que les autres font.
Donc au final, les arguments sont très discutables. Certains sont incorrects ( le 5 ), d'autres sont assez peu explicites ( le 6, le 8, le 1 ), d'autres sont pas très clairs car ça demande à réutiliser des choses existantes ce qui est le cas ( le 3, le 7 ). Il reste donc le 2 et le 4, à savoir la gestion des crashs, qui n'obligent à rien ( et qui reste une feature pour journald, donc hors du pid 1 ) et la partie sur le démarrage à la demande.
[^] # Re: GNU/SystemD/Linux
Posté par Misc (site web personnel) . En réponse au journal Systemd va gagner une console système, un bootsplash et un login-screen. Évalué à 6.
C'est une bonne question, du coup, j'ai relu :
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708
Grosso modo, je pense que la discussion et les arguments ont été exposés en détails et les gens considèrent la position comme étant final ( ie, les pages sont complètes ).
Celle de systemd est déclaré final :
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708#538
Celle de upstart :
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708#548
Celle du support multiple :
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708#553
et celle de openrc :
bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708#558
Donc depuis fin novembre, je pense que c'est bon, et la phase suivante peut commencer ( malgré la tentative de Ian jackson de relancer le débat en parlant de sécurité ).
[^] # Re: GNU/SystemD/Linux
Posté par Misc (site web personnel) . En réponse au journal Systemd va gagner une console système, un bootsplash et un login-screen. Évalué à 1.
Mhhh intéressant :
suivi de
Pour les gens qui n'ont pas lu le lien, je le colle :
"Essential is defined as the minimal set of functionality that must be available and usable on the system at all times, even when packages are in the "Unpacked" state. "
IE, essential est utilisé pour les trucs qu'on ne peut pas retirer, et qu'on estime donc faire parti de la base sur laquelle on peut s'appuyer. Donc ça impose le support des scripts d'init aux DDs. Le choix oui, mais pas pour les DDs, sauf si par choix on veut dire "faire tout ce que les utilisateurs veulent".
[^] # Re: Busybox
Posté par Misc (site web personnel) . En réponse au journal Systemd va gagner une console système, un bootsplash et un login-screen. Évalué à 7.
Faudrait avoir plus qu'un rêve, genre avoir la possibiltié de faire la chose, si seulement les sources des distributions étaient disponibles, et si seulement le code pouvait donner le droit de faire ce qu'on veut (ou presque) avec ..
[^] # Re: GNU/SystemD/Linux
Posté par Misc (site web personnel) . En réponse au journal Systemd va gagner une console système, un bootsplash et un login-screen. Évalué à 10.
bah, systemd est lui même censé remplacé sysvinit, et contrairement à systemd, sysvinit a été remplacé par : openrc, upstart, launchd, smf, parmi tant d'autres.
Au contraire, j'attends de voir qui remplace udev ou dbus.
Par exemple, qui utilise eudev, en dehors de gentoo ?
Et en fait, au vue de l'activité des derniers mois, ou on voitsoit des commits qui sont globalement une synchro du travail de l'original, ou rien à part de la doc, ou sont tout les gens qui veulent remplacer udev ?
Ou sont tout les gens qui poussent à faire des distros basé sur mdev ? Ou sont les gens qui ont cherché à garder devfsd en vie ? Tout ces howtos pour avoir une distro avec un /dev statique et tout les avantages si innombrale qu'on comprends pas comment on peut s'en passer ?
[^] # Re: La touche finale
Posté par Misc (site web personnel) . En réponse au journal Systemd va gagner une console système, un bootsplash et un login-screen. Évalué à 3.
Tu peux aussi parler de Greg KH qui encourage le dit David dans son entreprise :
http://lists.freedesktop.org/archives/systemd-devel/2013-November/014836.html
[^] # Re: suprématie de RedHat?
Posté par Misc (site web personnel) . En réponse au journal Systemd va gagner une console système, un bootsplash et un login-screen. Évalué à 8.
IB n'édite pas de version de Linux, ils proposent du RHEL, voir du SLES, en fonction de ce que les clients demandent. Si jamais les clients venaient à demander en masse autre chose, je suis sur qu'IBM le ferait sans souci.
[^] # Re: La touche finale
Posté par Misc (site web personnel) . En réponse au journal Systemd va gagner une console système, un bootsplash et un login-screen. Évalué à 10.
Je pense que ça vient de plusieurs choses.
D'une part, du fait d'avoir des développeurs en grand nombre. Je peux citer par exemple les contributeurs à gcc, à Linux, à gnome, etc, etc. Des logiciels que tout le monde utilise sans le savoir sont des contributions directs de salariés de la boite, comme par exemple kvm. Tu retrouves les gens dans les projets comme coreutils ( http://git.savannah.gnu.org/cgit/coreutils.git ). Tu peux avoir plus de détails sur http://community.redhat.com/software/
Ensuite, le fait d'avoir pris le magma primal qu'est le corpus de logiciels libres disponibles et d'en avoir fait un produit fini. Plein de boite le font, je ne dit pas le contraire, mais RH a réussi à s'en tirer de façon des plus honorables. La documentation traduite, écrit par des personnes à temps plein, a beaucoup aidé pour la perception du logiciel libre. De même, le fait de faire de la QA un peu plus formel que "si personne ne signale de bug alors c'est bon", de faire des revues de sécurités sur le code, de faire certifier les OS pour divers gouvernements, etc. Ou simplement de proposer du support, des roadmaps sur leurs produits.
Et troisièmement, le fait de ne pas s'opposer à la communauté, mais d'en faire parti. Par exemple, avoir monté des choses comme l'OIN pour tous et pas juste pour leur propre pomme, d'envoyer des avis légaux sur les procés sur les brevets logiciels afin d'aider à établir une jurisprudence en faveur du libre, d'être sponsor pour la Linux Fondation, pour pycon et d'autres, d'avoir aidé à monter la fondation Openstack, d'avoir proposé des briques comme libvirt ( sur lequel repose quand même pas mal de projet d'IaaS du moment ).
C'est une affirmation qui manque fortement de substance, et je suis sur que ton propos gagnerais en solidité si il était moins lapidaire. Mais sinon, il semble qu'il y a plein de gens satisfait de RHEL sur les serveurs, en partie de part la stabilité de la chose.
Sinon, moi, j'ai une Fedora sur un serveur, et je suis content d'avoir des choses comme selinux, comme systemd, comme des versions récentes de divers composants. Peut être qu'il y a des gens qui sont content d'avoir hadoop sans installer à la main ( cf https://fedoraproject.org/wiki/Releases/20/ChangeSet ) ou sans avoir à prendre des dépôts non officiels.
[^] # Re: shareware ou logiciel libre payant ?
Posté par Misc (site web personnel) . En réponse au journal Financement des applications sur le 'bureau'. Évalué à 4.
Je ne compare pas le développeur propriétaire à un esclavagiste, je donne un contre exemple au fait que l'argument de la diversité est valable.
Soit je donne un exemple ou une majorité de gens estime que la diversité passe en arrière plan, soit j'en trouve un ou tout le monde estime que la diversité passe en arrière plan. Si j'avais choisi le premier cas, je pense que la discussion virer sur le fait que ça soit discutable. Donc du coup, il a fallu prendre le 2eme, avec effectivement le risque que quelqu'un comprenne de travers et voit une comparaison direct alors que ce n'est pas le cas. On noteras que j'ai fait l'effort de pas donner le nazisme.
Je répète, l'argument "il faut garder la diversité des licences" est vide et creux de sens. Celui "les développeurs doivent pouvoir faire ce qu'ils veulent dans la limite de la loi" est déjà plus défendable.
le tout ensuite est de savoir ce qu'on estime juste et équitable, et savoir si on veut autoriser les choses en dehors de ce qu'on estime juste et équitable.
[^] # Re: shareware ou logiciel libre payant ?
Posté par Misc (site web personnel) . En réponse au journal Financement des applications sur le 'bureau'. Évalué à 3.
Mais dans ce cas, c'est le droit du développeur à choisir que tu veux défendre, pas le fait de garder la diversité parce que la diversité est vu comme bien.
[^] # Re: shareware ou logiciel libre payant ?
Posté par Misc (site web personnel) . En réponse au journal Financement des applications sur le 'bureau'. Évalué à 6.
La biodiversité à tout prix en gardant les licences propriétaires, c'est un peu de la connerie. C'est comme dire qu'il faut garder une diversité en se disant qu'il y a de la place pour les esclavagistes au nom de la diversité des approches en matière de travail.
Mais tu peux défendre la liberté des gens à avoir un rapport de force en leur faveur ( ie, je garde le code pour tel ou tel raison ), parce que tu estimes que c'est légitime, que le créateur a des droits, etc.
[^] # Re: shareware ou logiciel libre payant ?
Posté par Misc (site web personnel) . En réponse au journal Financement des applications sur le 'bureau'. Évalué à 5.
C'est pas trés dur à voir. Si jamais les plateformes libres ( ce qui dans le cas présent représente une distro, on va dire Debian pour la peine ) prends l'ascendance sur les plateformes proprios ( on va dire OS X ), alors le modèle consistant à vendre la version OS X va s'écrouler. Tout comme les gens finançant une version Windows gratuite avec l'argent que tu te fait sur la version OS/2 ( exemple hypothétique pour bien dédramatiser ).
Tu peux vouloir te dire "il faut pas que le libre prenne le pas sur le propriétaire", mais dans ce cas, faut le dire clairement "je ne veux pas que le logiciel libre soit majoritaire, car je pense que le logiciel propriétaire… "suivi de tout les arguments que tu veux en faveur du propriétaire et pourquoi c'est meilleur pour tous ( et pas juste toi, car bien sur, avoir plus de pouvoir en ta faveur est bien mieux pour toi, comme dans tout rapport de force, mais comme dans tout rapport de force, c'est dur d'argument pour dire qu'il est mieux que ça soit inégal en sa faveur ).
[^] # Re: shareware ou logiciel libre payant ?
Posté par Misc (site web personnel) . En réponse au journal Financement des applications sur le 'bureau'. Évalué à 8.
On peut dire que tu vends le service de compilation sur windows.
Bien sur, le dit modèle va s'écrouler le jour ou les dites plateformes vont s'écrouler, et donc au final, tu n'as aucun intérêt financier à ce que ça n'arrive, ce qui est quelque part génant dans le fond.
# Un rapport avec l'article que j'ai lu hier ?
Posté par Misc (site web personnel) . En réponse au journal Démocratie : histoire d'un malentendu. Évalué à 5.
Hier soir, je suis tombé sur un article des plus intéressants sur slashdot pointant vers techcrunch :
http://techcrunch.com/2013/11/22/geeks-for-monarchy/
Et sur tout le courant des gens voulant revenir à une aristocratie, avec parfois des idées un peu puantes ( à base de "l'intelligence est essentiellement génétique", etc ). Il y a un petit gout de Ayn Rand, du paternalisme digne de la révolution industrielle, etc, etc. J'invite les gens à lire et à commenter :)
[^] # Re: Une autre vidéo
Posté par Misc (site web personnel) . En réponse au journal Démocratie : histoire d'un malentendu. Évalué à 2.
J'ai pas vu la vidéo, mais il y a un roman de Phillipe K dick sur le sujet, Loterie Solaire ( je dis ça au cas ou la vidéo n'en parle pas ).
[^] # Re: LXC
Posté par Misc (site web personnel) . En réponse à la dépêche Du chiffrement et de la sécurité sur LinuxFr.org (statut au 24/11/2013). Évalué à 4.
Regarde du coté de svirt si tu veux une approche basé sur une whitelist ( attention, ça impliqe d'avoir selinux )
[^] # Re: Décomplexé
Posté par Misc (site web personnel) . En réponse au journal [trolldi] filtrage contre les maquereaux. Évalué à 10.
C'est clair qu'il y a 30 ans, on parlait pas de censure sur l'internet
[^] # Re: Troll
Posté par Misc (site web personnel) . En réponse à la dépêche Red Hat Enterprise Linux 6.5. Évalué à 5.
Je pense que comme toutes les distributions, Ubuntu a des outils de verification, et le souci, c'est plus que les mainteneurs de la communauté s'en foutent ( alors que je pense que Canonical fait gaffe à ça pour main ).
Donc la solution, c'est de s'impliquer pour les aider. Pour mageia, il y a une règle, si le paquet est pas installable au moment de la release, il est viré. Ça motive beaucoup plus les gens à les corriger :)
[^] # Re: Troll
Posté par Misc (site web personnel) . En réponse à la dépêche Red Hat Enterprise Linux 6.5. Évalué à 4.
Tu peux dire à yum de ne jamais expirer les métadonnées, et de le faire à la main avec yum makecache.
L'idée de faire ça automatiquement, c'est que ça évite les erreurs cons du style "j'ai fait ça mais ça me dit "package not found" car l'index n'est pas bon". Et au final, ça améliore la perception de ta distribution ( vu que tu élimines une classe d'erreur ) et ça réduit les appels au support ( que ça soit pro comme communautaire, la problématique est la même ).
Ensuite, je comprends que c'est pas un choix qui plait à tout le monde, que ça reste plus chiant en terme de ressources, mais faut bien faire un choix par défaut.
[^] # Re: Troll
Posté par Misc (site web personnel) . En réponse à la dépêche Red Hat Enterprise Linux 6.5. Évalué à 3.
Apt_pinning, c'est simple.
Tu mets un poids à chaque dépot, et en fonction du poids dans un range arbitraire ( http://linux.die.net/man/5/apt_preferences ), ça prends ou pas la priorité sur les autres dépots lors de la résolution de dépendances.
Donc de 0 à 100, y a un range, de 500 à 990, de 990 à 1000, et au delà aussi. Genre si je donne un note de 1200, alors le dépôt prends le pas sur tout les autres, même si ça fait revenir en arrière, sauf si le paquet vient du même dépot, auquel cas il va le mettre à jour.
Si le dépôt a par exemple 50, alors tu installes, mais il mets pas à jour si ç'est déjà sur place.
Etc, etc.
Alors tu peux faire ça par distribution, mais aussi par paquet.
Et à la fin, quand tu as compris ce que tu veux faire et comment le faire sur tes 15 dépôts, tu peux faire un cul de chouette, car si tu piges le pinning, tu piges le jeu aussi.
[^] # Re: Troll
Posté par Misc (site web personnel) . En réponse à la dépêche Red Hat Enterprise Linux 6.5. Évalué à 10.
j'aurais tendance à dire qu'un serveur foireux sur une debian ou une rh, ça dit beaucoup plus sur l'admin que sur la distribution. Globalement, aucune n'a 0 bug, je peux citer des cas chiants sur chacune ( genre par exemple, l'intégration selinux de debian a des bugs, j'ai soumis 4 patchs et du coté RHEL, j'ai trouvé des bugs dans augeas et postfix qui sont corrigé en 6.5 avec l'upgrade en 1.0, par exemple ).
Des serveurs qui ont sans arrêt des emmerdes, j'ai jamais croisé, ou quand j'ai croisé, c'était rarement la faute de la distribution.
[^] # Re: Et l'heure ?
Posté par Misc (site web personnel) . En réponse au journal DLFP journalyser 2.0 : pas de veille techologique le weekend. Évalué à 8.
Je crois que la twittosphére commence déjà à frémir, le buzz est bientôt la !