tgl a écrit 1743 commentaires

C'est n'importe quoi, tu es un troll énorme, tu carricatures et tu dénigres à tout va. Pour ce qui est des quelques fragments d'inquiétude légitime qui ont donné lieu à cette montagne, tu trouveras, si ça t'intéresse vraiment, des réponses dans les discussions sur lkml. Quant au reste, il me suffit amplement pour arrêter ici une conversation qui s'annonce stérile.

Tant qu'on aura pas une stabilité des APIs du noyau, Linux sera toujours à la traîne pour les drivers de matériel récent, car les constructeurs ne peuvent pas fournir les drivers avec le matériel vendu avec la certitude que ça marchera sur tel ou tel noyau.

Tu crois sincèrement qu'il est là le problème ? Les quelques constructeurs qui veulent sortir des drivers pour Linux n'ont pas de difficultée à le faire. Quelques semaines après le passage de la pile à 4Ko, c'est à dire bien avant que ça ne se retrouve dans la moindre distrib' Linux et que donc ça ne pause le moindre problème aux utilisateurs (sauf à qlqs geeks accrocs à kernel.org qui croient que leur système va s'autodétruire si ils n'utilisent pas la dernière version en date), des drivers NVidia corrigeant l'overflow sont sortis. Non, franchement, si beaucoup de constructeurs ne font pas de drivers Linux, ça n'est pas parcequ'il est trop mouvant ou je ne sais quoi, c'est juste parcequ'ils n'en n'ont rien à foutre des 1% de clients que ça pourrait intéresser.

Quant à l'histoire du logo, bof, pour moi ce qui serait à vérifier pour l'attribuer, ça n'est pas qu'il existe un driver qui va éternellement marcher sur toute la série des 2.X, mais plutôt qu'il y a un drivers qui marche avec les 2.X actuels, et un constructeur qui va le mettre à jour de façon à ce que ça continue. Moi ça me parait parfaitement acceptable de dire, et c'est ça qui compte, que « les NVidia sont supportée sous Linux avec la 3D et tout et tout via un driver proprio ». Alors que pourtant il y a effectivement eu qlqs semaines pendant lesquels ça n'était pas vrai pour la toute dernière version du noyau, mais je vais pas pinailler pour ça.

Accessoirement, quand bien même il y aurait une API à 100% figée pour une série de noyaux, ça ne voudrait pas dire qu'on peut certifier qu'un driver proprio marchera avec 2.X.Z sous prétexte qu'il marche avec 2.X.Y . Rien ne garantit en effet qu'elle n'est pas contournée et qu'il n'y a pas dans le code du driver des hacks qui créeront des incompatibilitées avec des versions futures à cause de changement internes au noyau, ne modifiant pourtant pas l'API. Donc une certification telle que tu l'entends, elle me parait bien illusoire.

Bof, quand il s'agit de récupérer des numéro de carte de crédit par exemple, que ça ne marche qu'une fois sur deux ou une fois sur six, ça change pas grand chose, tu en auras toujours plus qu'il n'en faut...

Les 2.6 n'ont jamais prétendu respecter l'ancien mode de dévelopement, mais on toujours fonctionnés en suivant le nouveau, même si tout ça n'a été officialisé que récemment. Alors des petits changement d'API, effectivement, il y en a eu et il y en aura encore. Ça n'a rien de contradictoire avec une certaine idée de la stabilité, ça dépend vraiment de la définition qu'on adopte. Celle considérée par les dévelopeurs du noyau n'est pas "rien ne bouge", mais plutôt "tout marche". En ce sens, la plupart s'accordent à dire que le 2.6 est la branche la plus stable qu'ils aient connu, alors qu'elle est effectivement assez mouvante.

> Trop régulierement des éléments experimentaux y sont introduits.

Les éléments introduits au fil des 2.6 ne sont pas expérimentaux. Ils sont passés par la branche -mm avant d'être intégrés, et ça n'est que là qu'ils étaient expérimentaux.

Ce qu'il faut bien voir, c'est qu'il n'y a aucune garantie qu'une mise à jour entre deux noyau 2.6 vanilla puisse être faite sans la moindre conséquence sur le reste du système. C'est plutôt du côté des noyaux des distributions qu'il faut se tourner si on veut pouvoir faire des mises à jour sans se poser de question. C'est à eux de fournir des ensemble noyau + drivers externes + outils userspace cohérents. L'utilisateur qui par contre se jette tête baissée sur le dernier vanilla le fait à ses risques et périls. Cette situation était clairement assez criticable tant qu'elle n'était pas annoncée noir sur blanc, mais maintenant que c'est fait, je n'y vois rien à redire.

Un truc intérressant à noter aussi c'est qu'il est serieusement envisagé, si il y a de la demande, de faire des backports des correctifs les plus importantes entre les versions mineures des 2.6 vanilla. Ainsi, si on est en 2.6.x et qu'il y a une nouvelle faille corrigée, ça ne serait pas en 2.6.(x+1) qu'il faudrait upgrader (enfin pas si on veut une stabilité au sens "rien de neuf"), mais plutôt en 2.6.x.1. Ça fournirait bien la même garantie de stabilité que des noyaux de distrib, mais sans imposer toutes les features additionnelles et parfois douteuses qui sont souvent livrées avec.

C'est un code "proof of concept", fait pour firefox 0.9. Le but du jeu c'était pas de fournir clefs en main la version ultime qui marche avec toutes les versions de mozilla... Que cette version là ne marche pas pour toi ne change rien au fait qu'il aurait été aussi facile d'en faire une pour mozilla 1.7 au lieu de firefox 0.9, et ne remet pas en cause la démonstration.

> Ca se fait bien en C/C++/VB/C#/Mono/ ... /Perl/PHP
> tout ce que vous voulez quoi ...

L'originalité n'est pas dans le fake (ça effectivement, c'est plutôt un classique des troyens), mais dans la façon dont la victime se retrouve à l'exécuter. Ici, suivre un lien web suffit, mozilla s'occupera du reste. Ça ne serait pas le cas avec autre chose que XUL (encore heureux qu'il n'est pas si facile de faire exécuter n'importe quel bout de C chez quelqu'un...).

> C'est quoi un ebuild ? C'est spécifique à une distrib ou
> commun aux linuxes ?

C'est spécifique à Gentoo.

> J'ai vaguement vu qu'il y avait un make-kpkg

Si mes souvenirs de debianeux ne sont pas trop rouillés, ça c'est pour faire un paquet pour un noyau et ses modules. C'est un cas un peu particulier.

> ou une commande du genre, ce qui construit je crois un .deb
> à partir d'une tripotée de règles pour définir le package (dépendances,
> suggérés, recommandés, conflits...). En somme, c'est un peu ça que tu
> utilises ?

Voilà oui, enfin l'équivalent gentoo. Perso je le trouve bien plus simple : un ebuild est un simple fichier bash, et une fois qu'il est prêt tu n'as plus qu'à faire ton "emerge <nom-du-logiciel>". En fait, sous Gentoo, tout est installé de cette manière, à partir d'une collection standard d'ebuild ("l'arbre portage"). Le fait d'avoir tout ça sous la main (alors que sous debian l'utilisateur de base n'est pas en contact avec les specifications de paquets) fournit plein d'exemples et rend plus naturel le fait de rajouter ses propres paquets.

Sous debian, je trouve la création des fichiers de specification plus fastidieuse, et une fois que c'est fait il reste des étapes intermédiaires avant d'arriver à qlqchose qui est exactement équivalent à un paquet standard. Du coup, quand j'étais debianeux, c'était assez rare que je prenne la peine de passer par là et j'avais plus tendance à faire des "configure ; make ; make install" hors du système de paquets. Sous gentoo je ne le fais plus du tout, et je sais que je suis loin d'être le seul à avoir ainsi changé mes habitudes.

Merci pour ta réponse. Je connaissais pas Libranet (enfin bon je perdais pas grand chose si j'en crois les commentaires que je viens de lire de ci de là), et je savais pas que Linspire était basée sur Debian.

L'utilisation de certificats de signature crypto pour identifier le code mobile de confiance, ça date pas de Palladium, loin de là. Et ça n'est pas du tout une idée choquante, et ça n'est pas du tout incompatible avec le libre. C'est juste dommage qu'il n'y ait rien de tel de prévu dans le système de code mobile de Mozilla.

En fait je comprends mal pourquoi ça n'a pas été prévu d'ailleurs. Peut-être qu'ils se sont dit que comme le code exécutable par défaut était uniquement du code d'interface, il ne pouvait rien faire de mal. Quelqu'un en sait plus ?

> d'autant que nombreux sont ceux qui se sont cassé les dents ...

Je me souviens de StormLinux, Corel Linux et Progeny (la vieille Progeny, pas le metamachin modularisé que c'est censé être maintenant). Y'en a eu d'autre ?

En fait, à part Knoppix (mais qui présente une vrai originalité), est-ce qu'il y a eu des succès dans les dérivés de Debian généralistes et grand public ?

> Sous gentoo, je n'ai jamais eu de problème en ajoutant des applis
> en faisant un ./configure && make && make install.

Perso je n'installe jamais rien de cette façon. Quand j'ai besoin d'une appli qui n'est pas dans portage, je me fait rapidos un ebuild bien baclé, ça prend 5 minutes et puis voilà, mon soft est installé proprement (donc désinstallable, etc.). Et puis comme ça au passage, si je me dis que ça peut intérresser des gens, alors je fignole un peu plus et je balance ça sur le bugzilla.

L'apprentissage de l'écriture d'ebuild est relativement simple, et c'est vraiment un bon investissement. La doc est bien faite, et puis y'a queqlues milliers d'exemples dans l'arbre portage pour trouver l'inspiration. Bon maintenant, il y a bien sûr des ebuilds compliqués à écrire, c'est clair, mais c'est typiquement pour les soft ou le "./configure ; make ; make install" aurait soit été insuffisant, soit ferait tellement d'autres choses que de coller qlqs fichiers dans /usr/local qu'il aurait vraiment été à proscrire pour garder son système propre.

> En fait si tu installes un paquet A qui demande la présence du paquet B,
> alors le paquet B est installé automatiquement. Mais si tu désinstalles
> le paquet A, B restera installé, alors qu'il n'est plus utilisé.

Ça c'est rien, "emerge -p depclean" de temps en temps et c'est nettoyé. Pour ceux qui connaissent pas, le principe est de virer tous les paquets installés qui ne sont pas référencés dans les groupes "system" ou "world", ou dans les dépendances directes ou indirectes des paquets de ces groupes. Le groupe "system" étant une liste des paquets de base indispensables spécifiés par les développeurs gentoo, et le groupe "world" la liste des paquets que l'utilisateur a explicitement installés (par explicitement, j'entend que si on fait "emerge MegaPlop", seul MegaPlop est ajouté au world, mais pas les éventuels autres paquets, par exemple des bibliothèques, dont il dépend).

Ouais mais là tu perds les tags. Ça peut se corriger aussi avec un bout de shell et de sed (je dois avoir une version basique dans un coin), mais en fait pour bien faire tu en arrives vite à un truc à peu près de la complexité de ogg2mp3 cité plus haut. Alors bon, pourquoi réinventer la roue ?...

D'ailleurs c'est pas pour rien que plein de boîtes ne dépassent jamais ce stade : monnayer une idée peut, selon les cas, être bien plus rentable (proportionellement à l'investissement), ou encore bien moins risqué, que de développer et vendre le produit fini qui l'utilise.

Bon celà dit, des brevets utilisés directement et exclusivement (au moins pendant les 6 ou 12 premiers mois, tant que c'est chaud) par leur détenteur, ça existe bien sûr aussi. Ça dépend vraiment de la politique de la boîte.

Oups, mea culpa, je crois que ma lecture un peu rapide du titre a retenu juste l'idée de dialogues passant sous une fenêtre.

C'est à peu près certainement une question de Window Manager. Tu utilises quoi ? Ici (avec sawfish), je n'ai pas ce pb.

Ok merci, je testerai ça.

PS : lecteurs, dans le lien vers kdissert, virez le "." à la fin.

Moi ce logiciel je le sentirais bien comme une vue dans un IDE. Genre en plugin Eclipse ou assimilé, avec une possibilité de créer des liens entre certains nœuds d'idées et des portions du code qu'on développe (au niveaux ligne, fonction, classe, commentaire, etc.), ce serait pratique.

Et puis je dis code, mais j'aurais rien contre le fait de pouvoir aussi faire des liens vers des chapitres, sections, définitions, théromes, paragraphes, etc., quand je fais du LaTeX.

Bref, en l'état je trouve ça sympa comme outil généraliste, un genre de brouillon pour brainstormer sur tout et n'importe quoi. Mais ça serait encore bien plus utile intégré comme une surcouche de commentaires dans des applications plus spécifiques. Avantages :
- elle pourrait être structurée différement de ce qui est commenté (contrairement aux commentaires fait dans le code/texte) ;
- elle n'en serait pas pour autant déconnectée (contrairement, ou presque, aux documents externes au code/texte, du style fichier TODO ou docs d'implem').

> j'ai beau rafraichir, y-a des infos qui sont pas mis à jour
> immédiatement

Bah si t'es sûr que c'est pas de ton côté (proxy ou cache du navigateur), alors ça peut être le cache de templeet qui sur certaines opération ne se rafraichit pas. C'est pas impossible du tout, il me semble que par exemple dans les journaux, les notes des commentaires se bougent pas en apparence tant qu'il n'y a pas un nouveau commentaire de posté (enfin si c'est plus le cas, ça l'était il y a qlqs temps). Alors sur l'ajout de lien, bof, va savoir, c'est pas hyper souvent qu'il y a cette opération sans une édition du texte en même temps, donc si ça se trouve ça déconne. Enfin j'en sais rien, j'y connais rien aux entrailles.

> ou alors il a été mis après ;)

Non, ça je suis sûr. Ici on le voyait bien en une en début d'aprèm'.

> Ça pourrait bien être le même en effet, enfin ça ressemble beacoup comme tu dis.

Ah mais non en fait, là c'est un Duron, l'autre était un Celeron, donc c'est clairement pas le même. Enfin c'est par contre pour sûr la même gamme, càd le moins cher du neuf d'aujourd'hui.

Ça pourrait bien être le même en effet, enfin ça ressemble beacoup comme tu dis. Par contre tel que leur truc est formulé, dur de dire si là la Mandrake est installée ou bien juste fournie sur CD.

À part ça, c'est marrant de voir la comparaison Windows/Linux qu'ils font, enfin y'a de bonne choses dedans.

Merci pour l'info en tout cas.

PS : Pour les flemmards, lien direct :
http://www.carrefour-multimedia.com/data/fr/magasin/produit/p_mag_p(...)

Bah il est censé être mieux qu'en première page, il est en "article phare" (le gros pâté de couleur en haut de la page d'acceuil). Mais bizarrement, on les rate souvent ceux là, probablement parcequ'ils ne changent que rarement et que donc on saute naturellement ce cadre pour aller voir les niouzes.

Je sais pas, peut-être que les 2 ou 3 jours qui suivent un changement il faudrait leur coller un gros "NEW!" en gif animé :)

Ou bien il faudrait que l'article phare puisse être en même temps en 1ère page quand il est frais. Mouaif, pas terrible non plus...

Bon bah toute idée sera probablement la bienvenue.

> ou au moins en lien sur l'autre article

On l'avait oublié au début, mais ça a été corrigé ~1 heure avant ton message :p

web::google('1002:434d') retourne entre autres ça :
http://linmodems.technion.ac.il/archive-fourth/msg01262.html(...)

À creuser, j'en sais pas plus.

Bon à savoir (je dis ça parceque je savais pas avant de chercher), gentoo-user-fr est archivé sur MARC. Le thread en question donc :
http://marc.theaimsgroup.com/?l=gentoo-user-fr&m=10908564032503(...)

À noter aussi :

- un mirroir ftp pour toutes les isos (y compris les GRP x86, dispos sinon uniquement sur Bittorrent) :
ftp://ftp2.stw-bonn.de/pub/mirror/gentoo/(...)

- une grosse collection de torrents là :
http://tracker.netdomination.org/(...)
(pareil, toutes les isos, alors qu'il n'y en a que qlqs unes sur http://torrents.gentoo.org/torrents/(...) )

Ou encore tu peux utiliser 'eval' pour forcer l'expension de tes variables avant l'interprétation de la ligne de commande :

% foo="foo"
% bar=">/dev/null"
% echo $foo $bar
foo >/dev/null
% eval echo $foo $bar
%

Lors du premier echo, comme l'a dit gc, deux arguments ont été passés et affichés. Pour le deuxième par contre, grâce au eval, bash a d'abord changé "echo $foo $bar" en "echo foo >/dev/null", puis a interprété cette ligne complète comme il le fait d'habitude, avec donc un seul argument et une redirection sur /dev/null.