Posté par benja .
En réponse au journal EDSL et F-algèbres.
Évalué à 1.
Dernière modification le 13 juin 2016 à 16:17.
CORRECTION: sorry m'est trompé la en fait je crois que t'évalue ton expression justement, ton e = expri. Tu évalue ta closure, ton {} c'est ton dictionaire avec tes fonction "lit", "sub", etc.
C'est bien ton évaluateur. Par exemple "{lit = fun x -> x}" serait un évaluateur vers int. Ton évaluateur vers string, ça serait {lit= fun x -> string_of_int x}. Après tu appliques "mon_ast (eval_dict_string : string algebre)" tu obtiens un string, dans l'autre cas tu fais "mon_ast (eval_dict_int : int algebre)", l'idée c'est que ton type de résultat d'évaluation/valeur n'est pas explicité dans ton type "expr/ast/arbre" mais juste dans ton expr_dict/algebre/evaluateur. Tu utilises donc l'encoding de Böhm-Berarducci, cqfd :p
Posté par benja .
En réponse au journal EDSL et F-algèbres.
Évalué à 1.
Dernière modification le 13 juin 2016 à 16:06.
Que signifie la syntaxe : {expi = …}
C'est un "record" avec un champs expi. C'est juste pour contourner l'impossibilité de faire un "type exp = forall a.a algebre -> a", on "emballe" la fonction dans le champs expi d'un record, car dans ce cas on peut faire le forall en utilisant la syntaxe 'a. type-exp.
Que signifie la syntaxe "fun {expi = e}"
C'est la destruction par pattern-match, équivalent à "fun record -> let e = record.expi in …"
"e {…}"
On réemballe notre fonction dans un record. Encore une fois, ça aurait été mieux de passer une fonction directement ("la closure") mais parce qu'on ne sait pas exprimer son type sans passer par ce contournement. On aurait pu utiliser un objet normalement¸ca aurait été pareil. C'est le même problème que tu as en faisait.
CORRECTION: sorry m'est trompé la en fait je crois que t'évalue ton expression justement, ton e = expri. Tu évalue ta closure, ton {} c'est ton dictionaire avec tes fonction "lit", "sub", etc.
type'avalfun='a*('a->())letmaliste=[(2,fun_->());("string",fun_->())](* marche pas car tous les éléments de la liste n'ont pas le même type "string valfun" contre "int valfun" *)(* versus *)typevalfun={valfun:'a.'a*('a->unit)}letmalist=[{valfun=(2,fun_->())};{valfun=("string",fun_->())}]List.iter(fun{valfun=(v,f)}->fv)malist(* OK *)
Posté par benja .
En réponse au journal EDSL et F-algèbres.
Évalué à 1.
Dernière modification le 13 juin 2016 à 15:07.
Je connais pas ton code, mais (il me semble que) la transformation revient à transformer tous les constructeurs des nodes de ton arbre en un fonctions sur un évaluateur. Par exemple si tu avais:
leteval_string={node=function(v1,v2,v3)->"NodeTerm("^v1^","^v2^","^v3^")"(*pas de récursion, v1-v3 déja évalués! *)leteval_bool={node=function_->true/false}
Chaque match de ton eval devient une fonction différente dans ton évaluateur (ça n'est pas pour rien qu'Oleg l'appelle expr_dict dans son exemple…) Par contre ce journal a utilisé un tuple, mais bon ça n'est pas très pratique à utiliser amha.
Donc en gros tu changes tes constructeurs en closures sur l'évaluateur. Tu construits ton abre en faisant une application partielle des tes fonctions de construction. Donc toutes tes expressions deviennent des fonctions d'un évaluateur vers un résultat, soit le fameux type de ce journal type expr = forall 'a . 'a algebre -> 'a. C'est plus clair ? À toi de nous dire si cette réécriture t'apporte quelque chose de mieux ?
Le truc pour comprendre c'est qu'il faut simplement lire le code d'Oleg (le dernier lien) et après tout devient limpide, en admettons une certaine familiarité avec ocaml :P En fait j'apprécie l'effort que son auteur a fait pour rendre ce journal précis et didactique : en effet la terminologie utilisée correspond finalement à la doc officielle d'ocaml. Bref grâce à ce journal j'ai appris la technique de fold au lieu de l'éval récursif, le fameux codage de Böhm-Berarducci, Plus simplement c'est un évaluateur en style CPS. Au lieu d'avoir un évaluateur récusrif eval expr = case expr with App x y -> x (eval y) sur le type "expr" on a un type "expr" qui accepte un évaluateur sur X et retourne X: expr_app f x = fun evaluator -> evaluator.app f (x evaluator).
L'astuce qu'Oleg utilise en fait en ocaml pour faire un type paramètrique sans fixer le paramètre, c'est qu'il faut embaler le type des fonctions constructrices d'expression dans un type du genre méthode polymorphique d'objet. En utilisant type expr = { expr : 'a . 'a algebre -> 'a } on arrive à exprimer "une fonction qui en reçevant une algèbre paramètré sur X s'évalue en X", sans fixer le type X au type de expr, i.e. le forall a. d'Haskell mentionné dans le journal. Si l'auteur du journal a trouvé une autre méthode pour exprimer le "forall" sans passer par cette indirection (donc ni par un objet, ni par un module first class), ça m'intéresse. Les GADT ne me semblent pas adaptés, mais, qui sait ?
Par contre à la question de la performance, ben je crains que cette technique soit moins efficace parce que cela revient à construire un objet plus une closure pour chaque "expr" (closure = function partiellement appliqué).
Btw, on pourrait traduire le code d'Oleg en Lua ou en javascript, j'imagine que ça rendrait ce journal plus compréhensible pour la majorité, ceci dit ça n'est pa la première fois que l'on cause ocaml sur ce site :-) Cela donnerait quelque chose comme ceci (note j'y connais pas grand chose en javascript, ça compile probablement pas tel quel).
Ou aussi se dire qu'ils n'ont rien pris à personne
Oui loin de moi l'idée d'avoir voulu faire sous-entendre le contraire. Je voulais simplement signaler que s'ils avaient vraiment eu besoin de repiquer quelque chose, il y existait du code qui n'est pas copylefté.
Vraiment, quand on ne sait pas de quoi on parle vaudrait mieux s'abstenir…
Ok je suis démasqué, j'avoue mon incompétence dans ce sujet. J'ai juste un souvenir peu glorieux d'une certaine implémentation de nfs, mais les détails sont déjà lointains, je te laisse donc le bénéfice du doute quant à la qualité de ce produit et de sa maintenance, et je te présente donc mes plus plates excuses. En ce qui concerne la motivation de proposer une telle chose, je peux supposer qu'implicitement tu es d'accord, n'est-ce pas ?
Ouaw super merci pour le lien (comme quoi il n'y a pas que sur debian-devel qu'on a besoin de popcorn). Une petite perle, de DJ Delorie (pour ceux qui ne savent pas, le gars à porté gcc sur DOS parmis probablement plein d'autres trucs de dingues. Je ne résiste pas à la copier ici :p
| Lennart Poettering <mzerqung(a)0pointer.de> writes:
| ...
| Sorry, but systemd is pretty exactly this: a process babysitter.
It's becoming a user nanny instead. I wish it would stop trying to enforce its "my way or the highway" approach to system rules. I've been playing whack-a-mole trying to keep up with all the tweaks I need (assuming I can find them) to let me do what I want to do with my own machine. I am not a baby and do not need a babysitter.
(La réponse de l'intéressé ne vaut probablement pas la peine que je la recopie ici…)
Bah en fait ça s'apparent plus à l'émulation de syscall apparue avec les BSDs qu'à wine.
En gros c'est juste le loader, gèrer le sys-enter et implémenter les syscalls. Avec derrière un travail pour traduire la sémantique posix/linux sur l'implémentation du noyau NT. Pour l'instant c'est fait de manière grossière (et probablement pour toujours cf. deuxième remarque): pas de mapping EUID, tout est "root", … On reste de loin du travail que wine doit effectuer qui consiste en plus à réimplémenter toutes les bibliothèques (ce qui est considérable).
Les ingénieurs de windows on pu s'inspirer, voir prendre du code des BSD et d'opensolaris sans aucun problème. D'ailleurs dixit Bryan Cantrill, c'est assez simple à faire vu que l'interface de linux ne consiste "que en" ces syscall, et elle est stable dans le temps, contrairement aux systèmes bsd. D'ailleurs historiquement ce mécanisme est utilisé sur bsd pour faire tourner d'ancien binaires.
Deuxième remarque, ça n'est pas la première fois qu'ils font le coups: se rappeller le unix subsystem for windows qui en gros était bien pourri, n'a jamais été maintenu et a juste servi à faire migrer des gens vers leur environement.
Il y a dans tous les cas /var/log/dpkg,log, Et puis en fonction de(s) l'interface(s) que tu as utilisée(s) tu auras aussi /var/log/aptitude.log, /var/log/apt/* (ou autres? pkg-kit, synaptic ont probablement aussi leur log qq part.). À partir d'un moment (une certaine taille p.e.) ces fichiers seront coupés et sauvegardés dans *.1.gz, puis 2.gz, jusqu'à 10 par défaut, par l'utlitaire logrotate.
b) freeze
Cf. c)
c) dans quelle version tu es un fois que la nouvelle stable sort.
Ça dépend. Soit dans ton fichier /etc/apt/sources.list tu as mis le nom de la version (stretch en l'occurence), ben alors tu passes en stable, le process de mise-à-jour ne modifie pas ce fichier (au contraire d'ubuntu où tu dois utiliser un outil spéficique pour faire un upgrade, dans debian tu peux simplement changer le nom de la distribution dans ce fichier (tu peux aussi sur ubuntu mais ça n'est pas "officiel", ymmv)). Soit tu as mis "testing", ben alors tu restes en testing et tu peux effectivement te poser la question de savoir s'il valait vraiment la peine de suivre le freeze ;-) Plus subtilement, tu peux passer en unstable pendant le freeze et repasser en testing juste au moment de la sortie car en gros un fois que la nouvelle stable est sortie, tous les paquets de unstable vont migrer dans testing. Enfin bon ça sera unstable pendant un moment (apt pinnning comme on t'as dit peut être un solution aussi pendant cette période de transition pour être dans un mix testing(freeze) + unstable)… donc bon à toi de voir.
(Bonne question btw!)
Je parlais de SYSV au moment de la "guerre" des unix… Je vois pas en quoi systemd homogénéise quoi que ce soit de ta liste, à part refuser de fonctionner si CONFIG_XYZ n'est pas activée ? D'ailleurs je ne vois pas pourqoi tu pars sur un délire d'homogénéisation. c'est par rapport à quelque chose que j'ai dite ?
la preuve j'ai parlé d'exposer et de déterminer une API publique qui serait commune à ces projets histoire d'étendre POSIX.
On est +/- d'accord sur ce point là. Sauf que systemd a pris la place, mais oui pourqoi pas, on peut le faire au dessus de systemd même si cela ne me semble pas la manière la plus économe en labeur.
Les applications libres communes à Linux et *BSD n'ont pas cessé le support de l'un des deux depuis, et sans devoir être modifié…
Écoutes ça n'est pas uniquement moi qui le dit. Bénéfice > coût, si tu ne me crois pas, ben tant pis. Pose la question à des personnes qui maintiennent un logiciel d'envergure et portable.
qui va maintenir tout ça sur la durée ?
T'inquiètes pas, s'il n'y a personne qui maintient/utilise, ben on retire le support. c'est aussi simple que ça… Juste laisser la possibilité.
(le reste de tes arguments convient à l'égard de toute contribution, pas uniquement de type "port"… bref ça pue la mauvaise foie).
Maintenir des patchs ? Sérieusement… Surtout que si chaque système doit le faire et au final on se retrouve avec 20 forks, ça n'est pas vraiment l'objectif. Une charge de travail supplémentaire ? On lui a jamais demandé de faire le travail, juste d'accepter le travail d'autres, de le fédérer afin que tout le monde y gagne et que la qualité du code commun augmente.
Un portage, pour être réussi et élégant doit se résoudre à exploiter le dénominateur commun entre les deux systèmes à gérer.
Non. Cela veut dire prendre en compte les différente spécificités.
ou se comporter sous Linux et *BSD de manière différente.
Oui. Ne pas offrir un match à 100% des features ? Big deal… Évidemment qu'il n'y aura pas de cgroup sous bsd, et alors est-ce que ça rend le 99% restant des autres features non pertinant ?
Scoop: systemd se comporte différemment sur différentes distros (relire ce journal…)
Ce qui en plus rend difficile la détection de problème, de la création de la documentation, etc.
Oui c'est plus difficile (logique) mais c'est ce travail qui rend au final la solution plus robuste.
est-ce que cela a un grand intérêt qu'un composant qui fait l'interface entre le noyau et l'espace utilisateur soit portable ?
Oui justement car ne pas le faire c'est reporter ce coût sur l'espace utilisateur justement…
SysV
Exactement la même situation: une solution d'un vendor, non standardisée, et non libre-réutilisable tel quel (surtout que la surface système dépendant de SysV init c'est un juste un sh, ça aurait été tout à fait possible). D'autres vendors s'en inspirent mais font un truc différent. Au final c'est l'utilisateur qui trinque et doit gèrer 50 façons différentes, ce qu'il ne fait pas. évidemment. Résultat ? Fragmentation de l'éco-système et affaiblissement/mort générale. Dire que seul Linux importe, c'est reffaire la même erreure et faire preuve de trop d'optimisme, il est probable qu'il soit perdant aussi…
De la même façon que de nombreux outils autours du noyau ne sont pas portables pour des raisons évidentes, je dirais que systemd peut en faire partie. Par contre, je pense qu'il serait intéressant de faire une API commune sur certains points dans ces systèmes. Une sorte de POSIX plus moderne sur cette question, mais laissant libre court à sa mise en œuvre.
Oui 100% d'accord. Vu que systemd est en gros cette nouvelle API/standard, c'est dommage de ne pas avoir pris l'opportunité de le faire correctement. 95% du code de systemd n'est pas du code system dépendant hein…
Note: la partie du milieu illustre bien que c'est d'abord un argumentaire idéologique ("cela devrait être notre but") et il rajoute une excuse soit disant rationnelle/technique:"une charge qui nous tire". Alors que, objectivement, porter un logiciel n'impacte pas sa qualité, au contraire. C'est tellement gros que venir affirmer le contraire est faire preuve d'une mauvaise foie flagrante.
«Oui, je ne pense pas que les BSD soient encore vraiment pertinents. Et je pense que l'obligation implicite de compatibilité avec ces systèmes, quand quelqu'un code un logiciel pour un bureau libre ou pour l'écosystème du Libre, est une charge qui nous tire en arrière pour très peu de bénéfices.
[…]
Ces systèmes sont non pertinents pour le but qui est de mettre du logiciel libre entre les mains de tout le monde, et je pense que cela devrait être notre but.
[…]
Debian kFreeBSD est juste un joujou et les gens ne doivent pas s'y tromper. C'est bien si les gens font des OS joujoux, tout le monde aime les joujoux après tout.»
En plus d'être méprisant du travail et des personnes qui travaillent sur ces systèmes, c'est assez clair qu'il ne souhaite pas la coopération, non ? Il me semble qu'il a aussi explicitement écrit qu'il ne mergerait pas de patch de portabilité mais qu'il n'empêcherait personne de forker ou qq chose du genre. À prendre avec des pincettes donc car je ne vais pas m'amuser à chercher la source, considérons simplement que c'est une interprétation de "est une charge qui nous tire en arrière".
Arrête, si tu lui dis que FreeBSD va avoir son launchd/systemd like, il va faire un malaise le mec ;)
Non, le projet consiste bien à porter launchd (celui d'Appel) et accessoirement d'ajouter les fonctionnalités manquantes au noyau de NextBSD (une sorte d'IPC fournie par mach sous MacOSX… IIRC). Bref rien à voir avec l'approche "seul au monde" prônée par certains.
D'ailleurs, FreeBSD a hérité de DragonFly un appel système pour faire du baby-sitting de process, et donc démontre qu'il n'y a pas que les cgroups comme solution. Bref que rien n'empêche objectivement de porter systemd sur BSD, il n'y a que l'hostilité affichée de son auteur.
C'est un fonctionnement simpliste qui permet à n'importe qui de créer des daemons
Ça n'est pas compliqué mais de la a dire que c'est "simpliste", faut pas exagèrer, hein. D'ailleurs ce sont deux concepts orthogonaux.
Le concept de daemon n'implique pas un traitement particulier de la session et des terminaux et réciproquement. On peut avoir un daemon controleur de session, ou pas contrôleur, avec un terminal, ou sans terminal. Un "daemon" est de ce fait une notion assez floue et qui dans le sens commun s'entend comme "tourne en arrière plan" (tourne == pas en tant que zombie…) mais sans impliquer d'autres comportements plus précis en ce qui concerne, p.e. la gestion de la session[1].
Effectivement, il y a des interactions et des changements d'états implicites avec la création/mort des processus, qu'il peut-être utile de comprendre pour ne pas se tirer une balle dans le pied. Bref dire que le hup sert à créer des daemons c'est comme dire que le klaxon sert écraser les piétons… Par exemple, ce screen/tmux qui nous occupe pour l'instant car il est sensé tourner en arrière-plan sans discontinuer (aux dernières nouvelles c'est un peu le sujet de la discussion, c'est un peu pourquoi on en est venu à dévier sur nohup) ne fonctionne pas du tout de la même façon qu'un programme lancé avec nohup même si, in fine, ils survivent tout deux à une rupture du terminal.
Pour info, HUP ça veut dire "hang up" et c'est le nom du signal que le noyau envoit au fameux "session leader" lorsqu'il détecte une perte sur la ligne du TTY "contrôleur". Ces histoires de tty controleur et de session est une relique de UNIX (enfin je crois que les sessions sont arrivées un peu plus tard avec BSD, la flemme d'aller vérifier), un gros hack qui s'est transformé en standard. Tout cela est bien documenté, il suffit de lire la doc, je ne ferrai pas l'affront de passer pour un "gouroux", on peut bien sûr discuter de la météo :D
Cette histoire de killer tous les users process, c'est un peu comme réinventer ce hack. Mais en encore plus crade car il n'y a plus de notion de session (enfin si, il parait que ça s'appelle logind et que ça sert à changer les ACL d'un fichier dans /dev/drm… pour ce que j'en ai compris) et donc pas de solution pour faire coopérer les programmes (on attend toujours le patch qui merge libdbus dans la glibc … :p et bye bye musl, uclib (ah non ça s'était déja fait))
C'est un peu retourner à l'ère des teletypes avec pour seul moyen pour se déconnecter que de tirer la fiche série…
Pour en revenir au sujet, pas la peine de se sentir idiot pour constater 1) c'est systemd qui a mis en avant un autre comportement assez surprenant 2) les empaqueteur debian ont peut-être mal évalué (ou ne se sont pas rendus compte de) la porté d'un tel changement 3) systemd reste une valeur trollifère sûre, au moins tout le monde est au courant; voir certains en font un argument marketing (cf. https://kaosx.us/news/2016/june/ )
Mon avis sur systemd (pour continuer un peu le trolll^W^Wla discussion) c'est que c'est à la fois trop et trop peu. Trop peu car j'ai un peu l'impression que c'est juste le produit d'une lubie pour faire jou-jou avec la dernière technique à la mode mais malheureusement sans profondes remises en questions ou innovations quant à la manière de concevoir un systèmes. Les avantages mis en avants sont souvent de l'ordre technique (ex. "pas de fuite possible de daemon", oui et ? moi j'ai jamais eu de daemon qui "fuite") voir rhéthorique (ex. "la classe tout le monde est dans son cgroup", mais maintenant, concrètement, qu'est-ce que je peux faire avec ?). Aussi paradoxalement, les techniques d'implémentations et les choix de conceptions sont décevants. À savoir: quantité importante de code dans un langage "unsafe", comportement difficilement explicable/non déterministe, API trop volatile/non-spécifiée, documentation imprécise et incomplète, dépendance sur d'autres composants et tous les problèmes qui vont avec (dbus), nécessite toujours un noyau récent, support déficient des montées en version sans rebooter (i.e. systemd est sensé sérialiser son état, mettre à jour son binaire puis recharger son état mais ça ne fonctionne pas très bien), flexibilité/configuratibilité très limitée, parti pris de ne pas vouloir être porté sur d'autre OS[2]… Conséquences de vouloir être ce "trop". En plus, il s'immisce partout, veut devenir une sorte d'API de-facto pour administrer un système: logind, timed, dbus, etc.
Sans finalement apporter de réelles avancées, il ne justifie pas, à mon sens, un tel coût.
Finalement, je constate que la rapprochement avec la guerre des unix est fort pertinent.
[1]: La fonction daemon est donc un cas particulier avec un comportement spécifique suffisant pour certains ou inacceptable pour d'autres. N'est pas daemon uniquement celui qui appelle daemon(), elle n'est d'ailleurs pas spécifée par POSIX (AFAICT).
[2]: le plus drôle dans cette histoire c'est que la personne à l'origine de cette décision, Lennart pour le nommer, justifie (et assume) cette décision avec un argument idéologico-politique. I.e. quand il dit "unix est mort, il s'appelle Linux" on est en plein dans le discours d'idées. C'est un comble de faire l'apologie d'une perfection (appelons un chat un chat) et en même temps de se refuser un moyen peu coûteux et avéré pour améliorer la qualité de son produit. Mais bon on a jamais pris de bonnes décisions en étant dogmatique… :p
HS: tu as l'air de prêter une signification erronée à ce terme. Pour ton info, cela désigne le diagnostique que l'on donne à un malade/patient dont l'état psychologique souffre alternativement d'épisodes de grave dépression et d'hypermanie.
quand tu as un parc de plus de 1000 machines, ça commence à arriver souvent.
Hmm, tu gères un parc de 1000 machines avec nohup???
me sauve très souvent d'une déconnexion ssh (ou moins souvent d'un crash ou un restart de Xorg)
Ca tombe bien, on ne parle pas d'SSH ici…
Vu ton manque flagrant de compréhension à la lecture, j'ai du mal à croire que tu, en te paraphrasant, aies été capable d'aller lire la doc pour comprendre que systemd est aussi un gestionnaire de session qui remplacera les daubes genre ksmserver et gnome-session.
(Ceci était une communication de l'association pour la défense des commentaires inutiles et gratuits.)
Sur une machine de calcul, lorsque tu lances un job via un scheduleur […]
En fait, logind fait exactement la même chose
Donc une parfaite illustration de "tried to be everything to everyone by providing the most general interface possible" si je comprends bien ?
il faut JUSTE ré-écrire nohup
Oui, comme tous les autres programmes qui utilisent le design pattern daemon() ou double fork. Tiens, il est où le patch de Lennart P. pour nohup et la glibc ?
Je suis d'accords avec le mainteneur de tmux: si on est cohérent, alors on modifie l'implémentation de daemon() dans la glibc pour parler avec systemd et éviter que chaque application doivent dupliquer le même code. Comme ça tout le monde est content, on garde l'interface posix et la vision de Lennart P.
+1, Mosh est super pratique… Du coup, au sujet de la question qui nous occupe, il inclue un support spécifique pour systemd ?
(Par contre au niveau de la charge cpu, je trouves mosh un peu décevant… Peut-être parce qu'il est écrit en python ?)
ps: qu'entends tu par redirection de port ?
Bon alors du coup, dans notre cas du KillUserProcess, est-ce que cela a mené à une correction des problèmes ?
Bien vu, tu mets le doigt sur la question essentielle. Si le problème est "il y a des process qui restent", je suppose que la réponse est oui. Si le problème est "le process X a un bug qui fait qu'il ne se ferme pas comme il devrait", alors la réponse est inverse. C'est comme choisir entre traiter la cause ou les symptômes; en fonction de l'objectif à atteindre la solution peut-être différente. Si l'objectif est à long terme, s'attaquer aux causes fonctionne généralement mieux.
[^] # Re: Dans l'art voluptueuse de ne rien comprendre
Posté par benja . En réponse au journal EDSL et F-algèbres. Évalué à 1. Dernière modification le 13 juin 2016 à 16:17.
C'est bien ton évaluateur. Par exemple "{lit = fun x -> x}" serait un évaluateur vers int. Ton évaluateur vers string, ça serait {lit= fun x -> string_of_int x}. Après tu appliques "mon_ast (eval_dict_string : string algebre)" tu obtiens un string, dans l'autre cas tu fais "mon_ast (eval_dict_int : int algebre)", l'idée c'est que ton type de résultat d'évaluation/valeur n'est pas explicité dans ton type "expr/ast/arbre" mais juste dans ton expr_dict/algebre/evaluateur. Tu utilises donc l'encoding de Böhm-Berarducci, cqfd :p
[^] # Re: Dans l'art voluptueuse de ne rien comprendre
Posté par benja . En réponse au journal EDSL et F-algèbres. Évalué à 1. Dernière modification le 13 juin 2016 à 16:06.
C'est un "record" avec un champs expi. C'est juste pour contourner l'impossibilité de faire un "type exp = forall a.a algebre -> a", on "emballe" la fonction dans le champs expi d'un record, car dans ce cas on peut faire le forall en utilisant la syntaxe 'a. type-exp.
C'est la destruction par pattern-match, équivalent à "fun record -> let e = record.expi in …"
On réemballe notre fonction dans un record. Encore une fois, ça aurait été mieux de passer une fonction directement ("la closure") mais parce qu'on ne sait pas exprimer son type sans passer par ce contournement. On aurait pu utiliser un objet normalement¸ca aurait été pareil. C'est le même problème que tu as en faisait.
CORRECTION: sorry m'est trompé la en fait je crois que t'évalue ton expression justement, ton e = expri. Tu évalue ta closure, ton {} c'est ton dictionaire avec tes fonction "lit", "sub", etc.
[^] # Re: Dans l'art voluptueuse de ne rien comprendre
Posté par benja . En réponse au journal EDSL et F-algèbres. Évalué à 1. Dernière modification le 13 juin 2016 à 15:07.
Je connais pas ton code, mais (il me semble que) la transformation revient à transformer tous les constructeurs des nodes de ton arbre en un fonctions sur un évaluateur. Par exemple si tu avais:
Tu le changes en
Et tu changes tes evals
comme ceci
Chaque match de ton eval devient une fonction différente dans ton évaluateur (ça n'est pas pour rien qu'Oleg l'appelle expr_dict dans son exemple…) Par contre ce journal a utilisé un tuple, mais bon ça n'est pas très pratique à utiliser amha.
Donc en gros tu changes tes constructeurs en closures sur l'évaluateur. Tu construits ton abre en faisant une application partielle des tes fonctions de construction. Donc toutes tes expressions deviennent des fonctions d'un évaluateur vers un résultat, soit le fameux type de ce journal
type expr = forall 'a . 'a algebre -> 'a. C'est plus clair ? À toi de nous dire si cette réécriture t'apporte quelque chose de mieux ?[^] # Re: Dans l'art voluptueuse de ne rien comprendre
Posté par benja . En réponse au journal EDSL et F-algèbres. Évalué à 1.
Le truc pour comprendre c'est qu'il faut simplement lire le code d'Oleg (le dernier lien) et après tout devient limpide, en admettons une certaine familiarité avec ocaml :P En fait j'apprécie l'effort que son auteur a fait pour rendre ce journal précis et didactique : en effet la terminologie utilisée correspond finalement à la doc officielle d'ocaml. Bref grâce à ce journal j'ai appris la technique de fold au lieu de l'éval récursif, le fameux codage de Böhm-Berarducci, Plus simplement c'est un évaluateur en style CPS. Au lieu d'avoir un évaluateur récusrif
eval expr = case expr with App x y -> x (eval y)sur le type "expr" on a un type "expr" qui accepte un évaluateur sur X et retourne X:expr_app f x = fun evaluator -> evaluator.app f (x evaluator).L'astuce qu'Oleg utilise en fait en ocaml pour faire un type paramètrique sans fixer le paramètre, c'est qu'il faut embaler le type des fonctions constructrices d'expression dans un type du genre méthode polymorphique d'objet. En utilisant
type expr = { expr : 'a . 'a algebre -> 'a }on arrive à exprimer "une fonction qui en reçevant une algèbre paramètré sur X s'évalue en X", sans fixer le type X au type de expr, i.e. le forall a. d'Haskell mentionné dans le journal. Si l'auteur du journal a trouvé une autre méthode pour exprimer le "forall" sans passer par cette indirection (donc ni par un objet, ni par un module first class), ça m'intéresse. Les GADT ne me semblent pas adaptés, mais, qui sait ?Par contre à la question de la performance, ben je crains que cette technique soit moins efficace parce que cela revient à construire un objet plus une closure pour chaque "expr" (closure = function partiellement appliqué).
Btw, on pourrait traduire le code d'Oleg en Lua ou en javascript, j'imagine que ça rendrait ce journal plus compréhensible pour la majorité, ceci dit ça n'est pa la première fois que l'on cause ocaml sur ce site :-) Cela donnerait quelque chose comme ceci (note j'y connais pas grand chose en javascript, ça compile probablement pas tel quel).
[^] # Re: Video only
Posté par benja . En réponse au journal Microsoft Windows Subsystem For Linux. Évalué à 1. Dernière modification le 12 juin 2016 à 18:46.
Oui loin de moi l'idée d'avoir voulu faire sous-entendre le contraire. Je voulais simplement signaler que s'ils avaient vraiment eu besoin de repiquer quelque chose, il y existait du code qui n'est pas copylefté.
Ok je suis démasqué, j'avoue mon incompétence dans ce sujet. J'ai juste un souvenir peu glorieux d'une certaine implémentation de nfs, mais les détails sont déjà lointains, je te laisse donc le bénéfice du doute quant à la qualité de ce produit et de sa maintenance, et je te présente donc mes plus plates excuses. En ce qui concerne la motivation de proposer une telle chose, je peux supposer qu'implicitement tu es d'accord, n'est-ce pas ?
[^] # Re: Commenter sur ce fil ?≣ Être orthogonal à Fedora
Posté par benja . En réponse au journal Attention avec systemd, Tmux ne survit plus après la fermeture de la session.. Évalué à 4.
Ouaw super merci pour le lien (comme quoi il n'y a pas que sur debian-devel qu'on a besoin de popcorn). Une petite perle, de DJ Delorie (pour ceux qui ne savent pas, le gars à porté gcc sur DOS parmis probablement plein d'autres trucs de dingues. Je ne résiste pas à la copier ici :p
(La réponse de l'intéressé ne vaut probablement pas la peine que je la recopie ici…)
[^] # Re: Video only
Posté par benja . En réponse au journal Microsoft Windows Subsystem For Linux. Évalué à 2. Dernière modification le 10 juin 2016 à 17:30.
Pour la clareté de mon propos, j'ai oublié de préciser que ces systèmes proposent déja une émulation linux qui est sous license de type BSD.
[^] # Re: Une nouvelle distribution ?
Posté par benja . En réponse au journal Microsoft Windows Subsystem For Linux. Évalué à 10.
L'avantage, pour Microsoft, c'est que le DSI va pouvoir poser la question inverse…
[^] # Re: Video only
Posté par benja . En réponse au journal Microsoft Windows Subsystem For Linux. Évalué à 6.
Bah en fait ça s'apparent plus à l'émulation de syscall apparue avec les BSDs qu'à wine.
En gros c'est juste le loader, gèrer le sys-enter et implémenter les syscalls. Avec derrière un travail pour traduire la sémantique posix/linux sur l'implémentation du noyau NT. Pour l'instant c'est fait de manière grossière (et probablement pour toujours cf. deuxième remarque): pas de mapping EUID, tout est "root", … On reste de loin du travail que wine doit effectuer qui consiste en plus à réimplémenter toutes les bibliothèques (ce qui est considérable).
Les ingénieurs de windows on pu s'inspirer, voir prendre du code des BSD et d'opensolaris sans aucun problème. D'ailleurs dixit Bryan Cantrill, c'est assez simple à faire vu que l'interface de linux ne consiste "que en" ces syscall, et elle est stable dans le temps, contrairement aux systèmes bsd. D'ailleurs historiquement ce mécanisme est utilisé sur bsd pour faire tourner d'ancien binaires.
Deuxième remarque, ça n'est pas la première fois qu'ils font le coups: se rappeller le unix subsystem for windows qui en gros était bien pourri, n'a jamais été maintenu et a juste servi à faire migrer des gens vers leur environement.
# As
Posté par benja . En réponse au message Utilisation de debian testing. Évalué à 2. Dernière modification le 09 juin 2016 à 17:12.
a) historique
Il y a dans tous les cas /var/log/dpkg,log, Et puis en fonction de(s) l'interface(s) que tu as utilisée(s) tu auras aussi /var/log/aptitude.log, /var/log/apt/* (ou autres? pkg-kit, synaptic ont probablement aussi leur log qq part.). À partir d'un moment (une certaine taille p.e.) ces fichiers seront coupés et sauvegardés dans *.1.gz, puis 2.gz, jusqu'à 10 par défaut, par l'utlitaire logrotate.
b) freeze
Cf. c)
c) dans quelle version tu es un fois que la nouvelle stable sort.
Ça dépend. Soit dans ton fichier /etc/apt/sources.list tu as mis le nom de la version (stretch en l'occurence), ben alors tu passes en stable, le process de mise-à-jour ne modifie pas ce fichier (au contraire d'ubuntu où tu dois utiliser un outil spéficique pour faire un upgrade, dans debian tu peux simplement changer le nom de la distribution dans ce fichier (tu peux aussi sur ubuntu mais ça n'est pas "officiel", ymmv)). Soit tu as mis "testing", ben alors tu restes en testing et tu peux effectivement te poser la question de savoir s'il valait vraiment la peine de suivre le freeze ;-) Plus subtilement, tu peux passer en unstable pendant le freeze et repasser en testing juste au moment de la sortie car en gros un fois que la nouvelle stable est sortie, tous les paquets de unstable vont migrer dans testing. Enfin bon ça sera unstable pendant un moment (apt pinnning comme on t'as dit peut être un solution aussi pendant cette période de transition pour être dans un mix testing(freeze) + unstable)… donc bon à toi de voir.
(Bonne question btw!)
http://www.debian.org/releases/testing/index.fr.html
[^] # Re: systemd, le nouveau Multics
Posté par benja . En réponse au journal Attention avec systemd, Tmux ne survit plus après la fermeture de la session.. Évalué à 3. Dernière modification le 08 juin 2016 à 17:59.
Je parlais de SYSV au moment de la "guerre" des unix… Je vois pas en quoi systemd homogénéise quoi que ce soit de ta liste, à part refuser de fonctionner si CONFIG_XYZ n'est pas activée ? D'ailleurs je ne vois pas pourqoi tu pars sur un délire d'homogénéisation. c'est par rapport à quelque chose que j'ai dite ?
On est +/- d'accord sur ce point là. Sauf que systemd a pris la place, mais oui pourqoi pas, on peut le faire au dessus de systemd même si cela ne me semble pas la manière la plus économe en labeur.
Laisse moi sourire…
Tu sais lire ?
[^] # Re: systemd, le nouveau Multics
Posté par benja . En réponse au journal Attention avec systemd, Tmux ne survit plus après la fermeture de la session.. Évalué à 2. Dernière modification le 08 juin 2016 à 17:39.
Écoutes ça n'est pas uniquement moi qui le dit. Bénéfice > coût, si tu ne me crois pas, ben tant pis. Pose la question à des personnes qui maintiennent un logiciel d'envergure et portable.
T'inquiètes pas, s'il n'y a personne qui maintient/utilise, ben on retire le support. c'est aussi simple que ça… Juste laisser la possibilité.
(le reste de tes arguments convient à l'égard de toute contribution, pas uniquement de type "port"… bref ça pue la mauvaise foie).
[^] # Re: systemd, le nouveau Multics
Posté par benja . En réponse au journal Attention avec systemd, Tmux ne survit plus après la fermeture de la session.. Évalué à 2.
Maintenir des patchs ? Sérieusement… Surtout que si chaque système doit le faire et au final on se retrouve avec 20 forks, ça n'est pas vraiment l'objectif. Une charge de travail supplémentaire ? On lui a jamais demandé de faire le travail, juste d'accepter le travail d'autres, de le fédérer afin que tout le monde y gagne et que la qualité du code commun augmente.
[^] # Re: systemd, le nouveau Multics
Posté par benja . En réponse au journal Attention avec systemd, Tmux ne survit plus après la fermeture de la session.. Évalué à 2.
Rapidement.
Non. Cela veut dire prendre en compte les différente spécificités.
Oui. Ne pas offrir un match à 100% des features ? Big deal… Évidemment qu'il n'y aura pas de cgroup sous bsd, et alors est-ce que ça rend le 99% restant des autres features non pertinant ?
Scoop: systemd se comporte différemment sur différentes distros (relire ce journal…)
Oui c'est plus difficile (logique) mais c'est ce travail qui rend au final la solution plus robuste.
Oui justement car ne pas le faire c'est reporter ce coût sur l'espace utilisateur justement…
Exactement la même situation: une solution d'un vendor, non standardisée, et non libre-réutilisable tel quel (surtout que la surface système dépendant de SysV init c'est un juste un sh, ça aurait été tout à fait possible). D'autres vendors s'en inspirent mais font un truc différent. Au final c'est l'utilisateur qui trinque et doit gèrer 50 façons différentes, ce qu'il ne fait pas. évidemment. Résultat ? Fragmentation de l'éco-système et affaiblissement/mort générale. Dire que seul Linux importe, c'est reffaire la même erreure et faire preuve de trop d'optimisme, il est probable qu'il soit perdant aussi…
Oui 100% d'accord. Vu que systemd est en gros cette nouvelle API/standard, c'est dommage de ne pas avoir pris l'opportunité de le faire correctement. 95% du code de systemd n'est pas du code system dépendant hein…
[^] # Re: systemd, le nouveau Multics
Posté par benja . En réponse au journal Attention avec systemd, Tmux ne survit plus après la fermeture de la session.. Évalué à 6.
Note: la partie du milieu illustre bien que c'est d'abord un argumentaire idéologique ("cela devrait être notre but") et il rajoute une excuse soit disant rationnelle/technique:"une charge qui nous tire". Alors que, objectivement, porter un logiciel n'impacte pas sa qualité, au contraire. C'est tellement gros que venir affirmer le contraire est faire preuve d'une mauvaise foie flagrante.
[^] # Re: systemd, le nouveau Multics
Posté par benja . En réponse au journal Attention avec systemd, Tmux ne survit plus après la fermeture de la session.. Évalué à 9.
http://linuxfr.org/nodes/86687/comments/1249943
http://linuxfr.org/news/un-entretien-avec-lennart-poettering
«Oui, je ne pense pas que les BSD soient encore vraiment pertinents. Et je pense que l'obligation implicite de compatibilité avec ces systèmes, quand quelqu'un code un logiciel pour un bureau libre ou pour l'écosystème du Libre, est une charge qui nous tire en arrière pour très peu de bénéfices.
[…]
Ces systèmes sont non pertinents pour le but qui est de mettre du logiciel libre entre les mains de tout le monde, et je pense que cela devrait être notre but.
[…]
Debian kFreeBSD est juste un joujou et les gens ne doivent pas s'y tromper. C'est bien si les gens font des OS joujoux, tout le monde aime les joujoux après tout.»
En plus d'être méprisant du travail et des personnes qui travaillent sur ces systèmes, c'est assez clair qu'il ne souhaite pas la coopération, non ? Il me semble qu'il a aussi explicitement écrit qu'il ne mergerait pas de patch de portabilité mais qu'il n'empêcherait personne de forker ou qq chose du genre. À prendre avec des pincettes donc car je ne vais pas m'amuser à chercher la source, considérons simplement que c'est une interprétation de "est une charge qui nous tire en arrière".
[^] # Re: systemd, le nouveau Multics
Posté par benja . En réponse au journal Attention avec systemd, Tmux ne survit plus après la fermeture de la session.. Évalué à 3.
Non, le projet consiste bien à porter launchd (celui d'Appel) et accessoirement d'ajouter les fonctionnalités manquantes au noyau de NextBSD (une sorte d'IPC fournie par mach sous MacOSX… IIRC). Bref rien à voir avec l'approche "seul au monde" prônée par certains.
D'ailleurs, FreeBSD a hérité de DragonFly un appel système pour faire du baby-sitting de process, et donc démontre qu'il n'y a pas que les cgroups comme solution. Bref que rien n'empêche objectivement de porter systemd sur BSD, il n'y a que l'hostilité affichée de son auteur.
[^] # Re: systemd, le nouveau Multics
Posté par benja . En réponse au journal Attention avec systemd, Tmux ne survit plus après la fermeture de la session.. Évalué à 8.
Ça n'est pas compliqué mais de la a dire que c'est "simpliste", faut pas exagèrer, hein. D'ailleurs ce sont deux concepts orthogonaux.
Le concept de daemon n'implique pas un traitement particulier de la session et des terminaux et réciproquement. On peut avoir un daemon controleur de session, ou pas contrôleur, avec un terminal, ou sans terminal. Un "daemon" est de ce fait une notion assez floue et qui dans le sens commun s'entend comme "tourne en arrière plan" (tourne == pas en tant que zombie…) mais sans impliquer d'autres comportements plus précis en ce qui concerne, p.e. la gestion de la session[1].
Effectivement, il y a des interactions et des changements d'états implicites avec la création/mort des processus, qu'il peut-être utile de comprendre pour ne pas se tirer une balle dans le pied. Bref dire que le hup sert à créer des daemons c'est comme dire que le klaxon sert écraser les piétons… Par exemple, ce screen/tmux qui nous occupe pour l'instant car il est sensé tourner en arrière-plan sans discontinuer (aux dernières nouvelles c'est un peu le sujet de la discussion, c'est un peu pourquoi on en est venu à dévier sur nohup) ne fonctionne pas du tout de la même façon qu'un programme lancé avec nohup même si, in fine, ils survivent tout deux à une rupture du terminal.
Pour info, HUP ça veut dire "hang up" et c'est le nom du signal que le noyau envoit au fameux "session leader" lorsqu'il détecte une perte sur la ligne du TTY "contrôleur". Ces histoires de tty controleur et de session est une relique de UNIX (enfin je crois que les sessions sont arrivées un peu plus tard avec BSD, la flemme d'aller vérifier), un gros hack qui s'est transformé en standard. Tout cela est bien documenté, il suffit de lire la doc, je ne ferrai pas l'affront de passer pour un "gouroux", on peut bien sûr discuter de la météo :D
Cette histoire de killer tous les users process, c'est un peu comme réinventer ce hack. Mais en encore plus crade car il n'y a plus de notion de session (enfin si, il parait que ça s'appelle logind et que ça sert à changer les ACL d'un fichier dans /dev/drm… pour ce que j'en ai compris) et donc pas de solution pour faire coopérer les programmes (on attend toujours le patch qui merge libdbus dans la glibc … :p et bye bye musl, uclib (ah non ça s'était déja fait))
C'est un peu retourner à l'ère des teletypes avec pour seul moyen pour se déconnecter que de tirer la fiche série…
Pour en revenir au sujet, pas la peine de se sentir idiot pour constater 1) c'est systemd qui a mis en avant un autre comportement assez surprenant 2) les empaqueteur debian ont peut-être mal évalué (ou ne se sont pas rendus compte de) la porté d'un tel changement 3) systemd reste une valeur trollifère sûre, au moins tout le monde est au courant; voir certains en font un argument marketing (cf. https://kaosx.us/news/2016/june/ )
Mon avis sur systemd (pour continuer un peu le trolll
^W^Wla discussion) c'est que c'est à la fois trop et trop peu. Trop peu car j'ai un peu l'impression que c'est juste le produit d'une lubie pour faire jou-jou avec la dernière technique à la mode mais malheureusement sans profondes remises en questions ou innovations quant à la manière de concevoir un systèmes. Les avantages mis en avants sont souvent de l'ordre technique (ex. "pas de fuite possible de daemon", oui et ? moi j'ai jamais eu de daemon qui "fuite") voir rhéthorique (ex. "la classe tout le monde est dans son cgroup", mais maintenant, concrètement, qu'est-ce que je peux faire avec ?). Aussi paradoxalement, les techniques d'implémentations et les choix de conceptions sont décevants. À savoir: quantité importante de code dans un langage "unsafe", comportement difficilement explicable/non déterministe, API trop volatile/non-spécifiée, documentation imprécise et incomplète, dépendance sur d'autres composants et tous les problèmes qui vont avec (dbus), nécessite toujours un noyau récent, support déficient des montées en version sans rebooter (i.e. systemd est sensé sérialiser son état, mettre à jour son binaire puis recharger son état mais ça ne fonctionne pas très bien), flexibilité/configuratibilité très limitée, parti pris de ne pas vouloir être porté sur d'autre OS[2]… Conséquences de vouloir être ce "trop". En plus, il s'immisce partout, veut devenir une sorte d'API de-facto pour administrer un système: logind, timed, dbus, etc.Sans finalement apporter de réelles avancées, il ne justifie pas, à mon sens, un tel coût.
Finalement, je constate que la rapprochement avec la guerre des unix est fort pertinent.
[1]: La fonction daemon est donc un cas particulier avec un comportement spécifique suffisant pour certains ou inacceptable pour d'autres. N'est pas daemon uniquement celui qui appelle daemon(), elle n'est d'ailleurs pas spécifée par POSIX (AFAICT).
[2]: le plus drôle dans cette histoire c'est que la personne à l'origine de cette décision, Lennart pour le nommer, justifie (et assume) cette décision avec un argument idéologico-politique. I.e. quand il dit "unix est mort, il s'appelle Linux" on est en plein dans le discours d'idées. C'est un comble de faire l'apologie d'une perfection (appelons un chat un chat) et en même temps de se refuser un moyen peu coûteux et avéré pour améliorer la qualité de son produit. Mais bon on a jamais pris de bonnes décisions en étant dogmatique… :p
[^] # Re: Bug ferme chez tmux
Posté par benja . En réponse au journal Attention avec systemd, Tmux ne survit plus après la fermeture de la session.. Évalué à 8.
HS: tu as l'air de prêter une signification erronée à ce terme. Pour ton info, cela désigne le diagnostique que l'on donne à un malade/patient dont l'état psychologique souffre alternativement d'épisodes de grave dépression et d'hypermanie.
[^] # Re: systemd, le nouveau Multics
Posté par benja . En réponse au journal Attention avec systemd, Tmux ne survit plus après la fermeture de la session.. Évalué à 1.
Vu ton manque flagrant de compréhension à la lecture, j'ai du mal à croire que tu, en te paraphrasant, aies été capable d'aller lire la doc pour comprendre que systemd est aussi un gestionnaire de session qui remplacera les daubes genre ksmserver et gnome-session.
(Ceci était une communication de l'association pour la défense des commentaires inutiles et gratuits.)
[^] # Re: musl
Posté par benja . En réponse au message Compatibilité de musl avec cible sous glibc [Résolu]. Évalué à 1.
Parfait !
[^] # Re: systemd, le nouveau Multics
Posté par benja . En réponse au journal Attention avec systemd, Tmux ne survit plus après la fermeture de la session.. Évalué à 9.
Donc une parfaite illustration de "tried to be everything to everyone by providing the most general interface possible" si je comprends bien ?
Oui, comme tous les autres programmes qui utilisent le design pattern daemon() ou double fork. Tiens, il est où le patch de Lennart P. pour nohup et la glibc ?
Je suis d'accords avec le mainteneur de tmux: si on est cohérent, alors on modifie l'implémentation de daemon() dans la glibc pour parler avec systemd et éviter que chaque application doivent dupliquer le même code. Comme ça tout le monde est content, on garde l'interface posix et la vision de Lennart P.
[^] # Re: Ne pas utiliser, recompiler… ou changer une option.
Posté par benja . En réponse au journal Attention avec systemd, Tmux ne survit plus après la fermeture de la session.. Évalué à 1.
La vraie vie, toussa…
Explicit is better than implicit !
(ok: vraie vie, toussa…;-) )
[^] # Re: Bug ferme chez tmux
Posté par benja . En réponse au journal Attention avec systemd, Tmux ne survit plus après la fermeture de la session.. Évalué à 1. Dernière modification le 03 juin 2016 à 15:12.
+1, Mosh est super pratique… Du coup, au sujet de la question qui nous occupe, il inclue un support spécifique pour systemd ?
(Par contre au niveau de la charge cpu, je trouves mosh un peu décevant… Peut-être parce qu'il est écrit en python ?)
ps: qu'entends tu par redirection de port ?
[^] # Re: Ne pas utiliser, recompiler… ou changer une option.
Posté par benja . En réponse au journal Attention avec systemd, Tmux ne survit plus après la fermeture de la session.. Évalué à 3.
Bien vu, tu mets le doigt sur la question essentielle. Si le problème est "il y a des process qui restent", je suppose que la réponse est oui. Si le problème est "le process X a un bug qui fait qu'il ne se ferme pas comme il devrait", alors la réponse est inverse. C'est comme choisir entre traiter la cause ou les symptômes; en fonction de l'objectif à atteindre la solution peut-être différente. Si l'objectif est à long terme, s'attaquer aux causes fonctionne généralement mieux.