ErrTu a écrit 108 commentaires

Et justement, ils ont bien raison de l'avoir fait.

Au final ça ne reste qu'une méthode alternative pour stocker la clé de chiffrage du disque dur (mais qui est quand même intéressante).

Le TPM n'est pas assez puissant/rapide pour chiffrer le disque tout entier (ben oui, il ne faut pas espérer des miracles pour une puce qui ne coute que quelques dollars), donc il ne chiffre ou stocke que la clé de chiffrage. Celle-ci sera ensuite mise dans la RAM pour que le processeur puisse l'utiliser pour chiffrer/déchiffrer les données.

Dommage car du coup l'ordinateur reste toujours aussi vulnérable aux attaques de type « Cold boot attack »[0].

[0] http://en.wikipedia.org/wiki/Cold_boot_attack

C'est pas comme si les pilotes de TPM existent depuis plusieurs années sous Linux et que le patch d'IBM mettant en œuvre IMA (Integrity Measurment Infrastructure, ce qui permet de pleinement exploiter les TPM) à été intégré dans le noyau[1] dans sa version 2.6.30.

Mais c'est pas demain la veille que l'on verra apparaître des DRM à base de TPM car c'est beaucoup trop complexe. Cela nécessiterait de construire une base complète contenant tous les hash de toutes les configurations d'ordinateurs ainsi que tous les hash de toutes les versions de programmes et bibliothèques qui seraient autorisés à utiliser le média. Ce qui est, on peut le dire, impossible. D'ailleurs, les TPM n'ont pas été conçu pour être utilisé comme DRM à la base.

Déployé correctement, un TPM n'est actuellement utile qu'en entreprise pour autoriser l'accès à une ou plusieurs ressources (le réseau, une base de données, ...) ou pour chiffrer des données, bref ce genre de chose.

En plus l'algorithme SHA-1 s'est pris un coup dans la gueule[2][3] récemment, mettant en doute ça fiabilité. Et tous les TPM se basent entièrement sur cet algorithme...

[1] https://linuxfr.org//2009/06/10/25555.html « Le noyau Linux 2.6.30 est disponible »
[2] http://linuxfr.org/2005/02/16/18319.html « SHA-1 aurait été cassé »
[3] https://linuxfr.org//2009/05/09/25437.html « Nouvelles attaques sur SHA-1 : Debian pourrait migrer vers SHA-2 »

Le « encore » peut se traduire par le fait que le support des webcams est très récent pour OpenBSD (depuis la dernière version, la 4.4) et qu'il y a encore pas mal d'activité de ce côté là dans le dépôt CVS. Ça ne serait pas étonnant de voir apparaitre la prise en charge des webcams des eeepc. Donc il y a espoir (pour les possesseur d'eeepc sous Open au moins) ^^

Mais j'attends avec impatience ta machine à remonter le temps.

Un petit lien vers la page de man pour répondre à ta question :

http://www.openbsd.org/cgi-bin/man.cgi?query=ral&apropos(...)

Et au cas où la carte serait branchée par USB :

http://www.openbsd.org/cgi-bin/man.cgi?query=rum&apropos(...)

Tu sous estimes le boulot des distributions. Sans elles, OpenSSH est mort, au moins virtuellement.

Non, c'est sans OpenBSD qu'OpenSSH est mort. Et encore, le code source étant sous licence ISC/BSD, je vois mal comment un programme de cette qualité peut mourir.

Imagines un instant un autre programme qui remplace OpenSSH et que les distributions majeures n'installent plus OpenSSH ? Crois-tu alors qu'OpenSSH vit encore ?

Parfaitement, il vivra encore, tout comme de nombreux programme vive à l'intérieur de l'arbre des sources d'OpenBSD (apache 1 est le premier exemple qui me vient). Même si un challenger arrive pour le remplacer, tu peux être sûr qu'il sera toujours utilisé et maintenu par les gens d'OpenBSD quoi qu'il arrive.

Au passage xv ni libre ni maintenu, ce qui explique bien des choses.

OpenSSH vit aussi grace aux distributions GNU/Linux. Demander des remerciements et des dons, c'est bien. Mais il faut aussi renvoyer l'ascensseur. Les distributions aident aussi à diffuser et elle font globalement du super boulot, même si elles sont à base Linux et non de BSD. En plus debian est la seule distribution Linux (à ma connaissance) a vouloir faire un port BSD...

OpenSSH vit grâce aux développeurs d'OpenBSD. Les distributions GNU/Linux ne font qu'empaqueter la version portable d'OpenSSH.

La faille d'OpenSSL dans Debian est dû à une erreur du mainteneur du paquet d'OpenSSL . Ça n'a absolument rien à voir avec OpenSSH (mis à part que la bibliothèque est utilisé par ce programme) donc les développeurs d'OpenBSD n'ont absolument aucune raison de communiquer là-dessus. C'est à Debian de le faire.

Tu confonds OpenSSH avec OpenSSL. OpenSSL n'a rien à voir avec OpenBSD mis à part qu'il est utilisé par ce projet.

Ce n'est pas une question de licence. Un projet de la taille d'OpenBSD a besoin de ressources pour fonctionner. L'infrastructure d'OpenBSD ne vit que par les dons et les ventes de CDs qui servent à acheter du matos pour les développeurs qui en ont besoin, financer certains évènements (les « hackatons »), payer la facture d'électricité des serveurs du projets, renouveler les serveurs... Tous ça, ça coûte de sous.

Il est important de le rappeler de temps en temps si les gens veulent que le projet continue (et qu'ils ne l'oublient pas).

En réalité, des TPM, correctement déployés, n'auraient pas pu empêcher l'infection des machines par le ver mais auraient permis de le détecter rapidement (ou au moins voir qu'il se passe quelque chose de louche).

Oui, c'est pas récent mais si on aime l'humour "british" on passera forcément un bon moment. C'est parfois difficile à suivre car il y a un certain nombre de références à des personnalités de l'époque (que je ne connais pas) ou à des choses purement Anglaises, mais ça ne m'empêche pas de bien rigoler. C'est de la "bonne" science-fiction qui couvre pas mal de points SF (voyage dans le temps, créature à la Alien, ...).

Voilà, je recommande chaudement Red Dwarf, un classique.

Je parle pour le cas BSD/GPL. Tu peux choisir de diffuser sous les termes de la licence BSD ou de la licence GPL (au choix) mais en aucun cas tu n'as le droit de supprimer une des licences du code source si tu n'en es pas l'auteur.

De plus Qt n'est pas sous licence GPL mais sous licence GPL + exceptions[0]. Et la version que tu télécharges et que tu utilises est la version entièrement sous licence GPL + exceptions (celle choisie directement en amont donc) et non pas la version doublement licencée GPL(+exceptions)/Proprio.

[0] http://doc.trolltech.com/4.4/license-gpl-exceptions.html

Non ce n'est pas illégal. Le logiciel est doublement licencié donc tu peux choisir quelle licence tu veux utiliser et retirer l'autre.

Non, ce n'est pas aussi simple que ça. Si le code source a été diffusé par son auteur sous une double licence (BSD/GPL), le code modifié doit être lui-même redistribué sous cette même double licence. Seul l'auteur a le droit de changer la licence de son code, et supprimer l'une des deux licences de la double licence revient à changer sa licence.

Dans le cas d'un double licence, on peut choisir quelle licence on décide d'appliquer (on applique les termes de cette licence) et non pas de supprimer la seconde licence.

Quant aux "changements substanciels" qui permettrait de changer la licence : ça n'existe tout simplement pas ! Un code écrit sous une licence reste sous cette licence malgré tous les changement possibles ou imaginables faits à ce code, sauf si le code source est réécrit (ou que la licence le permet, ce qui n'est pas le cas de la BSD ni de la GPL).

Ca te pose pas de pb de savoir que personne ne se preoccupe de determiner le besoin de l'utilisateur?

Dans une grande majorité des cas, les projets de logiciels libres sont réalisés parce que des développeurs ont eu un besoin à un moment donné et que les solutions alternatives ne leurs convenaient pas. Du coup ils se sont retroussés les manches et ont commencer à développer. Après les utilisateurs dans tout ça... c'est pas le plus important.

Parce que le .tex n'est pas le document final, et qu'avoir un document final version N montrant ce qui a disparu et apparu depuis la version N-1 est agréable ?

C'est le rôle de ton "front-end" à ton système de gestion de versions ou à ton éditeur de fichier de faire ça, pas au langage de description de document en lui-même.

(Les systèmes de type UNIX avaient un courant de pensée à une époque dont je me souvient plus très bien... mais je crois que ça se résumait à "KISS".)

RCS n'est qu'un outil avec ces commandes (co, ci, ...), et un format de fichier. Pour le contrôle de version, LyX n'est qu'un "front-end" à cet outil. S'il est bien intégré, on n'y voit probablement que du feu.

Mais pourquoi vouloir rajouter des macros à LaTeX pour contrôler les versions d'un document alors qu'un outil externe le fera nettement mieux. Rajouter des macros de cette sorte ne fera qu'alourdir le langage et le rendre plus difficile à utiliser qu'il ne l'est déjà, sans rien vraiment apporter.

Et puis bon RCS marche très bien et existe depuis plus de 20 ans.
Les bus aussi. Et pourtant il y a des gens qui utilisent encore des moto. Dingue non.
Euh j'essaye toujours de comprendre ton analogie entre un bon vieux logiciel de contrôle de version simple et efficace, et des véhicules...

J'aime beaucoup le "il suffit".

Dans la même veine, "il suffit de faire latex 2.0 qui prenne en compte toutes ces contraintes".
Ben oui, "il suffit de".

Comme quoi je n'avais pas tord, des gens l'ont déjà fait pour toi. Lyx gère le contrôle de version par RCS (comme notifié dans le commentaire de mats un peu plus haut).

Par contre tu es en retard sur le LaTeX 2.0, on l'utilise déjà. Non le futur, c'est LaTeX 3.0 que l'on ne verra probablement jamais^W pas avant longtemps.

Non, LaTeX n'a pas été conçu pour ressembler à office/ooo (ou c'est l'inverse, je ne sais plus). Donc jamais, au grand jamais, on ne pourra pas éditer de fichier .tex avec vi.

Et puis bon RCS marche très bien et existe depuis plus de 20 ans. Après il suffit juste d'écrire un bon éditeur LaTeX (ou de modifier un existant) pour qu'il prenne en charge les fichiers RCS et le tour est joué.

Et même sans aller jusqu'à faire l'effort de programmer ou de financer un tel éditeur, je suis sûr que quelque part sur le net on doit pouvoir trouver des programmes qui me font une belle mise en forme et me permettent de facilement naviguer dans l'historique du fichier (ah oui... par exemple et complètement au hasard un TWiki).

3°) ce qui manque aussi à latex est, amha, un systeme de "versionning". Avec word/ooo on peut transmettre un document et savoir qui a modifié quoi, ce qui est quelque chose d'intéressant quand on est plusieurs (et pas dans le même bureau, ni dans la même boite) à travailler sur le document.

Le "versionning" n'a rien à faire dans latex. Il y a RCS (ou équivalent) pour ça.

Plus sérieusement:
Moi, ce que je ne comprends toujours pas, c'est pourquoi X ne peut pas utiliser la configuration du clavier proposée par le système:
- un "wrapper" standard pour mapper le clavier
- chaque OS se débrouille pour développer l'interface avec sa gestion clavier sous-jacente, pas de problème de "marche que pour Linux, et les BSD alors? etc."

Je ne sais pas en ce qui concerne les autres variantes BSD, mais OpenBSD fait ça. Grâce à l'infrastructure wscons(4) ( http://www.openbsd.org/cgi-bin/man.cgi?query=wscons&sekt(...) ) et à un petit patch intégré à Xenocara (Xorg avec des patchs).

Du coup, un petit "echo fr > /etc/kbdtype" et pouf on a un clavier azerty dans la console et dans Xorg sans avoir à toucher quoi que ce soit d'autre (en virant éventuellement le fichier xorg.conf qui ne vous sert probablement à rien).

Mais bon ça ne fait que détecter la disposition clavier et sa variante de la console pour trouver l'équivalente dans les /etc/X11/xkb/symbols/* d'Xorg. Mais c'est déjà pas mal.

echo fr.dvorak > /etc/kbd
Pour être exact, c'est "echo fr.dvorak > /etc/kbdtype" et non pas "echo fr.dvorak > /etc/kbd". kbd(8), c'est le programme pour changer de disposition clavier à la main.

Sous OpenBSD, Il n'y a pas d'hal (et tout le bordel qui va avec) du coup, c'est beaucoup plus simple à configurer.

J'ai créé un fichier "/etc/X11/xkb/symbols/pc/bepo" qui contient quelque chose du genre :
partial alphanumeric_keys
xkb_symbols "bepo" {
// ma disposition personnelle des touches...
};

Et ensuite pour utiliser automatiquement cette disposition, je modifie le fichier "/etc/X11/xdm/Xsetup_0" d'XDM en y ajoutant:
setxkbmap bepo &

C'est une solution parmi tant d'autres.

En revanche sous OpenBSD, il doit être possible de charger la disposition bépo sans à avoir à modifier le fichier xorg.conf ou les fichiers de configuration de XDM (comme je fais ici), car l'xorg d'OpenBSD détecte automatiquement la disposition clavier de la console et l'applique au serveur X. Pour ce faire il faut utiliser le clavier bépo en mode console :
echo fr.dvorak > /etc/kbd
et mettre sa disposition de clavier dans le fichier "/etc/X11/xkb/symbols/pc/fr" avec pour nom de variante "dvorak" (et non pas "bepo").

Au pire, il y a toujours "Loki installers for linux gamers" qui permet d'installer facilement certains jeux : http://www.liflg.org/?catid=6

Toujours pas de prise en charge du Dom0 de Xen dans cette nouvelle version. Mais vu la masse de travail qu'ont fait les développeurs, on verra probablement le retour du Dom0 dans F11 en utilisant les paravirt_ops inclus dans le noyau.

paravirt_ops permettra de soulager grandement la tâche des développeurs de Xen qui doivent actuellement porter leurs changements d'une version du noyau à une autre... Et cela soulagera aussi les utilisateurs qui ne seront plus bloqués à la version 2.6.18.x.

Sauf qu'au final la plupart des specs sont écrites par Peter Saint-André, ce qui pour moi est vraiment un gros problème. D'accord il est payé pour faire ça, mais le jour où Jabber, Inc. Cisco ne veut plus le payer ça va ralentir encore plus le processus.

En même temps, sans Peter Saint-André, je doute que le protocole soit aussi avancé que ce qu'il est maintenant.