Sytoka Modon a écrit 4544 commentaires

Système de quota non finit, pas moyen de savoir quel espace il reste -> impossible à utiliser en production en entreprise pour moi ;-)

Non, ce n'est pas juste de la branlette intellectuelle ! Il y a un débat en ce moment sur un sujet parallèle : whitelist / blacklist. Pourquoi blacklist, c'est les mauvais et whitelist les bons ? Idem, il y a donc un mouvement qui pour moi est le même pour changer ces deux mots là.

Par exemple allowlist, denylist…

Je suis d'accord que c'est culturel. Par exemple, lorsque Linus parle des nazy de l'interface, cela passe. Il vit aux USA depuis des années et a grandit en Finlande. En France et en Allemagne, cela ne passe pas du tout (en tout cas pour moi). Cette phrase est une aberration en Europe.

Donc, je comprends bien que pour certaines personnes, cela soit réellement un soucis.

Cela dit, sur les connecteurs 'modernes', j'ai de plus en plus de mal à savoir lequel est le mâle, lequel est le femelle !

Par exemple, en USB-C, il y a du femelle dans le mâle et du mâle dans le femelle. Les deux connecteurs s'imbriquent. Donc plus si simple de savoir qui rentre dans qui !

De mémoire, Microsoft et Apple se sont pris par le passé des amendes pour ce genre de pratique. Pas top car trop longtemps après et une amende pas assez saignante mais quand on voit le RGPD (4% du chiffre d'affaire max), à force de jouer au con, un jour ils vont s'en prendre une très grosse !

Et comme je l'ai dis ci dessus, Google à la commission au cul. À force de trop tirer sur la corde, elle va leur péter au nez. Certes, cela prends du temps, pas mal de temps (mais parfois ce n'est pas plus mal aussi de prendre du temps) mais l'Europe prends pas mal de décision qui ne plaisent pas à ces boites américaines…

Microsoft s'est déjà pris une belle amende par le passé et a été obligé de proposé en Europe le choix entre plusieurs navigateurs (vers 2010 de mémoire).

Alors tu peux dire ce que tu veux mais c'est le seul endroit ou cela a été fait !

Google a déjà des procédures au cul… À ma connaissance, c'est directement la commission qui s'en occupe sur ces grosses entreprises.

Sauf que TeX / LaTeX est bien plus ancien qu'internet ;-)

Si, c'est plus que choquant. Cela veut dire clairement que l'outil de recherche a des cas particuliers et que la boite met carrément en valeur ses propres produits. C'est de la concurrence déloyale et il me semble que c'est justement ce que reproche la commission européenne à Google.

D'ailleurs, à ce niveau là, heureusement que l'UE nous protège globalement des pratiques prédatrices des USA…

Mon dernier post car tu est de mauvaise fois. Je te dis que c'est intéressant pour tester une clef particulière dans certain cas et tu me sors un fichier YAML complexe avec deux fois 'clef' et des machins multi-lignes. J'ai bien dis que je ne parse pas du YAML depuis Bash ! Uniquement quelques cas simples… En règle générale, j'utilise un vrai parseur avec un langage qui gère cela très bien comme Python ou Perl par exemple.

Tu dis que c'est fragile… Il y a tout plein de cas ou la clef est unique et le fichier YAML très très simple. Tu fait un test super simple et la maintenance ne change pas tant que le service tourne. Le jour d'une grosse mise à jour du service, tu mets à jour le test mais cela, c'est le cas quelque soit le test !

Si ton système de configuration des serveurs est versionné (git…) et avec déploiement automatique sur les postes (puppet…), la mise à jour une fois tous les 3 ans d'un test de deux lignes qui génère un faux positif n'est pas forcément une perte de temps. Je ne fais pas partie des fanatiques qui veulent sortir Bash des systèmes UNIX ;-)

Ton programme (ou mon programme) se configure avec du YAML et le lit avec un vrai parser YAML (donc conforme). Donc tout va très bien. En quoi est-ce un problème de pouvoir faire un grep, un ack ou un awk dessus pour certaines taches de recherche / contrôle ? Par exemple un test Nagios ou autre…

Bref, un "egrep 'ChapeauCrochetCrochet:space:CrochetCrochet*clef:' | awk '{print $2}'" renvoie la valeur d'une clef et cela peut être très pratique dans certains cas. C'est lisible et pour moi, c'est pas un bogue d'écrire cela ! J'ai jamais dis qu'il fallait parser 100% du fichier YAML en Bash !

Après, il y a effectivement des personnes pour qui il faut un programme Java ou un pip install d'une détrachiée de module pour juste lire une clef d'un fichier.

Le YAML est très bien et je l'utilise et le promeut depuis des années mais il a aussi des inconvénients. Il est vrai que les outils de validation sont moins nombreux et que si on fait un fichier hyper long très complexe, il peut lui aussi devenir compliqué à gérer.

Bref, YAML est super pour les choses simples ce qui me semble le cas présent sur l'outil "CAP" proposé.

J'édite avec vim en général… Quand je fais un grep sur un fichier YAML, cela renvoi juste la(les) bonne ligne dont il facile d'extraire la valeur avec cut ou awk. Bref, c'est plus facile de faire de la GLU en ligne de commande avec le YAML qu'avec le XML. Sinon, on voit souvent le XML dans les applications graphiques car -1- avec les schémas, c'est facile à valider coté dév et -2- malgré le coté verbeux, ça marche bien. Java et Tomcat en ont d'ailleurs un peu abusé ;-)

Ok, merci pour l'exemple. On voit rapidement que le même fichier en YAML serait bien plus lisible mais l'idée générale est effectivement déjà là.

Oui, c'est pénible à éditer, à écrire, à faire des "grep"…

Je trouve que la solution choisie par polkit, les fichiers de la distributions polkit en XML et la surcharge de l'admin systeme dans /etc en YAML très bien.

Le XML, c'est bien pour les interfaces graphiques, pas trop pour la CLI. Ne rendons pas trop le système trop dépendant des interfaces graphiques comme l'OS de Microsoft !

Je suis d'accord. Dans le cas que vous dites, cela peut marcher.

En pratique, des dev web vont vouloir être "root" via par exemple l'utilisation de conteneur genre docker. De plus en plus, cela va s’appuyer sur de l'intégration continue lié à par exemple gitlab…

Bref, c'est intéressant comme approche mais je crains que cela ne soit pas super utilisé.

Un truc que j'aimerais faire (simplement) est un rsync distant en mode readonly. Genre

rsync -av toto@server1:/etc /tmp/etc
Il y a moyen d'assurer que le rsync server qui tourne sur server1 soit en mode readonly sur le système de fichier avec votre système avec évidement la possibilité de voir tous les fichiers (comme root) ?

Pourriez faire du YAML. Quasiment la même chose mais en plus léger !

C'est ce qui se passe avec cette usine à gaz de polkit (un remplaçant lui aussi de sudo chiant à configurer). Les fichiers systèmes sont en XML mais on peut les surcharger en YAML parce que le XML, c'est vraiment très chiant pour l'admin système.

À noter que polkit n'a pas réduit l'usage de sudo… Parfois, c'est tellement peu claire que je préférais avoir une ligne claire dans sudoers que ce genre de droit compliqué à tester et qu'on ne sais pas trop si cela marche ou pas alors on élargit d'office !

Il me semble que l'approche pas capability marchait mal parce qu'il y avait au final quelques capability clefs qui font tout le job et que ce n'était pas bien réparti…

Je suis perso assez dubitatif. Par le passé, on a vu que cette approche par les CAP marchait pas trop, l’approche SELinux non plus (trop complexe)… Je crois qu'il faut essayé de plus faire confiance dans les DEV et faire une API propre (et standard entre OS) pour comme avec secomp et pledge, que l'appli réduire elle même son angle d'attaque. Ce sont les développeurs qui connaissent souvent le mieux celle-ci (et c'est plus facile à maintenir dans une même branche git).

Bref, les restrictions via l'OS comme vous le faites sont bien mais peu utilisée… car je pense trop éloigné de l'arbre de développement des codes.

je mettais autant de temps (voire plus) à les aider à faire du code de qualité qu'à l'écrire moi-même.

Il n'est pas sur que tu écrirais du code de la même qualité… Le faire écrire par quelqu'un d'autre t'oblige à la revue de code et le fait de lire du code d'un autre te fait toi aussi progresser dans tes propres critères de qualité.

Bref, c'était pour élargir le débat ;-)

Je pense que c'est cette association là : https://libreart.info/fr/.

Je pense par ailleurs que toute association qui reçoit des "dons" devraient mettre sur le web son rapport moral d'activité et le bilan de ses comptes CHAQUE année… Au niveau de mon laboratoire public, on s'est désengagé d'une association qui refusait de nous fournir ces deux documents là et donc nul ne savait où partait au final nos versements !

Et comment vous gérer les salles ? Car un EDT pour qu'il fonctionne, il faut des salles avec suffisamment de chaises dedans. Il gère donc les contraintes de place en terme de cours / TD / TP ?

Chaque langage devrait avoir un programme pour rendre joli. Et comme le monde a plusieurs points de vu sur ce qui est joli, il y a des règles de codage par projet.

Perso pour Perl, je prends la règle suivante :

perltidy -i=3 -ci=3 -pt=2 -icb -cti=3 -sbt=2 -bt=2 -bbt=2 -nsfs -bar -otr -olc -nolq -l=132 -vmll -msc=1 -iscl -nbbc -nola -st
Pour savoir ce que cela fait vraiment, man perltidy, mais cela n'est pas bien important !

Normalement, on fait cela avant de commiter ou via l'intégration continue…

Cela me fait penser à l'environnement tabular de LaTeX.

En fait, on parle de progression régression en terme de pourcentage… Par exemple, la part du RAIL dans le transport de marchandise diminue MAIS en pratique, le tonnage transporté par rail augmente chaque année (d'où peut être la tendance à mettre les passagers dans les cars et les avions).

Bref, les régressions sont peut être juste relative ;-)

démo -> application error !

Un effet DLFP ?