si la GPLv3 oblige à fournir un moyen de créer un pilote signé pour ce même OS, elle implique que la clé privé nécessaire à la signature soit également divulgé. Tout bonnement absurde, la signature numérique perd tout son intérêt.
La GPLv3 ne demande pas de fournir les moyens de reconstruire un pilote signé, sauf si c'est le seul moyen pour un utilisateur de charger ses propres pilotes.
Même si c'était le cas, rien n'empèche d'utiliser une clé privée différente pour chaque copie de l'OS distribué. Comme ça, la divulgation de la clé privée ne pose plus aucun problème de sécurité puisqu'un utilisateur ne pourra signer des pilotes que pour sa propre version de l'OS.
Autre solution, permettre à l'utilisateur de charger une deuxième clé privée dans l'OS pour que l'OS accepte de charger aussi bien les pilotes "officiels" (signés avec la clé privée du distributeur) que les pilotes "privés" (signés avec la clé de l'utilisateur).
C'est comme le débat sur les DRM, j'ai beau être contre dans le cadre de la protection des médias, ca peut avoir un intérêt pour par exemple signer numériquement des pilotes d'un OS (question sécurité) comme l'a fait gentiment remarqué Linus Torvald.
Mais la GPLv3 n'interdit absolument pas de signer les pilotes d'un OS. Elle dit juste qu'il ne faut pas que ça empèche l'utilisateur final de modifier un pilote et d'installer sa propre version du pilote si il le souhaite.
Rien n'interdit de verifier la signature des pilotes, mais dans ce cas, il faut laisser/donner à l'utilisateur les moyens soit de désactiver cette vérification, soit de remplacer la signature des pilotes.
Je n'ai jamais utilisé Spamassassin. Je l'avais vu fonctionner sur une machine bien plus récente que la mienne (P4 2 Ghz alors que je me servais d'un Duron 900) et ça m'avait dissuadé de l'installer, même si il ne laissait pratiquement passer aucun spam.
Avec Bogofilter, je n'ai pas de gros problèmes de performances et il ne laisse pas passer grand chose. Par contre, les premiers temps, sûrement à cause de la faiblesse de l'échantillon que j'avais utilisé pour son entrainement initial, Bogofilter avait renvoyé deux ou trois faux positifs.
Celà dit, ces deux programmes ne sont pas identiques. Bogofilter est un filtre bayésien. Le filtre bayésien n'est qu'une des méthodes utilisées par Spamassassin pour vérifier les mails.
A notter aussi que Bogofiler est écrit en C (Spamassassin est en Perl) ce qui doit également aider.
Avec Bogofilter, j'ai l'impression que ce sont les accès à la base de données qui prenaient le plus de temps. Depuis que ma base de données (128Mo) est dans un ramdisk (sauvegardé toutes les 6 heures), la vérification des mails est instantannée.
Enfin, je trouve très surprenants les résultats de Spamassassin qu'a obtenu l'auteur de ce journal. Celui que j'avais vu à l'oeuvre était vraiment redoutable. A mon avis, il n'a pas entrainé le filtre bayésien de son Spamassassin (ou il ne l'a pas fait correctement).
Ca reste un excellent browser, faudrait juste qu'il supporte les CSS, les tabs et le httpS et ça sera parfait :)
Pour les CSS, ce n'est pas géré, effectivement.
Pour les tabs, il y a un patch non officiel qui traine sur le web et il me semble bien que les versions de dillo fournies par Debian intègrent ce patch.
En ce qui concerne https, c'est disponible (mais c'est très basique et considéré comme du code en version alpha) : La FAQ de Dillo explique comment procèder :
Il faut récupèrer les sources, et dans le fichier dpi/https.c, remplacer le
As tu vérifié que le(s) gpu(s) ATI supporte(ent) le 16 bits?
Je suis bien placé pour affirmer que les R100 et les R200 supportent le 16 bits. J'utilise mes Radeons 7000, 9200 Mobility et 9250 en 16 bpp - C'est une vieille habitude héritée de l'époque où des applications ne supportaient pas le 24 bits.
J'utilise exclusivement les drivers libres (d'où le choix de ces chipsets).
Pour les chipsets plus récents, j'ai jamais testé, mais ce serait quand même surprenant que le 16 bits ne soient plus supporté (même si en informatique, qui peut le plus ne peut pas toujours le moins).
Comme imprimante Laser autour des 110 Euros, je vois que personne n'a mentionné la Lexmark e120n.
J'en ai acheté une il y a quelques mois que j'avais payé un peu moins de 110 Euros.
C'est une imprimante réseau qui supporte (entre autres) le protocole lpr/lpd. Pour ce qui est du langage, elle a un interpréteur PCL 6. Elle est donc parfaitement compatible Linux.
Je ne vois vraiment pas de quoi être fiers de ce correctif, mais alors vraiment pas. Je trouve la gestion de cette crise tout simplement déplorable.
D'après la chronologie, entre l'identification du patch responsable du problème et la fermeture du bug, il ne s'est même pas écoulé un quart d'heure. Le nouveau paquet n'a donc pas eu le temps d'être testé correctement.
C'était un bug grave, surtout pour une version stable. Même si le correctif pouvait sembler trivial et totalement sans danger, compte tenu de la gravité du bug, ça ne dispensait en aucun cas de tester soigneusement le nouveau paquet.
Dès que le problème a été connu, la priorité aurait du être de limiter les dégats en revenant le plus vite possible à l'ancien paquet (de préfèrence en lui donnant un nouveau numéro) histoire de ne pas mettre plus d'utilisateurs dans la mélasse pendant qu'on cherchait le bug et qu'on préparait un correctif.
Je pense que tout le monde sera d'accord pour dire que le bug initial est tout à fait excusable : Même les meilleurs font parfois des erreurs. Par contre, corriger un bug aussi grave en introduisant un correctif à la "vas y comme je t'y pousse" dans les dépots de stable, c'est lamentable.
Ca fait 5 mois que j'ai mon ibook, 4 mois qu'il tourne sous Linux et je ne l'ai encore jamais vu planter en veille, pas plus sous Linux que sous MacOS X.
ou que t'es branche sur secteur sans batterie et que le cable fait "pop!!"
J'enlève jamais la batterie du portable quand il tourne sur secteur, ne serait ce que pour protèger le système en cas de coupures de courrant.
tu fais quoi, gros malin?
Personnellement, j'estime qu'une partition démontée brutalement doit être l'exception, et sûrement pas la règle.
Maintenant, si j'ai des partitions HFS+, c'est uniquement parce que j'ai gardé MacOS X. Quand un démontage brutal se produira, je booterai tout simplement sur MacOS X pour qu'il répare ses partitions (au lieu de les bidouiller sous Linux au risque de perdre des données).
ben je te le dis, ca marche pas.
Si un driver existe, il y a certainement des gens qui ont réussi à le faire marcher.
faire marcher un truc plusieurs annees apres la sortie de la machine me parait pas etre une solution satisfaisante.
Ce n'est en rien spécifique au monde PPC et même si c'est pas idéal, une solution est en train de voir le jour au moins...
Le monde x86, c'est pas mieux de ce côté là. Le chipset son (qui fait aussi office de modem interne) de mon vieux portable x86 (Thinkpad TP760XD) n'est toujours pas supporté (et il ne le sera certainement jamais vu l'age très avancé de cette machine).
meme remarque qu'au dessus : mais bordel, pourquoi ne pas mettre la keymap qui va bien directement?
Je sais pas, demande aux DD responsables des paquets concernés. Ca fait des années que le problème a été soulevé mais les keymaps n'ont toujours pas changé.
Je suis propriétaire d'un ibook G4 depuis quelques mois et j'ai bien du mal à reconnaitre ma machine dans toutes ces doléances...
> la mise en veille
Elle marche depuis toujours.
> airport
J'ai une carte airport extreme dans la machine mais comme c'est ma seule machine à avoir du wifi, j'ai pas pu tester.
Tout ce que je peux dire, c'est que son kernel (2.6.17) détecte bien la carte.
> une partition HFS de facon brutale
Monter et démonter mes partitions HFS+ ne m'a jamais posé de problème (peut-être parce que je ne m'amuse pas à les démonter de façon brutale ?).
> Le clavier est fully operationnel
Certaines distributions (comme Debian par exemple) ont des fichiers keymap qui sont loin d'être au point, mais si on prend la peine de downloader et installer les bons fichiers keymap, le clavier intégré est "fully" opérationnel.
> J'avais aussi de gros problemes avec le son (les boutons faisaient un peu n'importe quoi).
Je n'ai jamais rien constaté de tel.
> L'autonomie est toujours aussi ridicule?
Elle m'a lair très correcte (je n'ai jamais mesuré, mais il m'est arrivé plus d'une fois de l'utiliser plus de 4 heures consécutives sur batteries).
> Le ventilo se met toujours en route aussi tot?
Personnellement, à part pendant la canicule, je n'ai pas vraiment eu l'occasion de m'en plaindre.
> C'est un portable, pas une machine de bureau.
Je m'en sers comme portable et j'en suis très content.
Plus généralement, sur le site de linux-france.org, il y a pas mal de choses intéressantes concernant Linux sur les Mac (d'ailleurs, mes fichiers keymap viennent de là).
Il faut être réaliste, les DRM sous leur forme actuelle ne seront probablement jamais implémentés sous Linux.
Espèrer protèger un contenu alors que le kernel du système est libre, c'est totalement irréaliste.
Il suffirait de modifier les drivers video et/ou son du kernel pour récupèrer un flux en clair de n'importe quel document drmisé. Et si le module de gestion de DRM utilisait ses propres drivers propriétaire pour le son et la vidéo, il serait quand même obligé de stocker le document en clair dans la RAM...
Comme sous root, on a accès à toute la RAM (tout se trouve dans /proc/kcore), ce ne serait pas bien dur, une fois repèrée la zone mémoire utilisée par le module de gestion des DRM, de récupèrer le document en clair.
Il faudrait donc que la distro tourne sur un kernel modifié et en interdise toute modification (il faudrait aussi qu'elle interdise le chargement de modules "inconnus" qui pourraient très bien se substituer à /proc/kcore). En gros, ça reviendrait à faire ce que RMS a appelé la "Tivoisation" du système.
Il ne faut pas perdre de vue que la GPL v3, qui va bientôt être prète a été pensée pour éviter ce genre de dérive et plus généralement pour contrarier autant que possible l'arrivé des DRM dans le monde du logiciel libre.
Au fur et à mesure que les nouvelles versions de composants vitaux changeront de licence pour passer en GPL v3, une distribution qui aurait implémenté les DRM se retrouverait vite dans une situation intenable.
Je ne pense pas qu'une distribution Linux investisse sur les DRM tant que la GPL v3 ne sera pas finalisée. Et si cette nouvelle version de la GPL tient ses promesses, les DRM n'auront tout simplement pas leur place dans le monde du logiciel libre.
est-ce qu'il y a moyen de booter un CD avec grub depuis une disquette si oui comment ?
Une solution serait d'installer grub sur une disquette avec une commande "grub-install --root-directory=/floppy /dev/fd0" et d'utiliser une entrée dans le menu.lst du style :
title cdrom
root (hd2) # Si le cdrom est vu comme /dev/hdc...
chainloader +1
Maintenant, ça me parait curieux que le BIOS de ce PC soit configuré pour booter sur la disquette puis sur le disque dur sans essayer de booter sur le CDROM. Ca pourrait accréditer la thèse selon laquelle ce BIOS n'est pas capable de booter sur un CDROM. Et dans ce cas, je ne sais pas si cette manip avec grub va fonctionner ?
A mon avis, ce serait plus simple, comme celà a déjà été suggéré, de réinitialiser le BIOS et voir ce qu'il est possible de faire.
Sinon, on peut installer Debian depuis des disquettes (et il n'en faut pas tant que ça puisqu'une fois que le programme d'install est lancé il pourra accèder au CDROM et y récupèrer le nécessaire (le système de base en particulier).
Oui, les deux sont disponibles séparément et aujourd'hui, Apple n'est pas plus dans la légalité que n'importe quel constructeur de PC (enfin, si, ils le sont puisqu'il est possible de se faire rembourser Mac OS X).
Seulement, il me semble que rien dans le code de la consommation n'interdit d'offrir un service de peu de valeur avec un bien matériel.
Si la DGCCRF (ou autre) venait leur chercher des crosses, se mettre en règle sans rien changer à leurs pratiques ne poserait pas de problème.
Par exemple, il leur suffirait de prétendre que les Mac OS X qui équipent les machines sont des versions OEM et que toutes les versions disponibles seules sont des versions "boite".
Ils pourraient continuer à vendre les versions "boite" au même prix qu'aujourd'hui et dire que la version OEM (que rien ne les oblige à vendre seule) ne vaut pas grand chose et est offerte, même si ça ne repose sur aucune réalité économique.
Apple est éditeur du soft, il peut faire ce qu'il veut avec les prix...
Bref je maintiens que même si elle aboutit, l'action actuelle risque de ne pas changer grand chose pour les constructeurs qui éditent eux même les logiciels qui font partie des bundles hard/soft qu'ils commercialisent.
Est-ce que la vente forcée est liée au fait que le fournisseur de soft est différent du fournisseur de hardware (MS/Dell), ou alors cela veut-il dire qu'Apple n'aurait jamais le droit de vendre de bundle hard/soft?
Il semblerait qu'Apple rembourse MacOS sans faire trop de difficultés.
Celà dit, Apple étant aussi éditeur des logiciels fournis avec ses machines, il est libre d'en fixer le prix comme il l'entend (contrairement à un revendeur de PC qui ne peut en aucun cas revendre Windows et compagnie à perte).
Apple aurait donc, contrairement à un constructeur de PC, la possibilité de jouer sur le prix des logiciels préinstallés par exemple pour satisfaire les conditions de l'article R121-8 du code de la consommation (qui fixe la valeur maximale de ce qui peut être offert avec le matériel).
Dans ces circonstances, ça me parait bien difficile d'empècher un constructeur comme Apple de vendre des bundles hard/soft avec le seul code de la consommation actuel.
Je pense aussi que ce serait vraiment pas mal que quelque chose soit inscrit en très gros au dos des tracts.
Mais plutôt qu'un NON qui ne veut pas dire grand chose (non à qui ? à quoi ?), pourquoi ne pas mettre DRM dans un panneau interdiction (vous savez, le cercle rouge avec une barre oblique) ?
D'autre part, ces sociétés ont déposé des brevets, mais sont-ils réellement valides? Pas sûr. Un tribunal pourrait invalider ces brevets. C'est pour ca que certaines boites ont déposé des brevets mais ne tentent rien contre ceux qui les violent: ils ne sont pas forcément sur de gagner en justice.
Et on en arrive à ce qu'on constate aux USA aujourd'hui... Ces brevets bidons créent un véritable climat d'insécurité juridique. Ce n'est pas parce que leur détenteurs ne les ont jamais utilisé qu'ils ne tenteront pas de le faire un jour.
Donc, il faut se donner les moyens de gagner en justice si on doit un jour se défendre contre un de ses brevets idiots.
Le résultat ? Un budget R&D logiciel en chute libre (aux USA, depuis que les brevets logiciels font parler d'eux, la baisse est d'environ 30%) pour pouvoir entretenir un service juridique.
Depuis quand diminuer les budgets R&D favorise l'innovation ?
Je crois qu'on compare des choses qui n'ont rien à voir. On peut pas comparer le développement d'un LL et d'un soft propriétaire.
Quand je regarde mon PC Linux, je me rend compte que pas mal de softs qui y sont installés sont des versions de développement (numéro de version << 1.0). Dans un monde propriétaire, c'est sûr que ces softs ne risqueraient pas de planter : Je n'y aurais pas accès du tout.
D'autre part, pour qu'un projet libre puisse espérer obtenir une base d'utilisateurs (et donc de contributeurs potentiels) non négligeable, il faut releaser souvent (ce n'est pas facilement conciliable avec la mise en oeuvre d'une politique de tests rigoureuses).
D'autres parts, tester tester, oui, mais comment ? J'ai l'impression que cette news fait l'impasse sur une différence majeure entre Linux et les OS propriétaires : la diversité.
Un logiciel peut bien fonctionner sur la machine d'un développeur et être instable sur celle d'un utilisateur pour peu qu'ils n'aient pas exactement les même bibliothèques (versions ou options de compilation légèrement différentes).
Oui, il y a des projets n'ayant aucune politique de tests digne de ce nom (mais c'est en rien spécifique au monde du LL), mais pour les autres, je crois que ce n'est pas aux développeurs, mais aux intégrateurs (donc les distributions) d'assurer le gros des tests et de ne pas intégrer de versions de développement en les présentant comme "stables"...
Il vire la couche graphique et la remplace par XFree, tout simplement. Si il veut aller jusqu'au bout, il devra peut-être virer un ou deux drivers propriétaires et renoncer à certains périphériques comme l'aeronet (qui ne dispose d'ailleurs d'aucun driver libre, quelque soit l'OS). Le système de base (Darwin) est libre.
Par contre, si le monsieur veut absolument un Linux, ça change tout (MacOS X appartient à la famille BSD).
Tous téléchargent parce c'est gratuit et sans trop de risques.
Et je vois 3 catégories :
- Ceux qui pensent que c'est légal (voir les anciennes publicités de certains FAI).
- "Ceux qui cherchent des justifications morales pour se donner bonne conscience".
- Et enfin, ceux qui assument (ou qui n'en ont rien à faire).
Pour en revenir au sujet, je trouve cette idée de dépénalisation pour faire baisser le P2P déconnectée des réalités. Il y a encore un an, beaucoups d'utilisateurs du P2P ne savaient pas que c'était illégal, mais ça n'a pas empèché le phénomène de prendre de l'ampleur.
Pourquoi cette dépénalisation devrait elle avoir un effet inverse aujourd'hui ?
Et les disquettes de l'atari c'était du 3 pouces introuvable.
s/atari/amstrad CPC/
En ma connaissance, les atari n'ont jamais utilisé de disquettes 3 pouces. La série XL avait un lecteur 5"1/4 externe (en option) et les ST ont toujours utilisé des disquettes 3"1/2.
Pourquoi ne pas récupèrer un vieux PC portable d'occasion ? Pour installer un simple émulateur terminal, c'est pas la peine d'avoir une bète de course. C'est même pas la peine d'avoir un disque dur puisqu'il suffirait d'avoir une disquette de boot dos (un émulateur terminal tient largement sur une disquette).
Bien sûr, rien n'empèche de prendre un portable un peu moins vieux et d'y mettre un Linux minimum et un minicom...
Ca marchait et ça ne marche plus... Je suppose qu'il y a eu des changements entre temps ?
Ca n'a peut-être rien à voir, mais il me vient une idée.
Est ce que tu as vérifié que ta machine a suffisamment de RAM disponible pour transférer ce qu'il y a dans le swap au moment où tu tappes ta commande swapoff. Il me semble que depuis la version 2.6.quelquechose le kernel refuse d'effectuer un swapoff si ce n'est pas le cas.
Si tu utilises depuis peu de nouvelles applis (ou des versions plus récentes et plus gourmandes en RAM) ou si tu as changé de kernel, ça pourrait expliquer pourquoi swapoff ne marche plus.
Posté par jch .
En réponse au journal Taxer Upload.
Évalué à 1.
S'ils taxent réellement l'upload, je pense qu'ils corrigeront vite le tir quand les gens vont résilier massivement leurs abonnements ADSL.
En effet, si l'upload est taxé:
- Il faudra surfer avec modération (comme avec un modem RTC ou Numeris) parce que ça génère un peu d'upload et ça fait gonfler la facture.
- Il faudra envoyer des mails avec encore plus de modération (ça génère surtout de l'upload). Idem pour l'irc, et autres formes de communication...
- On pourra plus avoir de site perso (le mettre à jour, c'est de l'upload).
- On pourra plus héberger de serveur http/ftp/ssh chez soit.
- Et je ne parle pas du pauvre type qui se retrouvera avec une taxe représentant 2 ou 3 mois de salaire à payer si son PC windows ramasse un virus.
Dans ce cas, avoir un accès "haut débit" à Internet sera devenu aussi inutile que risqué et je doute que beaucoups de monde continue à payer pour ça.
Je pense plutôt que ces ordures vont imposer une taxe forfaitaire sur les abonnements ADSL. Et que les utilisateurs de p2p ne s'inquiètent pas, cet outil ne risque rien. Il sera irremplaçable en tant que prétexte pour justifer des hausses continuelles de cette taxe.
> * Un systeme debian, ce qui pour une installation durable est tout de meme gage de qualite.
La knoppix est basée sur debian, mais le problème c'est que si on l'installe sur un disque dur, on se retrouve avec un mélange de stable, testing et unstable.
Installer une knoppix sur un disque dur permet de bénéficier de la détection automatique du matériel et de l'autoconfiguration, mais c'est une approche qui montre ces limites quand on essaye d'upgrader ou d'installer des paquets provenant d'un repositery debian (problèmes de dépendance, ...).
Si on veut une installation durable, il me semble quand même plus simple d'installer une véritable debian (surtout avec une knoppix sous la main pour s'inspirer de ses fichiers de configuration).
[^] # Re: Nouvelle section de la GPL
Posté par jch . En réponse à la dépêche Discours de Richard Stallman et Ciarán O'Riordan lors de la GPLv3 Conference à Tokyo. Évalué à 3.
La GPLv3 ne demande pas de fournir les moyens de reconstruire un pilote signé, sauf si c'est le seul moyen pour un utilisateur de charger ses propres pilotes.
Même si c'était le cas, rien n'empèche d'utiliser une clé privée différente pour chaque copie de l'OS distribué. Comme ça, la divulgation de la clé privée ne pose plus aucun problème de sécurité puisqu'un utilisateur ne pourra signer des pilotes que pour sa propre version de l'OS.
Autre solution, permettre à l'utilisateur de charger une deuxième clé privée dans l'OS pour que l'OS accepte de charger aussi bien les pilotes "officiels" (signés avec la clé privée du distributeur) que les pilotes "privés" (signés avec la clé de l'utilisateur).
Bref, ce ne sont pas les solutions qui manquent.
[^] # Re: Nouvelle section de la GPL
Posté par jch . En réponse à la dépêche Discours de Richard Stallman et Ciarán O'Riordan lors de la GPLv3 Conference à Tokyo. Évalué à 3.
Mais la GPLv3 n'interdit absolument pas de signer les pilotes d'un OS. Elle dit juste qu'il ne faut pas que ça empèche l'utilisateur final de modifier un pilote et d'installer sa propre version du pilote si il le souhaite.
Rien n'interdit de verifier la signature des pilotes, mais dans ce cas, il faut laisser/donner à l'utilisateur les moyens soit de désactiver cette vérification, soit de remplacer la signature des pilotes.
# En lisant la page de man de badblocks...
Posté par jch . En réponse au message hda4 + badblocks. Évalué à 0.
Voir l'option -c dans les pages de man de mke2fs ou de e2fsck pour plus de détails.
[^] # Re: Gourmand Bogofilter ?
Posté par jch . En réponse au journal Spamassassin/Bogofilter : net avantage à second !. Évalué à 3.
Avec Bogofilter, je n'ai pas de gros problèmes de performances et il ne laisse pas passer grand chose. Par contre, les premiers temps, sûrement à cause de la faiblesse de l'échantillon que j'avais utilisé pour son entrainement initial, Bogofilter avait renvoyé deux ou trois faux positifs.
Celà dit, ces deux programmes ne sont pas identiques. Bogofilter est un filtre bayésien. Le filtre bayésien n'est qu'une des méthodes utilisées par Spamassassin pour vérifier les mails.
A notter aussi que Bogofiler est écrit en C (Spamassassin est en Perl) ce qui doit également aider.
Avec Bogofilter, j'ai l'impression que ce sont les accès à la base de données qui prenaient le plus de temps. Depuis que ma base de données (128Mo) est dans un ramdisk (sauvegardé toutes les 6 heures), la vérification des mails est instantannée.
Enfin, je trouve très surprenants les résultats de Spamassassin qu'a obtenu l'auteur de ce journal. Celui que j'avais vu à l'oeuvre était vraiment redoutable. A mon avis, il n'a pas entrainé le filtre bayésien de son Spamassassin (ou il ne l'a pas fait correctement).
[^] # Re: Aléger le bouzin
Posté par jch . En réponse au journal Le troll de l'année?. Évalué à 1.
Pour les CSS, ce n'est pas géré, effectivement.
Pour les tabs, il y a un patch non officiel qui traine sur le web et il me semble bien que les versions de dillo fournies par Debian intègrent ce patch.
En ce qui concerne https, c'est disponible (mais c'est très basique et considéré comme du code en version alpha) : La FAQ de Dillo explique comment procèder :
Il faut récupèrer les sources, et dans le fichier dpi/https.c, remplacer le
#undef ENABLE_SSL
par
#define ENABLE_SSL
Ensuite, il suffit de recompiler et de réinstaller (voir http://www.dillo.org/FAQ.html#q12 ).
[^] # Re: gpu
Posté par jch . En réponse au journal Pilote propriétaire ATI : pas de mode 16 bits!. Évalué à 2.
Je suis bien placé pour affirmer que les R100 et les R200 supportent le 16 bits. J'utilise mes Radeons 7000, 9200 Mobility et 9250 en 16 bpp - C'est une vieille habitude héritée de l'époque où des applications ne supportaient pas le 24 bits.
J'utilise exclusivement les drivers libres (d'où le choix de ces chipsets).
Pour les chipsets plus récents, j'ai jamais testé, mais ce serait quand même surprenant que le 16 bits ne soient plus supporté (même si en informatique, qui peut le plus ne peut pas toujours le moins).
[^] # Re: Merci!
Posté par jch . En réponse à la dépêche Premiers pilotes libres pour les imprimantes Samsung. Évalué à 2.
J'en ai acheté une il y a quelques mois que j'avais payé un peu moins de 110 Euros.
C'est une imprimante réseau qui supporte (entre autres) le protocole lpr/lpd. Pour ce qui est du langage, elle a un interpréteur PCL 6. Elle est donc parfaitement compatible Linux.
[^] # Re: Vitesse de réaction
Posté par jch . En réponse au journal Ubuntu : La MAJ de xserver-xorg fait planter le serveur X. Évalué à 4.
D'après la chronologie, entre l'identification du patch responsable du problème et la fermeture du bug, il ne s'est même pas écoulé un quart d'heure. Le nouveau paquet n'a donc pas eu le temps d'être testé correctement.
C'était un bug grave, surtout pour une version stable. Même si le correctif pouvait sembler trivial et totalement sans danger, compte tenu de la gravité du bug, ça ne dispensait en aucun cas de tester soigneusement le nouveau paquet.
Dès que le problème a été connu, la priorité aurait du être de limiter les dégats en revenant le plus vite possible à l'ancien paquet (de préfèrence en lui donnant un nouveau numéro) histoire de ne pas mettre plus d'utilisateurs dans la mélasse pendant qu'on cherchait le bug et qu'on préparait un correctif.
Je pense que tout le monde sera d'accord pour dire que le bug initial est tout à fait excusable : Même les meilleurs font parfois des erreurs. Par contre, corriger un bug aussi grave en introduisant un correctif à la "vas y comme je t'y pousse" dans les dépots de stable, c'est lamentable.
[^] # Re: C'est triste.
Posté par jch . En réponse au journal Au revoir PowerPC. Évalué à 4.
Ca fait 5 mois que j'ai mon ibook, 4 mois qu'il tourne sous Linux et je ne l'ai encore jamais vu planter en veille, pas plus sous Linux que sous MacOS X.
J'enlève jamais la batterie du portable quand il tourne sur secteur, ne serait ce que pour protèger le système en cas de coupures de courrant.
Personnellement, j'estime qu'une partition démontée brutalement doit être l'exception, et sûrement pas la règle.
Maintenant, si j'ai des partitions HFS+, c'est uniquement parce que j'ai gardé MacOS X. Quand un démontage brutal se produira, je booterai tout simplement sur MacOS X pour qu'il répare ses partitions (au lieu de les bidouiller sous Linux au risque de perdre des données).
Si un driver existe, il y a certainement des gens qui ont réussi à le faire marcher.
Ce n'est en rien spécifique au monde PPC et même si c'est pas idéal, une solution est en train de voir le jour au moins...
Le monde x86, c'est pas mieux de ce côté là. Le chipset son (qui fait aussi office de modem interne) de mon vieux portable x86 (Thinkpad TP760XD) n'est toujours pas supporté (et il ne le sera certainement jamais vu l'age très avancé de cette machine).
Je sais pas, demande aux DD responsables des paquets concernés. Ca fait des années que le problème a été soulevé mais les keymaps n'ont toujours pas changé.
[^] # Re: C'est triste.
Posté par jch . En réponse au journal Au revoir PowerPC. Évalué à 5.
> la mise en veille
Elle marche depuis toujours.
> airport
J'ai une carte airport extreme dans la machine mais comme c'est ma seule machine à avoir du wifi, j'ai pas pu tester.
Tout ce que je peux dire, c'est que son kernel (2.6.17) détecte bien la carte.
> une partition HFS de facon brutale
Monter et démonter mes partitions HFS+ ne m'a jamais posé de problème (peut-être parce que je ne m'amuse pas à les démonter de façon brutale ?).
> Le clavier est fully operationnel
Certaines distributions (comme Debian par exemple) ont des fichiers keymap qui sont loin d'être au point, mais si on prend la peine de downloader et installer les bons fichiers keymap, le clavier intégré est "fully" opérationnel.
> J'avais aussi de gros problemes avec le son (les boutons faisaient un peu n'importe quoi).
Je n'ai jamais rien constaté de tel.
> L'autonomie est toujours aussi ridicule?
Elle m'a lair très correcte (je n'ai jamais mesuré, mais il m'est arrivé plus d'une fois de l'utiliser plus de 4 heures consécutives sur batteries).
> Le ventilo se met toujours en route aussi tot?
Personnellement, à part pendant la canicule, je n'ai pas vraiment eu l'occasion de m'en plaindre.
> C'est un portable, pas une machine de bureau.
Je m'en sers comme portable et j'en suis très content.
Plus généralement, sur le site de linux-france.org, il y a pas mal de choses intéressantes concernant Linux sur les Mac (d'ailleurs, mes fichiers keymap viennent de là).
# Les DRM ne passeront pas par Linux.
Posté par jch . En réponse au journal Le Bon, la Brute et le Truand.. Évalué à 2.
Espèrer protèger un contenu alors que le kernel du système est libre, c'est totalement irréaliste.
Il suffirait de modifier les drivers video et/ou son du kernel pour récupèrer un flux en clair de n'importe quel document drmisé. Et si le module de gestion de DRM utilisait ses propres drivers propriétaire pour le son et la vidéo, il serait quand même obligé de stocker le document en clair dans la RAM...
Comme sous root, on a accès à toute la RAM (tout se trouve dans /proc/kcore), ce ne serait pas bien dur, une fois repèrée la zone mémoire utilisée par le module de gestion des DRM, de récupèrer le document en clair.
Il faudrait donc que la distro tourne sur un kernel modifié et en interdise toute modification (il faudrait aussi qu'elle interdise le chargement de modules "inconnus" qui pourraient très bien se substituer à /proc/kcore). En gros, ça reviendrait à faire ce que RMS a appelé la "Tivoisation" du système.
Il ne faut pas perdre de vue que la GPL v3, qui va bientôt être prète a été pensée pour éviter ce genre de dérive et plus généralement pour contrarier autant que possible l'arrivé des DRM dans le monde du logiciel libre.
Au fur et à mesure que les nouvelles versions de composants vitaux changeront de licence pour passer en GPL v3, une distribution qui aurait implémenté les DRM se retrouverait vite dans une situation intenable.
Je ne pense pas qu'une distribution Linux investisse sur les DRM tant que la GPL v3 ne sera pas finalisée. Et si cette nouvelle version de la GPL tient ses promesses, les DRM n'auront tout simplement pas leur place dans le monde du logiciel libre.
# Une disquette de boot pour booter sur le cdrom.
Posté par jch . En réponse au journal Installation Debian & BIOS bloqué & GRUB ?. Évalué à 3.
Une solution serait d'installer grub sur une disquette avec une commande "grub-install --root-directory=/floppy /dev/fd0" et d'utiliser une entrée dans le menu.lst du style :
title cdrom
root (hd2) # Si le cdrom est vu comme /dev/hdc...
chainloader +1
Maintenant, ça me parait curieux que le BIOS de ce PC soit configuré pour booter sur la disquette puis sur le disque dur sans essayer de booter sur le CDROM. Ca pourrait accréditer la thèse selon laquelle ce BIOS n'est pas capable de booter sur un CDROM. Et dans ce cas, je ne sais pas si cette manip avec grub va fonctionner ?
A mon avis, ce serait plus simple, comme celà a déjà été suggéré, de réinitialiser le BIOS et voir ce qu'il est possible de faire.
Sinon, on peut installer Debian depuis des disquettes (et il n'en faut pas tant que ça puisqu'une fois que le programme d'install est lancé il pourra accèder au CDROM et y récupèrer le nécessaire (le système de base en particulier).
[^] # Re: Apple ou autres
Posté par jch . En réponse à la dépêche Vente liée de logiciels : pétition contre le "racketiciel". Évalué à 2.
Seulement, il me semble que rien dans le code de la consommation n'interdit d'offrir un service de peu de valeur avec un bien matériel.
Si la DGCCRF (ou autre) venait leur chercher des crosses, se mettre en règle sans rien changer à leurs pratiques ne poserait pas de problème.
Par exemple, il leur suffirait de prétendre que les Mac OS X qui équipent les machines sont des versions OEM et que toutes les versions disponibles seules sont des versions "boite".
Ils pourraient continuer à vendre les versions "boite" au même prix qu'aujourd'hui et dire que la version OEM (que rien ne les oblige à vendre seule) ne vaut pas grand chose et est offerte, même si ça ne repose sur aucune réalité économique.
Apple est éditeur du soft, il peut faire ce qu'il veut avec les prix...
Bref je maintiens que même si elle aboutit, l'action actuelle risque de ne pas changer grand chose pour les constructeurs qui éditent eux même les logiciels qui font partie des bundles hard/soft qu'ils commercialisent.
[^] # Re: Apple ou autres
Posté par jch . En réponse à la dépêche Vente liée de logiciels : pétition contre le "racketiciel". Évalué à 3.
Il semblerait qu'Apple rembourse MacOS sans faire trop de difficultés.
Celà dit, Apple étant aussi éditeur des logiciels fournis avec ses machines, il est libre d'en fixer le prix comme il l'entend (contrairement à un revendeur de PC qui ne peut en aucun cas revendre Windows et compagnie à perte).
Apple aurait donc, contrairement à un constructeur de PC, la possibilité de jouer sur le prix des logiciels préinstallés par exemple pour satisfaire les conditions de l'article R121-8 du code de la consommation (qui fixe la valeur maximale de ce qui peut être offert avec le matériel).
Dans ces circonstances, ça me parait bien difficile d'empècher un constructeur comme Apple de vendre des bundles hard/soft avec le seul code de la consommation actuel.
[^] # Re: Tract
Posté par jch . En réponse à la dépêche Appel à tous: samedi 4 mars, action aux Victoires de la Musique contre la loi DADVSI. Évalué à 10.
Mais plutôt qu'un NON qui ne veut pas dire grand chose (non à qui ? à quoi ?), pourquoi ne pas mettre DRM dans un panneau interdiction (vous savez, le cercle rouge avec une barre oblique) ?
[^] # Re: tentative légère d'historique
Posté par jch . En réponse au journal Petite reflexion sur les brevets logiciels. Évalué à 1.
D'autre part, ces sociétés ont déposé des brevets, mais sont-ils réellement valides? Pas sûr. Un tribunal pourrait invalider ces brevets. C'est pour ca que certaines boites ont déposé des brevets mais ne tentent rien contre ceux qui les violent: ils ne sont pas forcément sur de gagner en justice.
Et on en arrive à ce qu'on constate aux USA aujourd'hui... Ces brevets bidons créent un véritable climat d'insécurité juridique. Ce n'est pas parce que leur détenteurs ne les ont jamais utilisé qu'ils ne tenteront pas de le faire un jour.
Donc, il faut se donner les moyens de gagner en justice si on doit un jour se défendre contre un de ses brevets idiots.
Le résultat ? Un budget R&D logiciel en chute libre (aux USA, depuis que les brevets logiciels font parler d'eux, la baisse est d'environ 30%) pour pouvoir entretenir un service juridique.
Depuis quand diminuer les budgets R&D favorise l'innovation ?
# Il faudrait comparer ce qui est comparable...
Posté par jch . En réponse à la dépêche Démarche qualité et Logiciel Libre. Évalué à 1.
Quand je regarde mon PC Linux, je me rend compte que pas mal de softs qui y sont installés sont des versions de développement (numéro de version << 1.0). Dans un monde propriétaire, c'est sûr que ces softs ne risqueraient pas de planter : Je n'y aurais pas accès du tout.
D'autre part, pour qu'un projet libre puisse espérer obtenir une base d'utilisateurs (et donc de contributeurs potentiels) non négligeable, il faut releaser souvent (ce n'est pas facilement conciliable avec la mise en oeuvre d'une politique de tests rigoureuses).
D'autres parts, tester tester, oui, mais comment ? J'ai l'impression que cette news fait l'impasse sur une différence majeure entre Linux et les OS propriétaires : la diversité.
Un logiciel peut bien fonctionner sur la machine d'un développeur et être instable sur celle d'un utilisateur pour peu qu'ils n'aient pas exactement les même bibliothèques (versions ou options de compilation légèrement différentes).
Oui, il y a des projets n'ayant aucune politique de tests digne de ce nom (mais c'est en rien spécifique au monde du LL), mais pour les autres, je crois que ce n'est pas aux développeurs, mais aux intégrateurs (donc les distributions) d'assurer le gros des tests et de ne pas intégrer de versions de développement en les présentant comme "stables"...
[^] # Re: bon
Posté par jch . En réponse au journal Se faire rembourser Mac OS X.... Évalué à 4.
et si le monsieur veut simplement un OS libre ?
Il vire la couche graphique et la remplace par XFree, tout simplement. Si il veut aller jusqu'au bout, il devra peut-être virer un ou deux drivers propriétaires et renoncer à certains périphériques comme l'aeronet (qui ne dispose d'ailleurs d'aucun driver libre, quelque soit l'OS). Le système de base (Darwin) est libre.
Par contre, si le monsieur veut absolument un Linux, ça change tout (MacOS X appartient à la famille BSD).
[^] # Re: Mon avis sur le P2P
Posté par jch . En réponse au journal Mon avis sur le P2P. Évalué à 1.
Et je vois 3 catégories :
- Ceux qui pensent que c'est légal (voir les anciennes publicités de certains FAI).
- "Ceux qui cherchent des justifications morales pour se donner bonne conscience".
- Et enfin, ceux qui assument (ou qui n'en ont rien à faire).
Pour en revenir au sujet, je trouve cette idée de dépénalisation pour faire baisser le P2P déconnectée des réalités. Il y a encore un an, beaucoups d'utilisateurs du P2P ne savaient pas que c'était illégal, mais ça n'a pas empèché le phénomène de prendre de l'ampleur.
Pourquoi cette dépénalisation devrait elle avoir un effet inverse aujourd'hui ?
[^] # Re: en effet
Posté par jch . En réponse au journal "Une pensée ébouriffante". Évalué à 6.
Et les disquettes de l'atari c'était du 3 pouces introuvable.
s/atari/amstrad CPC/
En ma connaissance, les atari n'ont jamais utilisé de disquettes 3 pouces. La série XL avait un lecteur 5"1/4 externe (en option) et les ST ont toujours utilisé des disquettes 3"1/2.
# Un vieux portable ?
Posté par jch . En réponse au message Terminal série. Évalué à 1.
Bien sûr, rien n'empèche de prendre un portable un peu moins vieux et d'y mettre un Linux minimum et un minicom...
# Peut-être une idée...
Posté par jch . En réponse au message swapoff et swapon ne fonctionne plus. Évalué à 2.
Ca n'a peut-être rien à voir, mais il me vient une idée.
Est ce que tu as vérifié que ta machine a suffisamment de RAM disponible pour transférer ce qu'il y a dans le swap au moment où tu tappes ta commande swapoff. Il me semble que depuis la version 2.6.quelquechose le kernel refuse d'effectuer un swapoff si ce n'est pas le cas.
Si tu utilises depuis peu de nouvelles applis (ou des versions plus récentes et plus gourmandes en RAM) ou si tu as changé de kernel, ça pourrait expliquer pourquoi swapoff ne marche plus.
# Re: Taxer Upload
Posté par jch . En réponse au journal Taxer Upload. Évalué à 1.
En effet, si l'upload est taxé:
- Il faudra surfer avec modération (comme avec un modem RTC ou Numeris) parce que ça génère un peu d'upload et ça fait gonfler la facture.
- Il faudra envoyer des mails avec encore plus de modération (ça génère surtout de l'upload). Idem pour l'irc, et autres formes de communication...
- On pourra plus avoir de site perso (le mettre à jour, c'est de l'upload).
- On pourra plus héberger de serveur http/ftp/ssh chez soit.
- Et je ne parle pas du pauvre type qui se retrouvera avec une taxe représentant 2 ou 3 mois de salaire à payer si son PC windows ramasse un virus.
Dans ce cas, avoir un accès "haut débit" à Internet sera devenu aussi inutile que risqué et je doute que beaucoups de monde continue à payer pour ça.
Je pense plutôt que ces ordures vont imposer une taxe forfaitaire sur les abonnements ADSL. Et que les utilisateurs de p2p ne s'inquiètent pas, cet outil ne risque rien. Il sera irremplaçable en tant que prétexte pour justifer des hausses continuelles de cette taxe.
[^] # Re: meilleure méthode pour installer une debian sid
Posté par jch . En réponse au journal meilleure méthode pour installer une debian sid. Évalué à 1.
Simple.
apt-get remove kde
pour virer kde et tout ce qui en dépend.
Et ensuite, deborphan pour obtenir la liste des libs non utilisées.
[^] # Re: Comte rendu du groupe Attac & Logiciel libre au FSE
Posté par jch . En réponse à la dépêche Compte rendu du groupe Attac & Logiciel libre au FSE. Évalué à 1.
La knoppix est basée sur debian, mais le problème c'est que si on l'installe sur un disque dur, on se retrouve avec un mélange de stable, testing et unstable.
Installer une knoppix sur un disque dur permet de bénéficier de la détection automatique du matériel et de l'autoconfiguration, mais c'est une approche qui montre ces limites quand on essaye d'upgrader ou d'installer des paquets provenant d'un repositery debian (problèmes de dépendance, ...).
Si on veut une installation durable, il me semble quand même plus simple d'installer une véritable debian (surtout avec une knoppix sous la main pour s'inspirer de ses fichiers de configuration).