Buf a écrit 449 commentaires

Moi qui voulait justement, lorsque je rentre mon adresse et mon numéro de téléphone sur un site bien précis (genre achat en ligne), que ces infos soient partagées avec n'importe qui utilisant le même protocole, et ce sans mon consentement préalable... C'est exactement ce que je cherchais...

Alors, plusieurs choses :
- tu n'es pas obligé d'enregistrer quoi que ce soit dans ton profil OpenID
- le fournisseur OpenID ne va en général pas donner ces infos sans ton consentement. En général, la première fois que tu utilises OpenID pour te connecter sur un site, tu vas voir quelles infos le site en question demande, et pouvoir choisir ce que tu veux transmettre
- dans tous les cas, c'est complètement optionnel, et rien n'empêche d'utiliser OpenID uniquement pour l'authentification

Et les personnes physiques dans tout ça ? Si une personne physique ne peut se proposer comme fournisseur d'identité, les spécifications ont beau être ouvertes, l'utilisation ne l'est pas...

Les personnes physiques aussi peuvent être fournisseur d'identité. Comme dit plus haut, ça peut se faire simplement en installant un petit script PHP.

Le truc "open" là-dedans, c'est que ce n'est pas lié à un seul fournisseur, ni même à une autorité qui règlementerait tout ça. On est parfaitement libre d'être son propre fournisseur OpenID, il y a des scripts PHP qui permettent de se faire une identité hébergées sur son propre site en quelques minutes.

Mouais, le FAI voit de toute façon passer tous les paquets, il peut donc obtenir toutes ces informations beaucoup plus facilement et discrètement : en examinant les paquets.

Le SSL, c'est bon, mangez-en !

Le riz, je le fais dans un auto-cuiseur à riz, la techique ultime du geek qui ne veut pas surveiller la cuisson.

Moi je le fais au micro ondes. En moins de 15 minutes, mon riz est cuit, sans avoir eu besoin de surveiller la cuisson et avec un minimum de vaisselle. C'est encore plus simple à faire que des pâtes (et arrosé d'une bonne dose de ketchup et du gruyère râpé, c'est délicieux)

Les fichiers sans DRM d'iTunes ne sont pas du MP3, c'est aussi de l'AAC (la partie DRM est optionnelle)

On sait qu'il n'y a pas de watermark sur les données audio (le même fichier acheté avec des comptes différents produit exactement les mêmes données audio une fois décompressé)

Il peut y avoir d'autres données sur l'utilisateur, ça ne change au fait que pour les enlever définitivement, il suffit de réécrire toutes les métadonnées, en ne gardant que ce qui est "sûr" et anonyme (nom de l'artiste, de l'album, etc)

Plus que le risque d'erreur, je pense que le problème d'avoir une validation par un comité restreint, c'est un potentiel manque de neutralité.

Tu fais une hypothèse discutable dans ta démonstration : tu supposes que les experts vont systématiquement sélectionner la meilleure version disponible.

Je pense que les experts, aussi brillants soient-ils, vont :
- se tromper de temps en temps
- ne pas être complètement neutres en tout temps

Bref, ils sont faillibles. Autrement dit, ta suite ne sera pas strictement croissante, et risque d'aboutir à quelque chose qui ne sera pas optimal.

> La logique me pousserait à dire que le moteur n'est pas exactement le même mais bon, vu que les deux s'apellent IE

En fait, le nom est à peu près tout ce qu'ils ont en commun. IE Mac n'était pas un portage de la version Windows, mais bel et bien un logiciel développé séparément, par une autre équipe de développeurs.

Pour des exemples, il suffit de regarder du côté des Mac, qui utilisent Rendezvous un peu partout depuis un moment.
En vrac :
- partage de musique depuis iTunes
- même chose pour les photos depuis iPhoto
- partage de fichiers
- plus geek : le terminal est capable d'aller chercher une liste de serveurs SSH sur le réseau grace à Rendezvous
- certaines imprimantes réseau supportent ça. Elles apparaissent directement dans la liste des imprimantes disponibles, sans avoir dû les chercher ou les ajouter manuellement
- la version Mac de VNC supporte ça (quand on lance le client, on a la liste des serveurs qui apparaît)

Enfin bref, c'est très pratique, et ça peut s'utiliser pour plein de choses.

Euh, soit j'ai rien compris au lien que tu donnes, soit je ne vois absolument pas le rapport avec ce que j'ai écrit...

Le problème du md5, c'est que tu n'as que des lettres minuscules de A à F et des chiffres.

Pour générer des mots de passe, j'utilise ça :
dd if=/dev/random count=6 bs=1 | openssl base64

ça me donne un mot de passe aléatoire de 8 caractères, avec majuscules/minuscules/chiffres, du genre : BTjaFXk9 ou cpKiO8gO

Si je me souviens bien, le clavier Apple a 2 prises USB => clavier/souris/APN + imprimante = 2

Et tu peux aussi faire tout ça avec WebCore (le fork de khtml d'Apple), c'est du LGPL.

Sinon, pour ceux qui disent qu'Apple se moque complètement du logiciel libre :

Darwin est diffusé sous une licence libre, alors que rien n'obligeait Apple à le faire
Toutes les modifications apportées à XFree86 pour que ça tourne sous Mac OS X sont libres, alors que là aussi, Apple n'avait aucune obligation de le faire
En regardant la liste des développeurs de gcc, on y trouve une dizaine d'employés d'Apple. Et ça, c'est une contribution directement utile à beaucoup d'autres projets (libres ou pas)
Sans parler de : Rendezvous, Streaming server ou OpenPlay, tous des produits Apple diffusés sous une license libre


Bien sûr, on peut toujours répondre que Quartz, QuickTime, Aqua ou le Finder ne sont pas libres. Mais là, on parle des composants qui font la spécificité de Mac OS X. Les rendre libres, donc accessibles à tous, ça serait suicidaire d'un point de vue commercial (ne pas oublier qu'Apple est avant tout un vendeur de matériel relativement cher! Il faut bien avoir quelques arguments de vente...)

Ça ressemble plutôt à un iMac sous Mac OS X...

> je ne sais pas si la version 1.1 oblige d'utiliser host pour les connections

Oui, host est obligatoire en HTTP 1.1 (RFC2616 section 14.23: "A client MUST include a Host header field in all HTTP/1.1 request messages").

ça n'est en revanche pas obligatoire en HTTP 1.0.

Ouais, évidemment, si à chaque fois qu'on te trouve un contre exemple à ta belle théorie, c'est un mauvais exemple, on risque d'avoir du mal à discuter...

Je ne parle pas d'un point de vue technique, mais uniquement d'un point de vue utilisation. En quoi un jeu multi-joueur avec des possibilités de jeu en réseau est différent d'un truc type gimp ou gedit? Dans tous les cas, c'est une application qui ressemble à des dixaines d'autres, que l'utilisateur lance et arrête comme il veut.

Alors bon, tes histoires de serveur, ça n'a juste rien à faire ici.

> Pas possible (sauf utilisation de "/tmp" plus de gros risque de sécurité).
> Faut aussi le sid pour le programme.
> Ça peut être vu comme un serveur de score.

Mais oui, bien sûr....
Je te parle des jeux Gnome (style démineur), donc je donne un exemple concret. T'es allé voir comment c'est fait avant de dire n'importe quoi?
Il n'y a *aucun* serveur, ni aucune communication réseau, ni IPC, ni quoi que ce soit. C'est juste des accès tout à fait normaux à un fichier.
L'exécutable est setgid games, et le fichier de score (qui doit se trouver quelque part dans /var/lib/games, pas dans /tmp) est accessible en écriture au groupe games. C'est tout. Pour ce modèle marche quand on peut avoir plusieurs utilisateurs, il faut que le programme prenne un minimum de précaution avant d'accèder au fichier.

Accessoirement, le fait de jouer sur les permissions des fichiers pour que ça marche, ça fait aussi partie des choses qui doivent être pensées pour que le programme tourne dans un environement multi-utilisateurs (même si ça ne concerne pas le code)

> Faites une appli qui fait "une connerie empechant l'utilisation en multi-user" (hors "/
> tmp", je n'y reviens pas pour le centième foi.

Ok...

Imagine un jeu, qui permet de jouer à plusieurs en réseau. À un moment ou à un autre, il risque de devoir ouvrir un port TCP/IP. Si le dévelopeur n'a pas pensé au fait que le jeu peut être lancé par plusieurs utilisateurs en même temps, il risque d'utiliser un numéro de port fixe, codé en dur dans le programme (c'est pas très malin, mais ça peut se faire). Dans ce cas, si un deuxième utilisateur lance le même programme => port déjà utilisé, ça marche pas!

Autre exemple, toujours dans le cas d'un jeu. Suppose que le jeu garde en mémoire les meilleurs scores des utilisateurs (c'est le cas de pas mal des jeux fournis avec Gnome, par exemple). Si le développeur ne tient pas compte du fait que le programme peut être lancé par plusieurs utilisateurs, il risque d'y avoir des accès concurrents au fichier de scores => possibilités de corruption.

Ouais, mais bon, la résolution max, c'est du 1366x768, donc moins que l'iMac 17'' (1440x900).
Avoir un écran géant, c'est sympa, mais si c'est pour avoir des pixels énormes, bof...

Attention, les 1299$, c'est sans la TVA.
Pour pouvoir comparer, il faut prendre le prix européen HT. Et là, on arrive à ~1170¤.
C'est encore plus cher que le prix US, mais la différence est nettement plus raisonnable.

Je dirais sl, pour ceux qui ne sont pas capable de taper ls correctement...

http://www.tkl.iis.u-tokyo.ac.jp/~toyoda/sl/sl.tar(...) ou "apt-get install sl"

Pour sid, c'est déjà là.

$ dpkg -l bash
ii bash 3.0-4 The GNU Bourne Again SHell

d'ailleurs si quelqu'un connait un patch pour faire un vrai mode idle à la win, je suis preneur

Tu peux essayer le patch "Batch scheduling" qui doit faire à peu près ce que tu veux.

http://members.optusnet.com.au/ckolivas/kernel/(...) (il y a aussi le patch gérer correctement l'hyperthreading avec les tâches basse priorité)

Aussi dans le domaine bandes dessinées, au boulot, nos serveurs s'appellent : joe, jack, william, averell et rantanplan.

Faut arrêter avec ce genre d'affirmation, parce que c'est complètement faux. Un virus, même lancé par un utilisateur sans privilèges particuliers, peut :
- se transmettre par mail
- détruire les fichiers de l'utilisateur
- participer à un DDOS
- installer une backdoor (qui ne permettrait pas d'avoir plus de droits que ceux de l'utilisateur qui a lancé le virus, mais ça peut suffire pour faire des dégâts)

En clair, il pourrait être aussi dangereux que les virus du genre de MyDoom.

Si on ne trouve pas de virus sous Linux, c'est à mon avis pour d'autres raisons :
- aucun client mail (à ma connaissance) ne permet d'exécuter une pièce jointe directement
- le fait que la détermination si un fichier est exécutable ou pas n'est pas faite à partir de l'extension du fichier, mais d'un attribut sur le fichier (pour lancer une pièce jointe, il faut la sauver sur le disque, lui donner explicitement les droits d'exécution, et l'exécuter. C'est pas le genre de manip qu'on fait par erreur, et je ne crois pas qu'il existe des logiciels de mail qui le font automatiquement)
- la variété. On n'a pas une seule platforme homogène, comme Windows. Entre les différentes architectures matérielles, les différentes distributions, les différents logiciels et environnements, il peut être difficile d'écrire un virus qui fonctionnera sur un nombre suffisant de machine pour faire des dégâts.
- le fait que les utilisateurs de Linux, dans l'ensemble, soit plus au courant des questions de sécurité (non, je n'ai pas dit que tous les utilisateurs de Windows sont des neuneus...)