Guillaume Rousse a écrit 250 commentaires

Bonjour.

J'ai du mal à comprendre l'insistance dans la communauté python pour l'installation de modules supplémentaires dans l'arborescence d'un utilisateur spécifique, via l'option --user, au lieu de les installer sur le système, dans l'arborescence /usr/local dédiée à cet usage, après escalade de privilèges. L'auteur commence d'ailleurs par expliquer que cette arborescence est déjà prête à l'usage dans le cas de Debian, en dans fait pour n'importe quelle autre distribution Linux. La seule justification que j'ai vu jusqu'ici, c'est qu'il s'agit d'une bonne pratique, alors que pour moi, c'est clairement:
* ignorer les conventions d'administrations usuelles sous Linux
* privilégier un utilisateur particulier, ce qui a un sens sur une machine personnelle mono-utilisateur, pas sur un serveur géré par plusieurs personnes
* favoriser le déploiement d'une application s'exécutant avec le même compte utilisateur que celui qui possède les fichiers correspondant à celle-ci, donc mélanger privilèges d'exécution et d'écriture, une mauvaise pratique en terme de sécurité

Je comprendrais à la rigueur qu'on explique que Python n'étant pas spécifique à Unix, ses utilisateur privilégient l'utilisation de conventions facilement transposables d'un OS à l'autre. Ou encore que l'on dise que les risques d'interférence avec le système de base étant tellement élevés dans l'écosystème Python, qu'il mieux vaut ne surcharger les modules du système qu'à la demande, via des installations locales dans des répertoires qui ne sont pas pris en compte par défaut, mais uniquement via une variable d'environnement dédiée. Mais j'ai du mal avec l'argument d'autorité, même rebaptisé "bonne pratique (tm)".

Les obligations légales de conservation de traces en France s'appliquent aux hébergeurs de contenu en ligne, et aux opérateur de télécommunication (les fournisseurs d'accès, en clair). Un DNS public me parait difficilement assimilable à l'une ou l'autre de ces catégories.

En gros FIPS c'est pire qu'inutile, c'est néfaste.
Tout dépend du risque que l'on souhaite couvrir. Les techniciens se focalisent souvent sur les risques techniques, et fantasment volontiers sur les attaques de haut niveau, en passant à coté du risque juridique de non-conformité aux textes réglementaires. Ces textes s'appuyant généralement sur des normes comme FIPS, PCI-DSS et consort, il n'est pas forcément inutile d'y être conforme, quelle que soit leur valeur réelle.

Pour le niveau de journalisation, mieux vaut utiliser des valeurs textuelles que numériques, c'est plus lisible. Et contrairement à ce que le commentaire laisse supposer, le choix n'est pas entre 0 (rien) et 255 (trop), il y a tout un éventail de possibilité. Loglevel stats, par exemple, est largement supportable par n'importe quel annuaire, et permet d'identifier les problèmes après qu'ils soient signalés.

Pour les ACLs, mieux vaut éviter d'entrelacer les déclaration par objet (sur quoi porte une règle) et par sujet (sur qui elle porte), pour éviter les erreurs. Par exemple, il est plus lisible de commencer par:

 # l'admin peut tout écrire
 access to dn.subtree="dc=localdomain"
       by dn.exact="cn=admin,dc=localdomain" write
       by * break

 # readonly peut tout lire
 access to dn.subtree="dc=localdomain"
       by dn.exact="cn=admin,dc=localdomain" read
       by * break

Plutôt que de gérer ces cas par des clauses supplémentaires dans la règle par défaut qui vient tout à la fin.

Par ailleurs, l'utilisateur déclaré par les directives rootdn et rootpw dans les fichiers de configuration ignore totalement les ACLs, il n'y a aucune nécessité d'en prévoir pour lui. Ou alors, de ne pas utiliser ces directives (rootdn n'est nécessaire que sur un esclave) pour plus de contrôle.

Enfin, je suis très sceptique sur la nécessité pour une application d'avoir accès en lecture à l'attribut userPassword. Les seuls cas que je connaisse concernent radius ou kerberos, dans des configuration particulières, dans lesquelles l'annuaire est utilisé comme solution de stockage de mots de passe, avec des syntaxes spécifiques, et jamais en réutilisant l'attribut mot de passe de l'annuaire lui-même. Toutes les autres applications se contentent d'une opération bind sur l'annuaire, avec l'identificant de l'utilisateur, pour laquelle seul la permission by anonymous auth est nécessaire.

http://yro.slashdot.org/story/12/03/28/2124228/nyc-bans-mention-of-dinosaurs-dancing-birthdays-on-student-tests

"intégral" comme dans "utiliser un binding sur une bibliothèque native (SDL)", bien sur :)

avec une tendance pour la falsification

La falsification, c'est le procédé qui consiste à maquiller sciemment la vérité. Je doute fortement que ce soit le cas, et je pense que le Rasoir_d'Hanlon résume mieux la situation:
"Ne jamais attribuer à la malignité ce que la stupidité suffit à expliquer"

Tu lui aurais plutôt du lui demander s'il était fan de Mylène Farmer.

hors GPG mais ça ça change rien
C'est la signature cryptographique qui assure l'authenticité, pas l'outil employé. Et S/MIME marche tout aussi bien.

Il s'agit d'une solution logicielle de sécurisation de l'accès au réseau physique. Au lieu de donner automatiquement une adresse IP dans un réseau unique à n'importe quel équipement qui vient se raccorder à une prise RJ45, tu mets en place un certain nombre de critères pour décider si tu attribues ou non une adresse, et si oui sur quel réseau.

telnet permet juste d'envoyer du contenu à un serveur, pas de faire serveur lui-même pour relayer un flux envoyé depuis un autre client.

J'ai eu la curiosité d'aller jeter un coup d'oeil aux patches, ca mérite quelques commentaires.

D'abord, ils ne concernent pas que des versions désuettes, il y a un kernel 2.6.39 sur la freebox v6 (server), et un patch de 24000 lignes, qui a l'air de concerner principalement le support du matériel spécifique, ainsi que l'encodage lzma. La version PPP est aussi récente (OK, elle n'a pas évoluée depuis le siècle dernier...)

Ensuite, il y a beaucoup de choses qui semblent liées au portage sur une architecture un peu exotique (mips), avec des corrections de makefile, d'assembleur, et de script configure.

Et il y a également des surprises, comme par exemple rendre possible NFSv4 sur UDP, à l'opposé de la norme... J'imagine que c'est pour une question de performances, mais je doute que ca passe upstream :)

Le gros argument technique en faveur de rpm5, c'est son comportement transactionnel (ACID behavior), censé garantir la cohérence de la base à tout moment, même si l'installation est sauvagement interrompue à grand coup de CTRL+C, et permettre éventuellement des retour en arrière (rollback) facilité. Personnellement, j'ai surtout constaté un énorme impact sur les temps d'installation, ce qui parait peut-être un prix raisonnable à payer pour une telle sécurité, mais j'ai du mal à me sentir sensibilisé sur le sujet faute d'avoir jamais expérimenté une situation aussi catastrophique. Sur l'usage au quotidien, en terme de création et maintien de paquetages, je n'ai rien vu d'extraordinaire, surtout des nettoyages cosmétiques que l'on retrouve dans rpm 4.8. Et ce ne sont pas les réponses laconiques ou au contraire ultra-techniques aux demandes d'explications que j'ai vu passer sur cooker qui vont me convaincre de l'intérêt.

Par ailleurs, le changent de mandriva s'explique aussi largement par le contexte. Vu que quasiment toute l'équipe technique est partie un peu brutalement l'été dernier, il s'est juste trouvé quelqu'un pour devenir le mainteneur de rpm, et précipiter une migration qui avait jusqu'ici été refusée sur la base de discussion techniques. Forcément, c'est beaucoup plus simple de prendre des décisions quand il n'y a plus personne pour en discuter...

Les autotools ne sont clairement pas fait pour le monde Windows (hormis Cygwin), ils sont plutôt fait le monde Unix (au sens large), qui étaient la cible privilégiée des outils GNUs. Je doute qu'il y aie beaucoup d'alternative qui gère le cas des bibliothèques partagées sous HPUX, par exemple. Le fait qu'aujourd'hui on préfère en général cibler le triptyque macos/linux/windows, et cibler autre chose que des adeptes de la ligne de commande rend certainement l'outil inadapté aux objectifs de beaucoup de monde, mais absolument pas un outil dépassé. Jusqu'à preuve du contraire, la quasi-totalité des constituants de base d'un système linux (glibc, gcc, etc...) l'utilisent encore, par exemple.

Et je rejoins ce que disait le commentaire précédent, il n'y a aucune dépendance pour l'utilisateur final excepté le shell bourne (requis par POSIX) et la commande make. m4, comme perl et consort, c'est sur la machine du développeur que c'est nécessaire.

Parmi les autres approximations de l'article:
- il y a une commande fournie avec les autotools (autoreconf) qui remplace avantageusement les scripts autogen.sh fait maison
- il y a eu effectivement des incompatibilités entre versions, particulièrement la version 1.4 qui date de l'an 2000, et celles qui ont suivi, mais rien d'exceptionnel par rapport à d'autres outils

Le vrai point noir, ca reste la documentation, et le manque d'homogénéité des composants.

À quand une telle prise de conscience chez NVidia ?

Je pense plutôt qu'ils en ont parfaitement conscience, et que la politique actuelle est un choix délibéré de ne pas risquer d'exposer certains avantage concurrentiels juste pour grapiller quelques parts ridicules sur un marché de niche.

Non, une table casée, c'est une que tu as refilée à quelqu'un d'autre...

>Cela me permet d'avoir un single sign on pour tous mes services Linux
En général, on parle de SSO quand l'utilisateur s'authentifie une fois et une seule, pour un système de type Kerberos ou CAS, par exemple. Là, tu parles plutôt d'authentification centralisé (le même mot de passe pour tous les services).

...quand ceux-ci ne sont fournis que pour redhat, pour i386 seulement, et sont en retard de surcroit (2.4.16, alors que la version courante est la 2.4.19).

Pour Redhat, ceux fournis par Buchan Milne sont plus à jour et plus complets:
http://staff.telkomsa.net/packages/

Pour d'autres distributions, comme Mandriva, ils sont inclus de base.

Plutot que de contribuer à des distributions déjà existante, qui incluent déjà 80% de ces outils, et qui acceptent des contributions externes ? Mandriva (seuls centreon et nareto manquent à l'appel dans la liste fournie) ou Debian, par exemple.

Les distributions dédiées, ce sont autant de procédures dédiées à mettre en place dans un parc hétérogène. Beurk.

Pas _les_ auteurs, mais un seul. Et qui jette un peu vite la pierre sur le language plutot qu'explorer les solutions proposées par la communauté Perl. Ce qui est assez symptomatique de la façon dont le soft est developpé.

> On en arrive à la situation absurde ou il est plus simple d'installer un Logiciel Libre sur une plate-forme propriétaire que sur GNU/Linux, alors que c'est la plate-forme des développeurs !

Sauf que la plate-forme propriétaire (windows) n'existe qu'avec 6 variations possibles (95, 98, 2000, ME, XP, Vista), avec une ABI relativement homogène et une compatibilité ascendante marquée.

Tu retires toutes les distributions du monde sauf redhat, tu vires de celle-ci tous les noyaux sauf celui de base (et tu empeches bien sur de recompiler le sien), et tu auras une situation a peu près comparable...

C'est la diversité le problème ici. Pas un seul producteur de logiciel ne peut gérer l'ensemble de la diversité des cibles Linux à lui seul (ou alors il faut faire plein de compromis, genre compilation statique par exemple). L'ensemble du système est basé sur une distribution des taches entre les producteurs de logicels, et les intégrateurs finaux qui publient les distributions. Quand les premiers cherchent à faire le travail des seconds, par exemple parce qu'ils refusent le droit de redistribuer a des tiers (cas des logiciels propriétaires), on aboutit a des résultats au mieux médiocre, au pire non-fonctionnels.

Les projets les plus connus hebergés sur ce site tournent effectivement autour de mandriva, mais pas tous, loin s'en faut:
- jpackage (http;//www.jpackage.org)
- rpm4 (http;//rpm4.zarb.org)
- rpmlint (http;//rpmlint.zarb.org)
- youri (http;//youri.zarb.org)
- frozen-bubble (http;//www.frozen-bubble.org)
- booh (http;//www.booh.org)
- libconf (http;//libconf.zarb.org)
etc...

Et nous sommes ravis que tu te proposes pour faire l'intermédiaire auprès de Mandriva pour leur demander leur participation..

Ben non, c'est pas vrai. Avec quelque prestataire technique que tu passes, il faut préparer un motif, vérifier qu'il passe bien (a moins que tu ne sois assez inconscient pour commander 200 exemplaires les yeux fermés), récupérer le stock, et ensuite le gérer...

Et ensuite, notre but étant de récupérer de l'argent, soit pour nous dans la situation actuelle, soit pour des assos comme c'était le cas auparavent, il faut pouvoir obtenir une marge de bénéfice correcte, tout en restant raisonable sur le prix final. Un t-shirt qui nous reviendrait à 19¤ pièce (manifestement, ils ne connaissent pas les prix dégressifs sur le site que tu indiques), il faut le vendre a 38¤ si on veut marger a 50% dessus... Sans compter les frais de transport, que je n'ose pas imaginer depuis l'Allemagne.

Bref, on fais pas trop dans la net-économie...

Oui, c'est une bonne idée. Mais il faut aussi du temps pour réaliser les t-shirt, du temps pour les vendre ensuite, et il faut avancer une somme non-négligeable pour l'impression surtout... Donc c'était plus facile pour nous de passer par des dones pour l'occasion. On se lancera sans doute a nouveau dans les t-shirts un jour, mais il n'y a rien de prévu pour le moment.

C'est vrai, rien ne vaut un vrai test à la sauce Virus Mag: "Alors quand on laisse tomber le clavier du 60e étage, il tient pas le choc. C'est vraiment de la daube micro^D^D^D^DM$"