Gruik Man a écrit 547 commentaires

Quand on se lance dans l'utilisation d'un tel système il vaut mieux y réfléchir à deux fois (ex: Qt ou GTK :), pour ma part je suis pour Xlib (avec en plus le système de widget que l'on veut)

Gné? Je comprends rien. QT et GTK utilisent Xlib sous un système X11. Ils entrent parfaitement dans la catégorie « Xlib avec en plus le système de widget que l'on veut »
Quant à tous les avantages que tu as cités, ils sont aussi présents en utilisant GTK ou QT (sauf peut-être l'affichage sur plusieurs serveurs X?).

A moyen terme, le DRM apportera cet équilibre pour la société. On aura des échanges équitables en wma et tout le monde sera content.

Mouarf! Rassure-moi, ce post est une grosse blague?

Pourquoi seraient-ils les grands perdants? A qui va la taxe Tasca sur les CD-R? Pourquoi serait-ce différent si une redevance sur les connexions réseau était mise en place?

En effet, les pirates qui collectionnent les mp3 et les DivX, il y en a peu... En général, les pirates sont trop occupés à effectuer des détournements en haute mer pour s'occuper à collectionner des fichiers audio ou video.

Quels que soient les buts réels derrière la mise en place d'un système tel que TCPA, j'aime beaucoup cette citation : ) : « There is no "serial number revocation list". Could someone create such a list? Yes, this could be done, with or without TCPA. There is no end to the infinite number of stupid things that could be done on a Turing complete system. TCPA simply does not do this. »

selon les informations relayées par zataz.com,

Lol, th3 ult1m4t3 s3cUr1tY r3f3r3nc3! ^^

La propriété pour arrondir les bords, c'est -moz-border-radius. Mozilla dispose lui aussi de pas mal d'extensions propriétaires à CSS, mais elles commencent toutes par -moz-, indiquant clairement au développeur que ce sont des propriétés liées à Mozilla, et ne lui faisant pas croire qu'il s'agit de propriétés standard , comme certains autres logiciels ont par trop tendance à le faire...

apt-get install pfaedit : )

(ou si tu préfères, http://pfaedit.sourceforge.net/(...) )

A vot'service : )

C'est pas parce que je réponds à ton message que c'est forcément pour te contrarier : ) Il s'agit, comme tu l'as dit, de précisions.

La serif est affreuse, les serifs sont bien trop grosses, trop carrées, on dirait une police « courier ». A basse résolution, elle passe mieux, déjà, mais l'espacement etre caractères n'est pas très équilibré. C'est peut-être dû à Abiword, remarque?

Enfin, bref, bof bof, pour ce que j'ai pu en voir. Mais il faudra que je fasse mes propres test : )

Les polices TrueType sont (pour simplifier) des polices vectorielles (des courbes de Bezier définissant des contours) associées à des polices bitmap pour certaines résolutions (basses résolutions fréquemment utilisées, comme 10px, 12px, etc), et à un système de placement/déformation en pseudocode, permettant un affichage correct sur les basses résolutions non-couvertes par les représentations bitmap.

Les polices Type1, c'est à peu près la même chose (toujours pour simplifier), sauf qu'elles n'utilisent pas de pseudocode, mais des contraintes sur le placement et les distances, la déformation étant gérée par le moteur de rendu.

En fait, les fontes Verdana et Tahoma ont été conçues, pour Microsoft, en partenariat avec Agfa Monotype, si je ne m'abuse. Et ces polices sont bel et bien réputées comme étant parmi les meilleures pour ce qui est de la lisibilité à basse résolution.

Donc oui, à mon avis, ce n'est absolument pas aberrant de prendre les fontes Microsoft comme critère de comparaison pour l'utilisation « affichage informatique »

Oui, mais le « truc », ce n'est pas que deux informations ayant la même empreinte n'existent pas, c'est qu'il n'est pas possible d'en trouver deux en un temps donné, avec une puissance de calcul donnée.

Donc si en théorie, il existera deux fichiers ayant la même empreinte md5 128 bits, en pratique, il sera impossible -- à moins de disposer d'une puissance de calcule égale à celle de distributed.net : ) -- d'en trouver deux vérifiant cette propriété

Bah, le message original de Gobbles date du 13... C'est pas si vieillot que ça, on en trouve de plus vieilles ; )

Citation du message:

« The professional staff of GOBBLES Security believe that by releasing our
advisories without vendor notification of any sort is cute and humorous, so
this is also the first time the vendor has been made aware of this problem.
We hope that you're as amused with our maturity as we are. ;PpPppPpPpPPPpP »

Ca veut tout dire, non? : )

Ben heu, oui mais non. Le but des DRM n'est pas vraiment d'empêcher les utilisateurs de lire leurs MP3 actuels, c'est bien plus complexe que ça.

Imagines que tu télécharges, sur un site web, un document protégé par DRM. Le site web n'acceptera de te délivrer le document que si l'application qui le télécharge s'authentifie numériquement comme une application de « confiance »[1]. L'application en question, outre une gestion stricte des instructions contenues dans le document (ne pas permettre de la copier si le document l'interdit, ne la jouer que N fois et ensuite la détruire, etc), écrira les données du document dans une zone identifiée comme de « confiance » dans le disque dur. Cette zone, les applications non-signées, pas plus que ton Linux en dual-boot (la protection est gérée au niveau hardware) ne pourront y accéder. Vu que la clé privée de l'application signée est aussi protégée de manière matérielle, impossible de la récupérer pour l'utiliser ailleurs.

Quid des émulateurs / virtualisateurs, alors? Ben, vu que la protection est gérée au niveau matériel, le périphérique de « confiance » (disque-dur, lecteur externe, etc) n'acceptera de délivrer les données protégées qu'à une application de « confiance » (typiquement, un gestionnaire de périphériques signé). Laquelle, à son tour, ne pourra délivrer les données qu'à une application selon le même mécanisme, etc. On crée ainsi une « chaîne de confiance », d'où les données, sauf exploitation du bug, ne pourront pas sortir. Si, dans cette chaîne, on intercale un virtualisateur, ou tout dispositif externe brisant la chaîne (kernel non-signé, débugger, etc), les données s'arrêteront là où le dispositif a été interposé; l'élément de plus bas niveau refusant de fournir les données à ce dispositif.

Quid des interpréteurs, maintenant? Ben, même problème. Un interpréteur de « confiance » ne pourra faire transiter de données « protégées » que vers un script signé.

On peut, de plus, imaginer des classe de « confiance » apparaissant à un niveau ou à un autre de la chaîne. Il n'est pas impossible qu'une application puisse être signée comme ayant le droit d'ouvrir certains types de documents, et pas d'autres. Je n'ai pas lu le détail des spécifications.
Enfin bon, dans tous les cas, pour les virus, oublie; c'est de la propagande marketing ­ et même Microsoft dit bien que ça n'apportera rien à ce niveau. Un système de ce genre n'apporte rien de plus par rapport à un système de protection traditionnel. L'« innovation » de ce système est uniquement de « protéger » un équipement contre ses utilisateurs légitimes, pas contre d'éventuelles attaques externes.

[1]: Noter les guillements, qui traduisent la non-adéquation du terme « confiance ». On peut logiquement considérer que celui qui doit avoir confiance en un équipement ou un logiciel, c'est celui qui en a l'usage, et non des tierces personnes. Ce qui est de confiance pour les uns est déloyal pour les autres.

« queu d'lazik, »
« section rap&rnb »

<troll>Suis-je le seul à voir une oxymore là-dedans? : p</troll>

Vas-y, lâches-toi, dis-le qu'Access c'est une bouse! : )=

*message subliminal et hors-sujet: les [-], c'est lourd*

Pourquoi ne pas garder Copyleft, tout simplement? C'est un double-jeu de mots bien pensé, et même si le terme n'est pas français, il me semble bien plus adapté qu'une traduction bancale, un peu lourde, et qui ne tient pas compte des subtilités du terme original.

Enfin, personnellement, je continuerai à dire Copyleft : )

et fatalement tu tombes dans le privé, et donc dans le non-libre.

Urkh. Grosse confusion, ou bien?

Non, privé n'implique pas non-libre. Les résultats d'une étude scientifique peuvent très bien intéresser des sociétés privées, mais ça ne signifie pas forcément que ledit intérêt est basé sur la possibilité d'exploiter commercialement les licences d'utilisation des logiciels développés au cours de cette étude.

Le problème, c'est uqe dès qu'on attaque un peu le système DLFD ou les news ou les modéros, on passe à -12.

Peut-être est-ce parce que les commentaires des nouvelles ne sont pas l'endroit approprié pour discuter de la modération, et qu'il existe un forum dédié à ce sujet dans DLFP? Enfin, moi, j'dis ça...

Bah, sur Debian, au moins, c'est simple: si c'est utile, ne serait-ce qu'à quelques personnes, c'est inclus (et vive wmc² dans la Debian : ) )

Ceci dit, je te rejoins, longue vie à la Mandrake... Il serait vraiment dommage que Mandrakesoft ne parvienne pas à s'en sortir.

Bah, c'est pas parce qu'il n'est heu, herm... « pas vraiment compétent » en tant que designer web que son rapport doit être considéré comme moins valable... Je suis sûr qu'il y a plein d'excellents webmasters qui sont pas capables de pondre un rapport : )

S'il s'appelle Alfred Dupont, c'est quand même probable qu'il soit français : )

Pas forcément. Ca ne sera vrai que si le fichier enregistré par Word et le fichier enregistré par OOo contiennent les mêmes informations... Or Word, essentiellement dans les versions 97 et antérieures, avait tendance à enregistrer tout un tas de cochonneries absolument pas nécessaires à la lecture du document (notamment, si je ne m'abuse, l'historique d'annulation); ceci étant d'autant plus vrai que, par défaut, l'option « sauvegarde rapide » était activée (j'ai jamais vu en quoi elle était plus rapide, mais ça faisait toujours de fichiers beaucoup plus gros et impossibles à ouvrir avec d'autres logiciels). On pouvait se retrouver ainsi avec des documents d'une vingtaine de pages qui prenaient 20 Mo sur le disque, alors qu'ils auraient pris dans les 100Ko s'ils avaient été enregistrés par OOo.

Ce qui est vrai pour Word 97 ne l'est apparemment plus pour Word 2000, qui semble beaucoup plus propre au niveau de la taille des fichiers. Mais de toutes façons, même si la taille d'un document au format Word compressé est égale ou inférieure à celle d'un document OOo, l'argument d'économie de place reste valable; la compression / décompression du document étant une étape supplémentaire que l'on ne souhaitera pas forcément imposer à l'utilisateur.

Le PDF n'a pas beaucoup d'intérêt, autre que celui d'être présenté sur un media de caractéristiques bien particulières, à savoir une feuille de papier, ou un écran de résolution suffisante. Si le media n'est pas disponible, pas accessible (personnes mal-voyantes par exemple), ou si l'usage souhaité du document est autre que la présentation (l'indexation, l'analyse sémantique, etc), le PDF n'offre guère davantage d'options qu'une grosse image vectorielle représentant le document. (d'ailleurs, finalement, on peut considérer que le PDF _est_ une grosse image vectorielle représentant un document)

Un format décrivant le document en fonction de sa structure logique, et non plus en termes de polices/pages/position/couleur, éventuellement associé à une description de la présentation souhaitable de cette structure logique (il ne faut pas mépriser la présentation non plus, elle a de l'intérêt), serait largement plus approprié. Un document officiel n'est pas une oeuvre d'art où la présentation a valeur sémantique: seule la structure et le contenu du document portent un sens.

En exercice pour le lecteur, donner le nom de formats normalisés qui satisfont à ces objectifs : )