benja a écrit 1211 commentaires

Journald résout ca par défaut, il limite la taille des logs.

1) Non, systemd/journald ne corrige pas les bugs des autres applications. Au mieux, il est un palliatif, au pire il retarde leurs corrections.

2) J'ai eu le cas ou la limitation de journald ne fonctionnait pas, il fallait lancer la commande idoine à la main pour forcer la GC. Espérons que cela fonctionne de manière fiable maintenant.

3) Tout sysadmin qui se respecte se doit de passer en revue ces "défauts" car par définitions, ils ne sont pas adaptés (aussi appelés les "tunables"). Systemd n'a pas inventé la poudre verte de ce côté là non-plus. Un desktop n'est pas un serveur, un serveur n'en est pas un autre. J'en veux pour preuve: les valeurs par défaut (SystemMaxUse et SystemKeepFree), sont clairement inadaptées: un serveur aura un /var/log séparé -> ça n'a pas de sens de limiter à 10% ! Par opposition, un desktop aura probablement qu'une seule partition, 4G de logs ça fait quand même beaucoup pour un desktop, 10MB me semblent plus que suffisants. De plus, avec les FS copy-on-write (qui sont désignés par certains, dont l'auteur de systemd à une époque) comme étant le future du desktop, 15% d'espace libre est insuffisant pour des performances correctes…

4) Pour une distribution orienté serveur, il semble logique de ne pas imposer de limitations arbitraires pour laisser le sysadmin les mettre. Cela évite les problème du genre "j'ai perdu un enregistrement important parce que le système est configuré par défaut pour ne pas tout garder" vs "j'ai perdu des données parce que mon disque est plein"; bien qu'il s'agisse d'incompétence de l'admin dans les deux situations, dans le 2e cas de figure il va avoir du mal à rejeter la responsabilité sur le fournisseur de son OS. Maintenant est-ce que la distribution et/ou systemd doivent protéger l'usager pour une utilisation desktop ? Probablement oui. Par contre je suis moins certain que cela doit-être le défaut, mais par exemple quelque chose à activer pendant l'installation.

Je suis d'accord pour dire que linux n'est toujours pas prêt pour le desktop. Mais objectivement ça n'est pas beaucoup mieux chez la concurrence. C'est clair qu'avoir une architecture qui permet d'imposer des gardes-fous (sandboxes, limitation de journald, etc) aide. Mails il faut arrêter de propager le mythe du Saint Graal. Je crois que vous êtes bien placé pour savoir qu'en informatique, comme partout, la perfection n'existera jamais ;-)

(fin de mon 1/4 heure je trolle sur systemd :D)

Qui de la fusion ? C'est à dire, peut-on fusionner deux /home ? Et comment le système décide quel FS va se remplir en premier ? Sans réponse à ces questions, je ne vois pas trop l'intérêt surtout que le posteur part d'une situation vierge… Bref, je pense aussi que la solution la moins "hasardeuse", la plus simple et future-proof est LVM. Attention aussi qu'en raid 0 on augmente significativement la probabilité d'une panne…

Ou encore, sans devoir calculer les numéros de ligne avec grep : sed -n /Michel/,+2p.

;-)

Marrant la note de ton commentaire :D (ou pas… on se croirait en plein meeting politique) J'imagine que les premiers à crier au complot anti-systemd sont malheureusement aussi les derniers à savoir argumenter.

Donc tu fais tourner postgres sous un autre user, bien. Mais tu ne peux pas te logger sous cet user pour effectuer des tâches administratives; comment fais-tu alors ?

oh-merde-c-est-encore-un-autre-format-de-timestamp

Mauvais exemple… Pourquoi un daemon qui n'utilisait pas syslog(3) va se mettre à l'utiliser tout d'un coup ?

PS: si tu as des besoins particuliers au niveau du logging, je pourrais te conseiller quelques solutions qui prédatent systemd/journald. Tu dois juste dire quel est ton use-case réel, pas un exemple inventé qui ne correspond à rien sauf à essayer de justifier ton argumentaire.

Sympa le rctl, et ça supporte aussi les jails ! Et ça a l'air d'une simplicité, à comparer au bazard que c'est du côté linux entre lxc,libvirt,nspaw,sytemd,openvz, etc. /me rêve que quelqu'un resynchronise le code jail de dragonfly…

Ok merci !

Donc pour résumer, sous Linux il existe déjà un pilote "natif" qui ne sera jamais intégré et un pilote fuse aux performances moindres, sous FreeBSD il y a un pilote natif qui fonctionne bien (et à priori aussi via fuse), sous NetBSD il y a un pilote natif en développement et, à priori, un support via fuse, sous OpenBSD, à priori, il pourrait aussi y avoir un support via fuse. C'est correct ?

(Sous DragonFly, si je ne me trompe pas, fuse n'est actuellement pas fonctionnel mais il y a eu un volontaire qui s'est porté connu pour le rendre).

Une référence ? N'y-a-t'il pas non plus un projet d'implémentation fuse, ce qui pourrait pallier une non-intégration officielle ?

https://en.wikipedia.org/wiki/Daemon_%28computing%29#Creation

Bien que, techniquement, ça n'est pas un daemon…

Si tu veux utiliser mes services hébergés chez toi, payes (tu n'auras pas les sources).sion c'est gratos pour un usage public

En fait, si, tu peux avoir les sources de la version proprio

Je crois qu'il parlait du modèle de github. Son argument étant tant que gitlab n'a pas de communauté d'utilisateurs-développeurs forte, le fait qu'il soit libre ne le différencie pas vraiment de github. Par ce qu'il serait stupide pour une organisation d'investir dans de la RD pour au final se retrouver à maintenir son propre fork. Vous semblez confirmer ce point de vue, au niveau de votre organisation.

On peut se demander aussi si ce constat est du à un manque de la demande ou à une à une offre volontairement bridée. En d'autres mots, est-ce que les clients "pros" demandent simplement une solution clefs-en-main sans réel besoin d'une solution complètement customisable; ce que pourrait être gitlab si il y avait un processus de développement communautaire non pipé (note: interprétation de "je conserve un avantage commercial sur toi"; personnellement je n'ai pas d'opinion éclairée sur ce sujet: j'évite l'un comme l'autre ;-) ).

Par curiosité, quel est la propriété qui a fonctionné pour vous ?

Je viens d'essayer CPUQuota=20% sur une debian. Malheureusement, 1) ça ne modifie pas le quota d'un daemon déja lancé, de plus j'ai obtenu un message comme quoi il fallait exécuter un systemctl daemon-reload, donc cela ferait donc trois commandes a exécuter: set-property, daemon-reload et restart (à minima deux, la deuxième étant "reboot"…) 2) ça ne semble pas fonctionner, tout simplement :-/

Post Scriptum :

Ça permet aux personnes « non concernées » de tomber sur l'info et d'éventuellement devenir concernées.

J'aurais plus pensé que c'est la discussion, et non le journal, qui susciterait la naissance d'un intérêt par les «non-concernés».

Aussi paradoxalement, si la question d'un journal était "que pensez-vous du fait de poser une question spéficique à destination d'un public de connaisseur, sans expliquer les termes utilisés afin que des non-connaisseurs puissent devenir concernés", engendrerait-il des contributions pertinentes ?

Et donc, votre avis sur la question (du journal, pas celle de savoir ce qui est bien séant) ? Concerné ou pas ?

Personnellement, j'ai un petit faible pour CK parce qu'il incarne l'esprit du hackeur amateur, désintéressé voire philantrope. Et puis à l'époque il s'était poliment fait remercié par Linus, certes ça n'était pas le premier ni le dernier du genre, mais cet évènement montre bien que le développement du noyau reste avant tout une histoire politique (la solution "techniquement neutre" aurait été d'accepter plusieurs schedulers). Par contre je ne l'ai jamais utilisé, mais théoriquement, oui il est sensé être plus efficace car il a fait le compromis de sacrifier la sacro-sainte équité[1] du CFS[2] pour privilégier l'interactivité et l'utilisation d'un algorithme plus simple. En plus, IIRC[3], il parait que le gars est un médecin à la base ;-)

[1]: tiens tiens, on pourrait faire un lien avec le sujet de ce thread… :D
[2]: "Completly Fair Scheduler", ordonnanceur complètement équitable (pour ceux qui se sentent concernés mais qui ne savent pas pourquoi).
[3]: "If I Recall Correctly", en français "si je me souviens bien" (ça c'est pour être pertinenté :p)

Ou bien timeout 60 sh -c "a && b && c".

En fait on peut carrément se passer de stat:

--newer-mtime=DATE
              Work on files whose data changed after the DATE.  If DATE starts
              with / or . it is taken to be a file name;  the  mtime  of  that
              file is used as the date.

Donc tout simplement tar --newer-mtime="./`ls $a/*$t* -t | tail -1`" Si $a est absolu, alors il faut omettre le ./ évidemment.

Remarque aussi en passant, le double encadrement avec des guillemets est plus que probablement la source de l'erreur originale. Les guillemets intérieurs n'ont aucune raison d'être, tar ne s'attend probablement pas à parser une date qui commence et qui fini par des guillemets. Les premiers guillemets empêchent le shell de séparer la date au niveau de l'espace lorsqu'il construit la liste d'arguments à tar.

Dans un fichier unit ?

  /*
     * iASL Warning: There were 15 external control methods found during
     * disassembly, but only 0 were resolved (15 unresolved). Additional
     * ACPI tables may be required to properly disassemble the code. This
     * resulting disassembler output file may not compile because the
     * disassembler did not know how many arguments to assign to the
     * unresolved methods. Note: SSDTs can be dynamically loaded at
     * runtime and may or may not be available via the host OS.
     *
     * To specify the tables needed to resolve external control method
     * references, the -e option can be used to specify the filenames.
     * Example iASL invocations:
     *     iasl -e ssdt1.aml ssdt2.aml ssdt3.aml -d dsdt.aml
     *     iasl -e dsdt.aml ssdt2.aml -d ssdt1.aml
     *     iasl -e ssdt*.aml -d dsdt.aml
     */

Ok ça se tient.

(Mieux serait d'avoir type 'a liste_non_vide = End of 'a | Cons of 'a * 'a liste_non_vide)

Faux, avec fold_right, on commence avec Nil.

Correction: techniquement ce que vous dites est correct, simplement on commence l'évaluation une fois que l'on a atteint Nil.

Moi j'aurais écrit votre version list comme ceci… Enfin peu importe je crois que je n'apporterai plus rien à cette discussion qui tourne en queue de boudin.

let rec je_ne_suis_pas_fold f g = function
| Nil -> raise (Invalid_argument "pas de graine...")
| Cons (x, Nil) -> (f x)
| Cons (hd, tl) -> g (f hd) (je_ne_suis_pas_fold f g tl)

Il n'y a pas de zero dans le cas des arbres !

Avec votre version je suis obligé de l'écrire "valeur_de_depart + (fold f g t)" ou "fold f g (Tree(Node(valeur_de_depart),t)", je trouve ça vachement mois agréable à utiliser pour cet usage.

C'est la fonction f qui joue le rôle de cette constante

J'attends toujours la démonstration, qq chose me dit que ça n'est pas si trivial…

a graine est une constante

La graine s'appelle préférablement variable d'accumulation, et elle n'est évidemment pas constante pendant la traversée. là ou avec votre "fold", f et g sont fixes… Qui peut le plus, peut le moins ;-)

En étant pédant, j'ajouterais que toute valeur dans un langage fonctionnelle pur est constante.

et on te dit que comme on est dans un langage fonctionnel cela peut aussi être une fonction.

heu… je ne pensais pas donner l'impression d'avoir besoin de cette explication

Il n'y a que toi que cela perturbe, tu es la première personne que je rencontre qui voit là un problème.

Je suis désolé, appeler par le même nom deux fonctions avec des sémantiques différentes, je trouve cela perturbant. Surtout lorsqu'une des sémantiques est dans la librairie standard et reprise par d'autres librairies populaires.

Quand on parcourt une liste on termine toujours sur Nil

Faux, avec fold_right, on commence avec Nil.

et c'est la qu'on utilise la graine.

Encore faux. Cf. fold_left.

Désolé, mais je faisais juste une remarque pour essayer de rendre votre prochain exposé plus pédagogique. Je n'ai pas besoin que l'on m'explique ce que j'aurais mal compris alors que j'exprime juste un fait: l'usage en ocaml est de nommer le reduce "fold", et pas votre catamorphisme.