Tu pourrais aller plus loins dans ton raisonnement.
Dire que la FSF dit des conneries.
Que le fait que Gnewsens et d'autres qui virent les blobs dans les sources du kernel vanilla font du vent.
Etc.
> je demandais des informations sur Mandiva Free et Gobuntu...
Elles ne sont pas libres selon la FSF.
J'ai voulu t'expliquer pourquoi, ... mais tu t'en branles.
T'es comme MS avec l'ISO, tout ce qui t'importe c'est de savoir si tu as le label ou non afin de l'afficher.
> Est ce que tu peux définitivement essayer de faire un commentaire sans parler de RedHat ou Fedora ?
Ici tous mes commentaires ne parlent que de Red Hat et Fedora.
La FSF a fait un guide uniquement pour Red Hat et Fedora.
Mon journal porte sur le guide de la FSF pour Red Hat et Fedora.
Lorsqu'il est parlé de blob dans le kernel vanilla ça ne conserne que Red Hat et Fedora.
Les blob ne concerne que Red Hat et Fedora.
Il faut être très con pour voir que les choses comme ça.
T'es très con.
L'avantage d'avoir le blob dans Linux est qu'on peut éviter d'avoir le chargeur de firmware. Si le blob est plus petit que le chargeur c'est un gain de mémoire (un plus pour l'embarqué).
> Les petits bouts de binaire dont tu parles sont généralement des référencements aux registres, à la mémoire, etc. du hardware.
Non, il y a des petit blob. Je ne vois pas pourquoi il n'y aurait que des gros blob.
> Les petits bouts de binaire dont tu parles sont généralement des référencements aux registres, à la mémoire, etc. du hardware.
Tu parles peut-être d'autres choses. On peut souvent depuis Linux écrite dans des registres d'un périphérique. souvent ceci ne demande pas de blob (de binaire téléchargé sur le périphérique) mais seulement la doc du périphérique.
Notons bien que Linux n'a pas besoin de télécharcher un blob dans le périphérique pour écrire le blob dans le périphérique :-)
Ça serait impossible.
> La FSF fournit enfin des critères objectifs permettant de distinguer clairement une distribution libre/non-libre selon elle. J'applaudis même.
J'applaudis aussi.
L'avis de la FSF a toujours une forte valeur.
Ça peut aussi clarifier les choses. Pas dans une logique uniquement binaire (libre/non-libre), mais aussi pour qualifier une distribution.
On peut maintenant dire de Fedora (et d'autres) : "OK elle n'est pas libre selon la FSF, mais uniquement car elle intégre des blob-firmwares". On ne trompe pas sur la marchandise, on qualifie de façon courte mais assez précise et par rapport à une référence qu'est la FSF.
C'est vraiment bienvenu.
J'espère que la FSF ira plus loins dans la précision de la défintion pour aussi inclure quelques éléments du projet (fait-il la promotion du proprio (downloade en un clique sans warning), etc).
> On notera que RMS était plus conciliant au sujet de l'inclusion des firmware au début des discussions.
Je n'ai qu'un vague souvenir, mais il me semble que les propos de RMS étaient plus ciblés. De mon souvenir il disait que les blob-firmware étaient légaux (puisque Linus les accèpte et les considères comme des "données" (pour simplifier)) et donc il n'y a pas de violation de la GPL. En gros ici, RMS respecte l'avis de Linus.
Mais je n'ai pas souvenir qu'il disait que pour une distribution c'était OK pour la qualifier de libre. L'avis de Linus est respecté pour Linux, mais il n'est pas pris en compte pour la distribution (qui contient un nombre indéterminé de logiciels). La FSF ne peut pas dire : pour le projet Linux c'est OK, pour bidule ce n'est pas OK, pour machin c'est ...
Elle ne peut pas nom plus dire que c'est systématiquement OK pour les blobs pour tous les projets. Exemple fictif, imaginons un FS mais dans un blob. Pour l'utiliser il faut le charcher dans un périphérique (une carte raid par exemple) puis le noyau l'utilise via des appels au périphérique. Ça serait clairement une violation de la GPL (au moins dans l'esprit).
Linux a un historique et offre des protections (il n'y a qu'un nombre limité d'API qui n'impose pas la GPL, etc). Mais pour d'autres noyaux ?
Le document de la FSF n'est pas écrit spécifiquement pour GNU/Linux.
> Il serait intéressant pour Fedora de proposer un noyau 100% libre selon la FSF dans les dépôts, voire même un spin dédié (que ce soit via jigdo ou bien un fichier kickstart)
Non :-)
Du moins, pas comme ça.
Ce que tu proposes, c'est comme si Fedora avait livna par défaut et qu'il existait des spins (pour caricaturer des "sous-distributions") sans livna.
A mon avis, si Fedora veut virer les blobs, la distribution officielle Fedora (c'elle supportée et développée par Fedora) ne doit pas avoir de blobs.
Le noyau avec les firware (ou seulement les firmwares) doivent être ailleurs (par exemple livna). Idem pour les spins (notons qu'on peut aussi ajouter des dépôts lors de l'installation ce qui rend les spins non indispensables pour la majorité des installations).
La version la plus libre de Fedora ne doit pas être le parent pauvre de Fedora, la moins supporté/testé/développé par Fedora. Bien au contraire.
Après chaqu'un est libre, de sa propre initiative, en fonction de son matériel, de "polluer" la distribution avec des blobs, Flash, des drivers proprio, etc.
Ce modèle, même s'il est beaucoup critiqué car il demande des actions supplémentaier à beaucoup l'utilisateur, marche. Les contributeurs le respectent très bien. La communcation de Fedora gagne en cohérence en gardant ce modèle. Je ne veut pas d'un GoFedora parent pauvre de Fedora :-)
> Tous les blobs que j'ai déjà vu sont beaucoup trop gros pour avoir été fait à la main...
Je ne doute pas de la sincérité de ton propos. D'ailleurs je pensais la même chose.
Mais il me semble avoir vu Alan Cox dire que certains blobs sont développés avec un éditeur hex (ou un truc style "{ 0x01, 0xF7, ...}").
Le problème par rapport à l'esprit de la GPL n'est alors pas l'absence le source (plus présicément la forme utilisé pour le développement), mais la doc. Par que pour ce type de blob, mais si tu as le source, c'est quasi impossible à modifier (et que ça marche).
> Tous les blobs que j'ai déjà vu sont beaucoup trop gros pour avoir été fait à la main...
Pour ceux dans /lib/firmware probablement. Mais les sources de Linux ont aussi des blogs qui sont très petits.
Il ne parle que du cpu.
Il ne parle pas de l'écran (gros consommateur), de l'ajustement de la consommation de l'écran en fonction de l'utilisation du portable, de l'intéraction qu'il faut mettre en place avec l'utilisateur, etc.
Idem pour les disques dures.
Idem pour suspend.
Etc.
Le titre de la dépêche est trompeur ("Gestion de l'énergie : se dépêcher de ne rien faire"). Je ne peux pas croire que c'est ce que veut dire Matthew Garret (sauf peut-être pour le cpu).
On est dans un domaine facilement mesurable et la doc sur la consommation du cpu en fonction de la fréquence, etc doit être disponible.
Il suffit donc d'utiliser une calculatrice pour valides ou invalider ses propos.
Je pense qu'il a fait ce boulot :-)
Si au final il est claire que pour une même quantité de travail demandée au cpu il y a la même consommation d'énergie, il est un peu con de se faire chier avec la fréquence du cpu. Il est ridicule d'implémenter un truc qui n'apporte rien. D'autant plus qu'il y a beaucoup de boulot ailleurs et que les ressources sont limités.
Est-il raisonnable d'implémenter quelques chose pour le cas où les technologies des cpu changent ?
Je ne crois pas.
Ajouter des "si machin ...", "si bidule ..." ne change rien. Il y a des choses qui doivent marcher et ne marchent pas encore de façon satisfaisante (l'hibernation par exemple). Ces dernières n'ont pas à être justifiées par des "si ...".
Ah, interesting. We are not trying to solve the same problem, which
might explain why it's so hard to converge to a single solution.
The problem I am interested in solving is:
It is currently difficult for people not involved in Debian
development (upstream, other distros, users) to know which patches we
applied, the reason for the patch, and whether they should be
interested in that patch or not.
C'est "marrant". Parce que le problème, même s'il est recentré, n'est pas principalement ici (même si le problème décrit n'est pas à négliger). Le problème est de remonter les patchs upstream. Les développeurs upstream ne vont pas regarder les patchs de Gentoo, de Mandriva, de Red Hat, de Novell, Fedora, Ubuntu, Mepis, etc.
Mouaif.
Tu es plus spécifique (voire plus). Et probablement plus dans le vrai.
Mais ma description peut être une conséquence visible du problème que tu donnes.
> Aussi, tu peux être certain que le problème révélé cette semaine n'aboutira à aucun changement structurel
J'ai parcouru rapidement la liste devel de Debian. J'ai tendance à te donner raison.
Ça oublie souvent l'essentiel pour verser dans les trucs accessoires.
Avant de définir ce qu'il faut, ça commence par discuter sur comment le faire (git, guild, etc), etc.
Si quelqu'un dit que la règle doit être de renvoyer les patchs upstream, t'en a 10 qui disent que non car certains projets sont morts, etc. Ça oublie que les règles ont des exceptions...
Je caricature, mais c'est l'impression que ça donne.
Effectivement, on peut s'intéroger s'il sortira quelque chose de tout ça.
Et comment tu automatiques la création de clés que tu as été obligé d'anuler ?
Surtout si les clés ne sont pas à toi....
Tu définis les passphrase puis tu les envois par mail... Automatiquement...
Ça fait peur.
> mais croire que tu dois générer chaque clé à la mimine n'est pas forcément réaliste.
Tu devrais. Les clés c'est précieux. Ça ne doit pas se faire à la chaine.
> Si on veut être rigoureux et extrême,dans le etc il y a tout logiciels que tu n'a pas auditer, donc toutes les distribs a peu de choses près, donc fedora et redhat.
Ben oui.
> Ah tiens y'a pas que tes deux ennemis jurer (a t'en entendre parler).
Je suis cohérent. Je ne dis pas qu'il FAUT être paranoïaque (donc je peux utiliser une Fedora, voire même une Debian si le risque me parait raisonnable). Toi tu dis qu'il FAUT être paranoïaque. Ben utilise rien.
> Il n'y a pas de paranoia en sécurité, mais une prise de risque, qui doit etre fait en connaissance de cause
C'est très différent de "il FAUT être paranoïaque". La prise de risque n'est pas le truc des paranos (t'avais remarqué ça ?).
> qui doit etre fait en connaissance de cause
Dans le cas de la sécurité, ce n'est pas vraiment ça.
Si je suis cascadeur, je vais prendre des risques. Je dois les faire en connaissance de cause. Je vais par exemple prendre plus de risque de d'habitude pour faire une belle cascade. Mais prendre des risques pour la sécurité n'est pas logique. Par contre même si je suis cascadeur, je peux avoir un conseillé sécurité qui va me dire de mettre un casque. Ce n'est pas le conseillé sécurité qui prend les risques, c'est moi. C'est moi qui doit être conscient des risques.
Pour la sécurité, je dois analyser les risques et faire pour en prendre le moins possible pour un contexte donné (par exemple ça ne veut pas dire qu'il faut annuler la belle cascade dangereuse, mais la rendre moins dangereuse).
> Et vouloir faire croire le contraire est, excuse moi mais je n'ai pas d'autres mots, complètement idiot.
Soit pas "idiot", reste parano, débranche toi d'Internet alors.
> Une phrase, deux affirmations, toutes les deux fausses.
OK, je m'excuse.
Mais au début, tes propos ce n'étaient pas vraiment ça...
https://lists.ubuntu.com/archives/sounder/2006-January/00363(...)
4. The Premise. The vision behind DCC, which is indeed compelling, is that it would provide a common platform for certification, and that the distros that make up the DCC would all ship exactly that same core. But it strikes me that this approach has never worked in the past. In fact, every distro ALWAYS modifies elements of the core, and with good reason. And while we would love that not to be the case, the truth is that the reasons to specialise outweigh the benefits of homogeneity. Much as it may be compelling, the common core idea is ultimately flawed, because it's not just the bits at the core that matter. An ISV that certifies an OS is not just certifying the pieces on which it's app depends. It's also certifying the *environment* which it will support, which includes installer, documentation, even packaging. Screenshots, for example, won't be useful unless they reflect all of the certified OS's, and that's not possible in the DCC model. There have been several examples of places where this idea has failed. United Linux is one.
Joli retournement de veste Monsieur Mark Shuttleworth.
De l'article :
- "Ainsi on élimine la nécessité des sémaphores (sans doute destinés à mourir de leur belle mort)"
Le "sans doute destinés à mourir de leur belle mort" est me semble-t-il de trop.
Ils resteront. Au moins pour les applis qui ont besoin de sémaphore (ce qui ne peut être géré que par le noyau).
In practice, that upper limit is almost always set to one, resulting in semaphores which are used as a straightforward mutual exclusion primitive.
Dans ce contexte, je comprend.
Mais en général on utilise pas un semaphore si on a besoin d'un mutex (c-à-d d'un simple lock). Or c'est ce que faisait Linux (pour des raisons historiques).
Nul doute que reno savait ça...
Mais il se l'est gardé pour lui...
Copyright (c) 1999 Software in the Public Interest
1. Ce logo ne peut être utilisé que si :
* le produit pour lequel il est utilisé est conçu en utilisant une procédure documentée et publiée sur www.debian.org (par exemple la création de cédéroms officiels) ou ;
* une approbation officielle est fournie par Debian pour l'utiliser à cette fin.
2. Il peut être utilisé si une composante officielle de Debian (décidée en utilisant les règles du 1.) fait partie du produit complet, et à condition qu'il soit clairement précisé que seule cette composante est approuvée officiellement.
3. Nous nous réservons le droit de révoquer la licence pour un produit.
La permission d'utiliser le logo officiel sur les vêtements (chemises, couvre-chefs, etc.) sera accordée à condition qu'ils soient fabriqués par un développeur Debian et qu'ils ne soient pas vendus à des fins lucratives.
> On peut alors considérer que la JVM est bien un programme, et que le bytecode entre dans la catégorie des données.
Et un source en C ce n'est pas un programme mais des données pour un compilateur...
Arrêtons ce genre de masturbation intellectuelle.
> Concernant les fichiers de type "artwork", dans la mesure où ils sont indispensables au fonctionnement d'un logiciel, je trouverais normal qu'on attache autant d'importance au fait qu'ils soient libres. (n'est-ce pas le même genre de débat qui a entraîné le fork de Firefox en Iceweasel, etc ?)
Concernant Firefox, le artwork sous trademark n'est absolument pas nécessaire au fonctionnement du programme.
Contrairement à une certaine propagande... par défaut la compilation de Firefox n'utilise pas le artwork de Firefox.
Il n'y a rien à faire pour ne pas l'utiliser, pas besoin de faire de fork, etc.
En passant, le artwork de Debian est aussi sous la protection des marques...
Donc tu n'es pas libre de faire ce que tu veux avec (comme le artwork de Firefox, de Fedora, d'Ubuntu, de Mandriva, etc).
Tu parles de sémaphores et de mutex. Tu dis que c'est la même chose ou le laisse entendre.
Je ne connais pas grand chose au fonctionnement interne du noyau, mais mutex et sémaphore ne sont pas la même chose.
On peut utiliser un sémaphore comme un mutex, mais pas l'inverse. Certe, on peut implémenter les sémaphore uniquement avec les mutex, mais c'est n'est pas trivial.
Es-ce que j'ai rien compris ou as-tu fait un raccourcis pour simplifier ?
J'ai survolé. Mais c'est un autre problème. C'est un problème de licence qui ne permet pas la distribution.
Fedora ne fournit pas de blob si la licence ne le permet pas.
Fedora a le même problème que ce que tu pointes : http://fedoraproject.org/wiki/SIGs/FirmWare
Corriger ce problème n'est pas suffisant pour être conforme à la définition de distribution libre de la FSF.
[^] # Re: toujours cette maladie...
Posté par IsNotGood . En réponse au journal FSF et distributions. Évalué à 0.
Dire que la FSF dit des conneries.
Que le fait que Gnewsens et d'autres qui virent les blobs dans les sources du kernel vanilla font du vent.
Etc.
[^] # Re: Merci pour cette information.
Posté par IsNotGood . En réponse au journal FSF et distributions. Évalué à 1.
Elles ne sont pas libres selon la FSF.
J'ai voulu t'expliquer pourquoi, ... mais tu t'en branles.
T'es comme MS avec l'ISO, tout ce qui t'importe c'est de savoir si tu as le label ou non afin de l'afficher.
> Est ce que tu peux définitivement essayer de faire un commentaire sans parler de RedHat ou Fedora ?
Ici tous mes commentaires ne parlent que de Red Hat et Fedora.
La FSF a fait un guide uniquement pour Red Hat et Fedora.
Mon journal porte sur le guide de la FSF pour Red Hat et Fedora.
Lorsqu'il est parlé de blob dans le kernel vanilla ça ne conserne que Red Hat et Fedora.
Les blob ne concerne que Red Hat et Fedora.
Il faut être très con pour voir que les choses comme ça.
T'es très con.
[^] # Re: toujours cette maladie...
Posté par IsNotGood . En réponse au journal FSF et distributions. Évalué à 2.
[^] # Re: Une position claire
Posté par IsNotGood . En réponse au journal FSF et distributions. Évalué à 2.
http://www.redhat.com/archives/fedora-devel-list/2008-March/(...)
kernel-libre (hopefully 100% Free) for Fedora 8 and rawhide
Le fil de discussion est très intéressant, mais diablement long.
[^] # Re: Une position claire
Posté par IsNotGood . En réponse au journal FSF et distributions. Évalué à 2.
Ni la GPL.
[^] # Re: toujours cette maladie...
Posté par IsNotGood . En réponse au journal FSF et distributions. Évalué à 2.
blob = Binary blob
http://en.wikipedia.org/wiki/Binary_blob
This article is about drivers.
> Les petits bouts de binaire dont tu parles sont généralement des référencements aux registres, à la mémoire, etc. du hardware.
Non, il y a des petit blob. Je ne vois pas pourquoi il n'y aurait que des gros blob.
> Les petits bouts de binaire dont tu parles sont généralement des référencements aux registres, à la mémoire, etc. du hardware.
Tu parles peut-être d'autres choses. On peut souvent depuis Linux écrite dans des registres d'un périphérique. souvent ceci ne demande pas de blob (de binaire téléchargé sur le périphérique) mais seulement la doc du périphérique.
Notons bien que Linux n'a pas besoin de télécharcher un blob dans le périphérique pour écrire le blob dans le périphérique :-)
Ça serait impossible.
[^] # Re: Une position claire
Posté par IsNotGood . En réponse au journal FSF et distributions. Évalué à 2.
J'applaudis aussi.
L'avis de la FSF a toujours une forte valeur.
Ça peut aussi clarifier les choses. Pas dans une logique uniquement binaire (libre/non-libre), mais aussi pour qualifier une distribution.
On peut maintenant dire de Fedora (et d'autres) : "OK elle n'est pas libre selon la FSF, mais uniquement car elle intégre des blob-firmwares". On ne trompe pas sur la marchandise, on qualifie de façon courte mais assez précise et par rapport à une référence qu'est la FSF.
C'est vraiment bienvenu.
J'espère que la FSF ira plus loins dans la précision de la défintion pour aussi inclure quelques éléments du projet (fait-il la promotion du proprio (downloade en un clique sans warning), etc).
> On notera que RMS était plus conciliant au sujet de l'inclusion des firmware au début des discussions.
Je n'ai qu'un vague souvenir, mais il me semble que les propos de RMS étaient plus ciblés. De mon souvenir il disait que les blob-firmware étaient légaux (puisque Linus les accèpte et les considères comme des "données" (pour simplifier)) et donc il n'y a pas de violation de la GPL. En gros ici, RMS respecte l'avis de Linus.
Mais je n'ai pas souvenir qu'il disait que pour une distribution c'était OK pour la qualifier de libre. L'avis de Linus est respecté pour Linux, mais il n'est pas pris en compte pour la distribution (qui contient un nombre indéterminé de logiciels). La FSF ne peut pas dire : pour le projet Linux c'est OK, pour bidule ce n'est pas OK, pour machin c'est ...
Elle ne peut pas nom plus dire que c'est systématiquement OK pour les blobs pour tous les projets. Exemple fictif, imaginons un FS mais dans un blob. Pour l'utiliser il faut le charcher dans un périphérique (une carte raid par exemple) puis le noyau l'utilise via des appels au périphérique. Ça serait clairement une violation de la GPL (au moins dans l'esprit).
Linux a un historique et offre des protections (il n'y a qu'un nombre limité d'API qui n'impose pas la GPL, etc). Mais pour d'autres noyaux ?
Le document de la FSF n'est pas écrit spécifiquement pour GNU/Linux.
> Il serait intéressant pour Fedora de proposer un noyau 100% libre selon la FSF dans les dépôts, voire même un spin dédié (que ce soit via jigdo ou bien un fichier kickstart)
Non :-)
Du moins, pas comme ça.
Ce que tu proposes, c'est comme si Fedora avait livna par défaut et qu'il existait des spins (pour caricaturer des "sous-distributions") sans livna.
A mon avis, si Fedora veut virer les blobs, la distribution officielle Fedora (c'elle supportée et développée par Fedora) ne doit pas avoir de blobs.
Le noyau avec les firware (ou seulement les firmwares) doivent être ailleurs (par exemple livna). Idem pour les spins (notons qu'on peut aussi ajouter des dépôts lors de l'installation ce qui rend les spins non indispensables pour la majorité des installations).
La version la plus libre de Fedora ne doit pas être le parent pauvre de Fedora, la moins supporté/testé/développé par Fedora. Bien au contraire.
Après chaqu'un est libre, de sa propre initiative, en fonction de son matériel, de "polluer" la distribution avec des blobs, Flash, des drivers proprio, etc.
Ce modèle, même s'il est beaucoup critiqué car il demande des actions supplémentaier à beaucoup l'utilisateur, marche. Les contributeurs le respectent très bien. La communcation de Fedora gagne en cohérence en gardant ce modèle. Je ne veut pas d'un GoFedora parent pauvre de Fedora :-)
[^] # Re: toujours cette maladie...
Posté par IsNotGood . En réponse au journal FSF et distributions. Évalué à 2.
Je ne doute pas de la sincérité de ton propos. D'ailleurs je pensais la même chose.
Mais il me semble avoir vu Alan Cox dire que certains blobs sont développés avec un éditeur hex (ou un truc style "{ 0x01, 0xF7, ...}").
Le problème par rapport à l'esprit de la GPL n'est alors pas l'absence le source (plus présicément la forme utilisé pour le développement), mais la doc. Par que pour ce type de blob, mais si tu as le source, c'est quasi impossible à modifier (et que ça marche).
> Tous les blobs que j'ai déjà vu sont beaucoup trop gros pour avoir été fait à la main...
Pour ceux dans /lib/firmware probablement. Mais les sources de Linux ont aussi des blogs qui sont très petits.
[^] # Re: Un nouveau pas !
Posté par IsNotGood . En réponse à la dépêche Lemon : Gérez votre caisse en toute liberté !. Évalué à 2.
La dépêche a faire l'erreur, et maintenance c'est un commentaire.
Qt4 n'est pas un language de programmation.
Pourquoi pas "développé en libc" alors.
[^] # Re: Pas à l'utilisateur de deviner
Posté par IsNotGood . En réponse à la dépêche Gestion de l'énergie : se dépêcher de ne rien faire. Évalué à 1.
Il ne parle que du cpu.
Il ne parle pas de l'écran (gros consommateur), de l'ajustement de la consommation de l'écran en fonction de l'utilisation du portable, de l'intéraction qu'il faut mettre en place avec l'utilisateur, etc.
Idem pour les disques dures.
Idem pour suspend.
Etc.
Le titre de la dépêche est trompeur ("Gestion de l'énergie : se dépêcher de ne rien faire"). Je ne peux pas croire que c'est ce que veut dire Matthew Garret (sauf peut-être pour le cpu).
On est dans un domaine facilement mesurable et la doc sur la consommation du cpu en fonction de la fréquence, etc doit être disponible.
Il suffit donc d'utiliser une calculatrice pour valides ou invalider ses propos.
Je pense qu'il a fait ce boulot :-)
Si au final il est claire que pour une même quantité de travail demandée au cpu il y a la même consommation d'énergie, il est un peu con de se faire chier avec la fréquence du cpu. Il est ridicule d'implémenter un truc qui n'apporte rien. D'autant plus qu'il y a beaucoup de boulot ailleurs et que les ressources sont limités.
Est-il raisonnable d'implémenter quelques chose pour le cas où les technologies des cpu changent ?
Je ne crois pas.
Ajouter des "si machin ...", "si bidule ..." ne change rien. Il y a des choses qui doivent marcher et ne marchent pas encore de façon satisfaisante (l'hibernation par exemple). Ces dernières n'ont pas à être justifiées par des "si ...".
[^] # Re: Mesures qui seront prises ?
Posté par IsNotGood . En réponse à la dépêche Découverte d'une faille de sécurité critique dans OpenSSL de Debian. Évalué à 2.
Un message après un très long thread :
http://lists.debian.org/debian-devel/2008/05/msg00681.html
Ah, interesting. We are not trying to solve the same problem, which
might explain why it's so hard to converge to a single solution.
The problem I am interested in solving is:
It is currently difficult for people not involved in Debian
development (upstream, other distros, users) to know which patches we
applied, the reason for the patch, and whether they should be
interested in that patch or not.
C'est "marrant". Parce que le problème, même s'il est recentré, n'est pas principalement ici (même si le problème décrit n'est pas à négliger). Le problème est de remonter les patchs upstream. Les développeurs upstream ne vont pas regarder les patchs de Gentoo, de Mandriva, de Red Hat, de Novell, Fedora, Ubuntu, Mepis, etc.
Ils ne l'ont pas fait pour cette faille...
[^] # Re: Si au moins ils allaient jusqu'au bout...
Posté par IsNotGood . En réponse au journal FSF et distributions. Évalué à 2.
Je le fais quasiment toujours.
Pas ici car 2PetitsVerres ne l'a pas fait (ce qui m'a un peu énervé :-)).
[^] # Re: Mesures qui seront prises ?
Posté par IsNotGood . En réponse à la dépêche Découverte d'une faille de sécurité critique dans OpenSSL de Debian. Évalué à 2.
Mouaif.
Tu es plus spécifique (voire plus). Et probablement plus dans le vrai.
Mais ma description peut être une conséquence visible du problème que tu donnes.
> Aussi, tu peux être certain que le problème révélé cette semaine n'aboutira à aucun changement structurel
J'ai parcouru rapidement la liste devel de Debian. J'ai tendance à te donner raison.
Ça oublie souvent l'essentiel pour verser dans les trucs accessoires.
Avant de définir ce qu'il faut, ça commence par discuter sur comment le faire (git, guild, etc), etc.
Si quelqu'un dit que la règle doit être de renvoyer les patchs upstream, t'en a 10 qui disent que non car certains projets sont morts, etc. Ça oublie que les règles ont des exceptions...
Je caricature, mais c'est l'impression que ça donne.
Effectivement, on peut s'intéroger s'il sortira quelque chose de tout ça.
[^] # Re: Une réaction sur Debian Planet en français
Posté par IsNotGood . En réponse à la dépêche Découverte d'une faille de sécurité critique dans OpenSSL de Debian. Évalué à 1.
Et comment tu automatiques la création de clés que tu as été obligé d'anuler ?
Surtout si les clés ne sont pas à toi....
Tu définis les passphrase puis tu les envois par mail... Automatiquement...
Ça fait peur.
> mais croire que tu dois générer chaque clé à la mimine n'est pas forcément réaliste.
Tu devrais. Les clés c'est précieux. Ça ne doit pas se faire à la chaine.
[^] # Re: Mise en perspéctive
Posté par IsNotGood . En réponse à la dépêche Découverte d'une faille de sécurité critique dans OpenSSL de Debian. Évalué à 2.
Ben oui.
> Ah tiens y'a pas que tes deux ennemis jurer (a t'en entendre parler).
Je suis cohérent. Je ne dis pas qu'il FAUT être paranoïaque (donc je peux utiliser une Fedora, voire même une Debian si le risque me parait raisonnable). Toi tu dis qu'il FAUT être paranoïaque. Ben utilise rien.
> Il n'y a pas de paranoia en sécurité, mais une prise de risque, qui doit etre fait en connaissance de cause
C'est très différent de "il FAUT être paranoïaque". La prise de risque n'est pas le truc des paranos (t'avais remarqué ça ?).
> qui doit etre fait en connaissance de cause
Dans le cas de la sécurité, ce n'est pas vraiment ça.
Si je suis cascadeur, je vais prendre des risques. Je dois les faire en connaissance de cause. Je vais par exemple prendre plus de risque de d'habitude pour faire une belle cascade. Mais prendre des risques pour la sécurité n'est pas logique. Par contre même si je suis cascadeur, je peux avoir un conseillé sécurité qui va me dire de mettre un casque. Ce n'est pas le conseillé sécurité qui prend les risques, c'est moi. C'est moi qui doit être conscient des risques.
Pour la sécurité, je dois analyser les risques et faire pour en prendre le moins possible pour un contexte donné (par exemple ça ne veut pas dire qu'il faut annuler la belle cascade dangereuse, mais la rendre moins dangereuse).
> Et vouloir faire croire le contraire est, excuse moi mais je n'ai pas d'autres mots, complètement idiot.
Soit pas "idiot", reste parano, débranche toi d'Internet alors.
> Une phrase, deux affirmations, toutes les deux fausses.
OK, je m'excuse.
Mais au début, tes propos ce n'étaient pas vraiment ça...
# Re:
Posté par IsNotGood . En réponse au journal Mark Shuttleworth : il remet (encore) ça. Évalué à 2.
4. The Premise. The vision behind DCC, which is indeed compelling, is that it would provide a common platform for certification, and that the distros that make up the DCC would all ship exactly that same core. But it strikes me that this approach has never worked in the past. In fact, every distro ALWAYS modifies elements of the core, and with good reason. And while we would love that not to be the case, the truth is that the reasons to specialise outweigh the benefits of homogeneity. Much as it may be compelling, the common core idea is ultimately flawed, because it's not just the bits at the core that matter. An ISV that certifies an OS is not just certifying the pieces on which it's app depends. It's also certifying the *environment* which it will support, which includes installer, documentation, even packaging. Screenshots, for example, won't be useful unless they reflect all of the certified OS's, and that's not possible in the DCC model. There have been several examples of places where this idea has failed. United Linux is one.
Joli retournement de veste Monsieur Mark Shuttleworth.
[^] # Re: Sémaphore et mutex
Posté par IsNotGood . En réponse à la dépêche La fin du verrou global dans le noyau Linux ?. Évalué à 5.
- "Ainsi on élimine la nécessité des sémaphores (sans doute destinés à mourir de leur belle mort)"
Le "sans doute destinés à mourir de leur belle mort" est me semble-t-il de trop.
Ils resteront. Au moins pour les applis qui ont besoin de sémaphore (ce qui ne peut être géré que par le noyau).
[^] # Re: Sémaphore et mutex
Posté par IsNotGood . En réponse à la dépêche La fin du verrou global dans le noyau Linux ?. Évalué à -1.
In practice, that upper limit is almost always set to one, resulting in semaphores which are used as a straightforward mutual exclusion primitive.Dans ce contexte, je comprend.
Mais en général on utilise pas un semaphore si on a besoin d'un mutex (c-à-d d'un simple lock). Or c'est ce que faisait Linux (pour des raisons historiques).
Nul doute que reno savait ça...
Mais il se l'est gardé pour lui...
[^] # Re: Si au moins ils allaient jusqu'au bout...
Posté par IsNotGood . En réponse au journal FSF et distributions. Évalué à 2.
[^] # Re: Si au moins ils allaient jusqu'au bout...
Posté par IsNotGood . En réponse au journal FSF et distributions. Évalué à 2.
1. Ce logo ne peut être utilisé que si :
* le produit pour lequel il est utilisé est conçu en utilisant une procédure documentée et publiée sur www.debian.org (par exemple la création de cédéroms officiels) ou ;
* une approbation officielle est fournie par Debian pour l'utiliser à cette fin.
2. Il peut être utilisé si une composante officielle de Debian (décidée en utilisant les règles du 1.) fait partie du produit complet, et à condition qu'il soit clairement précisé que seule cette composante est approuvée officiellement.
3. Nous nous réservons le droit de révoquer la licence pour un produit.
La permission d'utiliser le logo officiel sur les vêtements (chemises, couvre-chefs, etc.) sera accordée à condition qu'ils soient fabriqués par un développeur Debian et qu'ils ne soient pas vendus à des fins lucratives.
[^] # Re: Si au moins ils allaient jusqu'au bout...
Posté par IsNotGood . En réponse au journal FSF et distributions. Évalué à 2.
Et un source en C ce n'est pas un programme mais des données pour un compilateur...
Arrêtons ce genre de masturbation intellectuelle.
> Concernant les fichiers de type "artwork", dans la mesure où ils sont indispensables au fonctionnement d'un logiciel, je trouverais normal qu'on attache autant d'importance au fait qu'ils soient libres. (n'est-ce pas le même genre de débat qui a entraîné le fork de Firefox en Iceweasel, etc ?)
Concernant Firefox, le artwork sous trademark n'est absolument pas nécessaire au fonctionnement du programme.
Contrairement à une certaine propagande... par défaut la compilation de Firefox n'utilise pas le artwork de Firefox.
Il n'y a rien à faire pour ne pas l'utiliser, pas besoin de faire de fork, etc.
En passant, le artwork de Debian est aussi sous la protection des marques...
Donc tu n'es pas libre de faire ce que tu veux avec (comme le artwork de Firefox, de Fedora, d'Ubuntu, de Mandriva, etc).
# Sémaphore et mutex
Posté par IsNotGood . En réponse à la dépêche La fin du verrou global dans le noyau Linux ?. Évalué à 3.
Je ne connais pas grand chose au fonctionnement interne du noyau, mais mutex et sémaphore ne sont pas la même chose.
On peut utiliser un sémaphore comme un mutex, mais pas l'inverse. Certe, on peut implémenter les sémaphore uniquement avec les mutex, mais c'est n'est pas trivial.
Es-ce que j'ai rien compris ou as-tu fait un raccourcis pour simplifier ?
[^] # Re: Un petit correctif
Posté par IsNotGood . En réponse à la dépêche La fin du verrou global dans le noyau Linux ?. Évalué à 6.
[^] # Re: Merci pour cette information.
Posté par IsNotGood . En réponse au journal FSF et distributions. Évalué à 2.
Je ne crois pas.
Gnewsense vire tous les blobs (même ceux dans le kernel vanilla).
Un employé Red Hat a fait un "kernel-libre" pour virer les blob :
http://www.redhat.com/archives/fedora-devel-list/2008-March/(...)
Je crois qu'il y a certains trucs que tu n'as pas compris.
Il faut reconnaitre que ce n'est pas simple .
[^] # Re: Merci pour cette information.
Posté par IsNotGood . En réponse au journal FSF et distributions. Évalué à 2.
J'ai survolé. Mais c'est un autre problème. C'est un problème de licence qui ne permet pas la distribution.
Fedora ne fournit pas de blob si la licence ne le permet pas.
Fedora a le même problème que ce que tu pointes :
http://fedoraproject.org/wiki/SIGs/FirmWare
Corriger ce problème n'est pas suffisant pour être conforme à la définition de distribution libre de la FSF.