Tu n'as rien compris. Le problème n'est pas que Windows soit préinstallé, le problème est que l'on ignore le prix de Windows sur la machine.
Pas d'accord. Ce qui est embêtant pour nous, c'est qu'il est difficile d'acheter un ordinateur sans logiciel. Or c'est Microsoft qui a les moyen de faire ce genre de pression sur les vendeurs (si ce n'est que par la popularité qu'ils ont mise en place).
Peut importe le prix, le consomateur a ce droit fondamental de choisir ce qu'il veut acheter, au regard, entre autre, du prix ; il est ici quelque peu baffoué. C'est un combat qui va au delà des enjeux du logiciel libre, mais n'oublions pas que ce droit de choisir est un des fondements du logiciel libre. Et le fait que ce coût supplémentaire soit substanciel rend la chose plus intolérable.
(...) pourquoi peut-on facilement acheter un PC sans écran ?
Pas d'accord avec ton argument. Il est infiniment plus facile de brancher un moniteur (celui de son ancien ordinateur, ou celui du grand oncle) que d'installer un système d'exploitation ou un logiciel. Brancher une prise fait partie des choses qui, à notre époque, va de soi.
On doit mal se comprendre. L'URL est évidemment un identifiant unique efficace. On ne va pas s'en passer. Mais on n'est pas obligé des les voir ou lire pour les utiliser. Et ce n'est pas en en étendant le charset utilisé que l'on va rendre le web plus accessible.
Je rapelle le problème : accéder à une page par des moyens adaptés à sa langue maternelle. Et l'on parle ici d'une utilisation basique de l'internet. Il est clair que quelqu'une qui cherche une information pointue, ou un papier académique n'aura probablement pas de difficulté avec le système actuel et anglais (disons international).
Je reste convaincu que pour la majeure partie des activité de surf peuvent se passer des adresse URL. Pour garder une page, il y a des bookmarks. Pour la transmettre à quelqu'un, il y a les emails. Et je pense que tout un tas d'autres moyens peuvent être mis en oeuvre, qui se grefferaient au dessus des adresses URL.
Prends pour exemple les numéros de téléphone. Le cas est un peu plus simple, mais un numro à plus de 8 chiffres n'est pas des plus facile à manipuler et retenir. Il y a eu les annuaires, les carnets d'adresses. Il y a les portables, qui remplacent ceux-là, ajoutant du confort (électronique). On peut presque se passer de connaître le numéro d'un ami (du moins je penses, je n'ai pas de portable). Reste le problème de l'échange de coordonées par écrit ou par oral. Là aussi, il y a des progrès en route.
Petite citation pour une exemple, qui fait écho à un vieux souvenir que j'ai d'une brève de la Planète Bleue (http://www.planet-express.com(...)) :
En utilisant un appareil de transmission de la taille d'un jeu de cartes, les chercheurs sont déjà capables de transmettre une carte de visite électronique au moyen d'une simple poignée de main.
Je maintiens en tout cas que les adresses URL sont avant tout une partie de la technologie qui permet d'identifier et d'accéder à une resource. C'est universel dans le nom. Et ça a la commode propriété d'être à peu près lisible pour un être humain qui connaît l'alphabet latin. Je pense que chercher de ce côté est une erreur.
Quand a-t-on besoin de lire un url ou un nom de domaine/host ?
La plupart des sites ont pour point d'entrée un moteur de recherche ou un autre site. L'HTML et les navigateurs sont ainsi faits qu'il n'est pas nécessaire de savoir lire les détails de l'infrastructure technique qui organise l'information pour y accéder. L'hypertexte, c'est cliquer sur du texte par sur des URL. Et les standards du web sont très internationalisés.
La seule raison d'avoir connaissance de l'adresse d'un site à laquelle je peux penser, c'est lorsqu'elle apparait sur un média non électronique (presse écrite, publicité,... ). Ca a été évoqué plus haut : c'est une système qui peut disparaitre au profit d'une interface que l'on interogerait par mots clés, etc... Un exemple simple me semble être ce que l'on voyait pour le désuet MINITEL.
Et puis j'ai l'impression que le fait de mentioner une adresse URL dans la presse ou dans une publicité indique d'abord que l'information existe. Plutôt que de s'en souvenir ou de recopier une longue adresse, il est peut-être plus simple d'utiliser un moteur de recherche pour accéder à cette information.
Bref, je pense que seules des considérations techniques peuvent amener à remettre en question le codage actuel des URL. Dans le cas de VeriSign, il me semble que c'est plutôt d'ordre marketing ou pour créer une nouvelle demande, donc vendre plus.
Bien-sûr, du fait que j'utilise au quotidien l'alphabet latin, cet argumentaire est peut-être biaisé.
1) Pas besoin de connetre l'anglais pour taper une URL.
Pour aller dans le même sens...
Tout le monde ne parle en effet pas anglais. C'est sans doute un handicap sur Internet, et en informatique en général. Mais le fait d'être, en quelque sorte, forcé d'utiliser des éléments de cette langue pour utiliser le web ne peut être, à mon avis, qu'une bonne manière de s'y familiariser.
Bien sûr, pour les pays non latins, le problème est différent : utiliser nos caractères n'est peut-être pas très confortable. Pourtant, là aussi, c'est une manière de s'y familiariser.
D'un autre côté, j'ai l'impression que le <<>> n'est pas prêt d'être au point. En attendant, il n'y a pas de doute que l'anglais (plutôt : l'ASCII standard) est le plus adapté au traitement informatique. Et le bricolage, parce que local, est une mauvaise manière de rendre les choses accessible à tout le monde. Il faut une solution générale est reconnue par tous.
Il s'agit juste d'un worm qui se propage : pas d'autre payload, pas de backdoor, etc.. Surtout, rien de directement lié aux root servers ou quoi que ce soit qui puisse ressembler à un DDos ciblé. Bien sûr, je ne peut pas dire que je dispose d'un échantillon représentatif.
Mais alors pourquoi les root-servers ont-ils des soucis ? Statistiquement, ils n'ont pas plus de chance de recevoir la visite du worm que d'autres hosts, et c'est dire s'ils sont plus solide que bcp de serveur web qui tiennent encore debout. S'agit-il d'un excès de reverse DNS (dont peu de requêtes seraient en cache dans les secondaires, vu le caractère aléatoire de la propagation), causé par chaque connection à un MSSQL ? Ou s'agit-il d'une autre attaque parallèle, ce worm n'étant qu'un écran de fumée ?
> Le juge l'esprit il s'en balance pas mal, il regarde ce qui est ecrit.
Un juge est plutôt là pour assurer une interprétation juste des textes lors de leur application.
Mais dans notre cas, c'est plus le problème de discrimination latent qui est en cause que la stricte application de l'esprit de la GPL. Devra-t-on en venir à parler de racisme envers le libre et lutter contre ? Et comment ?
Jon n'est pas l'auteur de l'algorithme de DeCSS, mais bien d'une GUI qui s'en sert. La première publication de l'algorithme, en 1999, était anonyme (source : http://www-2.cs.cmu.edu/~dst/DeCSS/Gallery/(...) ). Finalement, est-ce l'étude de l'agorithme CSS qui est mis en cause dans cette affaire, ou le fait d'en rendre le décodage possible au grand public ?
Non, on ne peut pas faire fonctionner scp lorsque l'utilisateur a comme shell /bin/false ou autre. Si je ne me trompe pas, scp execute scp à distance en utilisant ssh (comme pour cvs : deux instances du programme communique, l'une locale et l'autre executée a distance par une méthode quelconque). Or ssh utilise le shell de l'utilisateur pour interpréter les commandes.
Quoi qu'il en soit, donner un compte, même volontairement restreint, à un utilisateur revient presque à lui donner un shell. Il y a de multiples manières d'executer une commande si l'on à accès aux fichiers de l'utilisateur (.forward, fichiers rc, php et autre, crontabs peut-être, etc...). C'est pas gagné d'avance, mais il faut considérer cette possibilité, surtout si la config du système est complexe. Reste à savoir si les utilisateurs en question sont dignes de confiance (ainsi que ceux qui peuvent avoir accès à leurs mots de passe).
Si l'on ne veut donner qu'un accès fichier à un utilisateur, il vaut peut-être mieux considérer d'en faire un utilisateur virtuel, sans UID réel.
Il existe des projets pilotes en Suisse, dans divers petits vilages (en particulier dans le conton de Fribourg, IIRC). Plus d'information sur cette page : http://www.allo.ch/fr/internet/powerline.php(...) .
C'est vrai que les risque de sécurités sont assez limité ici.
Pourtant, le bug concernant la mémoire partagée (les scoreboards, là ou résident les infos relatives au thread et aux processus enfants) n'est pas si anodin que ça. Il est en effet possible d'envoyer le signal USR1 à n'importe quel processus (en mettant son PID dans la table, en gros) et ce sans limitation (avec les privilèges de root). Par défaut, ce signal termine le processus.
Pour acéder à cette mémoire, il faut avoir les privilèges de l'user correspondant à l'httpd. Il se trouve que les scripts web (php, par exemple) son normalement executés avec ces privilèges. N'importe qui ayant un compte web peut donc potentiellement fermer un service arbitraire (un IDS par exemple ?), en utilisant system() ou autre.
De meme, des bugs dans les scripts peuvent etre exploités par un quidam pour obtenir ces (maigres) privilèges.
Enfin, il arrive que l'user associé à httpd soit 'nobody'. Il peut exister de nombreuses autres manières d'executer du code à distance avec ces privilèges.
Mise à jour conseillée, donc, mais pas si urgente pour un serveur simple.
>> 1. Arreter de prendre les news de /. ...
>> C'est clair, tant qu'elles ne seront pas modérées ! (...)
La valeur des news de slashdot réside dans les commentaires y-relatifs. Le nombre de lecteur est immense, et il y a presque toujours quelqu'un de mieux informé pour rétablir la vérité ou préciser des détails.
C'est ainsi que slashdot fonctionne.
Qu'en est-il de linuxfr ?
Non, l'extension d'un fichier ne détermine pas son format. Tous les formats de fichier ont une signature (contenant et contenu) et il n'est pas si couteux de la reconnaître : il suffit de lire une poignée d'octets. Ton système n'implémente pas cette manière naturelle de reconnaître le type d'un fichier ? ( file permet de faire cela : http://gnuwin32.sourceforge.net/packages/file.htm(...) et ftp://ftp.astron.com/pub/file(...) )
L'extension est indicative, sans plus.
D'un autre côté, sur un serveur web, il me paraiterait normal de stocker des fichiers de types différents (audio/video/...) en des emplacements différents. ForceType est une directive apache qui permettrait en outre de spécifier le type des fichiers dans un repertoire donné. Et si l'extension suffisait, pourquoi voudrais-tu te soucier du type mime ?
Il s'agit ici de bash.
Avec tcsh ou csh, il n'est pas possible - à ce que je sais - de rediriger séparément les deux canaux de sortie. On peut par contre les joindre de cette manière :
[^] # Re: 25% du prix d'un ordinateur
Posté par dvrasp . En réponse à la dépêche « Les logiciels Microsoft représentent 25% du prix de l'ordinateur ». Évalué à 5.
Pas d'accord. Ce qui est embêtant pour nous, c'est qu'il est difficile d'acheter un ordinateur sans logiciel. Or c'est Microsoft qui a les moyen de faire ce genre de pression sur les vendeurs (si ce n'est que par la popularité qu'ils ont mise en place).
Peut importe le prix, le consomateur a ce droit fondamental de choisir ce qu'il veut acheter, au regard, entre autre, du prix ; il est ici quelque peu baffoué. C'est un combat qui va au delà des enjeux du logiciel libre, mais n'oublions pas que ce droit de choisir est un des fondements du logiciel libre. Et le fait que ce coût supplémentaire soit substanciel rend la chose plus intolérable.
(...) pourquoi peut-on facilement acheter un PC sans écran ?
Pas d'accord avec ton argument. Il est infiniment plus facile de brancher un moniteur (celui de son ancien ordinateur, ou celui du grand oncle) que d'installer un système d'exploitation ou un logiciel. Brancher une prise fait partie des choses qui, à notre époque, va de soi.
[^] # Re: Editorial FreshMeat sur GCC
Posté par dvrasp . En réponse à la dépêche Editorial FreshMeat sur GCC. Évalué à 1.
[^] # Re: A-t-on besoin des URL ?
Posté par dvrasp . En réponse à la dépêche VeriSign impose le support des adresses Web avec accents. Évalué à 1.
[^] # Re: A-t-on besoin des URL ?
Posté par dvrasp . En réponse à la dépêche VeriSign impose le support des adresses Web avec accents. Évalué à 0.
Je reste convaincu que pour la majeure partie des activité de surf peuvent se passer des adresse URL. Pour garder une page, il y a des bookmarks. Pour la transmettre à quelqu'un, il y a les emails. Et je pense que tout un tas d'autres moyens peuvent être mis en oeuvre, qui se grefferaient au dessus des adresses URL.
Prends pour exemple les numéros de téléphone. Le cas est un peu plus simple, mais un numro à plus de 8 chiffres n'est pas des plus facile à manipuler et retenir. Il y a eu les annuaires, les carnets d'adresses. Il y a les portables, qui remplacent ceux-là, ajoutant du confort (électronique). On peut presque se passer de connaître le numéro d'un ami (du moins je penses, je n'ai pas de portable). Reste le problème de l'échange de coordonées par écrit ou par oral. Là aussi, il y a des progrès en route.
Petite citation pour une exemple, qui fait écho à un vieux souvenir que j'ai d'une brève de la Planète Bleue (http://www.planet-express.com(...)) :
(http://www.tregouet.org/lettre/1999/Lettre57-Au.html(...))
Je maintiens en tout cas que les adresses URL sont avant tout une partie de la technologie qui permet d'identifier et d'accéder à une resource. C'est universel dans le nom. Et ça a la commode propriété d'être à peu près lisible pour un être humain qui connaît l'alphabet latin. Je pense que chercher de ce côté est une erreur.
# A-t-on besoin des URL ?
Posté par dvrasp . En réponse à la dépêche VeriSign impose le support des adresses Web avec accents. Évalué à 3.
La plupart des sites ont pour point d'entrée un moteur de recherche ou un autre site. L'HTML et les navigateurs sont ainsi faits qu'il n'est pas nécessaire de savoir lire les détails de l'infrastructure technique qui organise l'information pour y accéder. L'hypertexte, c'est cliquer sur du texte par sur des URL. Et les standards du web sont très internationalisés.
La seule raison d'avoir connaissance de l'adresse d'un site à laquelle je peux penser, c'est lorsqu'elle apparait sur un média non électronique (presse écrite, publicité,... ). Ca a été évoqué plus haut : c'est une système qui peut disparaitre au profit d'une interface que l'on interogerait par mots clés, etc... Un exemple simple me semble être ce que l'on voyait pour le désuet MINITEL.
Et puis j'ai l'impression que le fait de mentioner une adresse URL dans la presse ou dans une publicité indique d'abord que l'information existe. Plutôt que de s'en souvenir ou de recopier une longue adresse, il est peut-être plus simple d'utiliser un moteur de recherche pour accéder à cette information.
Bref, je pense que seules des considérations techniques peuvent amener à remettre en question le codage actuel des URL. Dans le cas de VeriSign, il me semble que c'est plutôt d'ordre marketing ou pour créer une nouvelle demande, donc vendre plus.
Bien-sûr, du fait que j'utilise au quotidien l'alphabet latin, cet argumentaire est peut-être biaisé.
[^] # Re: VeriSign impose le support des adresses Web avec accents
Posté par dvrasp . En réponse à la dépêche VeriSign impose le support des adresses Web avec accents. Évalué à 2.
Pour aller dans le même sens...
Tout le monde ne parle en effet pas anglais. C'est sans doute un handicap sur Internet, et en informatique en général. Mais le fait d'être, en quelque sorte, forcé d'utiliser des éléments de cette langue pour utiliser le web ne peut être, à mon avis, qu'une bonne manière de s'y familiariser.
Bien sûr, pour les pays non latins, le problème est différent : utiliser nos caractères n'est peut-être pas très confortable. Pourtant, là aussi, c'est une manière de s'y familiariser.
D'un autre côté, j'ai l'impression que le <<>> n'est pas prêt d'être au point. En attendant, il n'y a pas de doute que l'anglais (plutôt : l'ASCII standard) est le plus adapté au traitement informatique. Et le bricolage, parce que local, est une mauvaise manière de rendre les choses accessible à tout le monde. Il faut une solution générale est reconnue par tous.
[^] # Re: Un ver déstabilise Internet
Posté par dvrasp . En réponse à la dépêche Un ver déstabilise Internet. Évalué à 10.
J'ai comparé avec les infos données pas http://www.boredom.org/~cstone/worm-annotated.txt,(...) je n'ai trouvé aucune différence dans le shellcode.
Il s'agit juste d'un worm qui se propage : pas d'autre payload, pas de backdoor, etc.. Surtout, rien de directement lié aux root servers ou quoi que ce soit qui puisse ressembler à un DDos ciblé. Bien sûr, je ne peut pas dire que je dispose d'un échantillon représentatif.
Mais alors pourquoi les root-servers ont-ils des soucis ? Statistiquement, ils n'ont pas plus de chance de recevoir la visite du worm que d'autres hosts, et c'est dire s'ils sont plus solide que bcp de serveur web qui tiennent encore debout. S'agit-il d'un excès de reverse DNS (dont peu de requêtes seraient en cache dans les secondaires, vu le caractère aléatoire de la propagation), causé par chaque connection à un MSSQL ? Ou s'agit-il d'une autre attaque parallèle, ce worm n'étant qu'un écran de fumée ?
[^] # Re: Violation de la GPL ?
Posté par dvrasp . En réponse à la dépêche TCPA/Palladium va attenter à la GPL. Évalué à 3.
[^] # Re: Accès publics gratuits à des machines sous Linux
Posté par dvrasp . En réponse à la dépêche Accès publics gratuits à des machines sous Linux. Évalué à 2.
http://web.archive.org/*/www.testdrive.compaq.com/(...)
# Le cas DeCSS ?
Posté par dvrasp . En réponse à la dépêche Jon Johansen acquitté dans le cas DeCSS. Évalué à 9.
Jon n'est pas l'auteur de l'algorithme de DeCSS, mais bien d'une GUI qui s'en sert. La première publication de l'algorithme, en 1999, était anonyme (source : http://www-2.cs.cmu.edu/~dst/DeCSS/Gallery/(...) ). Finalement, est-ce l'étude de l'agorithme CSS qui est mis en cause dans cette affaire, ou le fait d'en rendre le décodage possible au grand public ?
[^] # Re: Sftp et Scp sans se logguer
Posté par dvrasp . En réponse à la dépêche Sftp et Scp sans se logguer. Évalué à 2.
Quoi qu'il en soit, donner un compte, même volontairement restreint, à un utilisateur revient presque à lui donner un shell. Il y a de multiples manières d'executer une commande si l'on à accès aux fichiers de l'utilisateur (.forward, fichiers rc, php et autre, crontabs peut-être, etc...). C'est pas gagné d'avance, mais il faut considérer cette possibilité, surtout si la config du système est complexe. Reste à savoir si les utilisateurs en question sont dignes de confiance (ainsi que ceux qui peuvent avoir accès à leurs mots de passe).
Si l'on ne veut donner qu'un accès fichier à un utilisateur, il vaut peut-être mieux considérer d'en faire un utilisateur virtuel, sans UID réel.
# Projets pilotes en Suisse
Posté par dvrasp . En réponse à la dépêche Internet par le réseau électrique, c'est parti. Évalué à 1.
[^] # Re: Le nouveau Validator du W3C est en service
Posté par dvrasp . En réponse à la dépêche Le nouveau Validator du W3C est en service. Évalué à 1.
Le validateur de w3c donne en plus des explications quant aux erreures et des liens qui permettent de les comprendre et corriger.
[^] # màj mineure ?
Posté par dvrasp . En réponse à la dépêche Apache 1.3.27 (upgradez!). Évalué à 2.
Pourtant, le bug concernant la mémoire partagée (les scoreboards, là ou résident les infos relatives au thread et aux processus enfants) n'est pas si anodin que ça. Il est en effet possible d'envoyer le signal USR1 à n'importe quel processus (en mettant son PID dans la table, en gros) et ce sans limitation (avec les privilèges de root). Par défaut, ce signal termine le processus.
Pour acéder à cette mémoire, il faut avoir les privilèges de l'user correspondant à l'httpd. Il se trouve que les scripts web (php, par exemple) son normalement executés avec ces privilèges. N'importe qui ayant un compte web peut donc potentiellement fermer un service arbitraire (un IDS par exemple ?), en utilisant system() ou autre.
De meme, des bugs dans les scripts peuvent etre exploités par un quidam pour obtenir ces (maigres) privilèges.
Enfin, il arrive que l'user associé à httpd soit 'nobody'. Il peut exister de nombreuses autres manières d'executer du code à distance avec ces privilèges.
Mise à jour conseillée, donc, mais pas si urgente pour un serveur simple.
# Jeter la première pierre
Posté par dvrasp . En réponse à la dépêche Le coté sombre des Pirates. Évalué à 10.
[^] # Modération distribuée
Posté par dvrasp . En réponse à la dépêche Le mp3 toujours gratuit pour le libre. Évalué à 5.
[^] # L'habit ne fait pas le moine
Posté par dvrasp . En réponse à la dépêche Après Ogg, Ogg vidéo!. Évalué à 9.
L'extension est indicative, sans plus.
D'un autre côté, sur un serveur web, il me paraiterait normal de stocker des fichiers de types différents (audio/video/...) en des emplacements différents. ForceType est une directive apache qui permettrait en outre de spécifier le type des fichiers dans un repertoire donné. Et si l'extension suffisait, pourquoi voudrais-tu te soucier du type mime ?
# bash | tcsh/csh
Posté par dvrasp . En réponse au message [Terminal] Du bon ordre des redirections. Évalué à 1.
Avec tcsh ou csh, il n'est pas possible - à ce que je sais - de rediriger séparément les deux canaux de sortie. On peut par contre les joindre de cette manière :
ou