e-t172 a écrit 150 commentaires

Ben oui, Google a tout simplement acheté le préfixe 8.8.8.0/24 à Level 3, comme semble l'indiquer le WHOIS. Il a peut-être payé très cher pour l'avoir, mais je ne vois pas ce qu'il y a de douteux là dedans.

"Bon, par contre j'apprécie particulièrement leur ligne dédiée pour les utilisateurs de la fibre, qu'on n'a pas besoin d'appeler en pleine nuit, avec des gens compétents à l'autre bout qui ne te demandent pas de retester toute ton installation si tu leurs explique bien ce qu'il se passe."

Chez SFR/Neuf en fibre optique à Pau c'est pareil, c'est franchement agréable d'avoir quelqu'un de constructif à l'autre bout du fil. En plus, contrairement à Orange, y'a IP fixe et aucune restriction particulière.

Ton récit est vraiment très intéressant. T'as essayé avec Windows server 2008 R2/7 ? Il me semble avoir lu qu'ils avaient fait des progrès sur le cache disque dans les dernières versions.

Ok, donc si on utilise requiretty, ça veut dire qu'on ne peut pas utiliser sudo sur un émulateur de terminal type xterm ? Puisque ce sont des PTS et pas des TTY ?

"Les TTYs sont fournies par le noyau. Alors il faut commencer par vaincre le noyau ..."

Non. N'importe qui peut émuler un TTY, c'est ce que fait ton émulateur de terminal (gnome-terminal, xterm, ssh, ...).

Ou alors faut qu'on m'explique.

Sous Windows t'ouvre une ligne de commandes en administrateur et t'exécute ces "paquets", et hop une volée de logiciel installés avec une seule autorisation à faire.

"requiretty[1] est suffisant, ou alors tu utilises des OTP[2], ..."

Requiretty ne peut-il pas être contourné en émulant un tty, justement ? Si ton émulateur de terminal peut le faire, pourquoi une application normale ne pourrait pas le faire ? (C'est une vraie question)

Pour les OTP : ça solve le problème de sécurité, mais c'est très contraignant. L'UAC, c'est un clic tout en restant un minimum secure.

"C'est ça la force de Microsoft, réussir à faire croire que la défragmentation du disque est une fonctionnalité, pas un bug, que l'UAC est une fonctionnalité pas un bug, ..."

Et alors ? Je m'en fous un peu de comment ils appellent ça, je vois pas l'importance de la terminologie là-dedans. Je considère ça comme une *avancée*. Que ce soit un bug en moins ou une feature en plus, je vois pas ce que ça change dans le cadre de cette discussion.

C'est plus une critique "distribution par dépôts" VS "distribution par installeurs" que "modèle de sécurité Linux" VS "modèle de sécurité Windows" ça.

"Avec une distribution linux moderne, il suffit de s'authentifier une seule fois, de choisir les divers logiciels, et tout s'installe dans la foulée, sans avoir besoin de faire 15 interventions différentes."

Mouais. Sous Windows t'as besoin de faire un clic supplémentaire par install (l'autorisation). Il vaut pas lourd l'argument.

"Bon à priori t'as jamais utiliser sudo et encore moins sudo-ldap ..."

J'utilise sudo tous les jours. Par contre sudo-ldap il est vrai que je ne connais pas.

"Avec sudo tu peux spécifier exactement la commande que l'utilisateur à le droit, tu peux donc autoriser par application les droits ... Qui plus est tu peux le mettre dans une base de données LDAP et gérer tous les utilisateurs depuis là. Tu peux faire une gestion par groupe (le groupe Admin peut lancer toutes les commandes, le groupe MàJ peut lancer uniquement aptitude update et aptitude upgrade, ...)"

Je n'ai pas regardé, mais ça m'étonnerait beaucoup que sous Windows tu ne puisse pas faire ça avec les statégies de groupe et les ACL.

Je ne parlais pas du même contexte : je voyais surtout ça du point de vue de l'utilisateur lambda chez lui qui utilise sa machine personnelle (auquel cas la discussion sur sudo-ldap et les stratégies élaborées n'a plus beaucoup de sens). Il est vrai que le fil portait plutôt sur l'utilisateur lambda en entreprise, je suis donc un peu hors sujet.

"sudo permet de configurer "NOPASSWD" pour ne pas avoir besoin d'entrer le mot de passe"

Oui mais non. Si tu mets NOPASSWD, qu'est ce qui empêche une appli normale de faire de l'escalation en appellant simplement sudo en interne sans rien demander à l'utilisateur ? Ca me semble être une grossière faille de sécurité... Sous Windows ce n'est pas possible parce que la fenêtre qui te demande l'autorisation est une fenêtre spéciale du système avec laquelle les autres applis ne peuvent pas interagir.

"toujours dix ans de retard."

Je ne me prononcerai pas là-dessus (je n'ai pas assez de connaissances pratiques en entreprise), mais à titre personnel j'ai beaucoup plus l'impression que Windows gagne du terrain qu'il n'en perd...

"Et c'est là que Windows devient particulièrement mauvais. C'est un système où les droits sont difficiles à gérer de manière correcte, particulièrement à cause de ces utilisateurs systèmes.
Il est aussi difficile d'avoir des élévations de droits sur demande, aussi simple et agréable que sudo, par exemple."

La situation est bien meilleure sur ce point depuis Vista/7. Grâce à l'UAC il est réellement possible d'utiliser Windows en tant qu'utilisateur de base, si l'application tente de modifier des données système les modifications sont automatiquement redirigées dans un répertoire utilisateur (selon un principe identique à unionfs sous Linux).

Ce qui fait que les applications vieilles ou mal codées qui tentent encore d'écrire des trucs dans Program Files peuvent toujours fonctionner en utilisateur limité, et en prime les modifications qu'elles font sont isolées sur le profil de l'utilisateur qui utilise l'application. On arrive au même comportement que Linux où les applis stockent leurs données dans /home/user.

De plus, bien que les utilisateurs de Windows soient par défaut administrateurs, en réalité les applications sont lancées avec les droits d'utilisateur normal : pour qu'une application aie les droits d'administrateur il faut que l'utilisateur les lui donne explicitement, via une boîte de dialogue que le système affiche lorsqu'une appli veut s'approprier des droits. C'est un fonctionnement absolument identique à sudo sous Linux. C'est même plus pratique que sous Linux vu qu'on a pas à entrer de mot de passe - ce qui au passage limite les chances de se faire keylogger ou autres joyeusetés.

J'utilise Windows 7 quotidiennement et dans une journée typique je ne lance pas une seule application avec les droits d'administrateur. Tiens, exactement comme sous Linux !

Donc alors voyons voir :

Sous Linux :
- Par défaut on n'utilise pas les applications avec des droits d'administrateur
- Toutes les applications ou presque qui ne sont pas des outils d'administration fonctionnent en temps qu'utilisateur limité
- Pour lancer une application en administrateur pour celles qui en ont besoin, on utilise sudo

Sous Windows Vista/7 :
- Par défaut on n'utilise pas les applications avec des droits d'administrateur (tiens, comme sous Linux)
- Toutes les applications ou presque qui ne sont pas des outils d'administration fonctionnent en temps qu'utilisateur limité (tiens, comme sous Linux, grâce à l'UAC)
- Pour lancer une application en administrateur pour celles qui en ont besoin, on répond oui lorsqu'on nous pose la question (tiens, comme sous Linux ou presque)

Donc je sais pas pour vous, mais moi quand je lis encore l'argument "Windaube c'est de la mairde, tout le monde est admin", je me marre. (et je moinsse) Désolé, mais quand Windows XP aura totalement disparu (ce qui devrait s'accélerer depuis 7), cet argument sera devenu totalement caduc.

Détails et source : http://technet.microsoft.com/en-us/magazine/2007.06.uac.aspx

Alors après on peut encore soulever deux points :
- L'utilisateur lambda répondra toujours "autoriser" à l'UAC sans se poser de question : en effet, de la même façon qu'il peut sudo n'importe quoi n'importe comment sous Linux.
- Beaucoup de gens sous Windows désactivent l'UAC : c'est une trace historique de Vista sous lequel l'UAC est beaucoup plus chiant que sous 7. Mes amis ont toujours désactivé l'UAC sous Vista mais ils le laissent activé sous 7. Après, si on se met à tripatouiller le système et à foutre les mains dans le cambouis (genre éditer des fichiers dans Program Files), l'UAC peut se mettre en travers du chemin, ce qui pousse les gens à le désactiver. Sous Linux c'est pareil : le même utilisateur va appliquer le même raisonnement en faisant tout sous root sous prétexte qu'il ne peut rien éditer dans /etc.

Quelle joie d'être Vendredi !

"Et puis, sous Linux, à quoi bon avoir une config de gamer ?"

Ce n'est pas une config de gamer. La carte graphique ne suivra pas (et largement).

"en parcourant quelques blogs de ce type, le seul reproche que j'ai pû lire à l'égard de Spice est du type "lourd sur le réseau"... logique, non ? On va pas faire du Spice avec une ligne adsl... (quoique...)"

J'utilise NX quasiment tous les jours. L'énorme intérêt de NX est justement de pouvoir accéder à son environement de travail de n'importe où, y compris sur des connexions pourries.

Exemple récent : utiliser NX sur une connexion mobile 3G avec 1 mbit de bande passante et surtout 150 ms de latence. C'était tout à fait utilisable et j'ai pu vraiment bosser avec. De là à dire que c'était "agréable" je n'irais pas jusque là, mais en même temps, on peut pas tout avoir...

Si t'as besoin d'une connexion haut débit voire très haut débit pour utiliser Spice, il perd tout son intérêt à mes yeux. Choisir entre la vidéo HD/l'audio bidirectionnel et pouvoir accéder à mon bureau en tout-terrain, mon choix est vite fait. Peut-être que Spice n'est en fait que pour les "clients légers" utilisés en entreprise et sur réseau local...

Moi je fais tout simplement :

cat /dev/zero > /dev/sda

Ça ne m'avait pas paru particulièrement lent...

"Relis mieux la norme XHTML (pas seulement la version W3C de la norme XML 1.0) tu verras qu'un élément déclaré en balise auto-fermante est un élément vide terminal, ce qui veut dire qu'il ne peut pas avoir de fils."

Je viens de relire la norme XHTML et la seule chose qui ressemble à ce que tu dis c'est ça :

"Given an empty instance of an element whose content model is not EMPTY (for example, an empty title or paragraph) do not use the minimized form (e.g. use <p> </p> and not <p />)."

Là où le bât blesse, c'est que ce paragraphe est dans la section "HTML compatibility guidelines", qui est informative et non-normative. Raté, essaie encore.

"Tu mets donc une balise à contenu (fut-il distant) en auto-fermant... Bien bien bien...
Tu m'aurais dit une balise link vers un script pourquoi pas (même si la norme ne le permet pas à l'heure actuelle). Mais du container, donc rentrant dans le DOM, en auto-fermant ca me fait un peu peur. Pourquoi pas <p /> quand on veut créer un paragraphe vide tant qu'on y est ?"

Où est le problème ? En XML <blabla></blabla> veut dire EXACTEMENT la même chose que <blabla />. C'est IDENTIQUE. <br /> c'est pareil que <br></br>. <p /> c'est pareil que <p></p>.

http://www.w3.org/TR/2008/REC-xml-20081126/#d0e2433

"[Definition: An element with no content is said to be empty.] The representation of an empty element is either a start-tag immediately followed by an end-tag, or an empty-element tag."

"Empty-element tags may be used for any element which has no content, whether or not it is declared using the keyword EMPTY."

(la phrase qui suit "for interoperability" concerne la compatibilité avec SGML, autant dire qu'on s'en fout complètement aujourd'hui)

Tu es coupable de deux infractions du type "je ne lis pas les posts de mon interlocuteur".

Preuves :

- A :
"quand au xhtml déclaré proprement avec version xml et encoding il fait figure d'ovni"

Tu as cité plusieurs sites. Aucun ne déclare proprement "avec version xml et encoding". En effet je ne vois aucun prologue "<?xml version="1.0" charset="utf-8" ?>".

- A :
"Donc XHTML 1.0 Transitional ovni, certainement pas, mais Strict et 1.1 oui."

Tu as répondu :
"Ben évidemment, vu que Strict 1.1, ça doit être servi en application/xhtml+xml".

Il ne parlait pas de "Strict 1.1" mais de XHTML 1.0 Strict et de XHTML 1.1. Tu as sans doute sauté le "et" dans sa phrase. Tu as donc répondu pour XHTML 1.1, maintenant on attend l'argument pour XHTML 1.0 Strict.

Attention, tu as perdu à la troisième petite croix !

C'est déjà le cas pour HTML... tu peux très bien avoir le HTML le plus syntaxiquement dégueu de la terre, le passer dans un parseur HTML tolérant (genre IE, firefox) et ensuite manipuler le DOM avec Javascript. Le seul problème c'est que l'arbre généré ne sera pas forcément le même selon les navigateurs, ce qui amène à un fort potentiel d'emmerdes. Mais dans l'absolu, c'est possible.

Non. Le HTML est une norme au même titre que le XHTML (va voir HTML 4.01 sur le site du W3C).

"un code XHTML est forcément syntaxiquement propre, sinon le parseur XML t'enverra bouler..."
->
"un code HTML est forcément syntaxiquement propre, sinon le parseur SGML t'enverra bouler..."

(ce qui en pratique ne se produit jamais, mais c'est un choix des navigateurs d'être tolérant, ça n'a rien à voir avec la norme elle-même)

Tu peux très bien avoir du XHTML syntaxiquement dégueu comme du HTML syntaxiquement dégueu. Dans le premier cas il ne passera pas un parser XML strict, dans le second cas il ne passera pas un parser SGML strict.

"Google n'arrête pas de me confirmer que le FOV de HL2 est de 75°"

Faudrait savoir, tu parles de HL ou de HL2 ? Sur HL il est bien à 90° par défaut.

Par contre ça m'étonne effectivement qu'il soit à 75° sur HL2. Mea culpa.

"Des jeux comme HL le mettent à 70°"

Non. Tous les jeux respectables le mettent à 90° (sur du 4/3, sur un écran wide ce serait plutôt 110°). Les seuls jeux qui ont un FOV de 70° sont des petits rigolos (comprendre : casual), genre Halo.

D'où le "quasi".

Si tu avais lu le jugement tu saurais que "l'argument Google" a été répondu par le juge en arguant du fait que Google n'offre pas en quasi-totalité du contenu soumis au droit d'auteur, alors que c'est le cas de TPB.

Le truc, c'est que les logiciels de calcul partagé (type distributed.net, SETI@Home, etc.) sont les meilleurs moyens de faire exploser ta consommation d'électricité. Faut pas croire que lorsque le CPU est inutilisé, c'est de l'électricité "perdue" : la consommation d'un CPU en charge est beaucoup plus grande qu'un CPU au repos, surtout sur les plus récents (par exemple les Core 2).

Donc répondre à quelqu'un qui se soucie de sa consommation d'électricité en lui disant de faire bosser en permanence sa machine, c'est tout simplement contre-productif.

"la base de donnée me semble bien pour faire des recherches dans l'historique et les signets"

C'est aussi ce qui rend mon Firefox incroyablement lent sur certaines opérations (ouvrir le menu Historique, par exemple) lorsqu'on a un profil stocké sur le réseau.