à mon avis (de non expert, je note bien), je trouve normal la non-adoption de ces mécanismes de sécurité par défaut dans la plupart des distributions. Si on regarde bien, les configurations par défaut (je parle du noyau là) sont assez génériques et cherchent à répondre à un grand panel de besoins différents. Mon impression jusqu'à présent est que la politique est la suivante : "on donne un noyau qui marche correctement, avec une majorité de configurations (matérielles), sans trop de compromis d'un point de vue performances".
Si on était amené à faire un sondage auprès des utilisateurs linux, je pense que l'on serait surpris de voir un grand pourcentage de personnes travaillant avec le noyau "basique" proposé par leur distribution favorite, et ce malgré le fait que bon nombre des utilisateurs linux ont souvent un certain bagage informatique qui leur permettrait de se lancer dans une recompilation du noyau.
Il faut rajouter à ça qu'une simple activation de SELinux ne suffit pas. Il faut chercher à comprendre ce que propose ce mécanisme et comment le configurer correctement, ce qui n'est ni à la portée de tous, ni jugé nécessaire par la majorité des utilisateurs Linux. Ainsi, on risquerait fort de donner une fausse impression de sécurité en posant une configuration "générique" de SELinux par défaut, ce qui est encore plus dangereux que ne rien mettre du tout à mon avis.
Donc pour répondre à ta question, je pense que c'est un choix réfléchi que de ne pas activer ces options de sécurité par défaut. Comme pour toute chose dans les distributions Linux (celles que je connais du moins), on laisse le choix à l'administrateur de faire ce qu'il veut avec sa machine. S'il est suffisament compétent pour activer et paramétrer SELinux, il le fera de lui-même, et bien mieux que toute configuration préfabriquée.
Vu comme ça oui, en effet ça peut paraître étrange. Mais à mon avis, l'insertion d'un code protégé par brevet est plus probable que tu le présentes. L'un des objectifs de l'accord est également de s'échanger des informations techniques pour permettre une meilleure interopérabilité entre produits M$ et libres.
Ce que je veux donc dire, c'est que pour le libre, le second cas est plus nuisible. Parce que si justement du code "inspiré" par celui de M$ se retrouve (par Novell) dans un projet libre, ce dernier pourrait un jour être en difficulté. Certes, je ne dis pas que c'est la fin du monde, mais cette dernière année, M$ parle de plus en plus de brevets. Intimidation non fondée ? Peut-être, mais ça n'empêche, il y a un certain flou dans cette affaire là qui n'est pas bénéfique au libre.
De l'autre côté, Tivo ne fait du "mal" qu'aux personnes qui veulent modifier et jouer avec leur appareil. Rien qu'en regardant le nombre de concernés, il y a une différence majeure entre les deux cas.
L'idéal serait de ne pas avoir à faire à ce genre de situations, mais si je devais choisir, la seconde m'inquiéterait plus...
Ils l'autorisent, mais la Freebox est inutilisable puisque une signature du firmware est normalement envoyée au DSLAM... Enfin du moins je crois. Quoi qu'il en soit, une freebox traffiquée n'est (ou ne sera) pas admise sur le réseau de Free...
Est-ce que la GPLv3 interdira tout dispositif qui empêche le fonctionnement correct d'un appareil avec firmware modifié, ou elle se focalise juste sur un problème de boot ?
A mon avis, entre les deux, je pense que c'est Novell à qui j'en voudrai le plus. Tivo exploite une "faille" de la GPLv2, certes, mais au moins on a accès au code source. Tout ce qu'on ne peut pas faire, c'est bidouiller l'appareil.
Par contre, Novell, comme tu le soulignes parfaitement (et je dirai même que t'es un brin trop critique là-dessus) contribue beaucoup au libre: mono, openoffice, samba, opensuse, etc. De plus ils sont membre à grande part du Open Invention Network, que du bon jusque là. Seulement, cet accord justement, comme il a été discuté moultes fois après son annonce ne protège que les clients de Novell, comme l'avait répété au moins à 2 reprises Ballmer qui reprenait les représentants de Novell. Ceci pourrait (je dis bien pourrai) mener à une inclusion de code protégé par un brevet de M$ dans un outil libre, modification qui serait après ramenée au projet principal, accessible à tous...
Si ceci est envisageable à court tèrme, à la longue ils se retrouveront avec des versions archaïques des outils en question et devront par eux-même s'amuser à les mettre à jour, sans pouvoir profiter du code sous GPLv3...
Il est question ici d'une vérification ayant lieu sur la machine même n'autorisant pas de booter un binaire modifié.
Dans le cas de Free, le code source est disponible (plus ou moins, je n'ai personnellement pas trop cherché, mais il me semble qu'on peut trouver presque tout ce qu'il faut sur les ftp de Free), mais je me souviens avoir lu il y a à peu près un an, un responsable de Free annoncer qu'il n'accepterait aucune Freebox avec firmware traffiqué sur le réseau de Free.
Bien que je comprenne son point de vue (la sécurité du réseau par exemple), n'est-ce pas un cas plus ou moins similaire avec celui de Tivo ? Ou bien, le fait que la vérification de la signature soit faites par le DSLAM fait qu'on ne tombe pas dans le même cas ?
Non pas que ça m'intéresse particulièrement de pouvoir modifier le firmware de la Freebox (je n'en ai même pas), mais c'était juste pour voir si Free aurait aussi à faire à ce genre de problème une fois la GPLv3 adoptée ?
Après lecture de l'article, je dois avouer que je suis perplexe. Pourquoi donc la présence d'un client de téléphonie IP quand aucune fonctionnalité réseau (wifi par exemple) n'est indiquée.
Il semblerait donc que wizpy contient une distribution linux basée sur turbolinux qui peut-être chargée sur un PC ! Donc tout ceci concerne ce que l'on peut faire une fois le (la ?) wizpy branché(e) sur un PC et non pas le lecteur multimédia même...
Alors là, je ne peux que te remercier infiniment :). Peut-être que je n'utiliserai pas sshfs pour écouter ma musique (c'est légèrement bourrin, puis pour une raison qui m'échappe, la connexion n'est pas terrible, bien que les deux machines soient connectées à un même réseau [certes il est très grand, mais bon, tout de même, du 50 ko/s c'est étrange]) mais c'est fort pratique...
en fait je viens d'acheter mon macbook, donc c'est un intel core 2 duo, et la carte airport utilise un chipset légèrement différent qui n'est pas encore supporté par madwifi : http://madwifi.org/ticket/1001
Il est possible apparemment d'utiliser ndiswrapper et un pilote pour une carte wifi DLINK, mais j'ai choisi d'installer un distribution AMD64, hors pour l'instant pas de pilotes 64bits.
En gros, soit madwifi supporte ma carte assez tôt, soit je profite de la sortie de vista pour (éventuellement) pouvoir décrocher un pilote là-bas (mais quelque chose me dit que là je rêve)...
Bien que ça réponde en tout point à mon problème (même pour l'autentification apparemment), je pense que je vais suivre cette voie que si l'option mpd+icecast ne fonctionne pas, puisqu'il s'agit là d'un protocole propriétaire, donc si je peux faire avec du libre, pourquoi pas.
Mon avis personnel est que les gains d'Ubuntu se feront (du moins en un premier temps) surtout grâce à la distribution pour serveurs et au support proposé.
Après avoir regardé la séance sur Ubuntu lors de la 6e debconf ( http://ftp.acc.umu.se/pub/debian-meetings/2006/debconf6/theo(...) pour ceux qui veulent), suite à une question sur l'éventuelle libération du code de Launchpad et si celle-ci se ferait bientôt, la réponse était "oui et non". En fait, l'argument de Shuttleworth est qu'à présent Canonical propose les services de Launchpad aux entreprises/organismes qui veulent travailler sur une variante d'Ubuntu, et que ceux-ci sont payants... Ceci dit, il ajoute que ce modèle ne s'appliquera pas d'ici quelques années et qu'il sera donc à ce moment là tout à fait possible, et viable, de libérer le code...
Je n'ai pas comparé Ubuntu à Novell, donc me dire que le dernier contribue grandement me fait croire que tu n'as pas lu mon commentaire. Qui plus est, ce sont deux choses incomparables rien qu'en tèrme de temps de présence sur le marché. Je n'ai pas d'idée du nombre d'employés au bout de deux ans de fonctionnement, mais à l'époque le marché était totalement différent, Red Hat est un des pionniers en tèrme de distribution linux, comme Suse si je ne m'abuse.
Quoi qu'il en soit, je ne compare pas la contribution de Shuttleworth à un autre acteur du libre. Je dis juste qu'il contribue lui aussi. Des termes comme "starlette", "Shuttlenoworthy", "MS" (qui est 3 fois sur 4 utilisé afin de faire le rapprochement à une boîte que je n'ai pas besoin de nommer) n'ont pas leur place ici et n'apportent rien de constructif à une discussion.
De plus, en ce qui concerne debian, peut-être que certains problèmes apparaissent, mais debian profite également de corrections de bugs qui peuvent être faites d'abord chez ubuntu, de nouveaux paquets n'étant pas dans sid mais dans ubuntu sont intégrées plus facilement/rapidement, etc. Si Ubuntu et Debian semblaient avoir des soucis il y a un an, je pense que les différences entre les membres des deux projets tendent à diminuer. La présence de Shuttleworth dans les deux dernières Debconf montrent bien que certaines personnes font l'effort de voir un peu plus loin et ne se content pas de critiques faciles. Pour les intéressés, la séance Ubuntu dans la dernière debconf : http://meetings-archive.debian.net/pub/debian-meetings/2006/(...) (ogg theora).
C'est drôle, j'avais l'impression pourtant d'avoir copié le dernier paragraphe de son mail qui disait justement qu'il ne fallait pas se focaliser sur ubuntu, d'autres distributions (gentoo,debian...) pouvant profiter de l'aide des développeurs openSUSE qui voudrait quitter ce projet. Je ne dis pas qu'il faut le croire les yeux fermés, mais ceci dit il faudrait pas non plus à chaque fois que l'on voit le nom Shuttleworth râler bêtement...
Pour ma part, je n'étais pas au courant de Launchpad, donc j'ai cherché un peu, et miracle :
Is Launchpad open source? Will it be?
Our goal is to release all of Launchpad as free software, though it will take some time (potentially, years) before that happens.
We are doing so in a piecemeal approach. Parts of Launchpad have already been released as free software where they would be particularly useful to other projects. And very few, if any, Launchpad modifications to upstream code are not immediately published to those upstream projects.
Launchpad is a large, monolithic, web application. We would be happy to release the code for the Registry, for example, which keeps track of all upstream products and their series and releases; however, that code will not run without the distribution management code, which is part of of the service that Canonical provides to other companies that make their own distributions.
If you are keen on seeing Launchpad components published as free software sooner, rather than later, and you have good Python and Zope3 skills, we are happy to provide code access and accept patches that use Zope 3's component architecture to factor out individual Launchpad applications and make it easier to release chunks of Launchpad. That is a lot of hard work, but it would make it possible to release the Registry, and the parts of Rosetta that are used for upstream translation.
source : https://launchpad.net/faq
Certes, entre le dire et le faire... c'est pas gagné, mais moi ce que je lis là (SANS de quelconques préjugés) c'est un "engagement" et une volonté de "libérer" le code... Donc je me pose des questions sur le temps qu'ont vraiment passé tous ces gens qui ne font que ressortir cet "argument" à s'informer sur le sujet...
Pour les pilotes propriétaires, lire quelques commentaires ci-dess(o)us...
Il faut cesser de critiquer gratuitement la moindre personne qui ne suit pas les "règles" du libre au moindre détail. En tant qu'observateur extérieur, moi ce que je vois c'est que Shuttleworth contribue de manière plus positive que négative dans le libre, en proposant une alternative abordable à windows. C'est une étape intermédiaire à mon avis qui est nécessaire pour faciliter la transition du 100% propriétaire au libre complet.
Plutôt donc que de s'attaquer à lui pour ses moindres propos, laissons-lui la chance de nous aider un peu à sa façon (à la limite du raisonnable bien évidemment, si du jour au lendemain ubuntu se voit surchargée de logiciels propriétaires, je serai moins indulgent).
Puis si certains voient en ce gars là [...] un ancien gros acteur du monde des logiciels propriétaires, moi je suis optimiste, et le fait qu'il soit à présent un gros acteur du libre (à sa façon, qui peut déplaire, mais sur laquelle il ne faut pas cracher) est signe que finalement, c'est peut-être un allié plus qu'un ennemi...
Je suis d'accord avec toi sur le 100% libre. J'avoue, je n'y suis pas encore (flash, nvidia) mais plus pour longtemps...
Par contre, je pense qu'il y a un point positif qu'il ne faut pas négliger avec ubuntu. Je connais pas mal de personnes qui s'aventurent pour la première fois avec linux et le choix de distribution est à priori vite fait. Et à priori le libre ça n'intéresse pas autant de personnes.
Ceci dit je pense qu'avec le temps, en ayant un contact continu avec les LL ils seront plus sensibles, ou du moins comprendront beaucoup plus l'enjeu et l'intérêt d'une distribution 100% libre. Qui plus est, il sera plus facile de convaincre les entreprises écrivant des pilotes de les distribuer sous une licence open-source.
Ceci dit, il ne faudrait pas non plus que l'on continue à accepter de plus en plus de logiciels/pilotes propriétaires dans le futur. Il faudra pouvoir définir une barrière à ne pas dépasser...
Hmm, openSuse est supposée aussi être une distribution sans business model. La comparer à RedHat aurait été injuste (on devrait plutôt comparer Novell Suse Enterprise aux produits de RedHat).
...prenez le temps de lire le message de Shuttleworth et surtout le dernier paragraphe :
I know that posting this message to an OpenSUSE list will be
controversial. I'm greatly respectful of the long tradition of
excellence in the SuSE product and community and have no desire to
undermine that with this post. That said, I think the position taken by
Novell leadership in their contract with Microsoft is hugely
disrespectful of the contributions of thousands of GPL programmers and
contributors to SuSE, and I know that many are looking for a new place
to get involved that is not subject to the same arbitrary executive
intervention. Ubuntu is one option, as are Gentoo, Debian and other
communities. Please accept this mail in that spirit.
Je ne sais pas si c'est le meilleur moyen de s'y prendre, mais ceci dit il n'a pas entièrement tort.
Je crois que les propos relevés ci-dessus s'adressaient surtout à des applications, pas à Linux même.
Ballmer s'attaque là à Linux directement, pas Mono, Samba ou autre application. Et c'est sur ce point précis que répond Mono dans le communiqué d'hier.
Ceci dit, pour un accord qui a été préparé pendant 6 long mois, la formulation aurait pu être plus correcte pour éviter ce genre de "flous". Pour ma part ce communiqué ne change pas le fait qu'on devra dans les années à venir payer une attention particulière à tout ce qui vient de Novell.
Un communiqué à l'intention de la communauté du libre de la part de Novell qui dit que les propos de Ballmer sont déplacés, et que l'accord entre Novell et M$ ne signifie en aucun cas qu'ils reconaissent/acceptent la présence de code dans linux qui porte atteinte à la propriété intelectuelle de M$ : http://www.novell.com/linux/microsoft/community_open_letter.(...)
L'article en question ne fait pas référence à la réponse de Redhat à l'invitation de M$ (visiblement cette dernière l'a contactée). Je n'ai plus l'article sous la main, mais ceci devrait faire l'affaire : http://www.redhat.com/promo/believe/
Pourquoi ? (c'est une vraie question, j'apprends le Perl actuellement et j'aimerai en savoir plus) Est-il possible de créer un exécutable ? J'avais cru lire quelque chose sur un présumé perlcc, mais est-ce que celà fonctionne vraiment ? Et est-ce que c'est réellement utilisé ?
A lire les commentaires qui ont été fait jusque là et à voir les choix des lecteurs (article du Monde: 679 hits, abstract de l'article scientifique 208 et article même 279), je dois avouer que l'article (de linuxfr) a été posté et accepté trop tôt...
Que dire quand on lit : "La technique découverte par Jean-Pierre Seifert consiste à analyser le comportement du processeur lui-même afin de déduire statistiquement la clé de chiffrement."
quand le résumé de l'article initial dit très clairement : "a Simple Branch Prediction Analysis (SBPA) attack --- sharply differentiating it from those one relying on statistical methods"
Du coup on lit des commentaires parlant de timing attack, que c'est pas nouveau, quand le résumé de l'article dit : "The successful extraction of almost all secret key bits by our SBPA attack against an openSSL RSA implementation proves that the often recommended blinding or so called randomization techniques to protect RSA against side-channel attacks are, in the context of SBPA attacks, totally useless."
En bref, beaucoup trop de commentaires qui s'acharnent sur l'exagération des conséquences de la méthode, etc. quand visiblement ils n'ont pas pris la peine de lire, ne serait-ce que le résumé de l'article SCIENTIFIQUE. Ne me parlez pas du Monde, depuis quand un journal est-il une référence absolue en tèrmes d'avancées/résultats scientifiques si récents (mi-octobre 2006) et si pointus (d'ailleurs, ne prenez-vous jamais le temps de regarder une autre source d'information que la première qui vous tombe sous la main pour des sujets autres que l'informatique ?) ?!
Ne pas lire entre mes phrases pour essayer de dicerner un avis quelconque sur la compétence de la méthode : je ne suis pas là pour faire son éloge (ou la critiquer d'ailleurs), pour la simple et bonne raison que je sais et je le dis, moi, que je n'ai pas les connaissances nécessaires pour pouvoir en tirer une conclusion. Ceci n'empêche que je ne vais pas cracher non plus dessus, par simple respect des personnes qui ont travaillé dessus et qui ont pris la peine de pointer une (éventuelle) faille.
Plutôt que de crier au ridicule et à la paranoïa exagérée d'un journaliste (encore que vous oubliez de le mentionner, on pourrait presque croire que vous donnez un avis sur la méthode), concentrez-vous plutôt sur le sujet même. Et cher(s) rédacteur(s)/rédactrices (d'articles sur linuxfr j'entends), un grand merci pour votre contribution (franchement), mais je vous en prie, évitez dans l'avenir de paraphraser un article comme celui proposé par le Monde.
D'autant plus que il me semble que l'article n'aborde pas le probleme d'execution concurente
En effet, c'est l'un des deux points qui me sont flous. Dans la section 2.3 ils disent qu'ils ne pousseront pas l'analyse trop loin et simplifient le problème. Ceci dit, ils font référence à d'autres articles qui pourraient éventuellement répondre à ces questions. J'ai jeté un coup d'oeil rapide à l'un d'entre eux ( [OST06] dans les références de l'article), mais il me semble que ce ne soit pas le bon, puis franchement, j'avais pas le temps :).
Donc oui ce n'est pas dans une semaine qu'on va apprendre qu'amazon doit changer de certificat parce que quelqu'un a la clé privée, mais ceci dit j'ai tendance à croire que les barrières sont beaucoup plus faibles à présent. Si un système cryptographique ne tient sa force qu'au fait qu'on ne peut pas savoir quand est-ce que le processus de (dé)chiffrement tourne, c'est à priori loin d'être rassurant.
Quoi qu'il en soit, l'article du Monde est tout à fait déplacé. Ce serait vraiment bien que les gens cessent d'y faire référence et d'extrapoler leurs critiques sur l'article scientifique même.
[^] # Re: Pourquoi une option ?
Posté par Alexis P. (site web personnel) . En réponse à la dépêche Dossier sur le renforcement des fonctions de sécurité du noyau sur Secuobs.com. Évalué à 4.
à mon avis (de non expert, je note bien), je trouve normal la non-adoption de ces mécanismes de sécurité par défaut dans la plupart des distributions. Si on regarde bien, les configurations par défaut (je parle du noyau là) sont assez génériques et cherchent à répondre à un grand panel de besoins différents. Mon impression jusqu'à présent est que la politique est la suivante : "on donne un noyau qui marche correctement, avec une majorité de configurations (matérielles), sans trop de compromis d'un point de vue performances".
Si on était amené à faire un sondage auprès des utilisateurs linux, je pense que l'on serait surpris de voir un grand pourcentage de personnes travaillant avec le noyau "basique" proposé par leur distribution favorite, et ce malgré le fait que bon nombre des utilisateurs linux ont souvent un certain bagage informatique qui leur permettrait de se lancer dans une recompilation du noyau.
Il faut rajouter à ça qu'une simple activation de SELinux ne suffit pas. Il faut chercher à comprendre ce que propose ce mécanisme et comment le configurer correctement, ce qui n'est ni à la portée de tous, ni jugé nécessaire par la majorité des utilisateurs Linux. Ainsi, on risquerait fort de donner une fausse impression de sécurité en posant une configuration "générique" de SELinux par défaut, ce qui est encore plus dangereux que ne rien mettre du tout à mon avis.
Donc pour répondre à ta question, je pense que c'est un choix réfléchi que de ne pas activer ces options de sécurité par défaut. Comme pour toute chose dans les distributions Linux (celles que je connais du moins), on laisse le choix à l'administrateur de faire ce qu'il veut avec sa machine. S'il est suffisament compétent pour activer et paramétrer SELinux, il le fera de lui-même, et bien mieux que toute configuration préfabriquée.
[^] # Re: Ce que les industriels (TiVO, Novell, MS) pensent du libre
Posté par Alexis P. (site web personnel) . En réponse à la dépêche GPL3, TiVo ou TiVo pas ?. Évalué à 2.
Ce que je veux donc dire, c'est que pour le libre, le second cas est plus nuisible. Parce que si justement du code "inspiré" par celui de M$ se retrouve (par Novell) dans un projet libre, ce dernier pourrait un jour être en difficulté. Certes, je ne dis pas que c'est la fin du monde, mais cette dernière année, M$ parle de plus en plus de brevets. Intimidation non fondée ? Peut-être, mais ça n'empêche, il y a un certain flou dans cette affaire là qui n'est pas bénéfique au libre.
De l'autre côté, Tivo ne fait du "mal" qu'aux personnes qui veulent modifier et jouer avec leur appareil. Rien qu'en regardant le nombre de concernés, il y a une différence majeure entre les deux cas.
L'idéal serait de ne pas avoir à faire à ce genre de situations, mais si je devais choisir, la seconde m'inquiéterait plus...
[^] # Re: Et le cas de Free ?
Posté par Alexis P. (site web personnel) . En réponse à la dépêche GPL3, TiVo ou TiVo pas ?. Évalué à 1.
Est-ce que la GPLv3 interdira tout dispositif qui empêche le fonctionnement correct d'un appareil avec firmware modifié, ou elle se focalise juste sur un problème de boot ?
[^] # Re: Ce que les industriels (TiVO, Novell, MS) pensent du libre
Posté par Alexis P. (site web personnel) . En réponse à la dépêche GPL3, TiVo ou TiVo pas ?. Évalué à 2.
Par contre, Novell, comme tu le soulignes parfaitement (et je dirai même que t'es un brin trop critique là-dessus) contribue beaucoup au libre: mono, openoffice, samba, opensuse, etc. De plus ils sont membre à grande part du Open Invention Network, que du bon jusque là. Seulement, cet accord justement, comme il a été discuté moultes fois après son annonce ne protège que les clients de Novell, comme l'avait répété au moins à 2 reprises Ballmer qui reprenait les représentants de Novell. Ceci pourrait (je dis bien pourrai) mener à une inclusion de code protégé par un brevet de M$ dans un outil libre, modification qui serait après ramenée au projet principal, accessible à tous...
Et là, c'est le bad...
[^] # Re: Le pistolet sur la tempe
Posté par Alexis P. (site web personnel) . En réponse à la dépêche GPL3, TiVo ou TiVo pas ?. Évalué à 2.
A mon avis, c'est un cul de sac...
# Et le cas de Free ?
Posté par Alexis P. (site web personnel) . En réponse à la dépêche GPL3, TiVo ou TiVo pas ?. Évalué à 1.
Dans le cas de Free, le code source est disponible (plus ou moins, je n'ai personnellement pas trop cherché, mais il me semble qu'on peut trouver presque tout ce qu'il faut sur les ftp de Free), mais je me souviens avoir lu il y a à peu près un an, un responsable de Free annoncer qu'il n'accepterait aucune Freebox avec firmware traffiqué sur le réseau de Free.
Bien que je comprenne son point de vue (la sécurité du réseau par exemple), n'est-ce pas un cas plus ou moins similaire avec celui de Tivo ? Ou bien, le fait que la vérification de la signature soit faites par le DSLAM fait qu'on ne tombe pas dans le même cas ?
Non pas que ça m'intéresse particulièrement de pouvoir modifier le firmware de la Freebox (je n'en ai même pas), mais c'était juste pour voir si Free aurait aussi à faire à ce genre de problème une fois la GPLv3 adoptée ?
# Petite correction
Posté par Alexis P. (site web personnel) . En réponse à la dépêche Deux nouveaux produits embarqués sous Linux !. Évalué à 6.
Il semblerait donc que wizpy contient une distribution linux basée sur turbolinux qui peut-être chargée sur un PC ! Donc tout ceci concerne ce que l'on peut faire une fois le (la ?) wizpy branché(e) sur un PC et non pas le lecteur multimédia même...
[^] # Re: SSHFS + mac
Posté par Alexis P. (site web personnel) . En réponse au message Ecouter de la musique qui se trouve sur un PC distant. Évalué à 1.
Une fois de plus, merci ;).
[^] # Re: Wifi aiport
Posté par Alexis P. (site web personnel) . En réponse au message Ecouter de la musique qui se trouve sur un PC distant. Évalué à 1.
en fait je viens d'acheter mon macbook, donc c'est un intel core 2 duo, et la carte airport utilise un chipset légèrement différent qui n'est pas encore supporté par madwifi : http://madwifi.org/ticket/1001
Il est possible apparemment d'utiliser ndiswrapper et un pilote pour une carte wifi DLINK, mais j'ai choisi d'installer un distribution AMD64, hors pour l'instant pas de pilotes 64bits.
En gros, soit madwifi supporte ma carte assez tôt, soit je profite de la sortie de vista pour (éventuellement) pouvoir décrocher un pilote là-bas (mais quelque chose me dit que là je rêve)...
Entre temps, OS X fera l'affaire.
[^] # Re: DAAP
Posté par Alexis P. (site web personnel) . En réponse au message Ecouter de la musique qui se trouve sur un PC distant. Évalué à 1.
[^] # Re: MPD+Icecast
Posté par Alexis P. (site web personnel) . En réponse au message Ecouter de la musique qui se trouve sur un PC distant. Évalué à 1.
J'y jette un coup d'oeil, ça a l'air prometteur...
[^] # Re: samba ?
Posté par Alexis P. (site web personnel) . En réponse au message Ecouter de la musique qui se trouve sur un PC distant. Évalué à 1.
[^] # Re: Avant de lancer des critiques "gratuites"...
Posté par Alexis P. (site web personnel) . En réponse à la dépêche Mark Shuttleworth invite les développeurs OpenSUSE à rejoindre Ubuntu et suscite la polémique. Évalué à 2.
Après avoir regardé la séance sur Ubuntu lors de la 6e debconf ( http://ftp.acc.umu.se/pub/debian-meetings/2006/debconf6/theo(...) pour ceux qui veulent), suite à une question sur l'éventuelle libération du code de Launchpad et si celle-ci se ferait bientôt, la réponse était "oui et non". En fait, l'argument de Shuttleworth est qu'à présent Canonical propose les services de Launchpad aux entreprises/organismes qui veulent travailler sur une variante d'Ubuntu, et que ceux-ci sont payants... Ceci dit, il ajoute que ce modèle ne s'appliquera pas d'ici quelques années et qu'il sera donc à ce moment là tout à fait possible, et viable, de libérer le code...
[^] # Re: Shuttleworse
Posté par Alexis P. (site web personnel) . En réponse à la dépêche Mark Shuttleworth invite les développeurs OpenSUSE à rejoindre Ubuntu et suscite la polémique. Évalué à 3.
Quoi qu'il en soit, je ne compare pas la contribution de Shuttleworth à un autre acteur du libre. Je dis juste qu'il contribue lui aussi. Des termes comme "starlette", "Shuttlenoworthy", "MS" (qui est 3 fois sur 4 utilisé afin de faire le rapprochement à une boîte que je n'ai pas besoin de nommer) n'ont pas leur place ici et n'apportent rien de constructif à une discussion.
De plus, en ce qui concerne debian, peut-être que certains problèmes apparaissent, mais debian profite également de corrections de bugs qui peuvent être faites d'abord chez ubuntu, de nouveaux paquets n'étant pas dans sid mais dans ubuntu sont intégrées plus facilement/rapidement, etc. Si Ubuntu et Debian semblaient avoir des soucis il y a un an, je pense que les différences entre les membres des deux projets tendent à diminuer. La présence de Shuttleworth dans les deux dernières Debconf montrent bien que certaines personnes font l'effort de voir un peu plus loin et ne se content pas de critiques faciles. Pour les intéressés, la séance Ubuntu dans la dernière debconf : http://meetings-archive.debian.net/pub/debian-meetings/2006/(...) (ogg theora).
Un autre lien intéressant, un petit questionnaire fait à Shuttleworth : http://interviews.slashdot.org/article.pl?sid=05/04/04/18592(...)
[^] # Re: Shuttleworse
Posté par Alexis P. (site web personnel) . En réponse à la dépêche Mark Shuttleworth invite les développeurs OpenSUSE à rejoindre Ubuntu et suscite la polémique. Évalué à -2.
Pour ma part, je n'étais pas au courant de Launchpad, donc j'ai cherché un peu, et miracle :
source : https://launchpad.net/faq
Certes, entre le dire et le faire... c'est pas gagné, mais moi ce que je lis là (SANS de quelconques préjugés) c'est un "engagement" et une volonté de "libérer" le code... Donc je me pose des questions sur le temps qu'ont vraiment passé tous ces gens qui ne font que ressortir cet "argument" à s'informer sur le sujet...
Pour les pilotes propriétaires, lire quelques commentaires ci-dess(o)us...
Il faut cesser de critiquer gratuitement la moindre personne qui ne suit pas les "règles" du libre au moindre détail. En tant qu'observateur extérieur, moi ce que je vois c'est que Shuttleworth contribue de manière plus positive que négative dans le libre, en proposant une alternative abordable à windows. C'est une étape intermédiaire à mon avis qui est nécessaire pour faciliter la transition du 100% propriétaire au libre complet.
Plutôt donc que de s'attaquer à lui pour ses moindres propos, laissons-lui la chance de nous aider un peu à sa façon (à la limite du raisonnable bien évidemment, si du jour au lendemain ubuntu se voit surchargée de logiciels propriétaires, je serai moins indulgent).
Puis si certains voient en ce gars là [...] un ancien gros acteur du monde des logiciels propriétaires, moi je suis optimiste, et le fait qu'il soit à présent un gros acteur du libre (à sa façon, qui peut déplaire, mais sur laquelle il ne faut pas cracher) est signe que finalement, c'est peut-être un allié plus qu'un ennemi...
[^] # Re: Il fallait oser, il font surtout parler d'eux.
Posté par Alexis P. (site web personnel) . En réponse à la dépêche Mark Shuttleworth invite les développeurs OpenSUSE à rejoindre Ubuntu et suscite la polémique. Évalué à 7.
Par contre, je pense qu'il y a un point positif qu'il ne faut pas négliger avec ubuntu. Je connais pas mal de personnes qui s'aventurent pour la première fois avec linux et le choix de distribution est à priori vite fait. Et à priori le libre ça n'intéresse pas autant de personnes.
Ceci dit je pense qu'avec le temps, en ayant un contact continu avec les LL ils seront plus sensibles, ou du moins comprendront beaucoup plus l'enjeu et l'intérêt d'une distribution 100% libre. Qui plus est, il sera plus facile de convaincre les entreprises écrivant des pilotes de les distribuer sous une licence open-source.
Ceci dit, il ne faudrait pas non plus que l'on continue à accepter de plus en plus de logiciels/pilotes propriétaires dans le futur. Il faudra pouvoir définir une barrière à ne pas dépasser...
[^] # Re: Avant de lancer des critiques "gratuites"...
Posté par Alexis P. (site web personnel) . En réponse à la dépêche Mark Shuttleworth invite les développeurs OpenSUSE à rejoindre Ubuntu et suscite la polémique. Évalué à -1.
# Avant de lancer des critiques "gratuites"...
Posté par Alexis P. (site web personnel) . En réponse à la dépêche Mark Shuttleworth invite les développeurs OpenSUSE à rejoindre Ubuntu et suscite la polémique. Évalué à 10.
Je ne sais pas si c'est le meilleur moyen de s'y prendre, mais ceci dit il n'a pas entièrement tort.
[^] # Re: Linux exploite la propriété de Microsoft
Posté par Alexis P. (site web personnel) . En réponse à la dépêche Microsoft une interopérabilité difficile avec la communauté du logiciel libre. Évalué à 4.
Ballmer s'attaque là à Linux directement, pas Mono, Samba ou autre application. Et c'est sur ce point précis que répond Mono dans le communiqué d'hier.
Ceci dit, pour un accord qui a été préparé pendant 6 long mois, la formulation aurait pu être plus correcte pour éviter ce genre de "flous". Pour ma part ce communiqué ne change pas le fait qu'on devra dans les années à venir payer une attention particulière à tout ce qui vient de Novell.
[^] # Re: Linux exploite la propriété de Microsoft
Posté par Alexis P. (site web personnel) . En réponse à la dépêche Microsoft une interopérabilité difficile avec la communauté du logiciel libre. Évalué à 3.
[^] # Re: Linux exploite la propriété de Microsoft
Posté par Alexis P. (site web personnel) . En réponse à la dépêche Microsoft une interopérabilité difficile avec la communauté du logiciel libre. Évalué à 3.
[^] # Re: Peux pas m'empêcher
Posté par Alexis P. (site web personnel) . En réponse à la dépêche PeerTV pour Linux. Évalué à 5.
C'est dommage, je croyais qu'il y avait réellement quelque chose d'intéressant là :).
Bon, bah.... merci quand même...
[^] # Re: Peux pas m'empêcher
Posté par Alexis P. (site web personnel) . En réponse à la dépêche PeerTV pour Linux. Évalué à 4.
Merci.
# Pertinence de l'article/dépêche ci-dessus
Posté par Alexis P. (site web personnel) . En réponse à la dépêche Une faille majeure de la cryptographie courante. Évalué à 10.
Que dire quand on lit : "La technique découverte par Jean-Pierre Seifert consiste à analyser le comportement du processeur lui-même afin de déduire statistiquement la clé de chiffrement."
quand le résumé de l'article initial dit très clairement : "a Simple Branch Prediction Analysis (SBPA) attack --- sharply differentiating it from those one relying on statistical methods"
Du coup on lit des commentaires parlant de timing attack, que c'est pas nouveau, quand le résumé de l'article dit : "The successful extraction of almost all secret key bits by our SBPA attack against an openSSL RSA implementation proves that the often recommended blinding or so called randomization techniques to protect RSA against side-channel attacks are, in the context of SBPA attacks, totally useless."
En bref, beaucoup trop de commentaires qui s'acharnent sur l'exagération des conséquences de la méthode, etc. quand visiblement ils n'ont pas pris la peine de lire, ne serait-ce que le résumé de l'article SCIENTIFIQUE. Ne me parlez pas du Monde, depuis quand un journal est-il une référence absolue en tèrmes d'avancées/résultats scientifiques si récents (mi-octobre 2006) et si pointus (d'ailleurs, ne prenez-vous jamais le temps de regarder une autre source d'information que la première qui vous tombe sous la main pour des sujets autres que l'informatique ?) ?!
Ne pas lire entre mes phrases pour essayer de dicerner un avis quelconque sur la compétence de la méthode : je ne suis pas là pour faire son éloge (ou la critiquer d'ailleurs), pour la simple et bonne raison que je sais et je le dis, moi, que je n'ai pas les connaissances nécessaires pour pouvoir en tirer une conclusion. Ceci n'empêche que je ne vais pas cracher non plus dessus, par simple respect des personnes qui ont travaillé dessus et qui ont pris la peine de pointer une (éventuelle) faille.
Plutôt que de crier au ridicule et à la paranoïa exagérée d'un journaliste (encore que vous oubliez de le mentionner, on pourrait presque croire que vous donnez un avis sur la méthode), concentrez-vous plutôt sur le sujet même. Et cher(s) rédacteur(s)/rédactrices (d'articles sur linuxfr j'entends), un grand merci pour votre contribution (franchement), mais je vous en prie, évitez dans l'avenir de paraphraser un article comme celui proposé par le Monde.
Pour ceux qui veulent avoir quelques infos supplémentaires, quelques commentaires pertinents peuvent être lus ici : http://it.slashdot.org/article.pl?sid=06/11/18/2030247
[^] # Re: Pas si révoluionnaire
Posté par Alexis P. (site web personnel) . En réponse à la dépêche Une faille majeure de la cryptographie courante. Évalué à 3.
En effet, c'est l'un des deux points qui me sont flous. Dans la section 2.3 ils disent qu'ils ne pousseront pas l'analyse trop loin et simplifient le problème. Ceci dit, ils font référence à d'autres articles qui pourraient éventuellement répondre à ces questions. J'ai jeté un coup d'oeil rapide à l'un d'entre eux ( [OST06] dans les références de l'article), mais il me semble que ce ne soit pas le bon, puis franchement, j'avais pas le temps :).
Donc oui ce n'est pas dans une semaine qu'on va apprendre qu'amazon doit changer de certificat parce que quelqu'un a la clé privée, mais ceci dit j'ai tendance à croire que les barrières sont beaucoup plus faibles à présent. Si un système cryptographique ne tient sa force qu'au fait qu'on ne peut pas savoir quand est-ce que le processus de (dé)chiffrement tourne, c'est à priori loin d'être rassurant.
Quoi qu'il en soit, l'article du Monde est tout à fait déplacé. Ce serait vraiment bien que les gens cessent d'y faire référence et d'extrapoler leurs critiques sur l'article scientifique même.