Je le refait "est ce qu'il faut être développeur pour utiliser make et faire des choix des options de compilations pour un programme d'un million de ligne de code C", je pense qu'il faut bien se rendre compte que oui, ça aide beaucoup. En fait, c'est comme "est ce qu'il faut être mécano pour changer un moteur", la réponse est sans doute que non, mais ça aide beaucoup si il y a des emmerdes. et des emmerdes, ça arrive plus souvent qu'on croit.
Ceci dit, c'est vrai que l'option est à 'Y' par défaut, mais le doc dit "say N if unsure", cf
Déjà, d'un point de vue purement du système d'init, tu changes rien. Ou plutôt, si, tu renforces l'idée que les gens qui refusent systemd sont colériques et n'ont pas d'arguments.
Bon, moi, je suis largement en faveur de systemd, j'ai déjà largement expliqué pourquoi, j'ai montré je pense qu'il y a des raisons techniques, etc, donc je devrait me réjouir.
Mais même pour toi, si tu cherches un peu sur le web, tu va tomber sur des articles bien fait qui vont te dire que le plus à plaindre, c'est toi :
Ensuite, peut être que tu estimes que tu es quelqu'un de calme dans la vie, et que ta qualité de vie est correcte, etc, etc. Mais peut être pas.
Mais si c'est pas le cas, je doute que ça soit la faute de systemd.
Quand à être des despotes, je pense que tu as choisi le jour ou tu as choisi de dépendre du travail des autres et d'avoir des gens indépendants de ta capacité à payer ou pas en prenant des logiciels données gratuitement. À un moment, faut pas l'oublier.
La question est pas tant de gagner plus d'argent que toi. C'est de savoir si les différentes tentatives de monétiser son audience marche pour eux dans l'état. Et je pense que non, sur la base du seul chiffre publique qu'on a sur le sujet.
Ensuite, on peut eassyer de faire une estimation de combien ça coute niveau serveurs et humain pour gérer le moteur de recherche ( vu que tout est fait du coté de Canonical ), la bande passante. Et ensuite, on va pouvoir comparer ça à des bénéfices supposés sur la base des gens qui achètent des trucs via amazon et le dash. Et j'insiste sur le "et", car c'est le souci.
Pour moi, la réponse à la 2eme question est je pense "presque personne". Presque personne parce que c'est globalement moins pratique que l'achat direct chez amazon ou ailleurs. Mais ça veut pas dire personne. Moi, je fait globalement 1 achat tout les 2/3 mois chez Amazon, surtout parce que j'ai des bons d'achat. Ça monte à 30/40€ à chaque fois, ça fait 20€ par mois. Sur les 20€, je pense que Canonical touche 1€. ( et encore, je pense que 5% de referal, c'est énorme, je suis sur que c'est plus du 3%, mais j'ai pas de lien pour ça )
Je sais pas combien de gens font des achats, combien de fois, pour combien. Je sais pas combien ça coute par mois, même si j'estime quand même que doit y avoir 5/6 personnes sur le projet à minima, et un petit paquet de serveur ( on voit que 2 frontaux sur productsearch.canonical.com, mais j'imagine qu'il y a les serveurs de stockage et/ou de base de données, etc, etc ). Chaque serveur a un cout et ce cout est régulier.
La, ce que fait Canonical, c'est réduire ses couts. Comme l'amazon lens va te donner des suggestions pour toutes les recherches, pas juste pour les recherches explicites, Canonical a un taux de conversion sans doute ridicule
Si tu n'as que les vrais recherches à gérer, tu réduis tes couts sans doute de façon drastique ( genre 90% de charge système en moins, ce qui peut sans doute permettre de réduire les serveurs par un facteur 2 ou 3 ). C'est sans doute pas grand chose par rapport à la taille de la boite, mais peut être que c'est beaucoup par rapport à ce que la fonctionnalité rapporte.
Et toi, tu t'en sort parce que tu as pas le choix. Canonical a quand même toujours donné l'impression de se laisser aller. Mon estimation personnel d'un UDS, c'était quand même du 500 000€ entre location, hotel, sponsoring des hotels, etc. Le fait d'envoyer les cds partout dans le monde, c'est pareil.
Et maintenant, ben on a des UDS par video conférence, et les cds sont plus envoyés partout. Et je pense pas que les libristes sont radins. Canonical a fait une grande partie de son blé avec la boutique en ligne ( on m'a donné des chiffres de 15 à 20 millions par an sur la boutique il y a 5/6 ans en chiffre d'affaire, mais j'ai jamais pu voir ça de façon vérifiable ). La, avec Amazon, avec Ubuntu One, c'est juste moins bien que la concurrence ( ie, Amazon, Dropbox ).
Faut pas exagérer non plus. Debug est utiliser par le kernel depuis des années sans doute, mais Le code pour agir sur debug est dans systemd depuis mai 2013. Y a eu globalement des releases de la majorité des distributions depuis ( sauf Debian, RHEL, etc ), et des releases de systemd.
Donc soit personne utilise la feature, soit les codeurs kernels dans leur majorité sont pas si genés que ça.
Donc oui, un truc qui arrive dans un cas ultra spécifique, c'est pour la plupart des gens minimal.
Sinon, je vois pas ce que PA viens faire ici, à part ton obsession récurrente sur le sujet, bien sur. ( d'ailleurs, je suis étonné que tu ne parles pas de Fedora qui a cassé le kernel avec systemd entrainant la mort du logiciel libre ou ce genre de choses )
Tu veux dire le comportement de se faire insulter par Linus et par les codeurs ? Oui, je comprends pas comment on peut supporter des gens avec des avis fermes et ce genre de choses.
car certains utilisateurs sont assez bruyants pour tuer l'idée
Ah Ah Ah. Franchement,tu crois vraiment que c'est la mauvaise pub sur le web qui a tué l'idée ? Tu te mets le doigt dans l'œil. Ce qui a tué l'idée, c'est que ça rapporte que dalle. Il suffit de voir combien est ce que le deal avec magnatune a rapporté :
Pas plus que le fait d' "abandonner" upstart, bzr-ng ou kubuntu, Canonical a des ressources limités et se contente juste de réassigner les gens sur des marchés qui sont moins couteux.
Canonical est loin d'avoir les moyens d'une grosse boite, et ils sont toujours pas à l'équilibre. Même si je comprends que ça puisse être inquiétant, en particulier pour les gens qui s'appuient sur Canonical pour leur business, c'est pas non le début de la fin, c'est même plutôt sain de savoir faire ce qu'il faut pour rester à flot.
Au départ, je ne voulais pas réagir, car les pro-systèmed sont
largement majoritaire
et que ceux si ont tendance à insulter directement les autres
Cf commentaire qui suit le tien sur ce qui a commencé le thread.
Sinon, je veux bien voir ou est ce que j'ai commencé à insulter les autres. En fait, j'aimerais voir des données un peu plus précises qu'un ressenti. Même si il y a des mecs qui sont insultants ou borderline ( Zertinam me viens à l'esprit ), je n'ai pas le sentiment que ça soit la majorité.
On ne peut argumenter ne serait-ce qu’un cas sans en prendre
plein la tronche gratos. C’est quoi la prochaine étape, venir
nous démolir la tronche ?
Mes réactions n’ont eu pour but que de relever des arguments
que je trouve non pertinent, (le beau code parce qu’il utilise
des extensions d’un compilateur…)
J'ai pas dit "beau", j'ai dit "Le code est aussi plus moderne et agréable que ce que j'ai pu lire ailleurs.", suivi des raisons qui font que je le trouve plus moderne et agréable.
Moderne, car oui, je pense qu'utiliser une extension des compilos pour gérer automatiquement une partie de la mémoire, c'est plus moderne que faire tout à la main. Moderne car il y a une suite de tests, c'est loin d'être un acquis ( exemple, la suite de tests de sysvinit ). Moderne car ça utilise par exemple git et pas bzr ou cvs.
Agréable, parce que j'ai eu moins de souci à trouver ce que je voulais faire que par exemple, sur upstart. Agréable parce que je trouve que le style consistant me fait moins saigner des yeux que le code de certains plugins de sane.
Ensuite,j'ai bien conscience que la beauté est un truc différent et dépendant, et c'est bien pour ça que j'ai pas utilisé ce mot. Et en effet, ça serait non pertinent de dire "le code est beau".
Tout comme il serait non pertinent de dire "le code est moche", bien sur. Mais personne n'arrive à décrire exactement ce qui est beau et moche, donc ç'est forcement plus dur de trancher..
C'est ce que je dis : ça répond a des problématiques plus
orienté mainteneurs qu'utilisateur final.
Je ne suis pas d'accord. Quand tu es admin d'un service, la frontière entre "mainteneur" et "utilisateur final" est pas aussi marqué.
Et je pense qu'il y a des fonctions de systemd ( le fait de régler les cgroups directement dans l'unité, les templates d'unités, le capacité à surcharger la config via des mechanismes qui embrouillent pas le système de paquets ) sont bien plus pour les admins que les mainteneurs.
Donc tout dépend ce que tu appelles "utilisateur final".
Si je configure le service pour qu'il se connecte à localhost
vers un autre service, le mettre dans un network namespace
séparé ne marchera pas, sauf configuration particulière du
namespace. Pourtant j'ai bien envie qu'il n'accède pas au
réseau. Et j'ai pas envie qu'il accède à tout mes services
locaux en plus.
En fait, le souci, c'est que tu fait pas vraiment d'effort pour être crédible. Car bon, tout ton argumentaire est foireux, mais jusqu'à maintenant, il était foireux mais crédible pour quelqu'un qui passe vite fait en ayant juste lu la dépêche. La, tu passes une étape, et tu commence à dire "systemd fait pas ça", avec ça étant décrit dans la dépêche.
En l'occurrence, "JoinsNamespaceOf" qui permet d'avoir 2 service dans le même namespace. mais bon, je sais déjà ce que tu va répondre, tu va sortir des trucs à base de "oui, je veux que les 2 soit dans le même namespace mais l'un des softs aussi dans un autre namespace, etc, etc, etc". et sortir un hypothétique soft et/ou réglage que tu seras incapable de faire en bash ( car pour le moment, tu brilles pas vraiment pas ta capacité à donner des vrais explications techniques, tu restes vachement dans le flou et dans le vague ).
Et si tu n'utilises pas tout ça ? Tu es obligé de te palucher
un script de la mort quand même ?
Non, tu peux utiliser mutualiser ça dans une lib, et par exemple, utiliser autre chose que le nom pour suivre les processus.
Tu peux faire ça par pid, mais ça, ça foire quand le process forke 2/3 fois. Et il y a des races conditions si tu écrit le fichier, etc.
Tu peux faire comme upstart, et utiliser ptrace pour suivre les forks. C'est moche et ça a son lot de problème, mais c'est "portable".
Tu peux utiliser les cgroups sous linux, comme systemd. Mais c'est trop bas niveau pour bash, y a pas d'helper pour l'utiliser.
Et tu peux aussi t'en foutre et te dire "ça me concerne pas, donc ça concerne personne". Une attitude valable aprés tout.
C'est vrai qu'un bon admin n'intervient jamais après une
intrusion, il préfère laisser faire parce qu'il n'a pas que ça
a faire :)
Je parle pas d'une intrusion, mais par exemple d'un serveur partagé avec plusieurs utilisateurs. Ça se fait encore assez souvent en fait. Moi, si j'étais admin de FAC ( pour donner un exemple réaliste ), je pense que ça me ferait chier si ma gateway openbsd qui fait aussi dns ne relance pas bind parce qu'un étudiant a cru bon d'appliquer les conneries qu'il lit sur Linuxfr ( si ça marche bien sur, j'ai extrapolé sur la base du fonctionnement sur Linux, mais visiblement, c'est différent sur openbsd, donc à prendre avec des pincettes tant que quelqu'un n'a pas vérifié en détail ).
par exemple, quand l'admin dit "je veux que ce logiciel tourne sans réseau", il fait abstraction de la méthode ( à savoir les namespaces réseau ). Quand l'admin dit "je veux que tel répertoire soit non lisible par ce démon", c'est une abstraction de niveau plus haut que "faire tel truc avec le namespace". la seule chose demandé, c'est le repertoire. Le reste est fait par systemd, sans que tu dise "je veux monter un namespace avec tel permission sur tel répertoire quand je lance tel truc".
Quand tu dit "il faut assigner tant de ram pour ce groupe", systemd va faire un cgroups, et mettre la config qu'il faut.
ce point de montage doit être démontable à n'importe quel
moment", ou "ce logiciel ne supporte pas les changements
d'heures".
Tu confonds "contraintes pour qu'un système démarre" et "contraintes pour qu'un systéme tourne sans jamais aucun souci".
Donc forcément, en demandant des trucs qui sont impossible ( à savoir une fiabilité à 100% ), tu déduis "systemd permet pas de filer un truc qui marche dans tout les cas sorti de mon imagination, alors c'est pourri".
c'est cool je suis sur que les utilisateurs de Fedora ayant des > casques bluetooth seront ravis de savoir que cela ne fonctionne
plus mais cela a ete fait en toute connaissance de cause…
au contraire des gens qui bénéficient des nouveautés de bluez 5, qui devraient ne pas en bénéficier pour ça ?
Et quand tu as un peu de bouteille dans la création d'une distribution, tu vois assez vite qu'il y a toujours un arbitrage à faire pour chaque upgrade important.
C'est pas "est ce que je rajoute une régression ou pas juste pour faire chier les gens", c'est "est ce que la fonctionnalité vaut le risque de rajouter une régression". Et comme je dit, le changement a été annoncé upstream et dans Fedora, avec l'input de la communauté ( https://fedoraproject.org/wiki/Changes/Bluez5 ). Ouais, y a eu une régressions, mais c'est l'upstream qui a décidé. Et l'upstream a bougé le code dans ofono donc dans son usecase ( ie ofono + bluez, par exemple sur un téléphone ), ça marche. Je me doute bien que ça puisse faire chier, mais que je sache, tu utilises pas Fedora donc je ne pige pas en quoi ça semble te géner toi ( sauf à t'abroger le droit de parler au nom d'un groupe dont tu ne fait pas parti )
En même temps, y a pas de raison de dire du mal de Fedora, vu que ça n'a pas été fait sans regarder, il suffit de voir le thread sur le sujet ou il est dit que le profile hfp doit être codé ailleurs que dans bluez :
Si tu veux laisser le langage gérer ta RAM utilise java ;
En l'occurrence, non, ça gère que les cas les plus triviaux. Genre fermeture du fichier quand la variable sort du scope, etc, etc.
Enfin je pense que c'est pas dur de voir qu'il y a une des tonnes de possibilités entre "tout faire gérer" et "rien gérer du tout", donc je suis pas sur que la dichotomie soit un argument valable.
Utiliser des extension d'un compilateur empêche d'utiliser les
autres… pas très libre dans l'esprit
Tu peux rajouter qu'avec une unité, on a un feedback si la syntaxe est invalide. Alors qu'il y a pas vraiment de vérificateur de base avec bash (que je sache).
C'est en effet court, mais buggué. Si jamais tu utilises un truc genre containers, ou chroot, et que les processus sont visibles depuis l'extérieur, le processus à l'intérieur va se faire tuer aussi ( cf http://www.openbsd.org/cgi-bin/cvsweb/src/etc/rc.d/rc.subr?rev=1.70;content-type=text%2Fplain ).
Mais bon, openbsd a juste chroot comme solution de container, et la virtualisation du réseau, donc c'est pas non plus l'os de choix pour ça.
De plus, sous Linux, ce script aurait un souci assez évident. Je précise sous Linux parce qu'il est possible que ça ne marche pas sous OpenBSD, donc je vais pas m'avancer avant de dire "y a peut etre un souci". Donc sous Linux, on peut changer le nom d'un process en modifiant argv[0]. Donc un utilisateur sans privilége peut faire un DoS en créant un processus, puis en le renommant en "named: [priv]" et en le faisant intercepter SIGTERM ( ou en forkant lorsqu'il reçoit le SIGTERM ) pour ne pas mourir.
Sauf erreur de ma part, le script va envoyer SIGTERM sur tout les process qui matche la regexp, puis attendre 30 secondes pour conclure "ok, j'ai bien fait mon boulot" à grand coup de pgrep. Comme il n'arrive pas à tuer tout les processus, alors il va s'arreter la. Si c'est "/etc/init.d/named start", ça se lanceras pas. Si c'est /etc/init.d/named restart", ça se relanceras pas.
Bien sur, un admin peut intervenir et corriger. Car c'est bien connu, ils ont en général que ça à faire.
Mais sinon, à part ces soucis qui dérange personne à part moi ( vu que comme tu dit, personne n'a cru bon de corriger ça depuis 2 ans ), c'est pas mal, c'est en effet bien plus clair que la majorité des scripts d'init que j'ai pu lire.
Chaque script d'init s'occupe d'une seule chose et s'exécute
dans un ordre bien précis.
Ce qui est bien, c'est que comme tu restes dans le vague, on peut pas te contredire. Donc je vais arbitrairement prendre Debian comme exemple en partant du principe qu'il y a que Debian ou Ubuntu avec /etc/default, et parce tout mes autres serveurs sont en systemd ( en fait, la Debian aussi, mais y a pas d'unité sauf les miennes ). et te montrer que non, si ta distrib est Debian, alors les scripts font plus que "juste une chose" et qu'en fait, ils font des tas de trucs pour "juste une chose" qui est "lancer un programme".
On va prendre par exemple bind9. Dans le script de bind9, le script fait :
- l'ajout de localhost dans /etc/resolv.conf de façon conditionnel
- le chargement d'un module ( capabilities )
- la creation de /var/run/named
- vérifie que le réseau est configuré avant de lancer bind
Une chose et une seule ? Le chargement du module, c'est le script kmod qui doit le faire, pas lui. La creation d'un repertoire, c'est l'ordre du paquet. Et la vérification du réseau, c'est pas pour ça qu'on a les dependances LSB et que "tout se lance dans l'ordre" ?
On peut voir dbus. Il fait :
- création du repertoire pour le pid
- vérification si /proc est monté
- génere un fichier /etc/machine-id si absent
On retrouve le même pattern, vérification que tout est en place ( le reseau, /proc ) pour palier à des dépendances qu'on peut pas exprimer avec la LSB ( genre le fait d'avoir /proc ). Et la création des fichiers, chose qui devrait être fait par le paquet ou en postinst.
Ok, un autre script au hasard, celui de saslauthd. 400 lignes.
Une grande partie de la complexité vient du fait que ce script gère le fait de lancer plusieurs instances du serveur ( stop_instance, start_instance ), qu'il duplique la logique de création de répertoire avec les autres scripts, fonction createdir ( en prenant en compte selinux, contrairement aux 2 autres, ce qui fait qu'il y a soit du code en trop dans le dernier, soit des bugs dans mes 2 autres exemples ).
Il refait aussi son propre oneliner pour parser la ligne de commande de saslauthd, qui est fourni par la configuration en bash:
Code copier coller entre le start et le stop, au passage.
Donc ça fait un chouia plus que "juste lancer le daemon". Comme les scripts d'init ont leur propre logique et configuration ( cad les fichiers /etc/default de Debian ), chacun requiert sa propre logique dans le script, sa propre doc et donc entraine l'apparition de ses propres idiosyncrasies, avec ce que ça entraine en terme de formation.
Un autre exemple pour la route ?
Le script de postfix fait une vérification de la config de postfix pour voir si tu n'a pas mis "ubuntu.com ou debian.org" ( le commentaire dit "c'est pas bon, et ça fait chier les admins des domaines" ).
Il gère aussi la création du chroot pour postfix. La création du chroot implique d'analyser le fichier de config pour savoir ce qu'il faut copier, mais il y a postconf pour ça. Il y a aussi besoin de savoir si il faut un chroot ou pas, via ce morceau si claire d'awk ( car bon, faire ça en bash tu peux pas, faut faire appel à un outil externe ) :
Sinon, si tu as une Debian, tes scripts font plus qu'une chose. En fait, ils font le café. Ils gèrent chacun à leur façon la gestion de plusieurs instances en même temps, ils préparent le FS plus ou moins bien, chargent les modules, lisent la config des serveurs, avec leur propre config. C'est des programmes à part avec beaucoup de redondances.
Ton exemple est le moins cryptique qu'on puisse trouver. Un truc comme :
*/5 10 * * 2 /usr/local/bin/yourjob
Est cryptique.
Bien sur, il est cryptique car il a pas beaucoup de sens ( le job est lancé tout les mardis, à 10h par intervalles de 5 minutes, c'est assez peu courant et compliqué à souhait ).
A comparer avec :
0 */2 */3 * * /usr/local/bin/yourjob
Lancer tout les 3 jours, et avec un intervalle de 2 heures entre chaque job.
Pour les trucs simples, c'est assez simple ( une fois que tu penses à mettre 0 et pas * pour lancer une fois par heure, et quand tu penses que c'est rangé par ordre de durée ( minute -> heure -> jour -> mois ), modulo une exception pour le jour de la semaine ). Pour les trucs compliqués, c'est vachement plus compliqués.
Une autre conséquence de cette évolution rapide est que ce
logiciel est tous sauf stable et bien testé. Il s'agit au mieux
d'un soft de qualité béta.
La version 208 est listé comme LTS, et elle est intégré dans RHEL 7. Que je sache, il y a une équipe QA dédié pour justement s'assurer que les logiciels soit pas dans l'état "pas stable" pour la version finale. De ce que je vois sur ma machine de test, c'est une version 208 qui est fourni, version 208 aussi listé comme "LTS" par l'upstream de systemd, avec une branche git dédié.
On peut rajouter que pour un truc que tu qualifies de béta, y a plein de distro qui l'utilise ( Mageia, Arch, Fedora, Opensuse ), qu'il y a des hébergeurs qui l'utilisent en prod ( Pantheon system, qui parle de 500 000 unités lancés https://www.getpantheon.com/blog/pantheon-running-over-500000-systemd-units , Flow Pilots ( http://savanne.be/articles/deploying-node-js-with-systemd/ ). Il y a des boites qui l'utilisent comme CoreOS qui fait un OS dédié à avoir systemd, docker et des outils de gestions, ou Axis ( vu les patchs qui passent sur la ml ).
Le problème pour comprendre systemd est que ce logiciel évolue
à toute vitesse et que pour le comprendre et suivre cette
évolution, il faut être un développeur payé à plein temps pour
ça.
Ma foi, je vais devoir demander à mon employeur de me payer un deuxiéme salaire, car j'arrive à suivre sans bosser à plein temps dessus. En fait, sans être payé pour regarder systemd, juste par curiosité.
C'est clairement plus complexe. Et je pense que l'article "remplacer cron par systemd" est trompeur, les 2 ne font pas les mêmes choses ( exemple, systemd envoie pas de mail que je sache quand un tache est lancé ). L'idée est plus de complémenter que de remplacer.
Systemd propose des choses que cron propose pas. La gestion fines des ressources intégré dans l'unité est AMHA important pour un usage dans un adre de serveur. Par exemple, la gestion des backups et des taches nocturnes ( genre la tache de backup qui prends pas tout les i/o sur le serveur ).
La précision des timers de systemd est aussi plus fine.
OnActiveSec fait la même chose que at, OnBootSec permet de delayer le lancement d'une tache aprés le boot ( cron ne supporte que @boot je crois ). OnUnitActiveSec permet de dire "toutes les 17 minutes et 5 secondes", chose qu'on peut pas vraiment faire proprement avec cron ( non pas que ça me manque en pratique, les gens sont content d'arrondir à "toutes les 10 minutes", ou à faire une magouille à base de script et d'estimation par pgcd ).
Les timers ont aussi une résolution inférieur à la minute, ce qui est un plus dans certains cas ( je pense par exemple pour de l'embarqué ).
Et la syntaxe est aussi AMHA plus simple à comprendre, car bon, sans la doc ajouté par un patch externe à cron ( come le fait Debian et Mageia ) quand on fait crontab -e ( qui rajoute "# m h dom mon dow command" en guise de doc ), la syntaxe de "* * 5 * * /bin/foo" est pas super intuitive par rapport à celle de systemd, dont acte :
OnCalendar=08:05
vs
5 8 * * * /bin/foo
Donc non, on remplace pas cron par systemd, mais systemd peut apporter des choses à certains.
[^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
Posté par Misc (site web personnel) . En réponse au journal Systemd vs Linux, quand l'intransigeance d'un développeur tourne au ridicule.... Évalué à 2.
Je le refait "est ce qu'il faut être développeur pour utiliser make et faire des choix des options de compilations pour un programme d'un million de ligne de code C", je pense qu'il faut bien se rendre compte que oui, ça aide beaucoup. En fait, c'est comme "est ce qu'il faut être mécano pour changer un moteur", la réponse est sans doute que non, mais ça aide beaucoup si il y a des emmerdes. et des emmerdes, ça arrive plus souvent qu'on croit.
Ceci dit, c'est vrai que l'option est à 'Y' par défaut, mais le doc dit "say N if unsure", cf
https://git.kernel.org/cgit/linux/kernel/git/davem/net.git/tree/init/Kconfig#n855
[^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
Posté par Misc (site web personnel) . En réponse au journal Systemd vs Linux, quand l'intransigeance d'un développeur tourne au ridicule.... Évalué à 3.
Je suis pas sur que ça te fasse un bien fou.
Déjà, d'un point de vue purement du système d'init, tu changes rien. Ou plutôt, si, tu renforces l'idée que les gens qui refusent systemd sont colériques et n'ont pas d'arguments.
Bon, moi, je suis largement en faveur de systemd, j'ai déjà largement expliqué pourquoi, j'ai montré je pense qu'il y a des raisons techniques, etc, donc je devrait me réjouir.
Mais même pour toi, si tu cherches un peu sur le web, tu va tomber sur des articles bien fait qui vont te dire que le plus à plaindre, c'est toi :
http://youarenotsosmart.com/2010/08/11/catharsis/
Ensuite, peut être que tu estimes que tu es quelqu'un de calme dans la vie, et que ta qualité de vie est correcte, etc, etc. Mais peut être pas.
Mais si c'est pas le cas, je doute que ça soit la faute de systemd.
Quand à être des despotes, je pense que tu as choisi le jour ou tu as choisi de dépendre du travail des autres et d'avoir des gens indépendants de ta capacité à payer ou pas en prenant des logiciels données gratuitement. À un moment, faut pas l'oublier.
[^] # Re: Pourquoi ?
Posté par Misc (site web personnel) . En réponse au journal Canonical abandonne Ubuntu One. Évalué à 4.
La question est pas tant de gagner plus d'argent que toi. C'est de savoir si les différentes tentatives de monétiser son audience marche pour eux dans l'état. Et je pense que non, sur la base du seul chiffre publique qu'on a sur le sujet.
Ensuite, on peut eassyer de faire une estimation de combien ça coute niveau serveurs et humain pour gérer le moteur de recherche ( vu que tout est fait du coté de Canonical ), la bande passante. Et ensuite, on va pouvoir comparer ça à des bénéfices supposés sur la base des gens qui achètent des trucs via amazon et le dash. Et j'insiste sur le "et", car c'est le souci.
Pour moi, la réponse à la 2eme question est je pense "presque personne". Presque personne parce que c'est globalement moins pratique que l'achat direct chez amazon ou ailleurs. Mais ça veut pas dire personne. Moi, je fait globalement 1 achat tout les 2/3 mois chez Amazon, surtout parce que j'ai des bons d'achat. Ça monte à 30/40€ à chaque fois, ça fait 20€ par mois. Sur les 20€, je pense que Canonical touche 1€. ( et encore, je pense que 5% de referal, c'est énorme, je suis sur que c'est plus du 3%, mais j'ai pas de lien pour ça )
Je sais pas combien de gens font des achats, combien de fois, pour combien. Je sais pas combien ça coute par mois, même si j'estime quand même que doit y avoir 5/6 personnes sur le projet à minima, et un petit paquet de serveur ( on voit que 2 frontaux sur productsearch.canonical.com, mais j'imagine qu'il y a les serveurs de stockage et/ou de base de données, etc, etc ). Chaque serveur a un cout et ce cout est régulier.
La, ce que fait Canonical, c'est réduire ses couts. Comme l'amazon lens va te donner des suggestions pour toutes les recherches, pas juste pour les recherches explicites, Canonical a un taux de conversion sans doute ridicule
Si tu n'as que les vrais recherches à gérer, tu réduis tes couts sans doute de façon drastique ( genre 90% de charge système en moins, ce qui peut sans doute permettre de réduire les serveurs par un facteur 2 ou 3 ). C'est sans doute pas grand chose par rapport à la taille de la boite, mais peut être que c'est beaucoup par rapport à ce que la fonctionnalité rapporte.
Et toi, tu t'en sort parce que tu as pas le choix. Canonical a quand même toujours donné l'impression de se laisser aller. Mon estimation personnel d'un UDS, c'était quand même du 500 000€ entre location, hotel, sponsoring des hotels, etc. Le fait d'envoyer les cds partout dans le monde, c'est pareil.
Et maintenant, ben on a des UDS par video conférence, et les cds sont plus envoyés partout. Et je pense pas que les libristes sont radins. Canonical a fait une grande partie de son blé avec la boutique en ligne ( on m'a donné des chiffres de 15 à 20 millions par an sur la boutique il y a 5/6 ans en chiffre d'affaire, mais j'ai jamais pu voir ça de façon vérifiable ). La, avec Amazon, avec Ubuntu One, c'est juste moins bien que la concurrence ( ie, Amazon, Dropbox ).
[^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
Posté par Misc (site web personnel) . En réponse au journal Systemd vs Linux, quand l'intransigeance d'un développeur tourne au ridicule.... Évalué à 6.
Je ne suis pas sur qu'insulter les développeurs soient un usage productif de ton temps. mais c'est juste moi, hein.
[^] # Re: Désolé pour les yeux sensibles
Posté par Misc (site web personnel) . En réponse au journal Systemd vs Linux, quand l'intransigeance d'un développeur tourne au ridicule.... Évalué à 10.
Faut pas exagérer non plus. Debug est utiliser par le kernel depuis des années sans doute, mais Le code pour agir sur debug est dans systemd depuis mai 2013. Y a eu globalement des releases de la majorité des distributions depuis ( sauf Debian, RHEL, etc ), et des releases de systemd.
Donc soit personne utilise la feature, soit les codeurs kernels dans leur majorité sont pas si genés que ça.
Donc oui, un truc qui arrive dans un cas ultra spécifique, c'est pour la plupart des gens minimal.
Sinon, je vois pas ce que PA viens faire ici, à part ton obsession récurrente sur le sujet, bien sur. ( d'ailleurs, je suis étonné que tu ne parles pas de Fedora qui a cassé le kernel avec systemd entrainant la mort du logiciel libre ou ce genre de choses )
[^] # Re: Désolé pour les yeux sensibles
Posté par Misc (site web personnel) . En réponse au journal Systemd vs Linux, quand l'intransigeance d'un développeur tourne au ridicule.... Évalué à 2.
Tu veux dire le comportement de se faire insulter par Linus et par les codeurs ? Oui, je comprends pas comment on peut supporter des gens avec des avis fermes et ce genre de choses.
je vois vraiment pas d’où ça peut venir.
[^] # Re: Pourquoi ?
Posté par Misc (site web personnel) . En réponse au journal Canonical abandonne Ubuntu One. Évalué à 3.
Ah Ah Ah. Franchement,tu crois vraiment que c'est la mauvaise pub sur le web qui a tué l'idée ? Tu te mets le doigt dans l'œil. Ce qui a tué l'idée, c'est que ça rapporte que dalle. Il suffit de voir combien est ce que le deal avec magnatune a rapporté :
http://blogs.magnatune.com/buckman/2010/03/magnatune-sends-check-to-gnome-foundation-thanks-to-rhythmbox.html
Wow, sur 1 release, ça a rapporté 1000$, en 2010, donc quand Ubuntu était encore hype sans tout le monde en train de raler.
[^] # Re: Pourquoi ?
Posté par Misc (site web personnel) . En réponse au journal Canonical abandonne Ubuntu One. Évalué à 4.
Pas plus que le fait d' "abandonner" upstart, bzr-ng ou kubuntu, Canonical a des ressources limités et se contente juste de réassigner les gens sur des marchés qui sont moins couteux.
Canonical est loin d'avoir les moyens d'une grosse boite, et ils sont toujours pas à l'équilibre. Même si je comprends que ça puisse être inquiétant, en particulier pour les gens qui s'appuient sur Canonical pour leur business, c'est pas non le début de la fin, c'est même plutôt sain de savoir faire ce qu'il faut pour rester à flot.
[^] # Re: De plus en plus complexe, le système d'init...
Posté par Misc (site web personnel) . En réponse à la dépêche Spéciale Lennart Poettering : nouvelles versions de systemd et PulseAudio. Évalué à 10.
Cf commentaire qui suit le tien sur ce qui a commencé le thread.
Sinon, je veux bien voir ou est ce que j'ai commencé à insulter les autres. En fait, j'aimerais voir des données un peu plus précises qu'un ressenti. Même si il y a des mecs qui sont insultants ou borderline ( Zertinam me viens à l'esprit ), je n'ai pas le sentiment que ça soit la majorité.
Dans le style de ce message sur debian-devel :
https://lists.debian.org/debian-devel/2014/02/msg00462.html
J'ai pas dit "beau", j'ai dit "Le code est aussi plus moderne et agréable que ce que j'ai pu lire ailleurs.", suivi des raisons qui font que je le trouve plus moderne et agréable.
Tu peux relire le commentaire :
https://linuxfr.org/news/speciale-lennart-poettering-nouvelles-versions-de-systemd-et-pulseaudio#comment-1527799
Moderne, car oui, je pense qu'utiliser une extension des compilos pour gérer automatiquement une partie de la mémoire, c'est plus moderne que faire tout à la main. Moderne car il y a une suite de tests, c'est loin d'être un acquis ( exemple, la suite de tests de sysvinit ). Moderne car ça utilise par exemple git et pas bzr ou cvs.
Agréable, parce que j'ai eu moins de souci à trouver ce que je voulais faire que par exemple, sur upstart. Agréable parce que je trouve que le style consistant me fait moins saigner des yeux que le code de certains plugins de sane.
Ensuite,j'ai bien conscience que la beauté est un truc différent et dépendant, et c'est bien pour ça que j'ai pas utilisé ce mot. Et en effet, ça serait non pertinent de dire "le code est beau".
Tout comme il serait non pertinent de dire "le code est moche", bien sur. Mais personne n'arrive à décrire exactement ce qui est beau et moche, donc ç'est forcement plus dur de trancher..
[^] # Re: De plus en plus complexe, le système d'init...
Posté par Misc (site web personnel) . En réponse à la dépêche Spéciale Lennart Poettering : nouvelles versions de systemd et PulseAudio. Évalué à 5.
Je ne suis pas d'accord. Quand tu es admin d'un service, la frontière entre "mainteneur" et "utilisateur final" est pas aussi marqué.
Et je pense qu'il y a des fonctions de systemd ( le fait de régler les cgroups directement dans l'unité, les templates d'unités, le capacité à surcharger la config via des mechanismes qui embrouillent pas le système de paquets ) sont bien plus pour les admins que les mainteneurs.
Donc tout dépend ce que tu appelles "utilisateur final".
[^] # Re: De plus en plus complexe, le système d'init...
Posté par Misc (site web personnel) . En réponse à la dépêche Spéciale Lennart Poettering : nouvelles versions de systemd et PulseAudio. Évalué à 6.
En fait, le souci, c'est que tu fait pas vraiment d'effort pour être crédible. Car bon, tout ton argumentaire est foireux, mais jusqu'à maintenant, il était foireux mais crédible pour quelqu'un qui passe vite fait en ayant juste lu la dépêche. La, tu passes une étape, et tu commence à dire "systemd fait pas ça", avec ça étant décrit dans la dépêche.
En l'occurrence, "JoinsNamespaceOf" qui permet d'avoir 2 service dans le même namespace. mais bon, je sais déjà ce que tu va répondre, tu va sortir des trucs à base de "oui, je veux que les 2 soit dans le même namespace mais l'un des softs aussi dans un autre namespace, etc, etc, etc". et sortir un hypothétique soft et/ou réglage que tu seras incapable de faire en bash ( car pour le moment, tu brilles pas vraiment pas ta capacité à donner des vrais explications techniques, tu restes vachement dans le flou et dans le vague ).
[^] # Re: De plus en plus complexe, le système d'init...
Posté par Misc (site web personnel) . En réponse à la dépêche Spéciale Lennart Poettering : nouvelles versions de systemd et PulseAudio. Évalué à 3. Dernière modification le 25 mars 2014 à 13:09.
Non, tu peux utiliser mutualiser ça dans une lib, et par exemple, utiliser autre chose que le nom pour suivre les processus.
Tu peux faire ça par pid, mais ça, ça foire quand le process forke 2/3 fois. Et il y a des races conditions si tu écrit le fichier, etc.
Tu peux faire comme upstart, et utiliser ptrace pour suivre les forks. C'est moche et ça a son lot de problème, mais c'est "portable".
Tu peux utiliser les cgroups sous linux, comme systemd. Mais c'est trop bas niveau pour bash, y a pas d'helper pour l'utiliser.
Et tu peux aussi t'en foutre et te dire "ça me concerne pas, donc ça concerne personne". Une attitude valable aprés tout.
Je parle pas d'une intrusion, mais par exemple d'un serveur partagé avec plusieurs utilisateurs. Ça se fait encore assez souvent en fait. Moi, si j'étais admin de FAC ( pour donner un exemple réaliste ), je pense que ça me ferait chier si ma gateway openbsd qui fait aussi dns ne relance pas bind parce qu'un étudiant a cru bon d'appliquer les conneries qu'il lit sur Linuxfr ( si ça marche bien sur, j'ai extrapolé sur la base du fonctionnement sur Linux, mais visiblement, c'est différent sur openbsd, donc à prendre avec des pincettes tant que quelqu'un n'a pas vérifié en détail ).
[^] # Re: De plus en plus complexe, le système d'init...
Posté par Misc (site web personnel) . En réponse à la dépêche Spéciale Lennart Poettering : nouvelles versions de systemd et PulseAudio. Évalué à 5.
Tu bullshites.
par exemple, quand l'admin dit "je veux que ce logiciel tourne sans réseau", il fait abstraction de la méthode ( à savoir les namespaces réseau ). Quand l'admin dit "je veux que tel répertoire soit non lisible par ce démon", c'est une abstraction de niveau plus haut que "faire tel truc avec le namespace". la seule chose demandé, c'est le repertoire. Le reste est fait par systemd, sans que tu dise "je veux monter un namespace avec tel permission sur tel répertoire quand je lance tel truc".
Quand tu dit "il faut assigner tant de ram pour ce groupe", systemd va faire un cgroups, et mettre la config qu'il faut.
Tu confonds "contraintes pour qu'un système démarre" et "contraintes pour qu'un systéme tourne sans jamais aucun souci".
Donc forcément, en demandant des trucs qui sont impossible ( à savoir une fiabilité à 100% ), tu déduis "systemd permet pas de filer un truc qui marche dans tout les cas sorti de mon imagination, alors c'est pourri".
[^] # Re: De plus en plus complexe, le système d'init...
Posté par Misc (site web personnel) . En réponse à la dépêche Spéciale Lennart Poettering : nouvelles versions de systemd et PulseAudio. Évalué à 4.
Ah oui, c'est pour ça qu'on retire jamais des drivers du kernel ?
Par exemple, le token ring n'a pas été retiré :
http://lwn.net/Articles/497397/
Ou ça :
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=127781d1ba1ee5bbe1780afa35dd0e71583b143d
Ou les API dépréciés :
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=43720bd6014327ac454434496cb953edcdb9f8d6
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=35b2a113cb0298d4f9a1263338b456094a414057
Et je suppose bien sur aussi que tu utilises pas la glibc, car elle n'a pas non plus une politique "0 régression", cf https://bugzilla.redhat.com/show_bug.cgi?id=638477
Ou gcc, cf tout le code qui compile plus à chaque version car gcc est devenu plus strict. (exemple : http://gcc.gnu.org/gcc-4.7/porting_to.html)
[^] # Re: Ils ont de l'avance, c'est pourtant pas le premier avril !
Posté par Misc (site web personnel) . En réponse à la dépêche Spéciale Lennart Poettering : nouvelles versions de systemd et PulseAudio. Évalué à 4.
au contraire des gens qui bénéficient des nouveautés de bluez 5, qui devraient ne pas en bénéficier pour ça ?
( les nouveautés sont détaillés sur http://lwn.net/Articles/531133/, par exemple, le support des 5 nouveaux profiles BT )
Et quand tu as un peu de bouteille dans la création d'une distribution, tu vois assez vite qu'il y a toujours un arbitrage à faire pour chaque upgrade important.
C'est pas "est ce que je rajoute une régression ou pas juste pour faire chier les gens", c'est "est ce que la fonctionnalité vaut le risque de rajouter une régression". Et comme je dit, le changement a été annoncé upstream et dans Fedora, avec l'input de la communauté ( https://fedoraproject.org/wiki/Changes/Bluez5 ). Ouais, y a eu une régressions, mais c'est l'upstream qui a décidé. Et l'upstream a bougé le code dans ofono donc dans son usecase ( ie ofono + bluez, par exemple sur un téléphone ), ça marche. Je me doute bien que ça puisse faire chier, mais que je sache, tu utilises pas Fedora donc je ne pige pas en quoi ça semble te géner toi ( sauf à t'abroger le droit de parler au nom d'un groupe dont tu ne fait pas parti )
[^] # Re: Ils ont de l'avance, c'est pourtant pas le premier avril !
Posté par Misc (site web personnel) . En réponse à la dépêche Spéciale Lennart Poettering : nouvelles versions de systemd et PulseAudio. Évalué à 2.
En même temps, y a pas de raison de dire du mal de Fedora, vu que ça n'a pas été fait sans regarder, il suffit de voir le thread sur le sujet ou il est dit que le profile hfp doit être codé ailleurs que dans bluez :
https://lists.fedoraproject.org/pipermail/devel/2014-January/194512.html
Et notamment la partie sur "bluez 4 n'était plus maintenu depuis 1 an"
https://lists.fedoraproject.org/pipermail/devel/2014-January/194757.html
Et que la QA de Fedora a vu la regression, mais n'a pas jugé ça suffisamment important pour bloquer la release :
https://lists.fedoraproject.org/pipermail/devel/2014-January/194375.html
[^] # Re: De plus en plus complexe, le système d'init...
Posté par Misc (site web personnel) . En réponse à la dépêche Spéciale Lennart Poettering : nouvelles versions de systemd et PulseAudio. Évalué à 5.
En l'occurrence, non, ça gère que les cas les plus triviaux. Genre fermeture du fichier quand la variable sort du scope, etc, etc.
Enfin je pense que c'est pas dur de voir qu'il y a une des tonnes de possibilités entre "tout faire gérer" et "rien gérer du tout", donc je suis pas sur que la dichotomie soit un argument valable.
Sauf si l'extension est compatible.
En l'occurrence, on parle de ça :
http://cgit.freedesktop.org/systemd/systemd/tree/src/shared/macro.h#n47
Utilisé pour ça :
http://cgit.freedesktop.org/systemd/systemd/tree/src/shared/path-lookup.c#n93
Et la doc pour GCC est la :
http://gcc.gnu.org/onlinedocs/gcc/Variable-Attributes.html
Et c'est compatible avec llvm, cf ce morceau du code de llvm :
https://github.com/llvm-mirror/clang/blob/master/include/clang/Basic/Attr.td#L482
Il y a des gens qui compilent systemd avec clang, des patchs qui remontent donc c'est pas par hasard non plus.
[^] # Re: De plus en plus complexe, le système d'init...
Posté par Misc (site web personnel) . En réponse à la dépêche Spéciale Lennart Poettering : nouvelles versions de systemd et PulseAudio. Évalué à 7.
Tu peux rajouter qu'avec une unité, on a un feedback si la syntaxe est invalide. Alors qu'il y a pas vraiment de vérificateur de base avec bash (que je sache).
[^] # Re: De plus en plus complexe, le système d'init...
Posté par Misc (site web personnel) . En réponse à la dépêche Spéciale Lennart Poettering : nouvelles versions de systemd et PulseAudio. Évalué à 10.
C'est en effet court, mais buggué. Si jamais tu utilises un truc genre containers, ou chroot, et que les processus sont visibles depuis l'extérieur, le processus à l'intérieur va se faire tuer aussi ( cf http://www.openbsd.org/cgi-bin/cvsweb/src/etc/rc.d/rc.subr?rev=1.70;content-type=text%2Fplain ).
Mais bon, openbsd a juste chroot comme solution de container, et la virtualisation du réseau, donc c'est pas non plus l'os de choix pour ça.
De plus, sous Linux, ce script aurait un souci assez évident. Je précise sous Linux parce qu'il est possible que ça ne marche pas sous OpenBSD, donc je vais pas m'avancer avant de dire "y a peut etre un souci". Donc sous Linux, on peut changer le nom d'un process en modifiant argv[0]. Donc un utilisateur sans privilége peut faire un DoS en créant un processus, puis en le renommant en "named: [priv]" et en le faisant intercepter SIGTERM ( ou en forkant lorsqu'il reçoit le SIGTERM ) pour ne pas mourir.
Sauf erreur de ma part, le script va envoyer SIGTERM sur tout les process qui matche la regexp, puis attendre 30 secondes pour conclure "ok, j'ai bien fait mon boulot" à grand coup de pgrep. Comme il n'arrive pas à tuer tout les processus, alors il va s'arreter la. Si c'est "/etc/init.d/named start", ça se lanceras pas. Si c'est /etc/init.d/named restart", ça se relanceras pas.
Bien sur, un admin peut intervenir et corriger. Car c'est bien connu, ils ont en général que ça à faire.
Mais sinon, à part ces soucis qui dérange personne à part moi ( vu que comme tu dit, personne n'a cru bon de corriger ça depuis 2 ans ), c'est pas mal, c'est en effet bien plus clair que la majorité des scripts d'init que j'ai pu lire.
[^] # Re: De plus en plus complexe, le système d'init...
Posté par Misc (site web personnel) . En réponse à la dépêche Spéciale Lennart Poettering : nouvelles versions de systemd et PulseAudio. Évalué à 10.
Ce qui est bien, c'est que comme tu restes dans le vague, on peut pas te contredire. Donc je vais arbitrairement prendre Debian comme exemple en partant du principe qu'il y a que Debian ou Ubuntu avec /etc/default, et parce tout mes autres serveurs sont en systemd ( en fait, la Debian aussi, mais y a pas d'unité sauf les miennes ). et te montrer que non, si ta distrib est Debian, alors les scripts font plus que "juste une chose" et qu'en fait, ils font des tas de trucs pour "juste une chose" qui est "lancer un programme".
On va prendre par exemple bind9. Dans le script de bind9, le script fait :
- l'ajout de localhost dans /etc/resolv.conf de façon conditionnel
- le chargement d'un module ( capabilities )
- la creation de /var/run/named
- vérifie que le réseau est configuré avant de lancer bind
Une chose et une seule ? Le chargement du module, c'est le script kmod qui doit le faire, pas lui. La creation d'un repertoire, c'est l'ordre du paquet. Et la vérification du réseau, c'est pas pour ça qu'on a les dependances LSB et que "tout se lance dans l'ordre" ?
On peut voir dbus. Il fait :
- création du repertoire pour le pid
- vérification si /proc est monté
- génere un fichier /etc/machine-id si absent
On retrouve le même pattern, vérification que tout est en place ( le reseau, /proc ) pour palier à des dépendances qu'on peut pas exprimer avec la LSB ( genre le fait d'avoir /proc ). Et la création des fichiers, chose qui devrait être fait par le paquet ou en postinst.
Ok, un autre script au hasard, celui de saslauthd. 400 lignes.
Une grande partie de la complexité vient du fait que ce script gère le fait de lancer plusieurs instances du serveur ( stop_instance, start_instance ), qu'il duplique la logique de création de répertoire avec les autres scripts, fonction createdir ( en prenant en compte selinux, contrairement aux 2 autres, ce qui fait qu'il y a soit du code en trop dans le dernier, soit des bugs dans mes 2 autres exemples ).
Il refait aussi son propre oneliner pour parser la ligne de commande de saslauthd, qui est fourni par la configuration en bash:
Code copier coller entre le start et le stop, au passage.
Donc ça fait un chouia plus que "juste lancer le daemon". Comme les scripts d'init ont leur propre logique et configuration ( cad les fichiers /etc/default de Debian ), chacun requiert sa propre logique dans le script, sa propre doc et donc entraine l'apparition de ses propres idiosyncrasies, avec ce que ça entraine en terme de formation.
Un autre exemple pour la route ?
Le script de postfix fait une vérification de la config de postfix pour voir si tu n'a pas mis "ubuntu.com ou debian.org" ( le commentaire dit "c'est pas bon, et ça fait chier les admins des domaines" ).
Il gère aussi la création du chroot pour postfix. La création du chroot implique d'analyser le fichier de config pour savoir ce qu'il faut copier, mais il y a postconf pour ça. Il y a aussi besoin de savoir si il faut un chroot ou pas, via ce morceau si claire d'awk ( car bon, faire ça en bash tu peux pas, faut faire appel à un outil externe ) :
Sinon, si tu as une Debian, tes scripts font plus qu'une chose. En fait, ils font le café. Ils gèrent chacun à leur façon la gestion de plusieurs instances en même temps, ils préparent le FS plus ou moins bien, chargent les modules, lisent la config des serveurs, avec leur propre config. C'est des programmes à part avec beaucoup de redondances.
[^] # Re: À corriger
Posté par Misc (site web personnel) . En réponse à la dépêche Spéciale Lennart Poettering : nouvelles versions de systemd et PulseAudio. Évalué à 2.
dans le même genre, le nom du portable, c'est "lenovo yoga", pas yago.
[^] # Re: Timers
Posté par Misc (site web personnel) . En réponse à la dépêche Spéciale Lennart Poettering : nouvelles versions de systemd et PulseAudio. Évalué à 6.
Ton exemple est le moins cryptique qu'on puisse trouver. Un truc comme :
Est cryptique.
Bien sur, il est cryptique car il a pas beaucoup de sens ( le job est lancé tout les mardis, à 10h par intervalles de 5 minutes, c'est assez peu courant et compliqué à souhait ).
A comparer avec :
Lancer tout les 3 jours, et avec un intervalle de 2 heures entre chaque job.
Pour les trucs simples, c'est assez simple ( une fois que tu penses à mettre 0 et pas * pour lancer une fois par heure, et quand tu penses que c'est rangé par ordre de durée ( minute -> heure -> jour -> mois ), modulo une exception pour le jour de la semaine ). Pour les trucs compliqués, c'est vachement plus compliqués.
[^] # Re: Merci Lennart (and sinma)
Posté par Misc (site web personnel) . En réponse à la dépêche Spéciale Lennart Poettering : nouvelles versions de systemd et PulseAudio. Évalué à 4.
Virer les macs est aussi une solution…
[^] # Re: De plus en plus complexe, le système d'init...
Posté par Misc (site web personnel) . En réponse à la dépêche Spéciale Lennart Poettering : nouvelles versions de systemd et PulseAudio. Évalué à 5.
La version 208 est listé comme LTS, et elle est intégré dans RHEL 7. Que je sache, il y a une équipe QA dédié pour justement s'assurer que les logiciels soit pas dans l'état "pas stable" pour la version finale. De ce que je vois sur ma machine de test, c'est une version 208 qui est fourni, version 208 aussi listé comme "LTS" par l'upstream de systemd, avec une branche git dédié.
On peut rajouter que pour un truc que tu qualifies de béta, y a plein de distro qui l'utilise ( Mageia, Arch, Fedora, Opensuse ), qu'il y a des hébergeurs qui l'utilisent en prod ( Pantheon system, qui parle de 500 000 unités lancés https://www.getpantheon.com/blog/pantheon-running-over-500000-systemd-units , Flow Pilots ( http://savanne.be/articles/deploying-node-js-with-systemd/ ). Il y a des boites qui l'utilisent comme CoreOS qui fait un OS dédié à avoir systemd, docker et des outils de gestions, ou Axis ( vu les patchs qui passent sur la ml ).
Ma foi, je vais devoir demander à mon employeur de me payer un deuxiéme salaire, car j'arrive à suivre sans bosser à plein temps dessus. En fait, sans être payé pour regarder systemd, juste par curiosité.
[^] # Re: Timers
Posté par Misc (site web personnel) . En réponse à la dépêche Spéciale Lennart Poettering : nouvelles versions de systemd et PulseAudio. Évalué à 9.
C'est clairement plus complexe. Et je pense que l'article "remplacer cron par systemd" est trompeur, les 2 ne font pas les mêmes choses ( exemple, systemd envoie pas de mail que je sache quand un tache est lancé ). L'idée est plus de complémenter que de remplacer.
Systemd propose des choses que cron propose pas. La gestion fines des ressources intégré dans l'unité est AMHA important pour un usage dans un adre de serveur. Par exemple, la gestion des backups et des taches nocturnes ( genre la tache de backup qui prends pas tout les i/o sur le serveur ).
La précision des timers de systemd est aussi plus fine.
OnActiveSec fait la même chose que at, OnBootSec permet de delayer le lancement d'une tache aprés le boot ( cron ne supporte que @boot je crois ). OnUnitActiveSec permet de dire "toutes les 17 minutes et 5 secondes", chose qu'on peut pas vraiment faire proprement avec cron ( non pas que ça me manque en pratique, les gens sont content d'arrondir à "toutes les 10 minutes", ou à faire une magouille à base de script et d'estimation par pgcd ).
Les timers ont aussi une résolution inférieur à la minute, ce qui est un plus dans certains cas ( je pense par exemple pour de l'embarqué ).
Et la syntaxe est aussi AMHA plus simple à comprendre, car bon, sans la doc ajouté par un patch externe à cron ( come le fait Debian et Mageia ) quand on fait crontab -e ( qui rajoute "# m h dom mon dow command" en guise de doc ), la syntaxe de "* * 5 * * /bin/foo" est pas super intuitive par rapport à celle de systemd, dont acte :
vs
Donc non, on remplace pas cron par systemd, mais systemd peut apporter des choses à certains.