TImaniac a écrit 6420 commentaires

Oui mais bon tu sais en 2 ans l'informatique évolue :) XVid aussi tu me diras. Enfin c'est très subjectif de toute façon.

Attention ce n'est pas une évaluation "scientifique" mais une évaluation des articles scientifiques.
C'est à peu prêt normal que Wikipedia s'en sorte correctement. Les polémiques sur Wikipedia serait plutôt raccrochées aux articles où la subjectivité, l'interprétation et la passion peuvent tuer la qualité d'un article : je penses aux articles historiques et articles concernant des personnes.
Evidemment ce n'est pas le créneau de Nature, mais ne tirons pas de trop rapides conclusions de cette étude en généralisant à toute l'encyclopédie. Cette étude qualitative ne concerne bien que la partie "sciences" de l'encyclopédie.

Piouu :) Ben tu vas galérer, désolé mais autant t'annoncer directement la couleur !
Y'a pas de drivers pour Linux, peut être que NdisWrapper fonctionnera, c'est un outil permettant d'utiliser les drivers Windows sous Linux avec les cartes Wifi.
Cela dis l'installation n'est pas spécialement à la portée du débutant...
Enfin si tu veux tu peux aller faire un tour par ici :
http://forum.hardware.fr/hardwarefr/OSAlternatifs/-Wifi-Tuto(...)

Le plus dur va être d'installer la clé usb wifi :) Tu peux donner la dénomination exacte de ta jolie clé ?

On peut vouloir faire du libre pas compatible GPL : MIT, BSD, etc.

Ca c'est un moyen comme un autre de statisfaire le besoin : commencer par créer le besoin. Reste que le but est toujours le même, répondre aux désirs/besoins du clients, quitte à les créer s'il le faut (ce qui est beaucoup plus douteux evidemment d'un point de vu éthique).

Essai F-Spot, il est rapide, même s'il gruge en affichant une première passe de l'image "grossière". Après peut être que ACDSee fait pareil je sais pas. En tout cas ca mais moins d'1/2 seconde c'est ce que tu veux :)

un programme qui tourne sous Linux 2.2 peut très bien tourner sous Linux 2.6
Je parle pas de la compatibilité binaire des exécutables, ca reste du x86 avec du posix, on parle de la compatibilité des modules/pilotes qui s'interfacent directement avec le noyau.
J'ai voulu comparer une interface et un standard (celui de OOo) et j'ai justement voulu montrer que cette interface n'était pas "interne", mais bien une interface "publique" avec laquelle devrait pouvoir s'interfacer tous les pilotes, qu'ils sont libres ou non, maintenus par l'équipe du noyau ou une équipe tierce.
Et je reproche au final à cette interface de pilotes d'être maintenue comme une interface interne alors qu'elle devrait s'ouvrir et se stabiliser.

Surtout qu'il est clairement expliqué dans le lien donné que dans Linux, c'est celui qui change l'interface qui doit mettre à jour le code de tous les modules qui l'utilise.
Cela reste une perte de temps, et surtout cela suppose que le noyau maintien tous les drivers/modules. Tu me diras c'est peut être pour ca qu'on a un bousin monolithique.

Pour les modules qui ne sont pas dans le noyau vanille et qui doivent donc être modifiés par leur mainteneur ben c'est soit que leur qualité est insuffisante soit...qu'ils ne sont pas libres.
Ou tout simplement qu'ils ne sont pas intégrés au processus de devel du noyau.

Evidemment quand les modifs sont en "interne" au noyau, les APIs stables ne sont pas forcement "utiles", mais il faut faire le raisonnement inverse : cette instabilité des APIs "ferme" le noyau, dans cette dépêche cette fermeture se fait au dépend des pilotes binaires non libre, mais d'une manière générale cela reste une fermeture tout court, aussi bien aux pilotes libres maintenus par des tierces personnes.

Même en supposant qu'un constructeur décide de faire des pilotes "libres", il est normal qu'il souhaite en être le mainteneur principal, mais le modèle de devel du noyau (modèle fermé par changement incéssant des interfaces) l'obligerait à laisser son contrôle à d'autres développeurs.

En fait le noyau est l'anti-thèse des standards. Il ne respecte rien, même en interne. C'est comme si OOo 1.1.3 était incompatible avec OOo 1.1.2 incompatible avec 00o 1.1.1, etc.

Les interfaces c'est comme les standards, il n'a jamais été écris qu'ils ne pouvaient pas évoluer, ce n'est pas pour autant qu'ils ne doivent pas exister et être stable, par soucis d'interopérabilité et d'ouverture.
Et je suis convaincu que cette mauvaise foi concernant les pilotes binaires n'est qu'une façon de cacher des lacunes flagrantes d'architecture et d'organisation au coeur du noyau.

Voilà tout ca pour dire que le noyau lui même contribue au final à son manque de succès auprès des fabriquants matériels.

Tiens on peut afficher des feeds rss dans les journaux maintenant ? C'est vraiment génial Templeet :)

Ça ne gêne que les éditeurs propriétaires.
Je ne suis pas un éditeur propriétaire, et ca m'enmerde. Je t'ai donné un exemple concrêt. Maintenant un autre exemple, amuses-toi pour le fun à reprendre un programme sur le net qui est vieux de y'a 3 ans sous Linux. Bien sûr tu es madame Michu et tu ne connais rien à gcc & co. Tu fais quoi ?

Ceci a tendance à fortement (très fortement) réduire le besoin de changer une API, car tu peux l'étendre sans avoir à réparer tous les utilisateurs de ladite API.
Ah bah voilà qui est mieux et qui rejoint ce que je dis :)
En gros l'API n'est pas changé, il est juste étendu. L'interface initiale est inchangée et fonctionne toujours.

comme Microsoft, à maintenir trois APIs USB différentes pendant plusieurs années (je ne retrouve pas le lien, non).
Ben au moins ils assument les changements, et doivent désormais réfléchir à 2 fois avant de pondre une interface. Je préfères largement avoir ouvertement plusieurs versions d'une interface, et maintenir ces interfaces pendant un certain temps, plutôt que d'avoir une seule interface qui bouge tout le temps, les développeurs démerdez-vous pour suivre.
On doit pas avoir la même vision du service rendu aux développeurs.

La force du libre est juste ceci : pas de contrainte au niveau binaire.
Au contraire : que des enmerdes au niveau binaires. C'est pour moi un des gros problèmes du libre justement. Sous prétexte qu'on a les sources on se fou royalement de la compatibilité binaire. Ca pose de nombreux problèmes de maintenance, de support, d'incompatibilités, et d'une manière générale ca empêche Linux de vraiment percer.

ton argument est un argument contre toi : MS casse bien les interfaces (certes moins souvent, mais c'est deja trop), et une tonne de pilotes meurent car non adaptables...
L'argument ne se retourne pas du tout, j'ai clairement dit qu'il fallait parfois changer les interfaces lors de grosses évolutions, et pour moi les passages de win3 à win9x à win2000 sont autant de grosses évolutions qui justifient des incompatibilités. Mais une interface reste stable pendant un certain temps. Sous Linux c'est l'orgie permanente dans le noyau.

et une tonne de pilotes meurent car non adaptables...
Ca c'est parcque c'est des pilotes binaires fermés et proprio. Je l'ai dis clairement, je suis contre les pilotes binaires fermés.

Un interface binaire est certes utile si on veut du closed-source, si on ne veut pas du close-source dans les pilotes, geler une interface n'est absolument pas utile.
Moi je crois surtout qu'une interface en perpétuelle évolution est un signe de bordel constant, de risques potentiels d'incompatibilités, de temps perdu en maintenance de centaines de drivers, et surtout une excuse pour ne pas "se faire chier" à bien concevoir ces interfaces justement.

La compatibilité binaire n'est pas du tout contradictoire avec le libre, je crois que Linux a besoin d'une compatibilité binaire, pas spécialement pour aider les softs proprio fermés, mais pour Linux lui même. Pour sa maintenance. Pour sa diffusion. Pour sa distribution.

Pourquoi avoir besoin d'interface stable si tu es contre les drivers closed-source?
Pour pleins de choses :
- forcer les développeurs à "réfléchir" avant de coder l'interface : bref à pondre un truc conçu pour être évolutif, et non pondre un bousin en se disant "cpa grave on pètera tout plus tard"
- faciliter la distribution (qui a dit incompatibilités entre distributions ?)
- arrêter de perdre du temps à maintenir la même chose pour 1000 versions.

J'ai eu l'occasion d'utiliser GStreamer en tant que développeur, rien de plus pénible que de voir des interfaces modifiées à chaque mise-à-jour. Je perdais un temps fou à suivre les "évolutions".
Seulement j'étais tolérant car je savais que ce n'était pas une interface "stable", GStreamer n'étant pas en version 1.0. Je suis heureux de voir qu'à l'approche de la 1.0 le tout se stabilise.

Je n'ai pas le droit d'avoir mon avis ?

Il est impossible de mettre à jour son noyau si le constructeur n'a pas sorti de nouvelle version de son pilote.
Qu'il y est des incompatibilités entre versions majeures oui, qu'il y est une impossibilité d'upgrader au noyau 2.6.14 depuis 1.6.12, c'est une abberation, une mauvaise architecture du noyau Linux, ou en tout cas de très mauvais choix d'évolution.
Sous Windows, on peut utiliser aujourd'hui des pilotes prévus pour marcher sous win2000 il y a 5 ans.
Bref le problème c'est Linux, pas le pilote.

Pour que les pilotes binaires fonctionnent bien, il faut une interface avec le noyau qui ne change pas. Cela est une aberration technique, car une interface gelée freinerait grandement le développement du noyau
Là encore je ne suis pas du tout d'accord.
Au lieu de changer d'interface toutes les semaines, qui est une une perte de temps continuelle pour les mainteneurs de pilotes, il faudrait mieux justement bien les concevoir et les figer. C'est le rôle même d'une interface : être pérenne dans le temps. Evolution nécessaire ? Changer d'interface. Et si possible garder la compatibilité avec l'ancienne.

Sinon je suis pas pour les pilotes binaires, mais pour d'autres raisons : c'est pas des logiciels libres tout simplement.

Oui et ? En quoi j'ai perdu ?

Toi tu comprends rien à la notion de couche intermédiaire et d'abstraction :)
WinFS est vu comme le système de fichier. C'est donc lui qui te fournis les moyens de retrouver et d'accéder à un fichier. Après qu'il utilise derrière NTFS, une base de données, du papier ou une pierre taillée c'est son problème.
Donc du point de vu de Word, c'est WinFS le système de fichier. Mais le fichier n'est pas physiquement stocké dans la BDD SQL Server, seules les tables relationnelles sont dedans.

J'ai eu que des galères avec ça, c'est pour ça que j'ai ajouté "et ça marche" :-)
chezmoicamarche.org :)

Perso j'avais pas trouvé comment faire.
Ben je sais pas dans Evolution tu peux saisir plusieurs adresses IM pour un même contact, un MSN, un AIM, etc.

T'arrive à ouvrir gedit dans un onglet Firefox ??? Donne le nom de ton plugin !
C'est quoi l'intérêt dans Firefox ? C'est pas le navigateur Gnome :)
Sinon j'avais pas capter l'intégration dans Konqueror, je croyais que tu parlais du côté "colorisation". Enfin bon je préfères autant que mon document s'ouvre dans des tabs de gedit ca me paraît plus "clair" que dans le navigateur.

Jamais entendu parlé de ça. Gaim sait l'utiliser ?
C'est le trousseau de clé Gnome, qu'utilise nautilus (genre mdp FTP). Gaim ne l'utilise pas par contre ca c'est clair.

Bref, sinon, j'ai une question, vu que c'est pas clair et que t'as l'air de maitriser le sujet :
Aucune idée, je te dirais ca quand je l'aurai testé :)

Juste pour préciser qu'il y a certaines différences qui n'en sont pas :

On peut facilement lier un contact à une adresse de messagerie instantanée (MI)
Comme sous Evolution quoi.

Le truc très fort : on peut regrouper des adresses de MI par contact
Comme sous Evolution quoi.

Kate est bien intégré (un ouvre un code C dans un onglet : hop, coloration syntaxique et tout le tralala).
Comme avec gedit quoi.

Enfin, Kwallet permet de centraliser les mots de passe.
Comme avec le trousseau de clé Gnome quoi.

Ils ne servent pas à stocker des fichiers les autres SGBD actuels...
Et alors ? Un fichier c'est des données, un y'a des SGBD qui stockent plusieurs dizaines de Go.

Quand on backup, si t'as 200 Go de données dans ton winfs, c'est pas gagné quand meme la...
Euh, les fichiers sont stockés dans le système de fichier sous-jacent, à savoir NTFS. WinFS ne s'occupe pas du stockage physique. Ce qu'il a à maintenir, c'est ses tables de méta-données et les tables relationnelles, ca va pas faire 200 Go. Et ca sera alors exactement la même problèmatique que pour les SGBD traditionnels.

Et je reste quand meme persuadé que tout stocker plusieurs fichiers dans un seul fichier
Gni ? Qui a parlé de faire ca ?

Le marketing ça sert à quoi à part abrutir les gens?
Wikipedia :
"Le marketing (on utilise aussi plus rarement le terme mercatique) est une discipline qui cherche à satisfaire le ou les désirs et besoins du consommateur ou de groupes de consommateurs (segments marketing), et à assurer la commercialisation des biens et services proposés dans les meilleures conditions de profit. "

Bref ca sert à vendre.

Oui, enfin si NTFS se chie dessus, je vois mal comment le SGBD va s'en sortir, en clair, au lieu d'avoir perdu deux ou trois fichiers, tu risques de perdre tous tes fichiers!
Maintenant répond à cette autre question : comment font tous les SGBD actuels ? Le support physique aura toujours un taux de défaillance. Le tout est d'être capable de reconstruire la base après un crash. Pour cela il y a pleins de systèmes : backup, log, duplication, etc.

La vidéo est pourtant clair et explicite :
"It's not just about search anymore"
"It's about seeing relationships... across your data..."

Effectivement WinFS utilise NTFS comme support de l'information, mais les programmeurs et les utilisateurs ne voient plus le système de fichier, WinFS fourni une abstraction de plus haut niveau, basé sur un modèle relationnel. Bref, il y a exactement la même différence entre une base de données SQL et des données dans un fichier texte classés dans des répertoires.

Ce genre de système existe déjà dans de nombreuses application de musique, où les tags des chansons sont utilisés comme méta-données pour fournir une abstraction généralement appelée "bibliothèque musicale", où tu te moques éperdument de l'emplacement de ton fichier, ce qui t'intéresse c'est de pouvoir le retrouver classé par genre, par album, par artiste, etc.

qui est deja livré par defaut avec macos, et qui existe sous forme de surcouche pour linux (beagle)?
N'importe quoi :)
Tu confonds moteur d'indexation/recherche et système de fichier orienté contenu.

On appelle ca des frames. L'histoire a décidé que les frames devaient mourir parcqu'elles puent.