Ceux qui se contentent d'un apt-get upgrade sans régénérer leurs clefs resteront vulnérables... un beau foutoir pour ceux qui doivent faire régénérer des certificats ssl... et certainement des brouettes d'admins qui ne prendront pas le temps de le faire. Bref, une baisse qualitative de la sécurité sur le web.
Il me semble qu'OpenGL faisait ça bien avant Direct3D... mais bon, ce n'était pas juste pour les jeux, mais bien pour de nombreuses applications CAD, et graphiques... Direct3D est venu plus tard, pour contrer le risque de portabilité induit par OpenGL...
Certes, il y a la question du contexte du texte... hors situation c'est parfois incompréhensible, mais le xml reste du texte, et ça reste peu comparable à ce niveau là avec du flash.
De même il serait possible de transformer dans une certaine mesure les images en svg en langage littéral (même si ce n'est pas à priori pertinent)... le xml permet en tout cas de nombreux traitements que le flash ne permet pas aussi facilement.
C'est la FSF qui est le mieux placé pour le faire.
La liberté n'a pas été inventée par la FSF, je ne vois pas en quoi ce concept précis leur appartiendrait plus à eux qu'à n'importe quel bipède doué de deux neurones. Certes, la FSF formalise le concept de libertés au sein du monde logiciel, mais elle ne doit pas avoir le monopole de la réflexion. La FSF, si elle est admirable pour de nombreuses réalisations, ne doit pas rester non critiquée, car elle n'est pas à l'abri de dérives.
Donner le monopole de ses libertés à une seule entité, est-ce rester libre?
Oui en soi cette possibilité peut poser un problème, mais pour le grand public Firefox serait par exemple extrêmement désavantagé s'il ne supportait pas flash.
C'est clair que sans flash, il y a pas mal de monde qui repasserait vers le produit d'une autre entité unique bien plus dangereuse et en situation de dominance sur ce marché...
Le fait est aussi qu'il ne faut pas oublier pour qui on développe et ce qu'on veut faire, chaque projet a des objectifs, et ceux-ci ne sont pas forcément les mêmes que ceux de la FSF.
Pourquoi on met pas la doc de C/C++ dans le kernel?
Ici, personne, ne peut comprendre, ni étudier le fonctionnement car il manque quelque chose d'énorme !
Ben c'est là dessus qu'il faudrait bosser, pour les microcontrôleurs dont la doc n'est pas disponible... (parce qu'il y en à où un coup de google devrait suffir)
Ce qui serait intéressant, c'est au lieu d'appliquer une pensée binaire concernant ces "bobs" et de vouloir dicter leur suppression bête et méchante, faire un inventaire, établir un score par "bob", sur sa criticité par rapport au bon fonctionnement du matériel selon le type de public (mobile/serveur/desktop), sur les possibilités de faire l'ingénierie inverse, sur les possibilités de créer une chaîne de compilation, et ensuite d'adresser ces "bobs" au cas par cas: on jette, on démarre un projet de substitution, on documente, on garde tel quel, ...
la liberté d'étudier le fonctionnement du programme. On ne peut pas être libre d'étudier le fonctionnement (étudier signifie également avoir la possibilité de l'appréhender pas juste le regarder) puisque la signification de ces nombres sont inconnus/non documentés.
Celui qui veut étudier le fonctionnement de ces blobs peut toujours faire de l'ingénierie inverse et nous faire une belle doc sur le sujet... l'étude n'est pas entravée, c'est juste que l'info ne tombe pas toute cuite dans la bouche de la personne qui lit le code binaire...
Pour pouvoir étudier et comprendre le fonctionnement des applications, il faut maîtriser le langage dans lequel elles sont écrites, sinon, on pourrait voir des hordes de personnes ne connaissant pas le C dire que emacs c'est pas libre parcequ'ils ne comprennent pas le code source.
faut pas exagérer, le goulag n'est pas dans les réactions possibles...
par contre, il est clair que mettre une directive de censure ne fait pas honneur aux principes de liberté... il est dommage de voir le ton de la FSF se durcir à ce point, c'est contre-productif et ça ne va faire qu'une chose: diviser un peu plus la communauté, radicaliser les positions au delà du raisonnable, et faire une mauvaise pub.
... si les magasins continuent sur leur lancée: le eeepc 900 n'est disponible à la pré-commande QUE en version XP pour le moment, mauvais présage à mon avis.
le texte contenu dans les svg est lisible en texte plein, au sein du xml (sauf si l'auteur du svg s'est amusé à convertir le texte en courbes), c'est à des années lumières plus accessible que le flash.
Il y a problème pour la distribution. Le problème se pose lorsque, par exemple, tu conseilles une distribution et dis qu'elle est libre (ce qui veut dire que TOUS les sources (y compris les firmwares) sont disponibles). Ben s'il y a un blob-firmware, elle n'est pas libre.
Si ce blob est distribué distribué sous gplv2, je ne vois pas en quoi on peut prétendre qu'il n'est pas libre. Certes on a pas les sources (mais dans certains cas il n'y en a pas), mais les conditions de modification, de redistribution, ... sont d'application. C'est moins lisible, mais y a t'il moyen de le rendre plus lisible?
doit faire le nécessaire pour permettre de facilement faire des versions de Linux sans blob
Je pense que c'est surtout ceux en quête de pureté à venir participer au projet upstream plutôt que de poser des exigeances. chacun son projet.
On veut qu'il y ait les sources
Encore une fois, il y en a où il n'y a pas de source parceque ça a été développé directement en binaire. Libre à qui veut de faire de l'ingénierie inverse sur ces petits éléments et de faire une documentation. Ce sera toujours plus productif que de chercher à les virer sans pallier au manque engendré.
de vouloir virer des "blobs" du kernel, pour le plaisir de dire qu'on vire des blobs... (je parle des petits bouts binaires qu'on trouve dans le noyau vanilla et qui sont la cible d'une campagne d'épuration)
les questions à se poser tout de même par rapport aux blobs fournis dans le kernel, avant de les virer maladivement sont:
- est-ce qu'il existe réellement un code source qu'on aurait pu obtenir, ou est-ce du binaire parceque ça a été codé directement en binaire (fréquent pour certains microcontrolleurs)
- dans le cas où un code source existerait, est-il possible de mettre en œuvre une chaine de compilation pour ces éléments sans faire exploser la complexité de la compilation du noyau?
Le choix a été fait entre deux distributions (RHEL et ?) et c'est le support (au sens large) qui a semble-t-il fait la différence.
Novell?
De toutes façons, ce sont les deux seules distributions réellement supportées par HP sur ses serveurs (le support du hw nécessite l'installation du Proliant Support Pack, qui n'est dispo que pour ces deux distros)
De la chance? Non, je pense plutôt que chez Fedora ils ont fait leur boulot... che ubuntu, par contre :/
Et question Intel HD Audio, au minimum tous ceux qui ont une P5B et un noyau vanilla avec acpi actif sont concernés... c'est à dire tous ceux qui ont la P5B et Hardy Heron...
# Patcher, c'est bien, changer ses clefs, c'est mieux...
Posté par ragoutoutou . En réponse au sondage La faille OpenSSL Debian. Évalué à 4.
[^] # Re: Quelques détails, svp...
Posté par ragoutoutou . En réponse à la dépêche Red Hat Enterprise Linux 5.2. Évalué à 2.
c'est simple et ça marche très bien sur les bl20p, les bl4xxc, ...
[^] # Re: Quelques détails, svp...
Posté par ragoutoutou . En réponse à la dépêche Red Hat Enterprise Linux 5.2. Évalué à 2.
Perso, sur les serveurs blades HP, j'utilise une image iso montée sur le lecteur cdrom virtuel de la carte ilo.
# C'est dans l'ordre des choses...
Posté par ragoutoutou . En réponse à la dépêche Microsoft va-t-il ouvrir Office à de nouveaux formats de documents ?. Évalué à 10.
[^] # Re: Et si rien ne disparaissait ?
Posté par ragoutoutou . En réponse à la dépêche Les GPU promis à une mort prochaine ?. Évalué à 10.
[^] # Re: Extraits
Posté par ragoutoutou . En réponse au journal Offre - Développeur web polyvalent Belgique. Évalué à 2.
De même il serait possible de transformer dans une certaine mesure les images en svg en langage littéral (même si ce n'est pas à priori pertinent)... le xml permet en tout cas de nombreux traitements que le flash ne permet pas aussi facilement.
[^] # Re: toujours cette maladie...
Posté par ragoutoutou . En réponse au journal FSF et distributions. Évalué à 4.
La liberté n'a pas été inventée par la FSF, je ne vois pas en quoi ce concept précis leur appartiendrait plus à eux qu'à n'importe quel bipède doué de deux neurones. Certes, la FSF formalise le concept de libertés au sein du monde logiciel, mais elle ne doit pas avoir le monopole de la réflexion. La FSF, si elle est admirable pour de nombreuses réalisations, ne doit pas rester non critiquée, car elle n'est pas à l'abri de dérives.
Donner le monopole de ses libertés à une seule entité, est-ce rester libre?
[^] # Re: toujours cette maladie...
Posté par ragoutoutou . En réponse au journal FSF et distributions. Évalué à 2.
"et si on suis ton raisonnement, il faudrait attendre que le bios des cartes mères soit libre avant de pouvoir lancer emacs."
[^] # Re: Mauvaise approche d'un problème certain
Posté par ragoutoutou . En réponse au journal FSF et liberté d'expression. Évalué à 4.
C'est clair que sans flash, il y a pas mal de monde qui repasserait vers le produit d'une autre entité unique bien plus dangereuse et en situation de dominance sur ce marché...
Le fait est aussi qu'il ne faut pas oublier pour qui on développe et ce qu'on veut faire, chaque projet a des objectifs, et ceux-ci ne sont pas forcément les mêmes que ceux de la FSF.
[^] # Re: toujours cette maladie...
Posté par ragoutoutou . En réponse au journal FSF et distributions. Évalué à 3.
Pourquoi on met pas la doc de C/C++ dans le kernel?
Ici, personne, ne peut comprendre, ni étudier le fonctionnement car il manque quelque chose d'énorme !
Ben c'est là dessus qu'il faudrait bosser, pour les microcontrôleurs dont la doc n'est pas disponible... (parce qu'il y en à où un coup de google devrait suffir)
Ce qui serait intéressant, c'est au lieu d'appliquer une pensée binaire concernant ces "bobs" et de vouloir dicter leur suppression bête et méchante, faire un inventaire, établir un score par "bob", sur sa criticité par rapport au bon fonctionnement du matériel selon le type de public (mobile/serveur/desktop), sur les possibilités de faire l'ingénierie inverse, sur les possibilités de créer une chaîne de compilation, et ensuite d'adresser ces "bobs" au cas par cas: on jette, on démarre un projet de substitution, on documente, on garde tel quel, ...
[^] # Re: toujours cette maladie...
Posté par ragoutoutou . En réponse au journal FSF et distributions. Évalué à 1.
Celui qui veut étudier le fonctionnement de ces blobs peut toujours faire de l'ingénierie inverse et nous faire une belle doc sur le sujet... l'étude n'est pas entravée, c'est juste que l'info ne tombe pas toute cuite dans la bouche de la personne qui lit le code binaire...
Pour pouvoir étudier et comprendre le fonctionnement des applications, il faut maîtriser le langage dans lequel elles sont écrites, sinon, on pourrait voir des hordes de personnes ne connaissant pas le C dire que emacs c'est pas libre parcequ'ils ne comprennent pas le code source.
# Pffffff...
Posté par ragoutoutou . En réponse au journal FSF et liberté d'expression. Évalué à 9.
par contre, il est clair que mettre une directive de censure ne fait pas honneur aux principes de liberté... il est dommage de voir le ton de la FSF se durcir à ce point, c'est contre-productif et ça ne va faire qu'une chose: diviser un peu plus la communauté, radicaliser les positions au delà du raisonnable, et faire une mauvaise pub.
# man sshd_config
Posté par ragoutoutou . En réponse au message Authentification forte openssh. Évalué à 4.
Il est à noter que tu n'as en aucun cas la garantie que les utilisateurs auront un passphrase sur leurs clefs.
Reste que si tu veux un niveau de sécurité combinant le "j'ai" et le "je sais", tu devrais plutôt investir dans une solution genre digipass.
Elle disait quoi, l'analyse de risques?
# La version linux sera introuvable...
Posté par ragoutoutou . En réponse au journal Encore un Portable bas de gamme sous Linux. Évalué à 3.
[^] # Re: Extraits
Posté par ragoutoutou . En réponse au journal Offre - Développeur web polyvalent Belgique. Évalué à 1.
le texte contenu dans les svg est lisible en texte plein, au sein du xml (sauf si l'auteur du svg s'est amusé à convertir le texte en courbes), c'est à des années lumières plus accessible que le flash.
[^] # Re: toujours cette maladie...
Posté par ragoutoutou . En réponse au journal FSF et distributions. Évalué à 3.
Si ce blob est distribué distribué sous gplv2, je ne vois pas en quoi on peut prétendre qu'il n'est pas libre. Certes on a pas les sources (mais dans certains cas il n'y en a pas), mais les conditions de modification, de redistribution, ... sont d'application. C'est moins lisible, mais y a t'il moyen de le rendre plus lisible?
doit faire le nécessaire pour permettre de facilement faire des versions de Linux sans blob
Je pense que c'est surtout ceux en quête de pureté à venir participer au projet upstream plutôt que de poser des exigeances. chacun son projet.
On veut qu'il y ait les sources
Encore une fois, il y en a où il n'y a pas de source parceque ça a été développé directement en binaire. Libre à qui veut de faire de l'ingénierie inverse sur ces petits éléments et de faire une documentation. Ce sera toujours plus productif que de chercher à les virer sans pallier au manque engendré.
# toujours cette maladie...
Posté par ragoutoutou . En réponse au journal FSF et distributions. Évalué à 5.
les questions à se poser tout de même par rapport aux blobs fournis dans le kernel, avant de les virer maladivement sont:
- est-ce qu'il existe réellement un code source qu'on aurait pu obtenir, ou est-ce du binaire parceque ça a été codé directement en binaire (fréquent pour certains microcontrolleurs)
- dans le cas où un code source existerait, est-il possible de mettre en œuvre une chaine de compilation pour ces éléments sans faire exploser la complexité de la compilation du noyau?
Enfin bon...
[^] # Re: Extraits
Posté par ragoutoutou . En réponse au journal Offre - Développeur web polyvalent Belgique. Évalué à 3.
reste que le texte affiché dans les flashouillements est difficilement récupérable pour les malvoyants...
...maintenant si de toutes façons les malvoyants sont malvenus sur le site...
# mini-itx.com
Posté par ragoutoutou . En réponse au journal Un PC qui consomme 1 Watt. Évalué à 2.
Ils n'ont pas la PX 5000, mais ils ont le modèle un peu au dessus pour 139 livres sterling.
http://mini-itx.com/store/?c=39
[^] # Re: Distro
Posté par ragoutoutou . En réponse au journal 140 milliard de $ par jour traité par GNU/Linux. Évalué à 2.
[^] # Re: Distro
Posté par ragoutoutou . En réponse au journal 140 milliard de $ par jour traité par GNU/Linux. Évalué à 2.
bon le health agent devrait suffire pour le support, mais la boîte à outils est un peu vide, et le mot "alien" est un peu trop utilisé à mon goût.
[^] # Re: Distro
Posté par ragoutoutou . En réponse au journal 140 milliard de $ par jour traité par GNU/Linux. Évalué à 2.
Pas vraiment, tu me trouves le lien officiel sur le site d'HP pour Debian et je te fais un bisou...
Parceque je vois pas Debian, là ...
http://h20000.www2.hp.com/bizsupport/TechSupport/DriverDownl(...)
# Distro
Posté par ragoutoutou . En réponse au journal 140 milliard de $ par jour traité par GNU/Linux. Évalué à 5.
Novell?
De toutes façons, ce sont les deux seules distributions réellement supportées par HP sur ses serveurs (le support du hw nécessite l'installation du Proliant Support Pack, qui n'est dispo que pour ces deux distros)
[^] # Re: Pas de son...
Posté par ragoutoutou . En réponse à la dépêche Test d'Ubuntu Hardy 8.04. Évalué à 3.
Et question Intel HD Audio, au minimum tous ceux qui ont une P5B et un noyau vanilla avec acpi actif sont concernés... c'est à dire tous ceux qui ont la P5B et Hardy Heron...
[^] # Re: Pas de son...
Posté par ragoutoutou . En réponse à la dépêche Test d'Ubuntu Hardy 8.04. Évalué à 2.
Ou le kernel lancé avec acpi désactivé...
Ou un kernel non-vanilla...
Pour plus d'info sur le bug: http://lkml.org/lkml/2008/1/27/168 ... symptomes identiques au problème rencontré avec le noyau de la 8.04.