Posté par Kaane .
En réponse au journal udev forké.
Évalué à 1.
Sincèrement, j'apprécierais d'avoir une discussion ou je suis pas obligé de sans arrêt sortir la documentation pour dire "voila comment faire tel chose" pour dire que la personne avec qui je discute qu'elle semble être dans le faux.
Et moi donc j'apprécierai que tu lises la doc que tu me balances avant de me dire que je suis dans le faux.
Je récapitule pour ce qui ne suivent pas : on a un process qui éventuellement fork et repasse la main à l'init avant de commencer une synchronisation et finalement de lancer le vrai processus.
On va partir du principe que le process ne fork pas pour simplifier le boulot, mais c'est encore pire si il fork
Dès le départ je suis obligé d'aller remplir le PIDFile avec le PID de mon premier élément sinon ca s'arrête et systemd concluera à un echec de lancement.
Ensuite je poursuis ma synchro. Quand ma synchro est finie problème :
Soit j'avais mis RemainAfterExit à TRUE et là je peux fermer mon process de synchro l'esprit tranquille, mais si mon process principal ne se lance pas, ben systemd ne sera jamais mis au courant du fait que ca ne marche pas. Pareil si le process se lance mais meurt par la suite.
Soit j'avais mis RemainAfterExit à FALSE et là c'est le drame parceque je ne peux pas fermer mon processus de synchro avant d'être sur que la mise a jour des PID a bien eu lieu dans systemd. Sauf que je sais pas quand elle a lieu la mise à jour. Donc je boucle en mode texte du systemctl jusqu'à ce que le PID modifié soit pris en compte. (Je ne sais pas si ca a changé, mais en vrai le nouveau PID dans le fichier ne sera jamais pris en compte)
On triche avec ExecStartPre, je lance la moitié de mon script d'init en pre pour la synchro et l'autre moitié en normal.
Problème : si la synchro se foire, l'autre commande n'est jamais executée. Sauf si je mets un - devant ma commande, auquel cas l'autre commande est toujours executée. Sauf que je veux du "des fois oui, des fois non". Donc il faut que j'étoffe mes deux scripts pour que le second script puisse récupérer et analyser les résultats du premier script (BEURK). Donc non seulement j'ai deux scripts à maintenir au lieu d'un, mais en plus j'ai du boilerplate qui vient se rajouter en plus sur l'existant.
Sauf que si le second script plante pendant le démarrage, il n'est pas dit qu'il aura fait le ménage avant que le plantage. Donc un petit troisième script en ExecStartPost pour passer le balais….(que tant qu'à faire je met aussi en ExecStartPre des fois que).
YOUPI trois scripts pour le prix d'un avec du boilerplate en plus…
Ensuite, si le souci, c'est l'orchestration de services sur le réseau
Non le soucis c'est de passer le service dans un état dans lequel il pourra être orchestré par la suite. C'est dire cohérent, synchronisé, stable et avec les bon paramètres de connexion connus.
_Ou tu penses que Oracle va juste décider de maintenir un system de boot différent à base d'initscripts pur, quitte à proposer moins de fonctionnalités que ses concurrents _
Non c'est quasiment certain que systemd évoluera pour s'adapter au besoin. Je doute sincèrement que RH aille au bras de fer (c'est à dire dise à Oracle : soit c'est comme on veut, soit il va vous falloir trouver une nouvelle distrib de référence). Aucun interet pour eux. Si ils le font - c'est à dire si ils refusent de rajouter des gruikeries dans systemd malgré un besoin Oracle je leur tire mon chapeau, et j'applaudirai des deux mains. Mais très honnêtement (et il s'agit de mon opinion personnelle là) je n'y crois pas.
Posté par Kaane .
En réponse au journal udev forké.
Évalué à 2.
Ne pas confondre pas encore supporté et non supporté. Je reviens dessus dans un instant.
Je suis pas revenu dessus.
Une des conditions pour la certif Oracle est de pouvoir faire monter les disque dur en raw directement par l'appli Oracle. Apparament (je ne suis pas complètement dans le secret des dieux) ca peut poser des problèmes avec systemd.
Le problème sera très certainement résolu bientôt, mais la question est de savoir comment.
Mon pari (et la c'est personnel et je l'admet un peu trollesque) est que pour faire face à tout un tas de situation (dont celle mentionnée plus haut) systemd va devoir se rapprocher progressivement d'un shell complet (voire d'un mini OS vu le nombre d'outils qui lui sont rajoutés chaque mois).
Red Hat ne peut pas se permettre d'essuyer un refus de certification de la part d'Oracle, donc si systemd bloque systemd sera poussé à évoluer, et ca le met dans une situation désagréable (un système d'init qui s'adapte à un programme userland c'est pas forcément glop).
IE, tu peux interagir avec les processes sans souci, le cgroup dans systemd n'est la que pour dire "tel process a lancé ces 15 processes". Ensuite, oui, si tu lances les processes en dehors de systemd, bah, il va rien pouvoir faire. Tout comme si tu lances un soft a la main, l'initscript va sans doute faire de la merde
Et c'est là que le bas blesse. L'init script va faire ce que je lui demande, systemd va essayer de deviner. Si mon script d'init est merdique, ben je le corrige, si les choix de systemd sont mauvais je dispose de très peut d'outils pour le faire changer d'avis.
A l'époque des bon vieux PID dans /var quand je lançait un nouveau process je récupérais son PID et j'allais le rajouter à la mano dans une liste. C'est moche d'accord mais ça marche. L'équivalent systemd consisterait à insérer mon nouveau process dans le cgroup qui va bien. Ben je ne sais pas faire.
tu crées pas une carte réseau, tu crées au mieux une interface réseau
Si tu veux, une interface réseau virtuelle.
Quand à lancer la couche tcp/ip, tu veux sans doute dire "demander un ip" ? ( parce que la couche tcp/ip, elle est déja la, sinon ton vpn tourne sans doute pas ).
Non, non je veux bien dire lancer la couche TCP/IP. Je ne veux pas de TCP/IP (sur mes interfaces) avant que les tunnels VPN soient montés et que les interfaces virtuelles soient créées. Et non je n'ai pas besoin de TCP/IP pour monter mes VPN, c'est du gre pur (par exemple).
Donc si ton souci c'est "j'ai une config trop compliqué pour la config par défaut de network-manager, alors systemd est merdique"
C'est dans la partie chat échaudé craint l'eau froide. J'ai une config son trop complexe pour pulse-audio, j'ai une config réseau trop complexe pour network manager, j'ai un UPnP trop spécifique pour avahi - mais c'est pas grave parce que je désactive le truc qui me casse les pieds et je fais à la main.
Par contre désactiver l'init je vois pas comment faire. Surtout que je ne peux même pas ruser (en créant une unit unique avec un daemon idle en exec et un init traditionnel en pre) parceque systemd va de toute façon faire une partie du boulot que je le veuille ou non.
Enfin, si tu lit la page de man systemd.service, tu verras qu'il y a :
ExecReload=
Commands to execute to trigger a configuration reload in the
service.
Oui mais je ne veux pas qu'il charge la config par défaut, je veux qu'il charge une autre config (de maintenance par exemple), et pour l'instant la seule solution que j'ai trouvée consiste à déclarer des tonnes de variables d'environnement et à s'en souvenir.
Donc tu peux juste lancer le kill -SIGHUP qui va bien, ou lancer apachectl, ou ce que tu veux, pas besoin de rajouter un support dbus totalement fantasmé de ta part.
Prenons le cas suivant, je veux modifier un paramètre apache (ou d'un module apache) qui requiert un redémarrage d'apache. Par défaut apache est configuré pour redémarrer automatiquement dans systemd avec préservation des sockets. Qu'est-ce qu'il va se passer d'après toi si je fais apachectl restart ? Moi j'en ai pas la moindre idée. Apache va être relancé, mais par qui ? La bonne façon de faire quand on a besoin de passer par apachectl (donc pour un truc un peu plus costaud que juste restart) c'est de dire à systemd de ne plus le relancer automatiquement. Mais comment faire ?
tu va sans doute pouvoir trouver du boilerplate et des exceptions pour montrer ce que tu avances ?
Je crois avoir donné pas mal d'exemples (et là je viens d'en détailler deux) donc je pense que l'attaque gratuite n'est pas franchement de rigueur. systemd est beaucoup plus rigide que l'init classique - ca n'est pas forcément un tort, mais il manque à mon sens pas mal d'outils/d'options à systemd pour être vraiment utilisable.
Posté par Kaane .
En réponse au journal udev forké.
Évalué à 2.
_Faut savoir, tu connais systemd sur le bout des doigts pour expliquer comment dbus est obligatoire pour le debug _
A l'heure actuelle il y a une personne qui connait systemd sur le bout des doigts et peut-être 150 qui le connaissent vraiment très bien. Je ne fais pas partie de ces élus, et j'éviterai aussi longtemps que possible d'en faire partie.
En ce qui concerne DBus, à l'heure actuelle (sauf erreur de ma part) on ne dispose que de deux façon de dialoguer avec systemd : systemctl et DBus.
Si on utilise systemctl on a un nombre (pour l'instant) limité de fonctions. Un autre utilitaire systemadm est en cours de création, mais il ne fonctionne qu'en mode graphique.
Et systemctl est assez pourri. (Ce n'est pas un troll, tout le monde est d'accord là dessus même chez RH/Fedora). Pourri pourquoi ? Parcequ'il est très incomplet et pas forcément cohérent avec lui même. Sur les commandes un peu complexe on se retrouve à faire du ;echo $ $ $ pour pouvoir lire le résultat, pour certaines opérations il faut aller shooter des symlinks à la main etc.
Systemctl permet de faire très simplement toutes les opérations de base (restart, reload, reboot, status, changement d'init etc.) par contre pour les opérations un peu plus complexe il faut soit passer par des variables d'environnement, ce qui nécessite un peu de jonglerie. Par exemple que veut dire : On top of that basic environment variable substitution is supported. Use ${FOO} as part of a word, or as word of its own on the command line, in which case it will be replaced by the value of the environment variable including all whitespace it contains, resulting in a single argument. Use $FOO as a separate word on the command line, in which case it will be replaced by the value of the environment variable split up at whitespace, resulting in no or more arguments. Note that the first argument (i.e. the program to execute) may not be a variable, and must be a literal and absolute path name.
Et l'air de rien ça complique pas mal la mise en mode maintenance…
Posté par Kaane .
En réponse au journal udev forké.
Évalué à 6.
donc j'ai l'impression qu'une version d'oracle non supporté sur RHEL est un événement déjà arrivé.
Ne pas confondre pas encore supporté et non supporté. Je reviens dessus dans un instant.
Moi, quand je relit ton histoire, je vois juste un client qui collabore avec son fournisseur sur un produit pas encore sorti, et ça me semble relativement positif comme façon de faire.
C'est très positif comme façon de faire. Il faut bien voir que les scripts d'init custom sont une plaie à maintenir, et que c'est la partie sur laquelle il est le plus complexe d'obtenir du support. Donc forcément il vaut mieux s'y prendre à l'avance. Le truc est que l'on peut lancer des scripts shells standard avec systemd mais que ça coince quand même à pas mal de niveaux.
Par exemple systemd essaye de suivre le double fork de la daemonisation comme il peut, parceque le plus souvent le processus qui est lancé immédiatement n'est pas le processus définitif. Au bout d'un temps X (qui dépend de tout un tas de paramètres y compris l'age du capitaine et les exceptions codées en dur) il va choisir un ou plusieurs processus à surveiller comme étant "le(s) bon(s)" processus.
Dans le cas d'un cluster qui peut mettre un certain temps à se synchroniser avant de démarrer (des fois plusieurs minutes, rarement quelques heures) le bon processus est lancé très tard et le processus daemonisé en premier qui ne fait que la synchro s'arrête. systemd n'aime pas du tout ce comportement, et on a pas de moyen simple de lui envoyer un message pour dire "tout va bien c'est XXXX le vrai processus".
Il existe des méthodes de contournement (on peut passer certaines infos d'un processus à un autre en systemd) mais ca fait des scripts complexes avec des exceptions, des tests et des cas aux limites un peu douteux.
Tu serais pas un peu aigri et totalement subjectif ?
Si bien sur pourquoi ? Mais pour autant la question à se poser est de savoir si j'ai tort ou pas…
parce que cette argument fonctionne aussi avec dash qui peut segfaulter pour une raison x ou y…
Tout à fait, c'est d'ailleurs pour ça qu'on utilise pas dash dans les scripts d'init mais sh. Enfin chez les vrai OS en tout cas.
Ou alors, tu voulais dire que Lennart n'aurait pas du utiliser libdbus et recoder un système d'IPC à la main ? SUPER!
Il fait comme il veut du moment que mon executable est compilé en statique est peut se lancer en mode recovery quand seule la partition racine remonte.
était un gros mensonge, histoire de faire peur à tout le monde, c'est bien, tu viens de t'auto fusiller…
Pas un mensonge, sans dbus l'init est inexistant. Sans dbus-daemon, ou si le service n'a pas un support dbus explicite les controles sont très réduits.
Avoir un init c'est pas juste pouvoir lancer et arreter des processus…
Mais le service dbus-daemon n'a aucun influence sur le fonctionnement de systemd et systemctl.
Très honnêtement, et même si ca a été corrigé depuis apparament, systemd avait besoin de DBus pour démarrer pleinement au départ.
Ensuite la place du socket a été déplacée, les ouvertures de sockets se faisaient de façon légèrement différente d'une version sur l'autre et au final pas mal de gens ont eu droit au fabuleux :
Failed to get D-Bus connection: Failed to connect to socket /org/freedesktop/systemd1/private: Connection refused
Ceci dit ca fait plaisir que DBus créée maintenant lui même son propre socket (et ca rassure un peu aussi, parcequ'un programme qui prétend pouvoir créer des sockets pour tout le monde mais qui utilise DBus pour fabriquer le sien ca fait un peu peur.)
Pour rentrer à nouveau dans le troll, quid de tous les autres points mentionnés ?
C'est pas systemctl -> systemd - C'est obligatoirement systemctl -> dbus-daemon -> systemd
Non.
Je viens de faire un:
mv /usr/bin/dbus-daemon /root
Je reboot et magie systemctl fonctionne toujours…
Donc il y a eu un fallback de rajouté au moins pour systemctl. C'est une bonne chose, plus il y a d'exception dans le truc, plus vite il meurt.
Par contre existe-t-il un moyen de signifier quelquechose à systemd autrement que via DBus (ie pour tous les programmes qui ne sont pas systemsctl) ?
J'avoue volontier avoir très peu investi dans systemd, j'ai regardé, j'ai pas aimé, j'ai arrété.
Oui les sockets ont déjà été ouverte par DBus et donc systemsctl peut dialoguer avec systemd.
Maintenant désinstalle DBus et essaye de faire quoi que ce soit.
Ca ne marche pas.
Il faut donc un DBus installé et fonctionnel au moment du boot pour que systemd puisse dialogeur avec systemctl et il faut un dbus actif et fonctionnel pour pouvoir ajouter des watchers/controles/processus dans un cgroup liés à systemd après le boot.
Posté par Kaane .
En réponse au journal udev forké.
Évalué à 2.
Faux, surtout que apachectl, c'est l'exemple type de l'outils codé parce que sysvinit ne répondait pas aux besoins…
On passe sur la logique tarabiscotté (il est faux de dire que A a besoin de B pour fonctionner avec C vu que A a été créé à cause de D)
Ensuite tu penses sincèrement que toutes les options de apachectl seront codées dans un init un jour, notamment les options des modules compilés statiquement dans apache ? Parce que apachectl fait ça aussi.
T'inquiètes, si systemd devient vraiment le standard, ton apachectl, il va partir dans /dev/null
Clairement, si systemd devient le standard, apache laisse tomber windows, Mac et *BSD.
Et je le redis: systemd n'a pas besoin de dbus pour fonctionner et pour controller les services
CF mon autre post dans l'autre thread pour cette question, systemd est aveugle et sourd sans DBus. (ce qui ne l'empêche pas de lancer des services d'accord, mais pour le contrôle on repassera)
Dbus est lancé par systemd après syslog sous Arch alors j'aimerai bien savoir comment tu m'expliques ton argument pourri…
En fait tout en dans la définition du mot "dialogue". Tant que DBus n'est pas lancé, systemd est sourd. Pas moyen de lui expliquer que tu rajoutes des worker tomcat, pas moyen de lui faire comprendre que tu vas faire un restart manuel avec d'autres paramètres de tels ou tels daemon, pas moyen de lui demander d'arréter de surveiller tel ou tel daemon qui va rentrer en maintenance.
systemd peut agir sur le système, mais le système ne peut pas agir sur lui. Pas de dialogue donc…
Non systemd peu utiliser dbus pour le lancement des services mais il ne dialogue pas en interne avec dbus.
Si si, c'est même comme ça qu'il valide le bon lancement de certaines applis. Par des dialogues avec DBus. Dés que tu as un BusName ou un NotifyAccess dans systemd c'est du dialogue de DBus. Dans cet article écrit par un des plus grand détracteur de systemd que je connaisse c'est très bien expliqué : http://0pointer.de/blog/projects/systemd-for-admins-3.html
Donc effectivement, si dbus ne se lance pas, la condition tel interface dbus existe ne pourra pas être vérifiée et sera ignorée
Et tous les scripts ayant un BusName ou un NotifyAccess dans leur config auront un comportement potentiellement différent et à valider en test.
Comme udev
udev n'existe que sous Linux, mais a un comportement POSIX. Les appels udev sont assez faciles à remplacer par des appels équivalents sous d'autres OS raisonnablement posix.
On continue dans le n'importe quoi, si tes démons n'ont pas le Wants=local-fs.target, tes fs locaux ne seront pas montés sauf si:
Erreur, les wants permettent de définir ce dont on a besoin, pas ce dont on ne veut pas. Si je veux que mon unit arrivent dans un systeme ou "tartempion" n'existe pas, il faut que j'active dans mon script "before = tartampion" ou alors si plusieurs daemon peuvent remplir une condition faire des "Wanted-By = ", sauf que dans le cas de local-fs.target tu l'as dans l'os. Quoi qu'il arrive systemd executera quand même cet unit quand il en a besoin (même si par exemple le daemon qui déchiffre les données n'est pas actif sur une partition chiffré)
Avec Wants=local-fs.target tout ce que j'ai c'est que mes disques locaux ne seront peut-être pas monté. Mais peut-être que si.
Et en gros, si je comprend bien ton argumentation, les programmes qui ne supportent pas DBus ne fonctionne pas avec systemd, et la marmotte…
Ils peuvent être lancé par systemd, mais toutes les fonctions de controle, d'altération, de controle fin etc. ne fonctionneront pas. Donc oui, pas de DBus => appli de controle à part en dehors de systemd.
Le dialogue avec systemd se fait via socket, pas via dbus qui n'est utilisé que pour valider des conditions!
Euh… Non.
Les sockets dans systemd servent à remplacer inetd, moyennant la perte de certaines fonctionnalité, ou des patchs de code ou autres.
Le socket /run/systemd/private est désormais créé par dbus_server_listen (je te laisse deviner sur quelle outil il s'appuie).
Sans DBus systemd est sourd. (Et systemctl ne marche plus)
Posté par Kaane .
En réponse au journal udev forké.
Évalué à 1.
Ca doit prendre 2 minutes de faire une "unit" systemd qui lance des scripts shell comme le faisait sysvinit
Et qui va créer 32 watcher si tu utilise apache en mode démon+fast cgi avec 32 spawn, et comme mentionné dans un autre post on va être gentil et pas parler d'Erlang ou des programmes qui utilisent du GPGCU.
La seule bonne façon d'utiliser systemd c'est d'avoir des démons et des outils de controle (type apachectl) qui parlent courament le DBus.
Et je veux pas de DBus dans mon apache, je ne veux pas de watcher, je veux des perfs maximale parceque j'ai des centaines de milliers de connexion par minute et que le roundtrip DBus est loin d'être gratuit.
Donc non, pour des programmes aussi marginaux que apache, mysql, postfix, JBoss, Oracle etc. il va falloir rajouter des trucs dedans pour que ca marche intelligemment avec systemd, des trucs qui vont géner les perfs et dont moi, personellement, je n'ai rien à foutre.
est-ce que vous pourriez m'expliquer pourquoi systemd est-il si critiqué ?
De nombreuses raisons, mais voici les principales :
sytemd ne dialogue vraiment qu'avec dbus, si dbus ne se lance pas la machine n'a plus d'init, ou tout du moins plus un init normal, ce qui implique de faire des tests doublé pour la cohérence d'état des machines, un ou dbus démarre, un ou dbus ne démarre pas (ou pas au moment attendu). En plus le coté dialogue exclusif avec dbus nécessite l'utilisation d'un client dbus avec de gros droits si on veut pouvoir traquer un bug qui se déclare à l'init. Cette outil devra être exempt des sécurités cgroups et devra pouvoir accéder à tous les services. Ca fait une faille potentielle de plus.
systemd n'est pas compatible avec autre chose que Linux, et même pas avec autre chose que GNU/Linux à la sauce Red Hat. Bon nombre de configuration de type disques chiffrés/partition délocalisées/configuration dynamique ne sont tout simplement plus possible avec systemd qui s'attend à ce que certains éléments soient à une place bien précise avec des droits bien précis et un ordre de démarrage fixe. Notament au niveau du réseau on retrouve des défauts qui apparaissaient déjà sur networkmanager, par exemple quand il faut d'abord créer un lien VPN (PPTP, GRE ou autre) AVANT de créer une carte réseau et de lancer la couche TCP/IP. De la même façon tous les points de montage locaux sont systématiquement montés avant de lancer le moindre démon. C'est con pour Oracle par exempel qui a besoin de prendre le controle de certains points de montage en RAW et dont le montage normal ne sert qu'au debug et au cold backup. A partir de là systemd prive linux de choses importantes qu'il sait faire (et même bien faire) aujorud'hui - et il oblige en plus les devs à créer plusiseurs version de leur script d'init en fonction de la machine sur laquelle ils sont supposés s'éxecuter.
systemd pose un problème aux outils de contrôle : un truc aussi bête que apachectl devient un casse tête avec systemd, plusieurs utilisateurs peuvent controller le logiciel apache avec cet outil. Mais alors quid de systemd ? Est-ce qu'on ajoute des fonctionnalité DBus à l'outil pour lui permettre de dialoguer avec systemd pour lui dire "au fait le recharge la config" ou est-ce que l'on fait ça dans son dos en esperant qu'ils ne panique pas en voyant les processus apaches se fermer et s'ouvrir du fait d'appels à un outils qui n'est pas dans le même cgroup ? Ou alors est-ce que l'on met tout le monde dans le même cgroup, auquel cas quand on essaye de tuer un apache planté on commence par tuer l'outil qui permet d'interragir avec apache ?
(Bon pour apache les soucis sont résolus rapidement, mais pour tomcat déjà ca se complique et je ne parle pas d'Erlang ou d'autres applis distribuées)
chat échaudé craint l'eau froide : C'est pas comme si les "nouvelles API qui tuent tout" avaient une espérance de vie limité sous Linux, mais ca fait quand même 5 fois en 10 ans que l'on change complètement le paradigme d'acès au périphériques. Linux n'a pas une super réputation sur la pérénité de ses api, et pas mal de mainteneurs commencent sérieusement à en avoir marre de réinventer la roue. Devoir refaire toute la config à cause de polkit/consolekit/udev/hal qui s'enva/dbus/systemd ca amuse 5 minutes, mais là ca fait 3 ans.
Pour l'instant à moins d'une évolution très très léchée du produit par RH on est toujours obligé de gruiker les scripts pour que systemd fasse ce dont tu as besoin et pas ce qu'il veut, notamment pour les processus qui forkent dans tous les sens et qui n'ont pas de support natif de DBus. Et comme DNS, Apache et Postfix ne sont pas supposé en avoir quoi que ce soit à faire de systemd (et qu'en plus les dialogues avec systemd ne peuvent qu'avoir un impact négatif sur les perfs) ils n'auront probablement jamais de support DBus.
En fait une application unique ne peut pas faire la surveillance/le controle/le restart etc. de toutes les applis possibles et imaginables dans toutes les config possibles et imaginables - ca parait évident dit comme ça mais c'est pourtant ce qu'il essaye de faire. Donc systemd échouera, ou se pervertira jusqu'à avoir autant d'exception et de boilerplates que ses ancètres. Le test grandeur nature est juste une couteuse perte de temps.
Posté par Kaane .
En réponse au journal udev forké.
Évalué à 4.
L'espoir fait vivre hein, bon courage :p
Si encore c'était un espoir. Mais je connais déjà un gros client RH qui utilise massivement oracle avec des scripts d'init custom pas piqué des hannetons. Et là ils sont en train de bomberder le support RH de questions pour être iso fonctionnel en systemd.
Je ne pense pas un seul instant que RH va accepter de perdre ce client (même si 5 ans de support c'est long, tu peux être sur qu'à la première version d'Oracle qui n'est plus certifié sur le RH qu'ils utilisent ils changent de crêmerie).
Donc comme RH veut garder ce client (et rpobablement d'autres avec des problematiques similaires) je suis prêt à parier qu'ils vont mettre des gruikeries dans leur systemd… Et de là c'est juste une question de patience.
Posté par Kaane .
En réponse au journal udev forké.
Évalué à 10.
La réponse est pourtant simple : parce que plus personne n'est intéressé à maintenir ta chose
Dans le cadre d'un système d'init la question ne se pose pas. SystemV en lui même est très simple à maintenir, ce qui coute cher ce sont les scripts d'init. Mais à moins que Linux/systemd n'envoient tous les autres systèmes à la casse on aura toujours des scripts raisonnablement simple à adapter chez les *BSD pour toutes les applications phares.
C'est la puissance de SystemV : en quelques minutes je peux écrire un script de démarrage qui correspond exactement à mes besoins. Le seul problème qui va se poser c'est au niveau du démarrage des couches réseaux (ip, gre, pptp etc.) mais bon les scripts n'ont pas été réécrits pour le passage ifconfig -> iptables (il y a 16 ans, presque 14 ans qu'ifconfig est en deprecated) donc on peut légitimement se demander si ils vont l'être pour systemd.
bon les gars, il y a des gens qui veulent leur ancien truc juste parce qu'ils ont du mal à suivre le changement
Non, c'est juste que systemd est une mauvaise idée. Il s'agit ni plus ni moins que de la nième tentative pour normaliser Linux, on sait ce qui est arrivé aux précédentes et on a pas envie d'investir dans un truc qui va forcément se péter la gueule. (comprenons nous bien, par péter la gueule je veux aussi bien dire disparaitre que d'être obligé d'évoluer dans de telles proportion que d'ici trois ans les scripts systemd auront autant de ifdef et d’exceptions que les inits actuels).
Posté par Kaane .
En réponse au journal udev forké.
Évalué à 10.
Et pourquoi pas? C'est si horrible que ça?
Oui.
Déjà il y a des dépendances dans tous les sens, ça ne peut être piloté correctement que via DBus (donc pour le debug il va falloir créer un client DBus avec des droits démentiels et des cgroups transversaux), c'est fortement incompatible avec pas mal de méthodes de chiffrement de la partition de boot (grosso-modo tous sauf luks), ca monopolise des ressources mémoires (les cgroups c'est loin d'être gratuit, surtout en embarqué) etc.
Mais surtout :
- C'est fait par Red Hat, les experts en "on laisse tomber la fonctionnalité phare de la version précédente". Si vous avez investi dans les technos de virtualisation à la sauce Red Hat, vous savez de quoi je parle.
Il faut réécrire profondément les scripts d'init pour en tirer partie. Certes on peut créer assez rapidement des scripts qui fonctionnent du moment que l'on force une exécution séquentielle (c'est d'ailleurs ce que font pas mal de distribs en ce moment) mais pour que systemd apporte quelque chose il faut repenser l'init. Quand on voit qu'en près de 14 ans de déprécation les scripts utilisant ifconfig n'ont pas tous été réécrit et que iwconfig n'est toujours pas complètement intégré à au set d'outils iproute2 …
Vu la gueule de la stabilité API des linuxeries du passé (HAL, DBus, SELinux etc.) je n'investirais pas de temps à apprendre systemd. Et quand je n'aurais pas le choix (tous les linux avec systemd) je créerai un script bien gruik dans un cgroup absolu (tous les pouvoirs) qui lancera un bon vieux script shell en mode séquentiel. Bref il y aura un script init2 sur ma machine sur lequel je pourrais intervenir en mode texte avec pour toute arme une console et un vi.
Mais bon le truc c'est que ce qu'il y a de plus chiant dans Linux (bien plus que de gérer les dépendances et de faire un système de packages cohérent) c'est de faire des scripts d'init. C'est probablement la seule raison pour laquelle j'utilise une distrib toute faite et pas un LFS ultra customisé. Donc la perspective de devoir tous les réécrire et les maintenir pendant les deux ou trois ans que va mettre systemd à crever ne m'enchante pas.
Posté par Kaane .
En réponse au journal udev forké.
Évalué à 6.
Question inverse : pourquoi vouloir l'ancienne méthode que les mainteneurs de distro ne veulent plus si on l’utilise que 2 ou 3 fois par an?
Tu veux dire : "Pourquoi ne pas rajouter à un OS tout un tas de fonctionnalité dont tu n'as pas besoin et dont tu ne te servirais que très rarement si tu les avais à disposition ?"
Ben écoute chacun fait comme il veut bien sur, mais personnellement les trucs dont je ne me sers pas je ne les installe pas. Il y a près de 15000 packages dans ma distrib, j'évite de les installer tous.
D'ailleurs, il me semble qu'en Belgique, il est interdit de faire un don aux entreprises, il doit toujours y avoir une contrepartie (pour éviter la fraude).
Pour la Grande Bretagne je ne sais pas, mais pour à peu près tous les autres pays d'Europe (au sens CE) je suis quasiment sur que pour pouvoir faire appel à l'épargne publique il faut
- Soit être une association à but non lucratif qui récolte des dons (i.e aucune contrepartie quel quel soit)
- Soit être une association à but non lucratif qui recrute des adhérents (et là les adhérents ont des droits au sein de l'association)
- Soit être une entreprise type SA coté sur un marché (et là les souscrivant récoltent des droits)
- Soit faire un emprunt obligataire avec une banque derrière qui se porte caution (et je crois qu'il faut en plus être une SA ou assimilé)
Éventuellement être une société à capital variable ou tous les souscrivant prennent des parts hors marchés (type SACEM)
Tout le reste (y compris les dons sur une page web pour que la page/le logiciel/l'auteur continue) est assimilé à une vente - avec tout ce qui va avec.
Curieux de voir ce que les avocats de kickstarter vont pondre si ils ouvrent en France. Si ça passe leur modèle de contrat sera copié/collé des milliers de fois.
Soit deux jours de perdus pour lui ! (et de l'essence, de l'usure matériel, et du stockage perdu pour le service)
Alors pour l'essence ne t'inquiete pas trop, les facteurs se déplacent plus avec de lourds colis dans leur camionette, ils ne prennent que le coupon "absent du domicile" et se lancent dans de grandes discussion sur "la place de l'homme dans un monde de travail mécanisé" quand vous les prenez la main dans le sac (ie quand vous voulez vraiment votre colis et que vous guettez le facteur - mauvais plan en fait puisqu'il faudra de toute façon faire la queue samedi)
Et en ce qui concerne le stockage, en tassant un peu ca passe. Les colis etiquettés "fragile" sont ceux qui prennent le moins de place quand on insiste un peu.
Reste l'usure - mais bon les trucs qui s'usent le plus dans l'histoire c'est pas la Poste qui les a payé…
OS X n'a pas grand-chose en commun avec BSD. Le noyau est différent (OS X a un noyau Mach), seule une partie des outils autour du noyau sont repris de BSD.
Oui enfin si tu as compris comment marche un micro-kernel, tu te rends rapidement compte que "outils autour du noyau" ça veut dire "pilote fondamental déplacé en userland, mais pas trop". Et la partie est loin d'être négligeable…
BSD c'est pas juste un kernel, et les outils autours c'est quand même une masse conséquente de code. On serait pédant comme d'autres on prétendrait qu'il faut dire BSD/OS X et non OS X tout court
Quant au framework Cocoa (qui fait tout l'intérêt d'OS X par rapport aux autres OS), il est fait maison par Apple
Pour les utilisateurs, ils savent même pas que ca existe (j'en ai entendu des excuses cons de la part d'un utilisateur qui achetait du matériel Apple, mais j'ai pas encore eu droit au "non mais rend-toi compte ! IL A UN FRAMEWORK COCOA"). Donc l'interet est limité
Pour les developpeurs c'est un truc non portable, dont n'importe quelle partie peut être déclarée deprecated n'importe quand par une seule boite.
Pour les admins sys et autres support, c'est un truc qui te parque dans ton coin sans te laisser en sortir.
Donc l'interet, à part pour Apple je vois pas trop…
BSD est utilisé par 3 ou 4 nerds qui trouvent que linux ne leur suffit pas et ça ne va pas plus loin.
C'est vrai qu'il y a très peu de nerds sous BSD. C'est un segment sur lequel Linux règne en maitre.
BSD ne sera jamais utilisé par M. Toutlemonde sur son PC chez lui (tu me diras que Linux de moins en moins à cause de GNOME3 qui devient de plus en plus pourri)
Ben BSD a déjà le Mac, le modem, le poste radio connecté, la moitié du lecteur blu-ray et la moitié de la télé (pour les mises à jour HDCP). Plus ca serait abuser.
BSD ne sera jamais utilisé dans une vraiue entreprise (Oui, j'en suis sûr que tu as un cousin qui a installé un firewall BSD chez son oncle qui est plombier et que ça marche super bien sauf quand ça tombe en panne et que ton cousin est en vacances)
Ben c'est vrai qu'un firewall chez un plombier ca fait des étincelles forcément. Il faut juste expliquer au plombier qu'en francais firewall se dit ecluse et là il retourne dans son élément.
Quand aux vraies entreprises (c'est à dire des entreprises qui présentent des comptes vrais aux actionnaires ET aux impots) c'était le bon temps, mais ca n'existe plus tout court.
C'est un site pedagogique, il utilise toutes les méthodes disponibles pour apprendre les bases de la sécurité a des non initiés.
Les personnes qui ont utilisé leur vrai compte GitHub pour rentrer dans le site vont apprendre très vite qu'il ne faut pas donner son mot de passe à n'importe quel site sur le net.
Et désolé si mon point de vue fait que pour moi, même si elle est normale médicalement parlant, elle est maigrichonne.
Tu peux être désolé, car c'est ce genre de comportement qui génère les comportement que tu dénonces. Olivia Wilde est normale, si elle perdait deux ou trois kilos elle serait encore normale, si elle prenait dix kilos elle serait encore normale. Le fait de cataloguer une personne suivant des critères non objectifs de poids participe à la névrose. Dans un sens ou dans l'autre. Ça envoie un message fort sur la primeur de l'apparence dans les relations humaines.
Si ta fille veux maigrir il y a plusieurs choses à voir avant de tirer la sonnette d'alarme. Plusieurs choses à expliquer sur le poids et l'apparence. Il se peut parfaitement que ce soit pour attirer l'attention d'un garçon (ou d'une fille d'ailleurs) qui sort avec une personne plus fine qu'elle. Ou même parce que pendant ses règles elle fait de la rétention d'eau (elle gonfle) et qu'elle a fait inconsciemment une association poids = douleur (très très courant chez les jeunes filles) ou pour des milliers d'autres raisons.
Rejeter sa volonté de perdre du poids sans en discuter ne peut que la braquer, tu la forces à choisir un camps (je choisis le camps papa/maman en gardant mon poids actuel - ou je choisis le camps copains/liberté/émancipation en maigrissant) et à partir de la manger devient un choix politique.
Il faut avoir en tête la ligne rouge :
- si on tombe malade on peut perdre plusieurs kilos (5 ou 6 sans problème même pour des maladies qui ne passent pas par l’hôpital) - donc il faut être 5 ou 6 kg au dessus des 5% de masse graisseuse totale. Sans quoi la moindre maladie qui dure un peu met la vie en danger.
- On dispose de 3 ans de réserve de vitamine B12 et de 9 mois de réserve de potassium - au début quand on va maigrir on se sentir mieux (le poste le plus consommateur en énergie : la digestion a été sacrément réduit.) Passé la première semaine d'adaptation du corps on va se sentir en super forme. C'est un leurre, le corps va ensuite s'affaiblir lentement. Donc on peut devenir relativement maigre "parce que ça nous plait" sous réserve de faire bien attention à entretenir correctement la B12 et le potassium. si le poids est un choix et pas un problème on a aucun soucis à manger correctement (même si peu en quantité) et à prendre des compléments alimentaires. Si c'est un problème par contre il y aura quasi systématiquement rejet de l'idée même de complément alimentaire.
- Si ta fille a moins de 16 ans, elle est en pleine période de stockage du calcium. Si elle maigrit maintenant ça peut poser des problèmes par la suite si elle décide d'avoir des enfants. Si elle mange peu il faut s'assurer qu'elle prenne suffisamment de soleil (mais pas aux mauvaises heures - mélanome toussa)
- Si on arrive aux 2/3 du poids de forme moyen idéal (pour Olivia Wilde ça serait ici 42kg) c'est hospitalisation directe, avec séparation de l'environnement (familial et affectif) pendant plusieurs mois.
Le mieux une fois de plus est d'en parler à ta fille en lui donnant explicitement les règles du jeu mais surtout en gardant bien présent à l'esprit que tant qu'elle ne franchit pas la ligne rouge c'est qu'elle garde le contrôle - c'est sa préférence, qui est peut-être différente de la tienne mais c'est son corps.
[^] # Re: la guerre de s unices
Posté par Kaane . En réponse au journal udev forké. Évalué à 1.
Sincèrement, j'apprécierais d'avoir une discussion ou je suis pas obligé de sans arrêt sortir la documentation pour dire "voila comment faire tel chose" pour dire que la personne avec qui je discute qu'elle semble être dans le faux.
Et moi donc j'apprécierai que tu lises la doc que tu me balances avant de me dire que je suis dans le faux.
Je récapitule pour ce qui ne suivent pas : on a un process qui éventuellement fork et repasse la main à l'init avant de commencer une synchronisation et finalement de lancer le vrai processus.
On va partir du principe que le process ne fork pas pour simplifier le boulot, mais c'est encore pire si il fork
Les options intéressantes :
RemainAfterExit=
PIDFile=
ExecStart=
ExecStartPre=, ExecStartPost=
Dès le départ je suis obligé d'aller remplir le PIDFile avec le PID de mon premier élément sinon ca s'arrête et systemd concluera à un echec de lancement.
Ensuite je poursuis ma synchro. Quand ma synchro est finie problème :
Soit j'avais mis RemainAfterExit à TRUE et là je peux fermer mon process de synchro l'esprit tranquille, mais si mon process principal ne se lance pas, ben systemd ne sera jamais mis au courant du fait que ca ne marche pas. Pareil si le process se lance mais meurt par la suite.
Soit j'avais mis RemainAfterExit à FALSE et là c'est le drame parceque je ne peux pas fermer mon processus de synchro avant d'être sur que la mise a jour des PID a bien eu lieu dans systemd. Sauf que je sais pas quand elle a lieu la mise à jour. Donc je boucle en mode texte du systemctl jusqu'à ce que le PID modifié soit pris en compte. (Je ne sais pas si ca a changé, mais en vrai le nouveau PID dans le fichier ne sera jamais pris en compte)
On triche avec ExecStartPre, je lance la moitié de mon script d'init en pre pour la synchro et l'autre moitié en normal.
Problème : si la synchro se foire, l'autre commande n'est jamais executée. Sauf si je mets un - devant ma commande, auquel cas l'autre commande est toujours executée. Sauf que je veux du "des fois oui, des fois non". Donc il faut que j'étoffe mes deux scripts pour que le second script puisse récupérer et analyser les résultats du premier script (BEURK). Donc non seulement j'ai deux scripts à maintenir au lieu d'un, mais en plus j'ai du boilerplate qui vient se rajouter en plus sur l'existant.
Sauf que si le second script plante pendant le démarrage, il n'est pas dit qu'il aura fait le ménage avant que le plantage. Donc un petit troisième script en ExecStartPost pour passer le balais….(que tant qu'à faire je met aussi en ExecStartPre des fois que).
YOUPI trois scripts pour le prix d'un avec du boilerplate en plus…
Ensuite, si le souci, c'est l'orchestration de services sur le réseau
Non le soucis c'est de passer le service dans un état dans lequel il pourra être orchestré par la suite. C'est dire cohérent, synchronisé, stable et avec les bon paramètres de connexion connus.
_Ou tu penses que Oracle va juste décider de maintenir un system de boot différent à base d'initscripts pur, quitte à proposer moins de fonctionnalités que ses concurrents _
Non c'est quasiment certain que systemd évoluera pour s'adapter au besoin. Je doute sincèrement que RH aille au bras de fer (c'est à dire dise à Oracle : soit c'est comme on veut, soit il va vous falloir trouver une nouvelle distrib de référence). Aucun interet pour eux. Si ils le font - c'est à dire si ils refusent de rajouter des gruikeries dans systemd malgré un besoin Oracle je leur tire mon chapeau, et j'applaudirai des deux mains. Mais très honnêtement (et il s'agit de mon opinion personnelle là) je n'y crois pas.
[^] # Re: la guerre de s unices
Posté par Kaane . En réponse au journal udev forké. Évalué à 1.
C'est vrai qu'avant, a part pouvoir faire start/stop/status/reload, on avait vachement plus de possibilités…
Ben avant le systeme d'init se prenait pas pour un système de controle. Donc un bête script rc de type
marchait plutôt pas mal. Même si en vrai on était obligé de rajouter des tests pour tout un tas de cas à la con.
[^] # Re: la guerre de s unices
Posté par Kaane . En réponse au journal udev forké. Évalué à 2.
Ne pas confondre pas encore supporté et non supporté. Je reviens dessus dans un instant.
Je suis pas revenu dessus.
Une des conditions pour la certif Oracle est de pouvoir faire monter les disque dur en raw directement par l'appli Oracle. Apparament (je ne suis pas complètement dans le secret des dieux) ca peut poser des problèmes avec systemd.
Le problème sera très certainement résolu bientôt, mais la question est de savoir comment.
Mon pari (et la c'est personnel et je l'admet un peu trollesque) est que pour faire face à tout un tas de situation (dont celle mentionnée plus haut) systemd va devoir se rapprocher progressivement d'un shell complet (voire d'un mini OS vu le nombre d'outils qui lui sont rajoutés chaque mois).
Red Hat ne peut pas se permettre d'essuyer un refus de certification de la part d'Oracle, donc si systemd bloque systemd sera poussé à évoluer, et ca le met dans une situation désagréable (un système d'init qui s'adapte à un programme userland c'est pas forcément glop).
[^] # Re: Questions
Posté par Kaane . En réponse au journal Linux from scratch face à udev. Évalué à 4.
IE, tu peux interagir avec les processes sans souci, le cgroup dans systemd n'est la que pour dire "tel process a lancé ces 15 processes". Ensuite, oui, si tu lances les processes en dehors de systemd, bah, il va rien pouvoir faire. Tout comme si tu lances un soft a la main, l'initscript va sans doute faire de la merde
Et c'est là que le bas blesse. L'init script va faire ce que je lui demande, systemd va essayer de deviner. Si mon script d'init est merdique, ben je le corrige, si les choix de systemd sont mauvais je dispose de très peut d'outils pour le faire changer d'avis.
A l'époque des bon vieux PID dans /var quand je lançait un nouveau process je récupérais son PID et j'allais le rajouter à la mano dans une liste. C'est moche d'accord mais ça marche. L'équivalent systemd consisterait à insérer mon nouveau process dans le cgroup qui va bien. Ben je ne sais pas faire.
tu crées pas une carte réseau, tu crées au mieux une interface réseau
Si tu veux, une interface réseau virtuelle.
Quand à lancer la couche tcp/ip, tu veux sans doute dire "demander un ip" ? ( parce que la couche tcp/ip, elle est déja la, sinon ton vpn tourne sans doute pas ).
Non, non je veux bien dire lancer la couche TCP/IP. Je ne veux pas de TCP/IP (sur mes interfaces) avant que les tunnels VPN soient montés et que les interfaces virtuelles soient créées. Et non je n'ai pas besoin de TCP/IP pour monter mes VPN, c'est du gre pur (par exemple).
Donc si ton souci c'est "j'ai une config trop compliqué pour la config par défaut de network-manager, alors systemd est merdique"
C'est dans la partie chat échaudé craint l'eau froide. J'ai une config son trop complexe pour pulse-audio, j'ai une config réseau trop complexe pour network manager, j'ai un UPnP trop spécifique pour avahi - mais c'est pas grave parce que je désactive le truc qui me casse les pieds et je fais à la main.
Par contre désactiver l'init je vois pas comment faire. Surtout que je ne peux même pas ruser (en créant une unit unique avec un daemon idle en exec et un init traditionnel en pre) parceque systemd va de toute façon faire une partie du boulot que je le veuille ou non.
Enfin, si tu lit la page de man systemd.service, tu verras qu'il y a :
ExecReload=
Commands to execute to trigger a configuration reload in the
service.
Oui mais je ne veux pas qu'il charge la config par défaut, je veux qu'il charge une autre config (de maintenance par exemple), et pour l'instant la seule solution que j'ai trouvée consiste à déclarer des tonnes de variables d'environnement et à s'en souvenir.
Donc tu peux juste lancer le kill -SIGHUP qui va bien, ou lancer apachectl, ou ce que tu veux, pas besoin de rajouter un support dbus totalement fantasmé de ta part.
Prenons le cas suivant, je veux modifier un paramètre apache (ou d'un module apache) qui requiert un redémarrage d'apache. Par défaut apache est configuré pour redémarrer automatiquement dans systemd avec préservation des sockets. Qu'est-ce qu'il va se passer d'après toi si je fais apachectl restart ? Moi j'en ai pas la moindre idée. Apache va être relancé, mais par qui ? La bonne façon de faire quand on a besoin de passer par apachectl (donc pour un truc un peu plus costaud que juste restart) c'est de dire à systemd de ne plus le relancer automatiquement. Mais comment faire ?
tu va sans doute pouvoir trouver du boilerplate et des exceptions pour montrer ce que tu avances ?
Je crois avoir donné pas mal d'exemples (et là je viens d'en détailler deux) donc je pense que l'attaque gratuite n'est pas franchement de rigueur. systemd est beaucoup plus rigide que l'init classique - ca n'est pas forcément un tort, mais il manque à mon sens pas mal d'outils/d'options à systemd pour être vraiment utilisable.
[^] # Re: la guerre de s unices
Posté par Kaane . En réponse au journal udev forké. Évalué à 2.
_Faut savoir, tu connais systemd sur le bout des doigts pour expliquer comment dbus est obligatoire pour le debug _
A l'heure actuelle il y a une personne qui connait systemd sur le bout des doigts et peut-être 150 qui le connaissent vraiment très bien. Je ne fais pas partie de ces élus, et j'éviterai aussi longtemps que possible d'en faire partie.
En ce qui concerne DBus, à l'heure actuelle (sauf erreur de ma part) on ne dispose que de deux façon de dialoguer avec systemd : systemctl et DBus.
Si on utilise systemctl on a un nombre (pour l'instant) limité de fonctions. Un autre utilitaire systemadm est en cours de création, mais il ne fonctionne qu'en mode graphique.
Et systemctl est assez pourri. (Ce n'est pas un troll, tout le monde est d'accord là dessus même chez RH/Fedora). Pourri pourquoi ? Parcequ'il est très incomplet et pas forcément cohérent avec lui même. Sur les commandes un peu complexe on se retrouve à faire du ;echo $ $ $ pour pouvoir lire le résultat, pour certaines opérations il faut aller shooter des symlinks à la main etc.
Systemctl permet de faire très simplement toutes les opérations de base (restart, reload, reboot, status, changement d'init etc.) par contre pour les opérations un peu plus complexe il faut soit passer par des variables d'environnement, ce qui nécessite un peu de jonglerie. Par exemple que veut dire :
On top of that basic environment variable substitution is supported. Use ${FOO} as part of a word, or as word of its own on the command line, in which case it will be replaced by the value of the environment variable including all whitespace it contains, resulting in a single argument. Use $FOO as a separate word on the command line, in which case it will be replaced by the value of the environment variable split up at whitespace, resulting in no or more arguments. Note that the first argument (i.e. the program to execute) may not be a variable, and must be a literal and absolute path name.
Et l'air de rien ça complique pas mal la mise en mode maintenance…
[^] # Re: la guerre de s unices
Posté par Kaane . En réponse au journal udev forké. Évalué à 6.
donc j'ai l'impression qu'une version d'oracle non supporté sur RHEL est un événement déjà arrivé.
Ne pas confondre pas encore supporté et non supporté. Je reviens dessus dans un instant.
Moi, quand je relit ton histoire, je vois juste un client qui collabore avec son fournisseur sur un produit pas encore sorti, et ça me semble relativement positif comme façon de faire.
C'est très positif comme façon de faire. Il faut bien voir que les scripts d'init custom sont une plaie à maintenir, et que c'est la partie sur laquelle il est le plus complexe d'obtenir du support. Donc forcément il vaut mieux s'y prendre à l'avance. Le truc est que l'on peut lancer des scripts shells standard avec systemd mais que ça coince quand même à pas mal de niveaux.
Par exemple systemd essaye de suivre le double fork de la daemonisation comme il peut, parceque le plus souvent le processus qui est lancé immédiatement n'est pas le processus définitif. Au bout d'un temps X (qui dépend de tout un tas de paramètres y compris l'age du capitaine et les exceptions codées en dur) il va choisir un ou plusieurs processus à surveiller comme étant "le(s) bon(s)" processus.
Dans le cas d'un cluster qui peut mettre un certain temps à se synchroniser avant de démarrer (des fois plusieurs minutes, rarement quelques heures) le bon processus est lancé très tard et le processus daemonisé en premier qui ne fait que la synchro s'arrête. systemd n'aime pas du tout ce comportement, et on a pas de moyen simple de lui envoyer un message pour dire "tout va bien c'est XXXX le vrai processus".
Il existe des méthodes de contournement (on peut passer certaines infos d'un processus à un autre en systemd) mais ca fait des scripts complexes avec des exceptions, des tests et des cas aux limites un peu douteux.
Tu serais pas un peu aigri et totalement subjectif ?
Si bien sur pourquoi ? Mais pour autant la question à se poser est de savoir si j'ai tort ou pas…
[^] # Re: Questions
Posté par Kaane . En réponse au journal Linux from scratch face à udev. Évalué à 6.
parce que cette argument fonctionne aussi avec dash qui peut segfaulter pour une raison x ou y…
Tout à fait, c'est d'ailleurs pour ça qu'on utilise pas dash dans les scripts d'init mais sh. Enfin chez les vrai OS en tout cas.
Ou alors, tu voulais dire que Lennart n'aurait pas du utiliser libdbus et recoder un système d'IPC à la main ? SUPER!
Il fait comme il veut du moment que mon executable est compilé en statique est peut se lancer en mode recovery quand seule la partition racine remonte.
était un gros mensonge, histoire de faire peur à tout le monde, c'est bien, tu viens de t'auto fusiller…
Pas un mensonge, sans dbus l'init est inexistant. Sans dbus-daemon, ou si le service n'a pas un support dbus explicite les controles sont très réduits.
Avoir un init c'est pas juste pouvoir lancer et arreter des processus…
[^] # Re: Questions
Posté par Kaane . En réponse au journal Linux from scratch face à udev. Évalué à 7.
Mais le service dbus-daemon n'a aucun influence sur le fonctionnement de systemd et systemctl.
Très honnêtement, et même si ca a été corrigé depuis apparament, systemd avait besoin de DBus pour démarrer pleinement au départ.
Ensuite la place du socket a été déplacée, les ouvertures de sockets se faisaient de façon légèrement différente d'une version sur l'autre et au final pas mal de gens ont eu droit au fabuleux :
Failed to get D-Bus connection: Failed to connect to socket /org/freedesktop/systemd1/private: Connection refused
Ceci dit ca fait plaisir que DBus créée maintenant lui même son propre socket (et ca rassure un peu aussi, parcequ'un programme qui prétend pouvoir créer des sockets pour tout le monde mais qui utilise DBus pour fabriquer le sien ca fait un peu peur.)
Pour rentrer à nouveau dans le troll, quid de tous les autres points mentionnés ?
[^] # Re: Questions
Posté par Kaane . En réponse au journal Linux from scratch face à udev. Évalué à 4.
Tiens donc, et ça fonctionne comment ? Je sens qu'on va rire…
Ca s'appelle le mode peer-to-peer en créant via dbus des DirectConnections.
Ensuite même si DBus tombe la connexion tient. (Juste que pour la retrouver et s'y inscrire bonjour).
[^] # Re: Questions
Posté par Kaane . En réponse au journal Linux from scratch face à udev. Évalué à 2.
Hein ? Tu sais comment fonctionne dbus.
Oui.
C'est pas systemctl -> systemd - C'est obligatoirement systemctl -> dbus-daemon -> systemd
Non.
Je viens de faire un:
mv /usr/bin/dbus-daemon /root
Je reboot et magie systemctl fonctionne toujours…
Donc il y a eu un fallback de rajouté au moins pour systemctl. C'est une bonne chose, plus il y a d'exception dans le truc, plus vite il meurt.
Par contre existe-t-il un moyen de signifier quelquechose à systemd autrement que via DBus (ie pour tous les programmes qui ne sont pas systemsctl) ?
J'avoue volontier avoir très peu investi dans systemd, j'ai regardé, j'ai pas aimé, j'ai arrété.
[^] # Re: Questions
Posté par Kaane . En réponse au journal Linux from scratch face à udev. Évalué à 7.
et oh, ca fonctionne et dbus est tjs coupé.
Oui les sockets ont déjà été ouverte par DBus et donc systemsctl peut dialoguer avec systemd.
Maintenant désinstalle DBus et essaye de faire quoi que ce soit.
Ca ne marche pas.
Il faut donc un DBus installé et fonctionnel au moment du boot pour que systemd puisse dialogeur avec systemctl et il faut un dbus actif et fonctionnel pour pouvoir ajouter des watchers/controles/processus dans un cgroup liés à systemd après le boot.
[^] # Re: la guerre de s unices
Posté par Kaane . En réponse au journal udev forké. Évalué à 2.
Faux, surtout que apachectl, c'est l'exemple type de l'outils codé parce que sysvinit ne répondait pas aux besoins…
On passe sur la logique tarabiscotté (il est faux de dire que A a besoin de B pour fonctionner avec C vu que A a été créé à cause de D)
Ensuite tu penses sincèrement que toutes les options de apachectl seront codées dans un init un jour, notamment les options des modules compilés statiquement dans apache ? Parce que apachectl fait ça aussi.
T'inquiètes, si systemd devient vraiment le standard, ton apachectl, il va partir dans /dev/null
Clairement, si systemd devient le standard, apache laisse tomber windows, Mac et *BSD.
Et je le redis: systemd n'a pas besoin de dbus pour fonctionner et pour controller les services
CF mon autre post dans l'autre thread pour cette question, systemd est aveugle et sourd sans DBus. (ce qui ne l'empêche pas de lancer des services d'accord, mais pour le contrôle on repassera)
[^] # Re: Questions
Posté par Kaane . En réponse au journal Linux from scratch face à udev. Évalué à 10.
Dbus est lancé par systemd après syslog sous Arch alors j'aimerai bien savoir comment tu m'expliques ton argument pourri…
En fait tout en dans la définition du mot "dialogue". Tant que DBus n'est pas lancé, systemd est sourd. Pas moyen de lui expliquer que tu rajoutes des worker tomcat, pas moyen de lui faire comprendre que tu vas faire un restart manuel avec d'autres paramètres de tels ou tels daemon, pas moyen de lui demander d'arréter de surveiller tel ou tel daemon qui va rentrer en maintenance.
systemd peut agir sur le système, mais le système ne peut pas agir sur lui. Pas de dialogue donc…
Non systemd peu utiliser dbus pour le lancement des services mais il ne dialogue pas en interne avec dbus.
Si si, c'est même comme ça qu'il valide le bon lancement de certaines applis. Par des dialogues avec DBus. Dés que tu as un BusName ou un NotifyAccess dans systemd c'est du dialogue de DBus. Dans cet article écrit par un des plus grand détracteur de systemd que je connaisse c'est très bien expliqué : http://0pointer.de/blog/projects/systemd-for-admins-3.html
Donc effectivement, si dbus ne se lance pas, la condition tel interface dbus existe ne pourra pas être vérifiée et sera ignorée
Et tous les scripts ayant un BusName ou un NotifyAccess dans leur config auront un comportement potentiellement différent et à valider en test.
Comme udev
udev n'existe que sous Linux, mais a un comportement POSIX. Les appels udev sont assez faciles à remplacer par des appels équivalents sous d'autres OS raisonnablement posix.
On continue dans le n'importe quoi, si tes démons n'ont pas le Wants=local-fs.target, tes fs locaux ne seront pas montés sauf si:
Erreur, les wants permettent de définir ce dont on a besoin, pas ce dont on ne veut pas. Si je veux que mon unit arrivent dans un systeme ou "tartempion" n'existe pas, il faut que j'active dans mon script "before = tartampion" ou alors si plusieurs daemon peuvent remplir une condition faire des "Wanted-By = ", sauf que dans le cas de local-fs.target tu l'as dans l'os. Quoi qu'il arrive systemd executera quand même cet unit quand il en a besoin (même si par exemple le daemon qui déchiffre les données n'est pas actif sur une partition chiffré)
Avec Wants=local-fs.target tout ce que j'ai c'est que mes disques locaux ne seront peut-être pas monté. Mais peut-être que si.
Et en gros, si je comprend bien ton argumentation, les programmes qui ne supportent pas DBus ne fonctionne pas avec systemd, et la marmotte…
Ils peuvent être lancé par systemd, mais toutes les fonctions de controle, d'altération, de controle fin etc. ne fonctionneront pas. Donc oui, pas de DBus => appli de controle à part en dehors de systemd.
Le dialogue avec systemd se fait via socket, pas via dbus qui n'est utilisé que pour valider des conditions!
Euh… Non.
Les sockets dans systemd servent à remplacer inetd, moyennant la perte de certaines fonctionnalité, ou des patchs de code ou autres.
Le socket /run/systemd/private est désormais créé par dbus_server_listen (je te laisse deviner sur quelle outil il s'appuie).
Sans DBus systemd est sourd. (Et systemctl ne marche plus)
[^] # Re: la guerre de s unices
Posté par Kaane . En réponse au journal udev forké. Évalué à 1.
Ca doit prendre 2 minutes de faire une "unit" systemd qui lance des scripts shell comme le faisait sysvinit
Et qui va créer 32 watcher si tu utilise apache en mode démon+fast cgi avec 32 spawn, et comme mentionné dans un autre post on va être gentil et pas parler d'Erlang ou des programmes qui utilisent du GPGCU.
La seule bonne façon d'utiliser systemd c'est d'avoir des démons et des outils de controle (type apachectl) qui parlent courament le DBus.
Et je veux pas de DBus dans mon apache, je ne veux pas de watcher, je veux des perfs maximale parceque j'ai des centaines de milliers de connexion par minute et que le roundtrip DBus est loin d'être gratuit.
Donc non, pour des programmes aussi marginaux que apache, mysql, postfix, JBoss, Oracle etc. il va falloir rajouter des trucs dedans pour que ca marche intelligemment avec systemd, des trucs qui vont géner les perfs et dont moi, personellement, je n'ai rien à foutre.
[^] # Re: Questions
Posté par Kaane . En réponse au journal Linux from scratch face à udev. Évalué à 10.
est-ce que vous pourriez m'expliquer pourquoi systemd est-il si critiqué ?
De nombreuses raisons, mais voici les principales :
sytemd ne dialogue vraiment qu'avec dbus, si dbus ne se lance pas la machine n'a plus d'init, ou tout du moins plus un init normal, ce qui implique de faire des tests doublé pour la cohérence d'état des machines, un ou dbus démarre, un ou dbus ne démarre pas (ou pas au moment attendu). En plus le coté dialogue exclusif avec dbus nécessite l'utilisation d'un client dbus avec de gros droits si on veut pouvoir traquer un bug qui se déclare à l'init. Cette outil devra être exempt des sécurités cgroups et devra pouvoir accéder à tous les services. Ca fait une faille potentielle de plus.
systemd n'est pas compatible avec autre chose que Linux, et même pas avec autre chose que GNU/Linux à la sauce Red Hat. Bon nombre de configuration de type disques chiffrés/partition délocalisées/configuration dynamique ne sont tout simplement plus possible avec systemd qui s'attend à ce que certains éléments soient à une place bien précise avec des droits bien précis et un ordre de démarrage fixe. Notament au niveau du réseau on retrouve des défauts qui apparaissaient déjà sur networkmanager, par exemple quand il faut d'abord créer un lien VPN (PPTP, GRE ou autre) AVANT de créer une carte réseau et de lancer la couche TCP/IP. De la même façon tous les points de montage locaux sont systématiquement montés avant de lancer le moindre démon. C'est con pour Oracle par exempel qui a besoin de prendre le controle de certains points de montage en RAW et dont le montage normal ne sert qu'au debug et au cold backup. A partir de là systemd prive linux de choses importantes qu'il sait faire (et même bien faire) aujorud'hui - et il oblige en plus les devs à créer plusiseurs version de leur script d'init en fonction de la machine sur laquelle ils sont supposés s'éxecuter.
systemd pose un problème aux outils de contrôle : un truc aussi bête que apachectl devient un casse tête avec systemd, plusieurs utilisateurs peuvent controller le logiciel apache avec cet outil. Mais alors quid de systemd ? Est-ce qu'on ajoute des fonctionnalité DBus à l'outil pour lui permettre de dialoguer avec systemd pour lui dire "au fait le recharge la config" ou est-ce que l'on fait ça dans son dos en esperant qu'ils ne panique pas en voyant les processus apaches se fermer et s'ouvrir du fait d'appels à un outils qui n'est pas dans le même cgroup ? Ou alors est-ce que l'on met tout le monde dans le même cgroup, auquel cas quand on essaye de tuer un apache planté on commence par tuer l'outil qui permet d'interragir avec apache ?
(Bon pour apache les soucis sont résolus rapidement, mais pour tomcat déjà ca se complique et je ne parle pas d'Erlang ou d'autres applis distribuées)
chat échaudé craint l'eau froide : C'est pas comme si les "nouvelles API qui tuent tout" avaient une espérance de vie limité sous Linux, mais ca fait quand même 5 fois en 10 ans que l'on change complètement le paradigme d'acès au périphériques. Linux n'a pas une super réputation sur la pérénité de ses api, et pas mal de mainteneurs commencent sérieusement à en avoir marre de réinventer la roue. Devoir refaire toute la config à cause de polkit/consolekit/udev/hal qui s'enva/dbus/systemd ca amuse 5 minutes, mais là ca fait 3 ans.
Pour l'instant à moins d'une évolution très très léchée du produit par RH on est toujours obligé de gruiker les scripts pour que systemd fasse ce dont tu as besoin et pas ce qu'il veut, notamment pour les processus qui forkent dans tous les sens et qui n'ont pas de support natif de DBus. Et comme DNS, Apache et Postfix ne sont pas supposé en avoir quoi que ce soit à faire de systemd (et qu'en plus les dialogues avec systemd ne peuvent qu'avoir un impact négatif sur les perfs) ils n'auront probablement jamais de support DBus.
En fait une application unique ne peut pas faire la surveillance/le controle/le restart etc. de toutes les applis possibles et imaginables dans toutes les config possibles et imaginables - ca parait évident dit comme ça mais c'est pourtant ce qu'il essaye de faire. Donc systemd échouera, ou se pervertira jusqu'à avoir autant d'exception et de boilerplates que ses ancètres. Le test grandeur nature est juste une couteuse perte de temps.
[^] # Re: la guerre de s unices
Posté par Kaane . En réponse au journal udev forké. Évalué à 4.
L'espoir fait vivre hein, bon courage :p
Si encore c'était un espoir. Mais je connais déjà un gros client RH qui utilise massivement oracle avec des scripts d'init custom pas piqué des hannetons. Et là ils sont en train de bomberder le support RH de questions pour être iso fonctionnel en systemd.
Je ne pense pas un seul instant que RH va accepter de perdre ce client (même si 5 ans de support c'est long, tu peux être sur qu'à la première version d'Oracle qui n'est plus certifié sur le RH qu'ils utilisent ils changent de crêmerie).
Donc comme RH veut garder ce client (et rpobablement d'autres avec des problematiques similaires) je suis prêt à parier qu'ils vont mettre des gruikeries dans leur systemd… Et de là c'est juste une question de patience.
[^] # Re: la guerre de s unices
Posté par Kaane . En réponse au journal udev forké. Évalué à 10.
La réponse est pourtant simple : parce que plus personne n'est intéressé à maintenir ta chose
Dans le cadre d'un système d'init la question ne se pose pas. SystemV en lui même est très simple à maintenir, ce qui coute cher ce sont les scripts d'init. Mais à moins que Linux/systemd n'envoient tous les autres systèmes à la casse on aura toujours des scripts raisonnablement simple à adapter chez les *BSD pour toutes les applications phares.
C'est la puissance de SystemV : en quelques minutes je peux écrire un script de démarrage qui correspond exactement à mes besoins. Le seul problème qui va se poser c'est au niveau du démarrage des couches réseaux (ip, gre, pptp etc.) mais bon les scripts n'ont pas été réécrits pour le passage ifconfig -> iptables (il y a 16 ans, presque 14 ans qu'ifconfig est en deprecated) donc on peut légitimement se demander si ils vont l'être pour systemd.
bon les gars, il y a des gens qui veulent leur ancien truc juste parce qu'ils ont du mal à suivre le changement
Non, c'est juste que systemd est une mauvaise idée. Il s'agit ni plus ni moins que de la nième tentative pour normaliser Linux, on sait ce qui est arrivé aux précédentes et on a pas envie d'investir dans un truc qui va forcément se péter la gueule. (comprenons nous bien, par péter la gueule je veux aussi bien dire disparaitre que d'être obligé d'évoluer dans de telles proportion que d'ici trois ans les scripts systemd auront autant de ifdef et d’exceptions que les inits actuels).
[^] # Re: la guerre de s unices
Posté par Kaane . En réponse au journal udev forké. Évalué à 10.
Et pourquoi pas? C'est si horrible que ça?
Oui.
Déjà il y a des dépendances dans tous les sens, ça ne peut être piloté correctement que via DBus (donc pour le debug il va falloir créer un client DBus avec des droits démentiels et des cgroups transversaux), c'est fortement incompatible avec pas mal de méthodes de chiffrement de la partition de boot (grosso-modo tous sauf luks), ca monopolise des ressources mémoires (les cgroups c'est loin d'être gratuit, surtout en embarqué) etc.
Mais surtout :
- C'est fait par Red Hat, les experts en "on laisse tomber la fonctionnalité phare de la version précédente". Si vous avez investi dans les technos de virtualisation à la sauce Red Hat, vous savez de quoi je parle.
Il faut réécrire profondément les scripts d'init pour en tirer partie. Certes on peut créer assez rapidement des scripts qui fonctionnent du moment que l'on force une exécution séquentielle (c'est d'ailleurs ce que font pas mal de distribs en ce moment) mais pour que systemd apporte quelque chose il faut repenser l'init. Quand on voit qu'en près de 14 ans de déprécation les scripts utilisant ifconfig n'ont pas tous été réécrit et que iwconfig n'est toujours pas complètement intégré à au set d'outils iproute2 …
Vu la gueule de la stabilité API des linuxeries du passé (HAL, DBus, SELinux etc.) je n'investirais pas de temps à apprendre systemd. Et quand je n'aurais pas le choix (tous les linux avec systemd) je créerai un script bien gruik dans un cgroup absolu (tous les pouvoirs) qui lancera un bon vieux script shell en mode séquentiel. Bref il y aura un script init2 sur ma machine sur lequel je pourrais intervenir en mode texte avec pour toute arme une console et un vi.
Mais bon le truc c'est que ce qu'il y a de plus chiant dans Linux (bien plus que de gérer les dépendances et de faire un système de packages cohérent) c'est de faire des scripts d'init. C'est probablement la seule raison pour laquelle j'utilise une distrib toute faite et pas un LFS ultra customisé. Donc la perspective de devoir tous les réécrire et les maintenir pendant les deux ou trois ans que va mettre systemd à crever ne m'enchante pas.
[^] # Re: la guerre de s unices
Posté par Kaane . En réponse au journal udev forké. Évalué à 6.
Question inverse : pourquoi vouloir l'ancienne méthode que les mainteneurs de distro ne veulent plus si on l’utilise que 2 ou 3 fois par an?
Tu veux dire : "Pourquoi ne pas rajouter à un OS tout un tas de fonctionnalité dont tu n'as pas besoin et dont tu ne te servirais que très rarement si tu les avais à disposition ?"
Ben écoute chacun fait comme il veut bien sur, mais personnellement les trucs dont je ne me sers pas je ne les installe pas. Il y a près de 15000 packages dans ma distrib, j'évite de les installer tous.
[^] # Re: Dindon
Posté par Kaane . En réponse au journal Des projets libres, des financements, de l'espoir !. Évalué à 2. Dernière modification le 26 août 2012 à 15:23.
D'ailleurs, il me semble qu'en Belgique, il est interdit de faire un don aux entreprises, il doit toujours y avoir une contrepartie (pour éviter la fraude).
Pour la Grande Bretagne je ne sais pas, mais pour à peu près tous les autres pays d'Europe (au sens CE) je suis quasiment sur que pour pouvoir faire appel à l'épargne publique il faut
- Soit être une association à but non lucratif qui récolte des dons (i.e aucune contrepartie quel quel soit)
- Soit être une association à but non lucratif qui recrute des adhérents (et là les adhérents ont des droits au sein de l'association)
- Soit être une entreprise type SA coté sur un marché (et là les souscrivant récoltent des droits)
- Soit faire un emprunt obligataire avec une banque derrière qui se porte caution (et je crois qu'il faut en plus être une SA ou assimilé)
Tout le reste (y compris les dons sur une page web pour que la page/le logiciel/l'auteur continue) est assimilé à une vente - avec tout ce qui va avec.
Curieux de voir ce que les avocats de kickstarter vont pondre si ils ouvrent en France. Si ça passe leur modèle de contrat sera copié/collé des milliers de fois.
Si un juriste peu confirmer/infirmer.
# Au contraire, c'est très au point.
Posté par Kaane . En réponse au journal La poste by Colissimo. Évalué à 10.
Soit deux jours de perdus pour lui ! (et de l'essence, de l'usure matériel, et du stockage perdu pour le service)
Alors pour l'essence ne t'inquiete pas trop, les facteurs se déplacent plus avec de lourds colis dans leur camionette, ils ne prennent que le coupon "absent du domicile" et se lancent dans de grandes discussion sur "la place de l'homme dans un monde de travail mécanisé" quand vous les prenez la main dans le sac (ie quand vous voulez vraiment votre colis et que vous guettez le facteur - mauvais plan en fait puisqu'il faudra de toute façon faire la queue samedi)
Et en ce qui concerne le stockage, en tassant un peu ca passe. Les colis etiquettés "fragile" sont ceux qui prennent le moins de place quand on insiste un peu.
Reste l'usure - mais bon les trucs qui s'usent le plus dans l'histoire c'est pas la Poste qui les a payé…
[^] # Re: BSD
Posté par Kaane . En réponse au journal Linux-only ; et BSD ?. Évalué à 3.
OS X n'a pas grand-chose en commun avec BSD. Le noyau est différent (OS X a un noyau Mach), seule une partie des outils autour du noyau sont repris de BSD.
Oui enfin si tu as compris comment marche un micro-kernel, tu te rends rapidement compte que "outils autour du noyau" ça veut dire "pilote fondamental déplacé en userland, mais pas trop". Et la partie est loin d'être négligeable…
BSD c'est pas juste un kernel, et les outils autours c'est quand même une masse conséquente de code. On serait pédant comme d'autres on prétendrait qu'il faut dire BSD/OS X et non OS X tout court
Quant au framework Cocoa (qui fait tout l'intérêt d'OS X par rapport aux autres OS), il est fait maison par Apple
Pour les utilisateurs, ils savent même pas que ca existe (j'en ai entendu des excuses cons de la part d'un utilisateur qui achetait du matériel Apple, mais j'ai pas encore eu droit au "non mais rend-toi compte ! IL A UN FRAMEWORK COCOA"). Donc l'interet est limité
Pour les developpeurs c'est un truc non portable, dont n'importe quelle partie peut être déclarée deprecated n'importe quand par une seule boite.
Pour les admins sys et autres support, c'est un truc qui te parque dans ton coin sans te laisser en sortir.
Donc l'interet, à part pour Apple je vois pas trop…
[^] # Re: BSD
Posté par Kaane . En réponse au journal Linux-only ; et BSD ?. Évalué à 10.
BSD est utilisé par 3 ou 4 nerds qui trouvent que linux ne leur suffit pas et ça ne va pas plus loin.
C'est vrai qu'il y a très peu de nerds sous BSD. C'est un segment sur lequel Linux règne en maitre.
BSD ne sera jamais utilisé par M. Toutlemonde sur son PC chez lui (tu me diras que Linux de moins en moins à cause de GNOME3 qui devient de plus en plus pourri)
Ben BSD a déjà le Mac, le modem, le poste radio connecté, la moitié du lecteur blu-ray et la moitié de la télé (pour les mises à jour HDCP). Plus ca serait abuser.
BSD ne sera jamais utilisé dans une vraiue entreprise (Oui, j'en suis sûr que tu as un cousin qui a installé un firewall BSD chez son oncle qui est plombier et que ça marche super bien sauf quand ça tombe en panne et que ton cousin est en vacances)
Ben c'est vrai qu'un firewall chez un plombier ca fait des étincelles forcément. Il faut juste expliquer au plombier qu'en francais firewall se dit ecluse et là il retourne dans son élément.
Quand aux vraies entreprises (c'est à dire des entreprises qui présentent des comptes vrais aux actionnaires ET aux impots) c'était le bon temps, mais ca n'existe plus tout court.
[^] # Re: Compte github requis
Posté par Kaane . En réponse au journal Jouer avec la sécurité web. Évalué à 4.
Quel intérêt d'exiger un compte github ?
C'est un site pedagogique, il utilise toutes les méthodes disponibles pour apprendre les bases de la sécurité a des non initiés.
Les personnes qui ont utilisé leur vrai compte GitHub pour rentrer dans le site vont apprendre très vite qu'il ne faut pas donner son mot de passe à n'importe quel site sur le net.
[^] # Re: Les jolies nimages ! Un commentaire de plus
Posté par Kaane . En réponse au journal Asile équatorien accordé à Julian Assange. Évalué à 4.
Et désolé si mon point de vue fait que pour moi, même si elle est normale médicalement parlant, elle est maigrichonne.
Tu peux être désolé, car c'est ce genre de comportement qui génère les comportement que tu dénonces. Olivia Wilde est normale, si elle perdait deux ou trois kilos elle serait encore normale, si elle prenait dix kilos elle serait encore normale. Le fait de cataloguer une personne suivant des critères non objectifs de poids participe à la névrose. Dans un sens ou dans l'autre. Ça envoie un message fort sur la primeur de l'apparence dans les relations humaines.
Si ta fille veux maigrir il y a plusieurs choses à voir avant de tirer la sonnette d'alarme. Plusieurs choses à expliquer sur le poids et l'apparence. Il se peut parfaitement que ce soit pour attirer l'attention d'un garçon (ou d'une fille d'ailleurs) qui sort avec une personne plus fine qu'elle. Ou même parce que pendant ses règles elle fait de la rétention d'eau (elle gonfle) et qu'elle a fait inconsciemment une association poids = douleur (très très courant chez les jeunes filles) ou pour des milliers d'autres raisons.
Rejeter sa volonté de perdre du poids sans en discuter ne peut que la braquer, tu la forces à choisir un camps (je choisis le camps papa/maman en gardant mon poids actuel - ou je choisis le camps copains/liberté/émancipation en maigrissant) et à partir de la manger devient un choix politique.
Il faut avoir en tête la ligne rouge :
- si on tombe malade on peut perdre plusieurs kilos (5 ou 6 sans problème même pour des maladies qui ne passent pas par l’hôpital) - donc il faut être 5 ou 6 kg au dessus des 5% de masse graisseuse totale. Sans quoi la moindre maladie qui dure un peu met la vie en danger.
- On dispose de 3 ans de réserve de vitamine B12 et de 9 mois de réserve de potassium - au début quand on va maigrir on se sentir mieux (le poste le plus consommateur en énergie : la digestion a été sacrément réduit.) Passé la première semaine d'adaptation du corps on va se sentir en super forme. C'est un leurre, le corps va ensuite s'affaiblir lentement. Donc on peut devenir relativement maigre "parce que ça nous plait" sous réserve de faire bien attention à entretenir correctement la B12 et le potassium. si le poids est un choix et pas un problème on a aucun soucis à manger correctement (même si peu en quantité) et à prendre des compléments alimentaires. Si c'est un problème par contre il y aura quasi systématiquement rejet de l'idée même de complément alimentaire.
- Si ta fille a moins de 16 ans, elle est en pleine période de stockage du calcium. Si elle maigrit maintenant ça peut poser des problèmes par la suite si elle décide d'avoir des enfants. Si elle mange peu il faut s'assurer qu'elle prenne suffisamment de soleil (mais pas aux mauvaises heures - mélanome toussa)
- Si on arrive aux 2/3 du poids de forme moyen idéal (pour Olivia Wilde ça serait ici 42kg) c'est hospitalisation directe, avec séparation de l'environnement (familial et affectif) pendant plusieurs mois.
Le mieux une fois de plus est d'en parler à ta fille en lui donnant explicitement les règles du jeu mais surtout en gardant bien présent à l'esprit que tant qu'elle ne franchit pas la ligne rouge c'est qu'elle garde le contrôle - c'est sa préférence, qui est peut-être différente de la tienne mais c'est son corps.