🚲 Tanguy Ortolo a écrit 12334 commentaires

S'ils le souhaitent, ils peuvent du jour au lendemain passer au H264 direct et virer Flash.

Ils ne le souhaitent pas. Pas plus que Google, comme on le fait remarquer plus haut. Dans leur navigateur Chromium, ils ont choisi, comme Mozilla, de ne pas implémenter de prise en charge d'MPEG-AVC.

Internet moins les sites en javascript sera toujours plus petit qu'Internet tout court

Correction : le web privé des sites avec du JavaScript sera toujours plus petit que le web tout court. Internet n'est pas le web, le web n'est qu'une partie d'Internet. Confondre les deux devrait être puni d'accès à Internet mobile selon Orange.

Je ne me plains pas des sites qui utilisent JavaScript, à condition :
— qu'ils restent accessibles sans ;
— que cela apporte quelque chose d'intéressant.

Slashdot est accessible sans JavaScript, en revanche leur utilisation de JavaScript est nuisible : elle n'apporte rien — on pouvait déjà cliquer sur le lien « suivant » pour lire la suite — et ralentit tout.

Le webmail Orange est inaccessible sans JavaScript.

Un webmail RoundCube est accessible sans JavaScript, et son utilisation de JavaScript apporte des fonctionnalités intéressantes : glisser-déposer, etc.

Un wiki DokuWiki est accessible sans JavaScript, et son utilisation de JavaScript apporte des fonctionnalités intéressantes : sauvegarde automatique, raccourcis pour l'édition de code wiki.

Et le football, il n'est pas assez « pur » avec les vuvuzelas ?

C'est quoi, libre mais pas selon Debian ? C'est quoi, la définition du logiciel libre ?

Des définitions du libre, il y en a deux :
— celle de la FSF qui est plutôt une explication sur ce qu'est le libre, pas des critères ;
— celle de Debian et de l'OSI, qui est un ensemble de critères pour déterminer si un logiciel est libre.

Il ne s'agit pas d'aller contre les logiciels propriétaires, mais de ne pas aller pour, ce qui n'a rien à voir.

Aller contre, ce serait mettre des moyens en œuvre pour qu'on ne puisse pas installer ces logiciels, ce qui est contraire au contrat social Debian.

Aller pour, ce serait mettre des moyens en œuvre pour qu'on puisse installer ces logiciels facilement, ce qui est de la pure bienveillance, pas un devoir. Et, oh, c'est ce que fait Debian aujourd'hui avec la section non-free !

SpiderMonkey est le responsable de la lenteur de Firefox qui sera remplacé dans un futur inconnu par JägerMonkey

Non, SpiderMonkey n'est pas responsable de cela. Ce sont des sites web bourrés de JavaScript bien gorêt qui en sont responsables. Il est très facile de pourrir un navigateur à coup de JavaScript, ce langage offrant beaucoup de trop de contrôle et étant d'une façon générale très intrusif.

Essayez par exemple Slashdot : c'est affreusement lent quand on arrive au bas d'une page, parce que ça charge la suite de façon manifestement sous-optimisée. Désactivez JavaScript : ah, on respire, c'est beaucoup plus utilisable.

Vouloir que Debian ne consacre pas de moyen à aider à l'installation de logiciels propriétaires, tu trouves ça intégriste ?

Sale intégriste du football, va.

Le point 3 est actuellement irréalisable, puisqu'aucun logiciel de sécurisation n'a été défini. Il restera irréalisable, puisque l'HADŒPDI souhaite ne pas conseiller de logiciel concret.

Le point 6 est irréalisable de façon raisonnable.

Non.
1. ne pas avoir sécurisé son accès ;
2. télécharger, ou que quelqu'un télécharge par son accès une œuvre sans autorisation ;
3. recevoir un recommandé donnant une solution de sécurisation ;
4. dans l'année, n'avoir toujours pas sécurisé son accès ;
5. dans l'année, télécharger, ou que quelqu'un télécharge par son accès une œuvre sans autorisation ;
6. que le parquet prouve que l'on n'avait pas sécurisé son accès.

Précision : SPF n'est pas fait pour lutter contre le spam ou contre l'usurpation d'adresse. Il est fait pour lutter contre le backscatter, les notification de non-livraisons renvoyées aux gens dont l'adresse a été usurpée.

C'est pour ça qu'il se vérifie sur l'adresse MAIL FROM : si celle-ci est usurpée, il ne faut surtout pas envoyer de notification de non-réception en cas de problème.

Mais de toute façon, un serveur bien configuré n'envoie de notification de non-réception que dans de très rares cas, le reste du temps, il refuse le message à la transaction SMTP.

Ce que tu souhaites mettre en place, c'est Sender ID, le SPF à la sauce Microsoft. Ce n'est pas une bonne idée, SPF est déjà très bien.

Il faut bien prendre le MAIL FROM pour ce qu'il est : l'adresse technique d'expédition, celle où les erreurs doivent être envoyées, celle dont tu utilises <abuse@son_domaine> pour te plaindre d'un abus.

Le From, c'est l'adresse officielle de l'expéditeur, pas forcément l'endroit d'où il l'a posté.

La seule chose raisonnable à faire quand MAIL FROM != From, c'est de l'afficher dans le logiciel de messagerie. Le serveur de réception doit placer l'adresse de MAIL FROM dans un champ Return-Path, et le logiciel de messagerie doit afficher un truc du genre « Message de [From] envoyé par [MAIL FROM] ».

Je continue de me renseigner, et j'ai maintenant des précisions sur la raison du listage :
— les serveurs de Free se sont retrouvés sur la DUL, où ils n'avaient aucune raison d'être ;
— MAPS a accepté de les en retirer à condition qu'ils leurs donnent toutes leurs plages d'abonnés ;
— Free a accepté, considérant que de deux maux, il faut prendre le moindre.

Il s'agit donc tout simplement d'un chantage exercé sur Free, qui y a cédé. MAPS, à l'origine une organisation à but non lucratif créée par des grands noms comme Paul Vixie, est donc simplement devenue une des nombreuses entreprises nuisibles à l'Internet, qui utilise des pratiques mafieuses.

Cette liste, la DUL, a mauvaise réputation. Elle est tout de même utilisée par AOL pour alimenter sa base d'adresses à bloquer dès l'ouverture de la connexion SMTP. Seulement AOL doit savoir que cette liste est mauvaise, puisqu'ils fournissent un moyen de se faire débloquer en outrepassant la DUL.

J'aurais tendance à penser qu'il n'y a pas d'utilisateurs "de base" de Debian, parce que c'est quand même une démarche motivée, de choisir cette distrib par rapport à d'autres bien plus marketées et packagées pour attirer l'utilisateur.

Oh si, il y en a, qui n'ont pas fait eux-même le choix de Debian en particulier. Mes parents et grand-parents, par exemple…

Je ne me souviens pas d'avoir vu passer, par exemple, une info sur ce sondage sur linuxfr.

Non, en effet, je n'y avait pas pensé.

Du coup, la question est : qui à répondu & les réponses sont elles représentatives des utilisateurs ?

Le sondage a été annoncé sur la liste de distribution <debian-news@d.o> : [http://lists.debian.org/debian-news/2010/msg00007.html]. Cette annonce a été relayée sur IRC, sur Jabber et sur plusieurs sites personnels ou communautaires, je pense.

Ont donc répondu des utilisateurs motivés. Pas des utilisateurs de base — passifs —, si vous voyez ce que je veux dire.

En tout cas, 80% de desktop, c'est l'argument qui me manquait encore pour que j'installe une Debian sur ma machine en lieu et place de la Mandriva qui y squatte depuis 10 ans.

Attention, c'était une question à choix multiple. Donc on ne peut pas dire que 80% des installations de Debian sont sur un ordinateur de bureau, seulement que 80% des utilisateurs de Debian l'ont installé sur leur ordinateur de bureau.

Je me suis renseigné sur les forums Free. Tu trouveras un long fil de messages sur le sujet sur proxad.free.services.messagerie (cherche l'article <4bd94faf$0$29992$426a74cc@news.free.fr>).

En résumé :
— un jour, les gros serveurs relais de Free se sont retrouvés listés sur la RBL de MAPS : forcément, en tant que gros serveurs centraux, ils envoient beaucoup de spam, parmis beaucoup, beaucoup plus de messages légitimes, et se retrouvent donc souvent listés ;
— Free a pris contact avec MAPS, qui se sont avérés très incommodes ;
— Free a obtenu le délistage de leurs serveurs, mais MAPS a alors pris l'initiative de mettre dans leur DUL — censée lister des adresses IPv4 dynamiques — tous les blocs d'adresses IPv4 d'abonnés de Free ;
— Free a laissé faire, considérant que cela servait la mieux la majorité de ses utilisateurs, qui utilise leurs relais, que de retourner à un blocage global de leurs relais.

Cette politique semble effectivement aller vers une restriction : les simples mortels ne sont pas censés poster directement, c'est réservé aux grands. Ce qui complique en réalité la lutte contre le spam : en concentrant les sources de courrier, on empêche le blocage fin des serveurs infectés.

Et bien, il suffit d'être en testing avec la possibilité de prendre des paquets d'unstable !

La DUL n'est pas une RBL, et n'est pas faite pour l'être. Ceux qui l'utilisent comme telle ne devraient pas le faire, et perdent du courrier légitime. C'est à eux qu'il faudrait signaler le problème, qui les concerne très certainement, puisque, je le répète, ils perdent du courrier légitime.

En effet : http://linuxfr.skyrock.com/

Autre façon de voir les choses  : pense en terme de niveaux de répertoires et de délégation de pouvoir. Si dans la compte, une équipe (appelons-la planning), composée de Titi et de Toto, a besoin de stocker des données, elle va avoir besoin d'un répertoire et du droit d'écrire dedans. Ce droit va lui être attribué par une chaîne de délégation de droits, matérialisée par un chemin de répertoires : root a créé le partage réseau, des gens peuvent créer des répertoires dedans, en autorisent d'autre à créer des sous-répertoires, etc. L'existence et le nom de ce répertoire sont du ressort du niveau supérieur : cette équipe a son répertoire, et fait ce qu'elle veut dedans.

Il y a une contradiction dans ton cas.

1. Tu veux que tes utilisateurs puissent créer des fichiers (en l'occurrence, des répertoires) eux-mêmes, sans te demander. Donc un répertoire racine où ils peuvent écrire.

2. Tu veux que n'importe quel utilisateur ne puisse pas retirer un fichier d'un autre (en l'occurrence, un répertoire). Donc un répertoire racine sticky.

3. Tu veux que tes utilisateurs puissent créer des sous-répertoires avec une liste précise de gens ayant le droit de faire ceci ou cela. C'est là que ça coince, parce que ça contredit le point 1 : ce sont des utilisateurs, et ça, ils ne le feront pas eux-mêmes. Ils te demanderont de le créer, le répertoire de la mort.

Donc, mon conseil : réfléchis à ton besoin. Si tu as un répertoire /compta (je compte à partir de la racine du partage), écrire dedans, cela signifie organiser le classement même des données de la compta : c'est un droit qui devrait revenir aux chefs de la compta. Si tu as un répertoire /compta/planning, écrire dedans signifie organiser le planning de la compta, à toi de voir qui est censé le faire. Mais quelqu'un qui a le droit d'organiser le classement de la compta pourra supprimer ce répertoire (s'il est vide), ou le renommer : c'est fort logique, puisqu'il est gestionnaire du classement de la compta…

À retenir, d'une façon générale : les droits (lecture, écriture, exécution) s'appliquent au fichier sur lequel ils sont définis, en tant que données (pour un répertoire, en tant que liste de liens nommés vers des fichiers). Pas au lien, c'est à dire au nom que ce fichier porte dans un ou plusieurs répertoires.

Les ACL ne permettent pas d'attribuer des droits plus fins.

Les ACL permettent d'affecter plus finement des droits classiques (lecture, écriture, exécution).

Les attributs étendus permettent d'attribuer des droits plus fins.

N'importe quoi.

1. Les permissions, c'est sur 4 chiffres octaux, pas 5.

2. Le sticky bit, c'est 1 sur le premier chiffre, pas 4.

Donc plutôt :
chmod 1777 comp/
Ou plus exactement, pour éviter de toucher aux permissions existantes :
chmod +t comp

Autre solution : fais en sorte que tout le monde puisse écrire dans ton répertoire, mais s'ils veulent empêcher que quelqu'un d'autre enlève les répertoires qu'ils ont créés, qu'ils mettent des fichiers dedans.

Parce que, quelque part, si quelqu'un crée un répertoire, mais ne met rien dedans, qu'est-ce que ça peut bien lui faire qu'on lui enlève ? Il n'y a pas de perte de données.

En revanche, s'il y met quelque chose, seuls les gens qui ont le droit d'écrire dans son répertoire (et ça, c'est lui qui le gère) pourront supprimer ce quelque chose, ce qui est un pré-requis pour pouvoir retirer le répertoire (on ne retire pas un répertoire non vide).

La « suppression » et la « création » de fichiers ne sont pas des droits. Les droits correspondants sont l'écriture dans le répertoire parent.

Si j'ai bien compris, tu veux n'autoriser la suppression d'un fichier (en l'occurrence, un répertoire) que pour certaines personnes, qui doivent quand même pouvoir créer et supprimer des fichiers dans le répertoire parent.

Oublions les ACL qui n'ont rien à faire ici : elles ne servent qu'à permettre des attributions plus fines des droits, et non des attributions de droits plus fins. On peut se contenter de parler de droits Unix classiques, tu adapteras selon la granularité à laquelle tu veux les accorder.

Bref, ça se rapproche assez du cas typique d'utilisation du sticky bit, qui, sur un répertoire, permet de n'autoriser la suppression d'un fichier que par le propriétaire de ce fichier. Il est typiquement utilisé dans /tmp, afin que tout le monde puisse y créer des fichiers, mais que personne ne puisse supprimer les fichiers d'autrui :
1777 /tmp
Ou en symbolique, le « t » représentant le sticky bit :
drwxrwxrwt /tmp

Et très nul pour faire des recherches ailleurs que sur un seul moteur de recherche par défaut.