Sytoka Modon a écrit 4538 commentaires

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 ?

Merci pour ton post super clair sur les effets de la dérégulation. Je ne suis effectivement pas persuadé que la dérégulation soit une bonne chose sur les réseaux public. Exemple autre sur la téléphonie, un bordel d'antenne.

Pour en revenir à EDF, un autre effet peu connu. Depuis que la CNR (Compagnie National du Rhône) est autonome, elle gère l'eau du Rhône pour maximiser son profit, au détriment des centrales nucléaires EDF donc en gros du profil global (CNR + EDF), donc en gros des français…

La dérégulation et la privatisation ne vont pas toujours de pair avec une bonne gestion des ressources finies…

Si je coupe l'électricité chez moi, je perds le contenu du frigo et du congélateur.
Contrairement à la téléphonie mobile, l'électricité est un service de base qu'on ne peut être désactivé facilement.

Tu veux le beurre et l'argent du beurre. Je te rappelle que dans ton abonnement, tu n'a aucune garantie de non coupure électrique. C'est possible mais cela coûte cher (genre maternité avec couveuse) et en plus, il vaut mieux avoir un groupe électrogène…

Bref, si tu vas dans certains pays (dans certains pays d'Afrique par exemple), les personnes ont plus de téléphone portable que d'électricité chez eux !

La notion de service de base est pas si facile que cela à distinguer selon les personnes !

Y'a plein de choses à critiquer dans Android et iOS, mais pas la manière dont ils traitent les programmes qu'ils lancent. Le modèle de Linux et Win32 a fait son temps de ce côté.

Android a un noyau Linux ;-)

Ensuite, les programmes qui me demande ceci cela, au bout d'un moment, tu ne sais même pas ce que tu as autorisé. Autre chose, mon tél ne voulait pas lancer de la musique tant que je ne lui avais pas mis une acrte SIM. Rapport SIM / Musique ? Ensuite, sécurisé ton portable pour tout donner à la NSA, je ne suis pas sur que ce soit toujours super. On est parfois dans un monde proche de 1984 et de son big-brother !

Mais c'est vrai que des bonnes idées comme Secomp, c'est à dire ou le programme s'auto enlève lui même des privilèves pour mieux se sécuriser sont une bonne idée.

Comment ça ? Si tu veux transférer le fichier chiffré, tu peux le chiffrer avant de l'envoyer.

Et la personne le déchiffre sur son poste (qui n'est peut être pas chiffré) et il reste en clair…

Encore une fois, comment ça ? Si tu partages ton fichier chiffré, tu dois envoyer la clé avec pour qu'il ait une utilité. Dans ce cas, comment tu t'assures que les collègues le gardent chiffré ?

Justement, tu n'as pas compris mais plein de personne ne l'ont pas compris. Si tu ouvres un fichier avec un phrase de passe avec un logiciel, celui-ci doit PAR DEFAUT toujours garder le chiffrement de ce fichier, même via un enregistrer sous ! Ainsi, cela ne protège pas du couper / coller mais protège de nombreux oublis possible.

Le soucis global n'est pas d'avoir de super algo de chiffrement, le pb est principalement social… Comment travailler à plusieurs sur des fichiers chiffrés avec des clefs USB dans la poche de chacun ?

Tu peux faire la chasse aux caches et miniatures et les désactiver un par un, mais rien te garantit que t'en auras pas raté un moins connu ou mieux caché

Avec ce genre de phrase, on ne fait rien ;-) Virer la SWAP n'est peut être pas parfait mais supprime déjà pas mal de soucis potentiel ;-)

Morale de l’histoire, à garder en tête pour tous ceux qui construisent des paquets pour quelque système que ce soit : un paquet n’est jamais construit dans le vide — le système sur lequel vous compilez vos paquets a une influence sur le paquet résultant.

Avec ReproductibleBuild que porte justement Debian, l'objectif est justement de corriger cela ! Debian a fait une belle boulette il y a longtemps mais qui ne fait rien ne casse rien…

Précision, Jersey, Guernesey (Sark…) ne dépendent pas de la Couronne britannique mais du duc de Normandie… D'ailleurs, c'est un des rares endroits où on applique encore (partiellement) le droit normand. C'est un oublie dans la négociation de la fin de la guerre de 100 ans. Cela n'a donc rien à voir avec la couronne britannique ;-)