Je n'ai lu que la conclusion du test et elle est bizarre pour ne pas dire tordue.
> Slackware a cette réputation de distribution pas vraiment aisée d'accès mais il faut dire que le passage en 2.6 la rapproche de ses rivaux.
En quoi le passage à Linux 2.6 rend la distribution plus "aisée d'accès" ?
> Il y a encore un peu de travail pour la rendre plus accessible aux débutants mais avec un minimum de lecture et les mains dans le cambouis
"un minimum de lecture et les mains dans le cambouis" va rendre la distrubtion plus accessible aux débutants ?
> c'est une distribution tout à fait utilisable et très stable
Qu'elle soit utilisable est le minimum. Tu ne crois pas ?
Et par "très stable" tu entends quoi ?
Elle ne plante pas ?
Beaucoup de distribution ne plante pas.
> Une fois que vous connaissez les quelques programmes à rajouter pour avoir un système bien géré au niveau paquets et dépendances, cela vous fera une station tout à fait flexible quelque soit votre utilisation sous Linux.
C'est comme ça pour quasiment toutes les distributions. Certains font d'une Mandriva un station de travail ou un serveur, idem pour Fedora, idem pour Gentoo, idem pour SuSE, etc...
> Rah la la tu m'a l'air particulièrement stressé.
Oui mais rien à voir avec linuxfr. Je suis sur un programme salement compliqué depuis des semaines et tout est en chantier. Je m'arrache les cheveux par poignés. M'enfin, le bout du tunnel n'est pas loins.
> Pour tout t'avouer, j'ai pas pigé grand chose de ton histoire de signature de paquet qui du coup permet des miroirs
Voilà le problème. Imaginons qu'Adobe ne signe pas ses paquets ;
- Adobe met un paquet flash à disposition sur un serveur https super sécurisé.
- Adobe autorise que les mirroirs à copier le paquet flash afin de soulager son serveur super sécurisé.
- Un mirroir peu sécurisé à le paquet flash.
- Un cracker profite du fait que le mirroir est peu sécuriser pour cracker le paquet flash (le remplacer avec un qui a un trou de sécurité par exemple).
- Je downloade le paquet flash cracké sur le mirroir.
- Je suis baisé (et je ne sais pas par qui)
Par contre, si le paquet est signé, je ne suis pas baisé. Mais imaginons que je sois baisé (le paquet a un virus), je sais par qui (Adobe). Donc je peux lui casser la gueule (ou seulement faire un procès). C'est très très important une signature gpg ! C'est comme une signature sur un chèque mais en moins violable.
Le paquet adobe-release.rpm contient la signature Adobe et le fichier de configuration yum.
Le fichier de configuration yum : [adobe-linux]
name=Adobe Systems Incorporated
baseurl=http://linuxdownload.adobe.com/linux/$basearch/
enabled=1 gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-adobe-linux
Une clée n'ait importé dans la base rpm qu'avec confirmation de l'utilisateur. C'est évidemment à l'utilisateur de dire si telle ou telle clée (ou fournisseur (de paquet ici)) est de confiance. C'est de sa seule responsabilité.
Imaginons que le paquet sur free.fr a été cracké. Lorsque je fais "yum update", yum va voir qu'il y a un nouveau paquet flash (sur mirroir.free.fr). Yum va donc le downloader et tenter l'installation. Mais l'installation va échouer car le paquet n'a pas la bonne signature (donc il n'a pas été fait par Adobe).
> Mais ça à l'air vachement bien pour les fedora/red hat
Ça me semble assez facile à réaliser pour les autres distributions.
> Mais arrêter de rebaver les mêmes conneries. C'est du xml DONC tout le monde peut lire...
Tu n'as pas compris. Un fichier xml est lu par un parser xml. S'il y a un champ supplémentaire inconnu, l'appli peut l'ignorer (c'est ce que fait Firefox etc).
> Ce serait un .ini on saurait pas ?
Il n'y a pas qu'un parser de fichier .ini. Ajoute un champ à un fichier .ini, et tout peu exploser. C'est au cas par cas.
> Ce serait un binaire avec une explication de comment il marche on saurait pas ?
Ça serait un truc qui fait comme xml pour les fonctionnalités qu'on demande à xml, ça le ferait. Évidemment. Il n'y a rien d'incoutournable.
> Ce serait un fichier text quelconque on saurait pas ?
Un fichier xml est un fichier text (sauf quelques exceptions). Son intérêt est qu'il n'est pas un fichier text quelconque. Mais un fichier dont les données sont structurés et accessibles. Pas de code spécifique à faire (à la fichier .ini), il suffit d'avoir un parser xml (qui répond à des spec très précises). Il y a aussi des outils pour faire des requêtes dans les fichiers xml, etc...
Évidemment, ça n'empêche qu'un fichier xml (qui a un format) soit rigoureusement documenté. C'est la même chose pour un fichier ini, etc...
Tu peux mettre tes données dans un fichier text quelconque. Mais essai avec un base de donnée. Tu verras, c'est plus cool.
> Tu peux faire un fichier xml illisible.
Tu peux faire un fichier .ini ou text quelconque illisible. Je ne vois pas où tu veux en venir. Tu n'as pas besoin d'xml pour ça.
Et illisible n'est pas le bon terme. Le fichier est forcément lisible. C'est ininterprétable le bon terme.
Fichier xml ou fichier texte quelconque, il faut une doc qui dit ce que signifie le contenu. C'est comme ça pour tout contenu. "Vin" signifie : "c'est un liquide, pas trop nocif, et qui fait rire". "Vin" a une signification, car on lui a donné une signification. C'est idem pour un fichier text quelconque ou pour un fichier xml.
> Oui, il y a des avantages au xml, mais pas ceux là. Merci donc de ne pas les citer comme une conséquence logique.
Documente toi, et prend un peu de recul.
> Et a mon sens c'est une mauvaise chose
Je trouve que c'est une bonne chose.
> maintenant ça c'est subjectif.
Idem pour moi.
> Donc qu'ils soient ou non dans yum je vois pas exactement le rapport.
Le format des dépôts yum n'a pas été fait pour être spécifique à rpm/yum.
Dès l'origine il a été pris en compte que le format de dépots yum supporte les paquets .deb. Des développeurs debian ont participés aux discussions initiales sur le format de dépôt yum mais ça n'a pas abouti de façon concrête.
Notons que le format apt marche pour rpm et deb. On trouvait beaucoup de dépot au format apt pour Red Hat/Fedora il y a quelques années. Maintenant on trouve rarement du apt pour les dépôt Red Hat/Fedora.
> Si ton cracker pose son code directement dans flash sans que le dev le vois, tu l'as dans l'os.
Ben non.
> Dans tous les cas quand tu accepte un code sans l'avoir entierement compris (et même comme ça) tu t'expose à un danger potentiel.
Tu veux me faire croire que tu comprends tout le code de ton OS ?
Un peu de sérieux...
Par contre Debian pourrait peut-être s'inspirer de ce qui est fait avec yum. Ça évitera de "tripatouiller" les fichiers de configuration apt et d'importer une clée à la main. Ça ne doit pas être bien compliqué à faire (si ce n'est pas déjà fait).
Merci.
Enfin un commentaire avec "Debian" dedans, qui est fort à propos, et qui n'est pas dans la catégorie "j'en ai une plus grosse que toi".
Ce que fait Opera avec Debian (et ses déclinaisons) est aussi cool que ce que fait Adobe avec Fedora (et toutes les distributions qui utilisent rpm/yum). Ce sont des choses comme ça qu'il faut et non des intermédiaires qui repackagent, des bugzilla séparés, etc...
Pour du logiciel proprio (où on n'a pas accès au source) c'est le plus approprié, c'est très "confortable" et sûr.
Pour être claire, j'en ai rien à foutre de savoir que Debian en a une plus grosse ou pisse moins loins que bidule.
Du moins ici, dans ce journal.
Ce journal montre une boite proprio qui fournit du logiciel de façon "standard" et/ou intégré à une distribution.
La majorité des boites proprios lorsqu'elle fait du logiciel pour Linux, les fournit de façon "bâtarde". Typiquement un .rpm au fond d'un site ftp, et donc pas de mise à jour automique. C'est à toi de "checker" régulièrement le site ftp pour voir s'il n'y a pas une mise à jour. C'est particulièrement dangereux pour des programmes qui sont de bonnes cibles pour les crackers.
Par exemple, le paquet adobe-release a aussi la clée gpg qui a signé les paquets. Donc de façon tout à fait intégrée, rpm/yum contrôle la signature du paquet. Ceci permet à Adobe d'autoriser les mirroirs (sauf pour adobe-release qui a la clée). Si un mirroir est cracké (et le paquet flash-plugin.rpm) le paquet ne sera pas installé.
Tous ça n'a rien de nouveau, c'est fait par Fedora et ceux qui fournissent des dépôts pour Fedora depuis des lustres. Probablement que d'autres distributions font de même.
Mais c'est la première fois que je vois ça pour une boite qui fournit du proprio.
Certes, toutes les distributions n'ont pas rpm/yum. Mais je crois qu'il existe des utilitaires pour installer des paquets rpm sur Debian par exemple. Les dépôts yum sont des fichiers xml et donc tout le monde peut les lires facilement voire les étendre si necessaire sans que ça perturbe le fonctionnement des utilisateurs de yum.
NB : un temps il était prévu que les dépots .deb se base sur les dépôts yum.
> acroread, nero, vmware, virtual box.
J'ignore la réponse à toutes ces questions :
- les paquets acroread sont signés et dispo via yum ?
- les paquets nero sont signés et dispo via yum ?
- ... vmware ... ?
- ... virtual box ... ?
Je suis très très content qu'une boite suive enfin le "logiciel libre touch" en matière d'installation de logiciel. Notamment pour la signature des paquets et la prise en compte du système de gestion de paquet (donc mise à jour automatique ce qui est très très très important pour la sécurité).
Que Debian aille checker tous les jours le site d'Adobe pour voir s'il y a une nouvelle version afin que les utilisateurs de Debian soit à jour, c'est bien.
Qu'Adobe nous fournisse ce service c'est mieux (pas d'intermédiaires, pas de duplication d'effort).
Debian et le proprio ça fait un. C'est leur truc (malgres les discours).
Fedora n'est pas "aussi intelligent" que Debian.
Sinon il y a aussi Linpire, Xandros, etc qui ont le Debian touch.
Les services secrets dans un parlement démocratique, ça fait très bizarre alors qu'ils doivent travailler avec une certaine transparence.
Pas très sérieux pour une démocratie...
Pour le ministre des affaires étrangères, etc je comprend un peu plus.
> Marant ça, j'aurais plutot dit ça des linuxiens qui sont toujours en train de dire du mal des licences BSD et qui pourtant utilisent allègrement du code sous cette license...
La licence est effectivement critiquée. Mais les outils récupérés rarement.
OK sur ce point ? Je n'aime pas la licence BSD, je critique très rarement les programmes sous BSD que j'utilise.
Que BSD critique la licence GPL, OK. Il y a incompatibilité de "philosophie".
Qu'ils critiquent aussi abondamment des programmes (L)GPL qu'ils utilisent librement => PAS OK.
> Plus sérieusement, si des outils GNU sont utilisés, c'est souvant du fait de la transmission à sens unique BSD -> GPL, par manque de bras pour tout reprendre ou par volonté de ne pas réinventer la roue, rarement en raison de la propreté du code.
Et alors ?
Il récupère un truc dont ils ont besoin et qu'ils ne peuvent pas faire. Il n'y a pas de raison de se plaindre. Et s'ils n'en veulent pas ? Ben qu'ils n'utilisent pas.
Si je ne veux pas d'un programme BSD, ben je ne l'utilise pas. Si je l'utilise alors je l'ai choisi et donc j'en suis satisfait (et donc je ne le critique pas).
C'est très très probablement une erreur de configuration du noyau. Le "2.6.22 a tué HAL", devient "ma mauvaise configuration de 2.6.22 a tué HAL" voire "mon incompétence a tué HAL".
Bref, journal sans intérêt comme je l'ai dit dans mon premier commentaire.
Que ça n'empêche pas ThK de faire des tests. Mais son journal aurait dû être dans la section forum ou un autre site d'aide.
Que de moinssage pour avoir dit une quasi "évidence".
Ça m'agace toujours de voir des gens critiquer aussi grossièrement ce qu'ils utilisent et notamment quand c'est du logiciel libre. Si ça ne leur plait pas, qu'ils fassent des patchs.
C'est assez typique des *BSD. Qu'ils n'utilisent pas les outils GNU pour qu'on ait la paix. Ben oui, ils ont *librement* choisi d'utiliser les outils GNU. Personne les a contraint.
Vous imaginez comme je passerais pour un con, si ayant librement choisi d'utiliser la distribution X je disais : "I have always thought that X was a horrid mess of unnecessary complexity, legacy, and overhead.".
Fedora a un autre mécanisme dont j'ai oublié les détails (voir le fichier .spec du noyau qui est riche d'information et particulièrement bien foutu). Le système Fedora était prévu pour être upstream (c'est déjà fait ?).
Quoiqu'il en soit, un "make oldconfig" n'est pas toujours satisfaisant (bien qu'il peut corriger quelques pépins automatiquement).
Il faut le dire et redire, il n'y a pas de garantit de compatibilité ascendante dans Linux (aussi bien binaire que source). Linus c'est déjà exprimé au moins 2^73 fois pour expliquer les tenants et aboutissants de cette position. Si un noyau x+1 marche mal alors qu'un x marche bien, c'est "normal" (ou prévisible) s'il n'y a pas eu de réajustement (config noyau et/ou applis proches noyau (lspci, udev, etc)).
> Le plus intrigant est que le même fichier .config est utilisé avec le 2.6.21.6 et le 2.6.22. Le 21 passe, le 22 cale.
Désolé de te le dire, mais c'est une erreur. Linux ne garantit pas qu'un .config adapté pour la version 2.6.x marche pour 2.6.(x+1).
Il faut donc revoir toute la configuration (avec "make menuconfig" par exemple) et tout contrôler. Pour faire ça bien il faut avoir en tête ce processus pour la version précédante afin de voir les évolutions et faire les adaptions nécessaires.
> Et comme j'ai un peu l'impression d'être le seul à avoir ce problème, j'hésite encore à faire un rapport de bug
Fait un essai avec le noyau 2.6.22 rawhide et la version précompilé. Si ça ne marche toujours pas, ton rapport de bug sera le bien venu (oui oui).
NB : F8 aura un "mass rebuild" (changement de la toolchain et introduction d'incompatibilité). J'ignore si F8 (rawhide) a déjà fait ce "mass rebuild". S'il a déjà été fait, il est possible que le noyau rawhide ne marche pas avec F7 à cause du changement de toolchain, il est possible qu'il ne marche jamais sur F7.
Imaginons que tu ais aussi fait un rapport de bug et qu'un développeur ait dit que le problème vient, par exemple, du udev de F7 qui n'a pas été mis à jour pour 2.6.22 et qu'il faut installer le udev de Rawhide (ben oui, il n'y a JAMAIS de garantit de compatibilité ascendante dans Linux même entre versions mineurs !). Dans ce cas, le problème n'est pas Linux 2.6.22, mais F7 (je ne fais en aucun cas de l'ombre à Fedora, c'est une distribution que j'utilise et adore (actuellement j'utilise FC6 et c'est un vrai bonheur)).
Les choses sont ainsi dans le développement de Linux. Un noyau 2.6.x peut marcher et un 2.6.(x+1) peut ne pas marcher sans que ça soit la faute au noyau. C'est archi connu et c'est pour ça que peu de distribution font des montées en version de noyau même pour des changements de versions mineurs. Fedora fait parti des rares à le faire. Et Fedora le fait avec beaucoup de prudence et d'expertise. Ils sont en mesure de savoir d'où vient le problème et s'il vient du noyau ou non. Et toi ? En tout cas pas moi.
Tu n'as (et beaucoup) pas aimé mon ton. Mais, s'il te plait, à l'avenir fait un rapport de bug. Dire que pour 2.6.x+1, pour une distribution, pour une configuration, ça ne marche pas est sans intérêt. Les développeurs le savent que ça arrive de façon quasi systématique et ça ne remet en rien en cause la version 2.6.x+1. Par contre ils veulent des rapports de bug ! Et principalement ceux qui font des distributions (enfin d'adapter la distribution aux évolutions du noyau ou remonter le bug en upstream).
> Je chercherais sans doute quand j'aurais un peu plus de temps à y consacrer, mais pour l'instant, je reste en 21.6.
Fais un rapport de bug :-)
Si possible fait un essai avec le noyau rawhide (la version précompilé, optionnellement en le compilant toi même). Tu trouveras sans difficulté un tutorial pour compiler un noyau fedora depuis un rpm si tu ne sais pas le faire. C'est important pour conserver les patchs de la distribution.
Bien amicalement. Même très amicalement. C'est important les gens qui testent les dernières versions et je me félicite que tu ais cette passion et patience. Par ma part ce n'est pas mon kife actuellement (manque de temps).
De plus, il faut définir RC. car RC1 chez Linux c'est souvent une beta (voire une alpha) dans d'autres projets. T'es OK sur ce point ?
Pour beaucoup de projet, RC signifie que la version sans la moindre modification est une version finale potentielle. RC signifie, que pour les développeurs et en l'état actuel des tests, c'est une version finale. Qu'il n'y a que des tests utilisateurs qui peuvent changer cet avis. Pour Linux, c'est rarement le cas. Pour le 2.6.22, il semble (je n'ai pas suivi le développement de cette version) que les "vrais" RC étaient RC6 et RC7. Les RC précédentes était des beta/test.
Pourquoi Linux ne fait que des RC ? J'ai oublié les détails, mais en gros l'objectif est de pousser aux tests. Si ce n'est pas labélisé RC, les gens ont tendance à ne pas tester. Le choix de Linus est très "psychologique".
RC n'est pas l'unique synonyme de "seulement bugfix". Pour le projet Fedora à partir de test2 (suivit de test3 et parfois test4) il n'y a que des bugfix et ça appelle test et non RC. Il arrive exceptionnellement que Fedora sorte des RC (souvent semi-confidentielle) juste avant le finale pour vérifier qu'une modification de dernière minutes ne pose pas de problème. Et souvant cette RC est identique à la version finale officielle (au paquet fedora-release près).
Linux a un usage particulier du label RC. Je comprend ce choix.
Mais le projet Linux n'est pas le seul projet, ne dicte pas tout aux autres projets, etc...
Il y a le même problème pour les dépêches, et les dépêches sont bien modifiées. Donc si c'est satisfaisant pour une dépêche, ça doit l'être pour un journal.
En passant, Linux 2.6 n'a que des RC (politique choisi par Linus depuis quelques mois). Ce ne sont pas de "vrais" Release Candidat car il y a ajout de fonctionnalités. Linux 2.4 a des "vrais" RC.
Bonne information.
Mais en passant, la branche Rawhide n'est pas faite pour marcher sur une version stable de Fedora. Si ça marche (et ça arrive souvent) alors tant mieux.
> Par ailleurs, redhat cherche de plus en plus à diminuer le nombre de patchs qu'il appliquent sur le kernel vanilla
Red Hat a toujours fait ça contrairement à ce qui se dit. Il n'y a que pour RHEL où il peut y avoir beaucoup de patchs (Red Hat doit assurer la compatibilité binaire et source pour RHEL, ce que Red Hat ne fait pas (ou très peu) pour Fedora).
T'inquiète pas, je sais aussi compiler noyau et je ne veux pas disuader les gens de le faire. C'est sympa à faire et "gratifiant" même si ce n'est pas aussi bénéfique qu'on le dit. Je veux que tu sois face à tes responsabilités. Si tu compiles un noyau et qu'il ne marche pas, ça peut venir de toi. Ceci ne te semble pas frappé du bon sens ?
> j'espère que d'autres n'auront pas ce problème en les prévenant
La solution à quoi ?
A ton problème, avec ta clée USB (qu'on ne connait pas) et ta configuration de compilation (qu'on ne connait pas).
Ce n'est pas parce que tu as un problème avec ta clée USB et ta configuration de noyau, que tout le monde va avoir un problème avec sa clée USB et sa configuration de noyau. Tu sera peut-être le seul à avoir ce problème ou alors qu'une poingnée de personne. Ce sont des choses qui arrivent. Et il y a peut-être plus de clée USB qui marchent sur 2.6.22 que sur 2.6.21. Tu n'as peut-être tout simplement pas chance. Tout nouveau noyau introduit des bugs (mais heureusement il en corrige plus qu'il en introduit).
[^] # Re: Re
Posté par IsNotGood . En réponse au journal Test de la Slackware 12.0. Évalué à -2.
C'est F7.
# Re
Posté par IsNotGood . En réponse au journal Test de la Slackware 12.0. Évalué à 5.
Je n'ai lu que la conclusion du test et elle est bizarre pour ne pas dire tordue.
> Slackware a cette réputation de distribution pas vraiment aisée d'accès mais il faut dire que le passage en 2.6 la rapproche de ses rivaux.
En quoi le passage à Linux 2.6 rend la distribution plus "aisée d'accès" ?
> Il y a encore un peu de travail pour la rendre plus accessible aux débutants mais avec un minimum de lecture et les mains dans le cambouis
"un minimum de lecture et les mains dans le cambouis" va rendre la distrubtion plus accessible aux débutants ?
> c'est une distribution tout à fait utilisable et très stable
Qu'elle soit utilisable est le minimum. Tu ne crois pas ?
Et par "très stable" tu entends quoi ?
Elle ne plante pas ?
Beaucoup de distribution ne plante pas.
> Une fois que vous connaissez les quelques programmes à rajouter pour avoir un système bien géré au niveau paquets et dépendances, cela vous fera une station tout à fait flexible quelque soit votre utilisation sous Linux.
C'est comme ça pour quasiment toutes les distributions. Certains font d'une Mandriva un station de travail ou un serveur, idem pour Fedora, idem pour Gentoo, idem pour SuSE, etc...
C'est quoi cette conclusion ?
De la langue de bois.
[^] # Re: Et sous Debian, y'en a encore moins à faire
Posté par IsNotGood . En réponse au journal Flash tar.gz rpm yum. Évalué à 1.
Oui mais rien à voir avec linuxfr. Je suis sur un programme salement compliqué depuis des semaines et tout est en chantier. Je m'arrache les cheveux par poignés. M'enfin, le bout du tunnel n'est pas loins.
> Pour tout t'avouer, j'ai pas pigé grand chose de ton histoire de signature de paquet qui du coup permet des miroirs
Voilà le problème. Imaginons qu'Adobe ne signe pas ses paquets ;
- Adobe met un paquet flash à disposition sur un serveur https super sécurisé.
- Adobe autorise que les mirroirs à copier le paquet flash afin de soulager son serveur super sécurisé.
- Un mirroir peu sécurisé à le paquet flash.
- Un cracker profite du fait que le mirroir est peu sécuriser pour cracker le paquet flash (le remplacer avec un qui a un trou de sécurité par exemple).
- Je downloade le paquet flash cracké sur le mirroir.
- Je suis baisé (et je ne sais pas par qui)
Par contre, si le paquet est signé, je ne suis pas baisé. Mais imaginons que je sois baisé (le paquet a un virus), je sais par qui (Adobe). Donc je peux lui casser la gueule (ou seulement faire un procès). C'est très très important une signature gpg ! C'est comme une signature sur un chèque mais en moins violable.
Le paquet adobe-release.rpm contient la signature Adobe et le fichier de configuration yum.
Le fichier de configuration yum :
[adobe-linux]
name=Adobe Systems Incorporated
baseurl=http://linuxdownload.adobe.com/linux/$basearch/
enabled=1
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-adobe-linux
Une clée n'ait importé dans la base rpm qu'avec confirmation de l'utilisateur. C'est évidemment à l'utilisateur de dire si telle ou telle clée (ou fournisseur (de paquet ici)) est de confiance. C'est de sa seule responsabilité.
Si dans mon fichier de configuration yum j'ai :
baseurl=http://mirroir.free.fr/linux/Adobe/$basearch/
Imaginons que le paquet sur free.fr a été cracké. Lorsque je fais "yum update", yum va voir qu'il y a un nouveau paquet flash (sur mirroir.free.fr). Yum va donc le downloader et tenter l'installation. Mais l'installation va échouer car le paquet n'a pas la bonne signature (donc il n'a pas été fait par Adobe).
> Mais ça à l'air vachement bien pour les fedora/red hat
Ça me semble assez facile à réaliser pour les autres distributions.
> Mais arrêter de rebaver les mêmes conneries. C'est du xml DONC tout le monde peut lire...
Tu n'as pas compris. Un fichier xml est lu par un parser xml. S'il y a un champ supplémentaire inconnu, l'appli peut l'ignorer (c'est ce que fait Firefox etc).
> Ce serait un .ini on saurait pas ?
Il n'y a pas qu'un parser de fichier .ini. Ajoute un champ à un fichier .ini, et tout peu exploser. C'est au cas par cas.
> Ce serait un binaire avec une explication de comment il marche on saurait pas ?
Ça serait un truc qui fait comme xml pour les fonctionnalités qu'on demande à xml, ça le ferait. Évidemment. Il n'y a rien d'incoutournable.
> Ce serait un fichier text quelconque on saurait pas ?
Un fichier xml est un fichier text (sauf quelques exceptions). Son intérêt est qu'il n'est pas un fichier text quelconque. Mais un fichier dont les données sont structurés et accessibles. Pas de code spécifique à faire (à la fichier .ini), il suffit d'avoir un parser xml (qui répond à des spec très précises). Il y a aussi des outils pour faire des requêtes dans les fichiers xml, etc...
Évidemment, ça n'empêche qu'un fichier xml (qui a un format) soit rigoureusement documenté. C'est la même chose pour un fichier ini, etc...
Tu peux mettre tes données dans un fichier text quelconque. Mais essai avec un base de donnée. Tu verras, c'est plus cool.
> Tu peux faire un fichier xml illisible.
Tu peux faire un fichier .ini ou text quelconque illisible. Je ne vois pas où tu veux en venir. Tu n'as pas besoin d'xml pour ça.
Et illisible n'est pas le bon terme. Le fichier est forcément lisible. C'est ininterprétable le bon terme.
Fichier xml ou fichier texte quelconque, il faut une doc qui dit ce que signifie le contenu. C'est comme ça pour tout contenu. "Vin" signifie : "c'est un liquide, pas trop nocif, et qui fait rire". "Vin" a une signification, car on lui a donné une signification. C'est idem pour un fichier text quelconque ou pour un fichier xml.
> Oui, il y a des avantages au xml, mais pas ceux là. Merci donc de ne pas les citer comme une conséquence logique.
Documente toi, et prend un peu de recul.
> Et a mon sens c'est une mauvaise chose
Je trouve que c'est une bonne chose.
> maintenant ça c'est subjectif.
Idem pour moi.
> Donc qu'ils soient ou non dans yum je vois pas exactement le rapport.
Le format des dépôts yum n'a pas été fait pour être spécifique à rpm/yum.
Dès l'origine il a été pris en compte que le format de dépots yum supporte les paquets .deb. Des développeurs debian ont participés aux discussions initiales sur le format de dépôt yum mais ça n'a pas abouti de façon concrête.
Notons que le format apt marche pour rpm et deb. On trouvait beaucoup de dépot au format apt pour Red Hat/Fedora il y a quelques années. Maintenant on trouve rarement du apt pour les dépôt Red Hat/Fedora.
> Si ton cracker pose son code directement dans flash sans que le dev le vois, tu l'as dans l'os.
Ben non.
> Dans tous les cas quand tu accepte un code sans l'avoir entierement compris (et même comme ça) tu t'expose à un danger potentiel.
Tu veux me faire croire que tu comprends tout le code de ton OS ?
Un peu de sérieux...
[^] # Re: Et sous Debian, y'en a encore moins à faire
Posté par IsNotGood . En réponse au journal Flash tar.gz rpm yum. Évalué à -1.
[^] # Re: Et sous Debian, y'en a encore moins à faire
Posté par IsNotGood . En réponse au journal Flash tar.gz rpm yum. Évalué à 2.
Enfin un commentaire avec "Debian" dedans, qui est fort à propos, et qui n'est pas dans la catégorie "j'en ai une plus grosse que toi".
Ce que fait Opera avec Debian (et ses déclinaisons) est aussi cool que ce que fait Adobe avec Fedora (et toutes les distributions qui utilisent rpm/yum). Ce sont des choses comme ça qu'il faut et non des intermédiaires qui repackagent, des bugzilla séparés, etc...
Pour du logiciel proprio (où on n'a pas accès au source) c'est le plus approprié, c'est très "confortable" et sûr.
[^] # Re: Et sous Debian, y'en a encore moins à faire
Posté par IsNotGood . En réponse au journal Flash tar.gz rpm yum. Évalué à 2.
Du moins ici, dans ce journal.
Ce journal montre une boite proprio qui fournit du logiciel de façon "standard" et/ou intégré à une distribution.
La majorité des boites proprios lorsqu'elle fait du logiciel pour Linux, les fournit de façon "bâtarde". Typiquement un .rpm au fond d'un site ftp, et donc pas de mise à jour automique. C'est à toi de "checker" régulièrement le site ftp pour voir s'il n'y a pas une mise à jour. C'est particulièrement dangereux pour des programmes qui sont de bonnes cibles pour les crackers.
Par exemple, le paquet adobe-release a aussi la clée gpg qui a signé les paquets. Donc de façon tout à fait intégrée, rpm/yum contrôle la signature du paquet. Ceci permet à Adobe d'autoriser les mirroirs (sauf pour adobe-release qui a la clée). Si un mirroir est cracké (et le paquet flash-plugin.rpm) le paquet ne sera pas installé.
Tous ça n'a rien de nouveau, c'est fait par Fedora et ceux qui fournissent des dépôts pour Fedora depuis des lustres. Probablement que d'autres distributions font de même.
Mais c'est la première fois que je vois ça pour une boite qui fournit du proprio.
Certes, toutes les distributions n'ont pas rpm/yum. Mais je crois qu'il existe des utilitaires pour installer des paquets rpm sur Debian par exemple. Les dépôts yum sont des fichiers xml et donc tout le monde peut les lires facilement voire les étendre si necessaire sans que ça perturbe le fonctionnement des utilisateurs de yum.
NB : un temps il était prévu que les dépots .deb se base sur les dépôts yum.
> acroread, nero, vmware, virtual box.
J'ignore la réponse à toutes ces questions :
- les paquets acroread sont signés et dispo via yum ?
- les paquets nero sont signés et dispo via yum ?
- ... vmware ... ?
- ... virtual box ... ?
Je suis très très content qu'une boite suive enfin le "logiciel libre touch" en matière d'installation de logiciel. Notamment pour la signature des paquets et la prise en compte du système de gestion de paquet (donc mise à jour automatique ce qui est très très très important pour la sécurité).
Que Debian aille checker tous les jours le site d'Adobe pour voir s'il y a une nouvelle version afin que les utilisateurs de Debian soit à jour, c'est bien.
Qu'Adobe nous fournisse ce service c'est mieux (pas d'intermédiaires, pas de duplication d'effort).
[^] # Re: Et sous Debian, y'en a encore moins à faire
Posté par IsNotGood . En réponse au journal Flash tar.gz rpm yum. Évalué à -3.
Fedora n'est pas "aussi intelligent" que Debian.
Sinon il y a aussi Linpire, Xandros, etc qui ont le Debian touch.
[^] # Re: Les "On dit que"
Posté par IsNotGood . En réponse à la dépêche Migration du parlement italien vers Linux. Évalué à -3.
Pas très sérieux pour une démocratie...
Pour le ministre des affaires étrangères, etc je comprend un peu plus.
[^] # Re: Quelles critiques ?
Posté par IsNotGood . En réponse au journal FreeBSD s'attaque au GNU Tools. Évalué à -1.
La licence est effectivement critiquée. Mais les outils récupérés rarement.
OK sur ce point ? Je n'aime pas la licence BSD, je critique très rarement les programmes sous BSD que j'utilise.
Que BSD critique la licence GPL, OK. Il y a incompatibilité de "philosophie".
Qu'ils critiquent aussi abondamment des programmes (L)GPL qu'ils utilisent librement => PAS OK.
> Plus sérieusement, si des outils GNU sont utilisés, c'est souvant du fait de la transmission à sens unique BSD -> GPL, par manque de bras pour tout reprendre ou par volonté de ne pas réinventer la roue, rarement en raison de la propreté du code.
Et alors ?
Il récupère un truc dont ils ont besoin et qu'ils ne peuvent pas faire. Il n'y a pas de raison de se plaindre. Et s'ils n'en veulent pas ? Ben qu'ils n'utilisent pas.
Si je ne veux pas d'un programme BSD, ben je ne l'utilise pas. Si je l'utilise alors je l'ai choisi et donc j'en suis satisfait (et donc je ne le critique pas).
[^] # Re: Tentative d'explication
Posté par IsNotGood . En réponse au journal 2.6.22 a tué HAL.... Évalué à 0.
C'est très très probablement une erreur de configuration du noyau. Le "2.6.22 a tué HAL", devient "ma mauvaise configuration de 2.6.22 a tué HAL" voire "mon incompétence a tué HAL".
Bref, journal sans intérêt comme je l'ai dit dans mon premier commentaire.
Que ça n'empêche pas ThK de faire des tests. Mais son journal aurait dû être dans la section forum ou un autre site d'aide.
Que de moinssage pour avoir dit une quasi "évidence".
[^] # Re: Tentative d'explication
Posté par IsNotGood . En réponse au journal 2.6.22 a tué HAL.... Évalué à 0.
[^] # Re: Quelles critiques ?
Posté par IsNotGood . En réponse au journal FreeBSD s'attaque au GNU Tools. Évalué à -4.
C'est assez typique des *BSD. Qu'ils n'utilisent pas les outils GNU pour qu'on ait la paix. Ben oui, ils ont *librement* choisi d'utiliser les outils GNU. Personne les a contraint.
Vous imaginez comme je passerais pour un con, si ayant librement choisi d'utiliser la distribution X je disais : "I have always thought that X was a horrid mess of unnecessary complexity, legacy, and overhead.".
Ridicule.
[^] # Re: Tentative d'explication
Posté par IsNotGood . En réponse au journal 2.6.22 a tué HAL.... Évalué à -7.
Tu peux moinser ce commentaire. Ça t'en fera deux. T'es satisfait ?
[^] # Re: Tentative d'explication
Posté par IsNotGood . En réponse au journal 2.6.22 a tué HAL.... Évalué à -6.
Tu peux moinser ce commentaire.
> Pourquoi tu te félicites
C'est une expression. Ouvre un dico.
[^] # Re: Heu non....
Posté par IsNotGood . En réponse au journal Samba passe au GPLv3. Évalué à 1.
[^] # Re: Je ne peux résister...
Posté par IsNotGood . En réponse au journal 2.6.22 a tué HAL.... Évalué à 2.
Quoiqu'il en soit, un "make oldconfig" n'est pas toujours satisfaisant (bien qu'il peut corriger quelques pépins automatiquement).
Il faut le dire et redire, il n'y a pas de garantit de compatibilité ascendante dans Linux (aussi bien binaire que source). Linus c'est déjà exprimé au moins 2^73 fois pour expliquer les tenants et aboutissants de cette position. Si un noyau x+1 marche mal alors qu'un x marche bien, c'est "normal" (ou prévisible) s'il n'y a pas eu de réajustement (config noyau et/ou applis proches noyau (lspci, udev, etc)).
[^] # Re: Je ne peux résister...
Posté par IsNotGood . En réponse au journal 2.6.22 a tué HAL.... Évalué à 1.
Désolé de te le dire, mais c'est une erreur. Linux ne garantit pas qu'un .config adapté pour la version 2.6.x marche pour 2.6.(x+1).
Il faut donc revoir toute la configuration (avec "make menuconfig" par exemple) et tout contrôler. Pour faire ça bien il faut avoir en tête ce processus pour la version précédante afin de voir les évolutions et faire les adaptions nécessaires.
> Et comme j'ai un peu l'impression d'être le seul à avoir ce problème, j'hésite encore à faire un rapport de bug
Fait un essai avec le noyau 2.6.22 rawhide et la version précompilé. Si ça ne marche toujours pas, ton rapport de bug sera le bien venu (oui oui).
NB : F8 aura un "mass rebuild" (changement de la toolchain et introduction d'incompatibilité). J'ignore si F8 (rawhide) a déjà fait ce "mass rebuild". S'il a déjà été fait, il est possible que le noyau rawhide ne marche pas avec F7 à cause du changement de toolchain, il est possible qu'il ne marche jamais sur F7.
[^] # Re: Tentative d'explication
Posté par IsNotGood . En réponse au journal 2.6.22 a tué HAL.... Évalué à 2.
Imaginons que tu ais aussi fait un rapport de bug et qu'un développeur ait dit que le problème vient, par exemple, du udev de F7 qui n'a pas été mis à jour pour 2.6.22 et qu'il faut installer le udev de Rawhide (ben oui, il n'y a JAMAIS de garantit de compatibilité ascendante dans Linux même entre versions mineurs !). Dans ce cas, le problème n'est pas Linux 2.6.22, mais F7 (je ne fais en aucun cas de l'ombre à Fedora, c'est une distribution que j'utilise et adore (actuellement j'utilise FC6 et c'est un vrai bonheur)).
Les choses sont ainsi dans le développement de Linux. Un noyau 2.6.x peut marcher et un 2.6.(x+1) peut ne pas marcher sans que ça soit la faute au noyau. C'est archi connu et c'est pour ça que peu de distribution font des montées en version de noyau même pour des changements de versions mineurs. Fedora fait parti des rares à le faire. Et Fedora le fait avec beaucoup de prudence et d'expertise. Ils sont en mesure de savoir d'où vient le problème et s'il vient du noyau ou non. Et toi ? En tout cas pas moi.
Tu n'as (et beaucoup) pas aimé mon ton. Mais, s'il te plait, à l'avenir fait un rapport de bug. Dire que pour 2.6.x+1, pour une distribution, pour une configuration, ça ne marche pas est sans intérêt. Les développeurs le savent que ça arrive de façon quasi systématique et ça ne remet en rien en cause la version 2.6.x+1. Par contre ils veulent des rapports de bug ! Et principalement ceux qui font des distributions (enfin d'adapter la distribution aux évolutions du noyau ou remonter le bug en upstream).
> Je chercherais sans doute quand j'aurais un peu plus de temps à y consacrer, mais pour l'instant, je reste en 21.6.
Fais un rapport de bug :-)
Si possible fait un essai avec le noyau rawhide (la version précompilé, optionnellement en le compilant toi même). Tu trouveras sans difficulté un tutorial pour compiler un noyau fedora depuis un rpm si tu ne sais pas le faire. C'est important pour conserver les patchs de la distribution.
Bien amicalement. Même très amicalement. C'est important les gens qui testent les dernières versions et je me félicite que tu ais cette passion et patience. Par ma part ce n'est pas mon kife actuellement (manque de temps).
Bien amicalement, bon test.
[^] # Re: Tentative d'explication
Posté par IsNotGood . En réponse au journal 2.6.22 a tué HAL.... Évalué à 0.
C'est comme ça pour TOUS les noyaux !
Tu peux donner une version de noyau sans bug ? C'est impossible.
Si la version X marche pour ta config, passer à une version Y peut poser des problèmes. Que Y soit supérieur à X ou non.
Ça a toujours été ainsi et ça le restera.
[^] # Re: Tentative d'explication
Posté par IsNotGood . En réponse au journal 2.6.22 a tué HAL.... Évalué à 1.
De plus, il faut définir RC. car RC1 chez Linux c'est souvent une beta (voire une alpha) dans d'autres projets. T'es OK sur ce point ?
Pour beaucoup de projet, RC signifie que la version sans la moindre modification est une version finale potentielle. RC signifie, que pour les développeurs et en l'état actuel des tests, c'est une version finale. Qu'il n'y a que des tests utilisateurs qui peuvent changer cet avis. Pour Linux, c'est rarement le cas. Pour le 2.6.22, il semble (je n'ai pas suivi le développement de cette version) que les "vrais" RC étaient RC6 et RC7. Les RC précédentes était des beta/test.
Pourquoi Linux ne fait que des RC ? J'ai oublié les détails, mais en gros l'objectif est de pousser aux tests. Si ce n'est pas labélisé RC, les gens ont tendance à ne pas tester. Le choix de Linus est très "psychologique".
RC n'est pas l'unique synonyme de "seulement bugfix". Pour le projet Fedora à partir de test2 (suivit de test3 et parfois test4) il n'y a que des bugfix et ça appelle test et non RC. Il arrive exceptionnellement que Fedora sorte des RC (souvent semi-confidentielle) juste avant le finale pour vérifier qu'une modification de dernière minutes ne pose pas de problème. Et souvant cette RC est identique à la version finale officielle (au paquet fedora-release près).
Linux a un usage particulier du label RC. Je comprend ce choix.
Mais le projet Linux n'est pas le seul projet, ne dicte pas tout aux autres projets, etc...
[^] # Re: Heu non....
Posté par IsNotGood . En réponse au journal Samba passe au GPLv3. Évalué à 2.
Ça fait parti des quelques bizarreries de dlfp.
[^] # Re: Tentative d'explication
Posté par IsNotGood . En réponse au journal 2.6.22 a tué HAL.... Évalué à -2.
En passant, Linux 2.6 n'a que des RC (politique choisi par Linus depuis quelques mois). Ce ne sont pas de "vrais" Release Candidat car il y a ajout de fonctionnalités. Linux 2.4 a des "vrais" RC.
[^] # Re: Rawhide
Posté par IsNotGood . En réponse au journal 2.6.22 a tué HAL.... Évalué à 1.
Mais en passant, la branche Rawhide n'est pas faite pour marcher sur une version stable de Fedora. Si ça marche (et ça arrive souvent) alors tant mieux.
> Par ailleurs, redhat cherche de plus en plus à diminuer le nombre de patchs qu'il appliquent sur le kernel vanilla
Red Hat a toujours fait ça contrairement à ce qui se dit. Il n'y a que pour RHEL où il peut y avoir beaucoup de patchs (Red Hat doit assurer la compatibilité binaire et source pour RHEL, ce que Red Hat ne fait pas (ou très peu) pour Fedora).
[^] # Re: Tentative d'explication
Posté par IsNotGood . En réponse au journal 2.6.22 a tué HAL.... Évalué à -4.
[^] # Re: Tentative d'explication
Posté par IsNotGood . En réponse au journal 2.6.22 a tué HAL.... Évalué à -4.
> j'espère que d'autres n'auront pas ce problème en les prévenant
Fait un rapport de bug :
http://bugzilla.redhat.com/
http://bugzilla.kernel.org/
> et en donnant la solution
La solution à quoi ?
A ton problème, avec ta clée USB (qu'on ne connait pas) et ta configuration de compilation (qu'on ne connait pas).
Ce n'est pas parce que tu as un problème avec ta clée USB et ta configuration de noyau, que tout le monde va avoir un problème avec sa clée USB et sa configuration de noyau. Tu sera peut-être le seul à avoir ce problème ou alors qu'une poingnée de personne. Ce sont des choses qui arrivent. Et il y a peut-être plus de clée USB qui marchent sur 2.6.22 que sur 2.6.21. Tu n'as peut-être tout simplement pas chance. Tout nouveau noyau introduit des bugs (mais heureusement il en corrige plus qu'il en introduit).