Sytoka Modon a écrit 4550 commentaires

Donc tu lances docker dans un docker lui même lancé dans un docker … ;-)

Ah non, pas les motards !

Un modèle alternatif est le financement participatif/communautaire.

Il est quasiment impossible dans la fonction publique de participer à ce genre de projet. Les règles de la comptabilité publique mais aussi le fait que l'argent, venant du contribuable, ne peut être dépensé sans quelques gardes fous. Il en va du respect du contribuable.

En règle général, c'est compliqué dans la fonction publique de financer directement du libre (or contrat via des boites). Ce qui serait plus simple serait de contribuer en terme de temps homme. C'est le cas sur quelques projets mais mais difficile à faire sur des projets "centraux" comme par exemple LibreOffice… Et pourtant, il y en aurait bien besoin.

Par contre, on peut financer via une boite un ajout de fonctionnalité qui peut être libre. Je sais que cela se fait pas mal via la territoriale sur les systèmes de positionnement GIS (toutes les cartes de risques et autres à faire ou à numériser)…

Exactement, la défiscalisation, c'est principalement de l'impôt que tu flèches en retirant cela au choix de la représentation nationale.

Lire Alvin le faiseur qui est une ré-écriture de l'histoire dans un monde parallèle mais qui parle beaucoup de ce problème d'esclavage aux USA.

Et bien c'est vachement futé car au moins n'importe qui se connecte n'importe ou, important pour dépanner dans l'espace !

On se fait CHIER en ce moment avec la connexion des portables sur les vidéo-projecteurs… Jamais le bon câble, jamais le bon adaptateur entre tous les DisplayPort, les HDMI, les DVI (et les USB en voici en voila)… Il arrive toujours le moment ou tu te retrouves avec deux mâles en face !

Donc vive l'USB-D hermaphrodite et je pense qu'il faudra un jour remplacer la connectique LC fibre pour la rendre plus "grand public", j'espère qu'on aura une prise réversible (c'est presque quasiment le cas puisqu'en fibre, les deux coté sont en LC et qu'il y a qu'une mini pièce passive en plastique à 20 centimes permettant juste le clipse de chaque coté).

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 ;-)