Va me dire ca quand j'ai compilé en statique un binaire sous un athlon xp , et je l'ai fait marché sous un freebsd sur un xeon.
Va pas me dire que c'est la solution optimal et la solution retenue par la plupart des distributions :)
Tu parle pe du bordel si une librairie est plus récente ou moins récente qu'une autre ?
Je parle du problème propre au monde open-source : à moins de tout compiler en statique, si toto utilise tel compilateur pour sa bibliothèque et marcel tel compilateur avec telle autre option pour la même bibliothèque (même version), les programmes utilisant la bibliothèque peuvent péter à tout moment.
Sous Windows, y'a quand même la techno COM qui résoud un grand nombre de problèmes liés aux interfaces de binaires. Sans parler des technos plus modernes qui résolvent pleinement ces problème de compatibilité binaire (.NET, Java), voir sans binaire (Python & Co). Mais tout ce qui est à base de C sous Linux, binairement parlant c'est le bordel.
Si les applis sont codés avec les pieds, oui, certains peuvent ne pas être compatibles. Mais si tu codes normalement en suivant les recommandations, et sans aller faire des hacks à 2 balles, la plupart des applis marchent. Binairement elles sont toutes potentiellement compatibles. Sous Linux, c'est le bordel complet d'un point de vu binaire. Tu me diras, on a les sources. Mais vu que GCC a également pété la compatibilité de partout et à plusieurs reprises dans le temps, c'est pas mieux.
Oué je vois, c'est pas très portable, c'est plus Linux friendly (ce qui se confirme maintenant que je suis chez moi :) ) Enfin ils auraient mieux fait de pas sortir la version Windows du tout, parcque là franchement, à part donner une très image du bouzin pour ceux qui n'ont pas la possibilité de tester sous Linux...
D'un point de vu droit d'exécution oui. D'un point de vu purement technique non. Bien qu'étant un noyau monolithique à la base, Linux est quand même suffisament bien foutu pour accepter des drivers "externes", d'où la présence des APIs. Ce qui les rend pas "user-friendly", c'est la façon dont ils sont maintenus. Y'a aucune raison de cantonner les drivers au processus interne de dev du noyau, ca doit ête externaliser pour que tout le monde puisse développer ses propres drivers sans subir la politique d'évolution du kernel. Evidemment, ca demande un minimum de boulot d'ingénierie de la part du noyau.
Et puis si on en revient à la question des privilèges utilisateurs, il n'est pas non plus pertinent de faire tourner l'ensemble des drivers avec les droits du noyau. Si un grand nombre de driver tourne encore dans cet espace de droit, c'est simplement pour des questions techniques (vitesse toussa), mais d'un point de vue architectural c'est pas du tout préconisé. Pour comparer avec un OS proprio dernière génération, beaucoup de drivers sont gérés avec un niveau de droit inférieurs aux droits du kernel lui même, voir même en espace utilisateur.
Evidemment, tout cela demande une refonte technique et politique du noyau Linux, mais ca reste un objectif de qualité qu'ils devraient se fixer, et visiblement ils s'en cognent. Si tu veux développer ton driver et que tu n'as pas l'intention de l'incorporer dans la branche principal, ils ne font rien pour t'aider, tu te démerdes pour suivre ces API "internes".
Le truc c'est qu'ils considèrent que les API des drivers sont de la tambouille interne, genre comme si les drivers faisaient partie intégrante du noyau.
Faut m'expliquer pourquoi sous XP ca serait lent et moche... c'est du Java made in Sun, réputé pour être plus performant sous Windows que sous Linux... C'est pas plutôt dû à la carte graphique ?
Sur un P4 2,8Ghz sous Windows XP avec 1 Go de RAM mais une carte vidéo intégrée, ca rammmme sec. y'a des trucs qui clignottes (genre des textures), et c'est globalement moche.
Après ca vient peut être de ma config.
Ben à l'époque le code traînait partout sur le net (eMule toussa), donc tout le monde pouvait vérifier. Il y est peut être encore. Bref, un grand nombre de personne y ont eu accès, des mecs payés par MS comme des détracteurs de MS impossible à soudoyer.
Ca fait quand même 2 fois que quelqu'un du support me conseille de résilier le contrat Free. C'est quoi cette politique de support de merde ?
Bof, c'est juste lié à France Telecom. En gros ca prend moins de temps de résilier une ligne et d'en commander une nouvelle auprès de FT que de demander une vérification de la ligne.
Comme le code crosoft est fermé peut importe, pourvu que ca semble marcher.
C'est quoi ces conneries à 2 balles ? Parcque une entreprise qui fait un produit proprio n'a aucun moyen de mettre en place un processus de qualité pour le code qu'elle écrit ? Tu racontes vraiment n'importe quoi pour servir tes propos, le tout basé sur des suppositions et le dénigrement de choses que tu ne peux pas vérifier. Ca s'appelle du FUD.
Moi je me rappelle d'une seule chose qui est sortie de chez MS avec le code source : le service pack (jesaispluscombien) de Windows 2000. Et bizzarement tous les analystes avaient constatés que le code était particulièrement bien écrit, structuré, documenté.
Ce qui est étonnant c'est qu'une boite comme crosoft, avec un code pour le moins.... bancal.. est arrivé à cette réussite
Mais c'est quoi encore ce FUD à 2 balles ? T'as le code de IIS6 pour prétendre ca ?
Je crois qu'en fait tu viens ici pour apprendre, mais que tu n'as pas compris exactement comment le libre fonctionne.
Affirmation gratuite. Ce que je constate, c'est qu'une bonne partie des "évangélistes" du libre font la promotion du libre en dénigrant systématiquement les produits concurrents, parfois sans aucune référence technique tangible, bref, du FUD à l'état pur. Et après ils s'étonnent que MS conserve ses parts de marché, et mettent en place des vagues théories du complot, se liguent contre le mal et sa propagande...
Moi je suis pragmatique et je constate. Il y a des bons logiciels libres comme il y a des bons logiciels proprios. C'est le cas de IIS6 et de Apache2. Moi je préfères largement mettre en avant les atouts techniques de Apache2 (modularité toussa, bien que IIS7 rattrape ce retard) et les avantages des licences libres, j'ai l'impression d'être beaucoup plus pertinent que des types comme toi qui ne font que désservir leur cause par un manque total de crédibilité (évidemment, ici tu prêches des convaincus, c'est totalement différent).
tant mieux pour eux si certains veulent implementer sur linux des framework made in microsoft , mais vient pas pleurer que certaines personnes les conspuent.
Attaque stupide sans aucun rapport. Allons conspuer OpenOffice.org, c'est vrai ils implémentent des technos de MS, allons conspuer Wine qui ne fait que copier (sans valeur ajoutée). Du grand n'importe quoi, tous ces projets apporte un plus indéniable à l'environnement Linux.
Je suis pirate, je trouve une faille dans IIS. Je la garde pour moi pour l'exploiter (je suis méchant). J'en trouve une dans Apache. Ah bah non là je suis gentil je la divulge, mais uniquement aux membres de l'équipe et je la rend publique que quand je suis sûr qu'un patch va être disponible.
Non faut arrêter c'est du n'importe quoi que tu nous racontes là, il n'y a aucune raison d'agir différement pour l'un ou l'autre produit.
Faut se rendre à l'évidence, MS fait aussi des produits qui ne sont pas "troués" de partout. IIS depuis 2 ans c'est 3 failles de sécu, comme pour Apache2.
Sachant que free amasse la majorité de problemes/plaintes
Pure connerie non étayée. Si tu mattes la plupart des sondages de satisfaction des clients des différents FAI, tu verras que Free n'est pas pire (sans doute pas mieux non plus) qu'un autre. Mon expérience dans mon entourage (ca vaut ce que ca vaut) m'a montré qu'ils ont tous des problèmes, que ce soit chez Free, Orange ou autre Neuf.
Ah ouais ? Et si c'est bien leur faute ? Ils se bougent le cul ? Te remboursent tes frais de téléphone ?
D'où l'idée de faire faire au client quelques tests pour savoir si ca vient de la ligne (FT ou Free), de la Freebox (Free) ou de l'utilisateur. Et c'est pour ca que je disais qu'un client coopératif est toujours mieux servi qu'un client à la con qui gueule en disant uniquement "m'en fou je paie faut que ca marche".
Ils se bougent le cul ?
Ben globalement si le problème vient de FT, ils envoient un ticket GAMOT et attende la réponse. Tu remarqueras que c'est le seul FAI qui propose une console de suivi des tickets GAMOT à ses clients pour qu'ils soient informés de ce qui est fait. SI c'est un problème de Freebox, Free propose un échange standard sans frais d'expédition pour le client. Si le problème est insoluble, ils se déplacent chez toi. Quand aux frais téléphoniques, Free donne désormais des cartes prépayés de 30 minutes.
Enfin, je suppose que tu fais partie des gens qui trouvent qu'on devrait laisser une pleine liberté à toutes ces pauvres petites entreprises
Moi je dis juste qu'un minimum de coopération ne nuit à aucun des 2 parties, qu'il soit fournisseur de service ou client.
Ils sont tenu à te fournir ce service, pour le reste ce n'est pas ton problème.
Et si c'est de TA faute que le service ne fonctionne pas ? Tu y as pensé à ca ? Globalement j'ai eu l'occasion de dépanner plein de monde dans mon entourage, si tu savais le nombre de fois que ca vient de l'utilisateur (le plus fréquent : un câble débranché, souvent : problème de configuration sur l'ordinateur)...
Faut-il encore le rappeler, Free s'engage à fournir un service en "collaboration" avec l'abonné, puisqu'une partie du service dépend de paramètres qui lui sont propres : toute la fin de la ligne, l'installation téléphonique finale, l'ordinateur, lui appartient.
Alors non, quand le service ne fonctionne pas, ca ne vient pas forcement de Free, et ca peut être TON problème.
En tout cas tout est explicitement mis dans l'article 21 de leur contrat, conformément à la directive ministérielle du début de l'année relative aux contrats de télécommunication : http://adsl.free.fr/cgv/CGV_FORFAIT_hors_opt_19122006.pdf
L'usager est tenu d'être un minimum coopératif, dans SON intérêt.
Oué mais si tout le monde fait pareil, c'est les journaux dans leur ensemble qui vont manquer d'intérêt et avoir globalement moins de réponse. Evidemment un de temps en temps ne va pas "tuer" les journaux, mais sur le principe on ne peut que conseiller de choisir la bonne catégorie. Si les gens veulent pas lire les forums, c'est un autre problème, mais ne les forçons pas à lire les questions en les noyants dans ce qu'ils trouvent intéressant ;)
Mouarf, c'est typiquement le genre de réaction que je trouve contre-productive au possible. Faut arrêter les comparaisons à 2 balles pour dénoncer n'importe quoi et demander tout de la part de son fournisseur de service sous prétexte que "môssieur est le client", il est roi, il a payé, on DOIT lui donner le service.
Non, si Free préfères avoir un service après vente de moins bonne qualité mais avec un prix inférieur, c'est leur problème, et personne ne te force à signer le contrat qu'ils te proposent où ils ne proposent aucune garantie quand au fonctionnement du service.
Dans leur contrat, c'est marqué nul part qu'ils s'engageaient à se déplacer chez toi pour résoudre tous tes problèmes. C'est marqué nul part qu'ils devaient te payer les frais de port en cas de problème. Et pourtant ils sont gentils, la plupart du temps, il se passe un échange entre l'ancienne et la nouvelle freebox, sans frais pour l'abonné.
Quand ils suggèrent de tester une autre freebox sur la ligne, c'est clairement pour gagner du temps : sans ca, Free doit tenter de vérifier sans la freebox d'où vient le problème, ce qui revient à demander à FT de vérifier le bon câblage de la ligne. Connaissant les délais de FT, la réponse risque d'être "lente"... A part faire chier le client, car c'est lui qui va devoir poireauter, c'est quoi l'intérêt ? Free ne force aucun client à tester avec une autre Freebox, tu peux très bien dire non (t'as pas d'amis toussa), et tu suis la procédure standard : tu attends qu'ils diagnostiquent. Ils peuvent même par exemple prendre la décision de se déplacer (avec ton accord) et s'apercevoir que le problème vient de toi (genre ton rezo téléphonique dans ton appart) et te faire payer le déplacement... C'est pas plus simple de tester une autre freebox par hasard ? C'est si simple !
Voilà c'est tout ce que je voulais dire, Free ne te force pas à les aider, mais c'est parfois dans ton intérêt de les aider d'une manière relativement "simple".
Mais bon, comme il y en a pour les défendre "parce que c'est eux" [ sur un air de parce que c'était lui, parce que c'était elle Abellard et Eloïse], c'est pas parti pour changer .
mais c'est pareil avec tous les FAIs, c'est le problème d'un techno avec des fournisseurs de service à distance. C'est comme le SAV d'un PC made in Taïwan, des fois faut attendre 6 mois que ton engin fasse l'aller-retour à Taïwan, c'est quand même plus simple de bêtement tester la pièce potentiellement défaillante si t'en es capable non ? C'est toi qui voit, c'est dans ton intérêt.
Etonnant comme on se retrouve encore 'rivaux' sur des sujet qui n'ont rien à voir non ?
Y dit qu'il voit pas l'rapport. Enfin si ca t'amuses de chercher des liens cachés...
Tu préfères qu'ils te disent : "ok renvoyez nous la freebox (à vos frais bien sûr comme indiqué dans les CGV) on va tester chez nous et vous la renvoyer, vous l'aurez probablement dans 3 ou 4 semaines" ?
Non, le plus intelligent reste effectivement de commencer à savoir si c'est un problème de freebox avant de la réexpédier, c'est préférable pour tout le monde. Ca sert à rien de faire le client bête et méchant qui ne veut rien comprendre, c'est toujours sur lui qui ca retombe.
Ce qui fait qu'ils ont beau avoir un numéro dédié, sans téléphone, ils ne peuvent pas l'appeler !
Oué enfin ca Free peut pas y faire grand chose... N'empêche que t'es sûr d'avoir appelé le numéro "spécial" pour les dégroupagés total (valable aussi pour Freebox Only) ? Elle est réputée pour être joignable instantanément... Si c'est pas le cas, je soupçonne grandement ton opérateur de téléphonie mobile.
"Vous êtes abonné Dégroupage Total ou Freebox Only, c'est à dire que vous n'avez plus d'abonnement téléphonique avec l'opérateur historique, contactez le Centre Relation Utilisateur spécialisé au 08 92 13 51 61 (0,34 euros soit 2,21 F TTC /mn) Le Centre est disponible 7 jours sur 7, 24 heures sur 24."
PS : visiblement t'as un problème de synchro, mon expérience et celles de nombreuses personnes indiquent qu'il y a très très peut de chance que le problème vienne de Free, surtout si c'est pas en dégroupé : soit une fausse manip de FT, soit pire, un slamming d'un concurrent (et c'est en grande partie pourquoi éthiquement je ne conseillerai jamais un de ces concurrents, aussi compétents soient-ils techniquement)
PS2 : quand tu dépannes pour tata ou mémé, toujours se faire passer pour tata ou mémé, pas dire que t'es pas eux, comme ca ils te disent pas que c'est à eux d'appeler directement.
J'ai pas tout compris... Soit ils sont en dégroupage partiel ou non dégroupé, auquel cas ils ont toujours une ligne de téléphone fixe pour appeler, soit ils sont en dégroupage total, auquel cas Free a un numéro dédié qui répond instantanément.
Sinon effectivement mon expérience perso confirme le fait que depuis certains opérateurs de portable (testé avec Orange), j'ai beaucoup plus de mal à joindre Free, je sais pas d'où ca vient (Orange ou Free ?). Certains constatent-ils la même chose avec Bouygues ou SFR ?
Sinon on a beau gueuler comme on veut, le service client ca coûte cher, je comprend aisement qu'ils n'ai pas envie d'appeler tous les clients qui en font la demande. Désolé mais Free c'est du "low-cost", dans les 30 euros y'a pas grand chose de dédié au support client. Faut se tourner vers d'autres FAI pour ca.
il peut apparaître que le processus de developpement chez microsoft n'est pas si obscur que cela car Miguel de Icaza a pu développer mono, mais est-ce que les informations qu'il a reçu sont disponibles à tous (du simple geek au développeur fou en passant par ma grand-mère), ou a-t-il pu les récupérer car il travaillait sur un projet spécifique ?
Grosso merdo le projet Mono se base principalement sur les specifications de l'ECMA, sur la documentation des bibliothèques de la MSDN et bien sûr le comportement réel du framework .NET. Effectivement Mono a commencé avant la sortie "officielle" du framework .NET, mais ca faisait déjà un bon bout de temps qu'il était en version beta (plus d'1 an), que la doc existait. Evidemment, certaines infos proviennent également directement des ingénieurs de MS. (le plus souvent il suffit de leur poser les bonnes questions sur les forums de MSDN, à travers les mailing list ou directement par mail voir, en face :) )
Excuse-moi pour le message précédent, je vais la refaire plus calme :
Merci, c'est beaucoup plus intéressant comme ca en plus ;)
Tu va me dire que ça donne le même résultat au final : soit on se fait intégrer upstream, soit on est condamné à rester à la bourre; mais sinon, ce serait le kernel qui serait tout le temps à la bourre.
Toutafé :)
jusqu'à maintenant, l'interface des drivers n'est pas une interface utilisateur car justement tout se passe en espace kernel, pas utilisateur.
Je n'employais pas le terme utilisateur au sens séparation espace noyau/espace utilisateur, mais au sens utilisation : le kernel offre des services et des points d'entrée pour s'interfacer avec lui. Pour moi les drivers sont un moyen d'utiliser le kernel (et réciproquement) au même titre que POSIX (même si c'est pas du tout le même cadre d'utilisation), les drivers ne doivent pas être "fagocités" par le kernel.
Quel rapport entre maintenir une API stable et la qualité du code ? Linux est très bien codé même si son API est changeante.
La stabilité de l'API constitue également une qualité. Il y a pleins de choses qui font qu'une brique logicielle est de qualité : qualité du code, qualité de la documentation, qualité de la conception, etc. J'ai essayé d'expliquer que des API non stables peut être véritablement handicapant, que ce n'est pas une simple question de compatibilité avec le proprio, que c'est un problème de qualité plus général.
D'un côté tu reproches l'API trop changeante, et après tu souhaites une réécriture complète (en parallèle avec l'ancienne, je suppose) ?
Oui, en parrallèle. On met en place un groupe "d'architecte" qui concoivent une API pensée avec les technos d'aujourd'hui et celle de demain, on fait un truc "propre" avec une certaine durée de vie. Et surtout on s'arrange pour que ca soit facile à "échanger" contre un nouvel API dans le futur, car c'est évident que le boulot devra être refait dans plusieurs mois/années. Si c'est bien foutu, on pourra créer une nouvelle version de l'API plus tard, migrer ceux qui sont important, et garder la compatibilité avec l'ancien. Un peu comme de nombreuses bibliothèques au niveau applicatif. Ca marche très bien, on conserve la compatibilité avec les "vieux" trucs qui personne ne veut plus toucher (le plus souvent "parceque ca marche") et de l'autre on propose du neuf.
Bon, depuis le début, tu parles de changements incessants : aurais-tu un exemple ?
Fut un temps ma clé USB était reconnue. Puis pouf plus reconnue. 1 an après re-reconnue. Relou. Pareil pour ma carte son, fut une époque où la sortie numérique fonctionnait, plus maintenant. Tu me diras sur ce coup je suis pas sûr, ca vient peut être du serveur de son qui a changé, je sais pas trop à quel niveau ca se passe ca.
.. alors oui c'est encore un autre problème, surtout quand on est sur un problème qui concerne peu de personnes
C'est pour ca que dire "on a les sources, c'est pas proprio, ca va évoluer avec le noyau", c'est illusoire. C'est pareil dans le monde proprio, les vieux trucs qui deviennent "anonymes" ne sont plus maintenu par manque d'intérêt de la part des dev. Et c'est pour ca que j'aimerai bien que les API restent stables pour que je puisse garder mon vieux driver-qui-marchait plutôt que de le voir évoluer vers le néant.
oui ça prend pas mal de temps de s'adapter, mais ce n'est pas du dev "fermé".
J'ai bien entendu forcé le trait. Mais l'idée est là : les dev du noyau veulent fagociter un maximum de chose, ils promettent le support du vieux matos mais le résultat n'est pas forcement là, et ca se comprend aisement. Et je suis près à parier que plus la base de driver va grossir, et plus on aura de problèmes.
Le problème, à mon avis, en tant que simple utilisateur, c'est que tu n'as pas à t'occuper de ces problèmes
Toutafé. Et moi en tant qu'utilisateur je constate parfois les "dégâts". Et j'ai la chance en tant que développeur de comprendre le contexte et le pourquoi du problème, et c'est pour ca que je gueule :)
Par contre, pour le matériel, les nouveaux bus, les nouvelles technologies, etc ... arrivent régulièrement, et il faut s'adapter.
Toutafé. Mais moi je dis que y'a d'autres manière de "s'adapter" à mon sens.
Sinon je plussois toute la fin de ton commentaire ;)
Moi ce que je trouve dommage c'est qu'un des problèmes majeurs de Linux est le support du matos, à cause du manque de disponibilité de doc de la part des constructeurs. J'ai l'impression qu'on ne fait rien pour mettre en évidence les avantages de drivers libres, à savoir la pérennité dans le temps, la réutilisation, toussa, et c'est bien dommage.
Pfff, vivement le Hurd ;)
Tu peux préciser ?
Ben concrêtement avant j'installait le driver Gatos, et j'avais la possibilité d'utiliser la sortie TV de la carte par exemple. Depuis "l'intégration" à X.org, marche plus. Et évidemment Gatos n'est plus maintenu en externe.
Et puis si tu n'est pas content , reste sous Windows !
Déjà faudrait que j'y sois :) Non, justement je préfèrerai profiter de ce qu'apporte les LL : à savoir des drivers qui peuvent être pérennes dans le temps. Mais visiblement le kernel en décide autrement.
Croire qu'avec une API stable, on obtient une ABI stable est faux, car suivant le compilateur utilisé, par exemple, les alignements, lef ait d'inliner certaines fonctions, etc. changent ; stabilité = nil.
Je suis bien d'accord. C'est par contre un problème purement technique, lié au langage C (pourri pour ce qui est de faire des ABI stable). Mais à la limite je m'en cogne d'avoir des ABI stable, on est dans le monde libre, je veux bien me "taper" la recompilation d'un driver.
Je demande pas la compatibilité binaire, juste une compatibilité au niveau source. Bref, des API stables.
Ce dont on parle n'a rien à voir avec un standard, c'est la cuisine interne du noyau.
Ah non non. On parle interface de driver. Et ce que justement je dénonce c'est cette volonté de vouloir "fermé" le noyau en déclarant "c'est de la tambouille interne".
Justement, ce qu'on dit c'est l'interface utilisateur <-> kernel est plus ou moins "standard" (de fait), contrairement aux API internes.
Pour moi l'interface des drivers du noyau constitue pleinement une interface utilisateur. Tout du moins ca devrait l'être.
Ho non, ça demande juste de recoder complètement une partie du noyau tout en en maintenant une autre, soit à peu près le double d'effort.
Ah bah oui, un code de qualité, c'est sûr, ca demande plus d'effort, que voulez vous ma petite dame, on peut pas tout avoir, la liberté et la qualité. Moi je dénonce au passage que ce manque de qualité est à mettre en corrélation avec un mode de développement fermé, ce que je trouve vraiment dommage dans le monde des logiciels libres.
Oui, ça les fait chier de garder des anciennes API pourries pour les beaux yeux de contructeurs qui font du proprio et veulent des API bien stables.
Mais je parle pas de proprio du remarqueras. Je parles aussi des drivers en général.
Ils ne perdent pas leur temps à adapter les drivers puisqu'ils devront bien s'adapter un jour à cette nouvelle API !
T'as déjà développé en groupe ou quoi ? Entre faire 15 passes successives sur un même code pour acoucher d'un truc bancal et une réécriture propre tu trouves que c'est où la perte de temps ?
Oui c'est mieux d'avoir une API stable, mais ce n'est pas toujours possible. Le kernel avance très vite, et c'est cela qui a beaucoup bousculé le monde proprio :
Ca c'est effectivement la situation actuelle. Moi je râle sur ces changements incessant. Evidemment qu'il ne faut pas rester avec des API "figés". Que y'es des gros changement de Linux 2.4 à 2.6, je comprend. Qu'il y en ai tous les mois voir toutes les semaines, ca devient hallucinant. Les API qui "cassent" la compatibilité avec l'existant devrait apparaître dans les versions majeures, tous les 2 ans (je donne l'ordre de grandeur).
N'importe quoi, les changements assez profonds sont prévus à l'avance, bien documentés.
C'est pas n'importe quoi, ca change beaucoup trop souvent.
C'est le même genre de tendance qu'on a vu arriver avec le changement d'ABI d'Xorg 7.1 : certains utilisateurs ce sont mis à critiquer les packageurs de mettre Xorg 7.1 dans leur distro car NVidia et ATI n'avaient pas encore sorti de drivers compatibles avec la nouvelle API !
Mouarf, arrête de parler du problème du proprio. Enlève du sujet le proprio tu veux bien. Moi tu vois lors de l'intégration du pilote libre Gatos dans X.org (gestion des tuner et I/O video des cartes Radeon AIW), j'ai tout simplement vu disparaître un grand nombre de fonctionnalité de ma carte graphique. Youplaboum. Je fais quoi : je reste avec l'ancienne version ? Je maintiens moi même dans mon coin un driver que je dois modifier à chaque fois que les API changent ? Merci bien. C'est pas un problème de proprio/libre, c'est un problème général. Et j'en ai marre d'entendre cette excuse à 2 francs, limite on casse les API exprès pour faire chier le proprio. Et c'est la même chose à chaque fois : "pourquoi vous cassez les API ?" "Proprio c mal toussa". Où comment chercher des excuses philosophiques à des problèmes techniques. Du grand n'importe quoi (:-p)
Encore du n'importe quoi, les changements sont généralement documentés.
Pour moi un API qui change tout le temps, ca revient à faire une API fermée. La documentation n'est pas le saint graal. "Ah j'ai documenté, demerdez vous !".
Arf, comme tu dis au début de ton commentaire, Linux est toujours compatible POSIX malgré les changements dont on parle ici, heureusement. Encore du n'importe quoi.
Arrête avec ton "n'importe quoi". Tu fais exprès de pas comprendre. Je voulais dire qu'une des seules normes que le noyau suit, c'est l'interface POSIX, imposée dans un monde proprio. Ils avaient des bonnes pratiques à l'époque, il n'y a pas de raison de ne pas les utiliser aujourd'hui dans le monde libre. C'est pour ca que j'ironisait au début en disant qu'il faudrait standardiser les API de drivers du noyau, histoire de.
tu utilises le mot liberté pour obtenir arbitrairement des choses des gens, ce qui montre bien ton intolérance.
Houlà, mais je suis pas intolérant, je respecte le choix des développeurs du noyau, je serais inccapable de faire ce qu'ils font, mais en tant qu'utilisateur je donne mon avis. Enfin si on me pertinente, c'est que certains sont peut être dans la même situation que moi, à savoir de simple utilisateur qui aimerait voir leur noyau plus stable.
PS: Désolé pour la vulgarité, mais te voir dire tant de bêtises et te faire plusser ça m'énerve
C'est vrai que quand on prend un tout petit bout d'une phrase, en virant le contexte, en faisant samblant de pas comprendre ce que le type a voulu dire, et en disant "n'importe quoi" toutes les 2 lignes, ont doit vite s'énerver.
Un truc aussi qui m'énerve dans cette situation : Linux s'impose comme impossible à forker. J'entend par là que c'est pas demain la veille qu'on aura une alternative à Linux. Pas d'API stables pour les drivers ? Pas de couche d'abstraction du fonctionnement sous-jacent. Et donc pas d'alternative possible au coeur du noyau sans un fork de l'ensemble des drivers. Moi j'aimerai bien avoir une banque de driver "réutilisable" avec des vrais alternatives quand au noyau utilisé dessous.
[^] # Re: Partisant ?
Posté par TImaniac (site web personnel) . En réponse à la dépêche La guerre contre l'ODF et le RGI fait rage.... Évalué à 2.
Va pas me dire que c'est la solution optimal et la solution retenue par la plupart des distributions :)
Tu parle pe du bordel si une librairie est plus récente ou moins récente qu'une autre ?
Je parle du problème propre au monde open-source : à moins de tout compiler en statique, si toto utilise tel compilateur pour sa bibliothèque et marcel tel compilateur avec telle autre option pour la même bibliothèque (même version), les programmes utilisant la bibliothèque peuvent péter à tout moment.
Sous Windows, y'a quand même la techno COM qui résoud un grand nombre de problèmes liés aux interfaces de binaires. Sans parler des technos plus modernes qui résolvent pleinement ces problème de compatibilité binaire (.NET, Java), voir sans binaire (Python & Co). Mais tout ce qui est à base de C sous Linux, binairement parlant c'est le bordel.
[^] # Re: Partisant ?
Posté par TImaniac (site web personnel) . En réponse à la dépêche La guerre contre l'ODF et le RGI fait rage.... Évalué à 3.
[^] # Re: Quid des perfs
Posté par TImaniac (site web personnel) . En réponse au journal Looking Glass 3D en version 1.0 !. Évalué à 2.
[^] # Re: Faut pas exagerer...
Posté par TImaniac (site web personnel) . En réponse à la dépêche Une plongée dans le développement de Linux. Évalué à 1.
Et puis si on en revient à la question des privilèges utilisateurs, il n'est pas non plus pertinent de faire tourner l'ensemble des drivers avec les droits du noyau. Si un grand nombre de driver tourne encore dans cet espace de droit, c'est simplement pour des questions techniques (vitesse toussa), mais d'un point de vue architectural c'est pas du tout préconisé. Pour comparer avec un OS proprio dernière génération, beaucoup de drivers sont gérés avec un niveau de droit inférieurs aux droits du kernel lui même, voir même en espace utilisateur.
Evidemment, tout cela demande une refonte technique et politique du noyau Linux, mais ca reste un objectif de qualité qu'ils devraient se fixer, et visiblement ils s'en cognent. Si tu veux développer ton driver et que tu n'as pas l'intention de l'incorporer dans la branche principal, ils ne font rien pour t'aider, tu te démerdes pour suivre ces API "internes".
[^] # Re: Faut pas exagerer...
Posté par TImaniac (site web personnel) . En réponse à la dépêche Une plongée dans le développement de Linux. Évalué à 2.
[^] # Re: Quid des perfs
Posté par TImaniac (site web personnel) . En réponse au journal Looking Glass 3D en version 1.0 !. Évalué à 2.
[^] # Re: Et demain c'est Noel ????
Posté par TImaniac (site web personnel) . En réponse au journal Frontpage: Le chant du cygne. Évalué à 5.
[^] # Re: Quid des perfs
Posté par TImaniac (site web personnel) . En réponse au journal Looking Glass 3D en version 1.0 !. Évalué à -1.
Après ca vient peut être de ma config.
[^] # Re: Partisant ?
Posté par TImaniac (site web personnel) . En réponse à la dépêche La guerre contre l'ODF et le RGI fait rage.... Évalué à 2.
[^] # Re: Suite de mes aventures avec Free
Posté par TImaniac (site web personnel) . En réponse au journal Free n'est pas prêt pour assumer le téléphone. Évalué à 2.
Bof, c'est juste lié à France Telecom. En gros ca prend moins de temps de résilier une ligne et d'en commander une nouvelle auprès de FT que de demander une vérification de la ligne.
[^] # Re: Partisant ?
Posté par TImaniac (site web personnel) . En réponse à la dépêche La guerre contre l'ODF et le RGI fait rage.... Évalué à 5.
C'est quoi ces conneries à 2 balles ? Parcque une entreprise qui fait un produit proprio n'a aucun moyen de mettre en place un processus de qualité pour le code qu'elle écrit ? Tu racontes vraiment n'importe quoi pour servir tes propos, le tout basé sur des suppositions et le dénigrement de choses que tu ne peux pas vérifier. Ca s'appelle du FUD.
Moi je me rappelle d'une seule chose qui est sortie de chez MS avec le code source : le service pack (jesaispluscombien) de Windows 2000. Et bizzarement tous les analystes avaient constatés que le code était particulièrement bien écrit, structuré, documenté.
Ce qui est étonnant c'est qu'une boite comme crosoft, avec un code pour le moins.... bancal.. est arrivé à cette réussite
Mais c'est quoi encore ce FUD à 2 balles ? T'as le code de IIS6 pour prétendre ca ?
Je crois qu'en fait tu viens ici pour apprendre, mais que tu n'as pas compris exactement comment le libre fonctionne.
Affirmation gratuite. Ce que je constate, c'est qu'une bonne partie des "évangélistes" du libre font la promotion du libre en dénigrant systématiquement les produits concurrents, parfois sans aucune référence technique tangible, bref, du FUD à l'état pur. Et après ils s'étonnent que MS conserve ses parts de marché, et mettent en place des vagues théories du complot, se liguent contre le mal et sa propagande...
Moi je suis pragmatique et je constate. Il y a des bons logiciels libres comme il y a des bons logiciels proprios. C'est le cas de IIS6 et de Apache2. Moi je préfères largement mettre en avant les atouts techniques de Apache2 (modularité toussa, bien que IIS7 rattrape ce retard) et les avantages des licences libres, j'ai l'impression d'être beaucoup plus pertinent que des types comme toi qui ne font que désservir leur cause par un manque total de crédibilité (évidemment, ici tu prêches des convaincus, c'est totalement différent).
tant mieux pour eux si certains veulent implementer sur linux des framework made in microsoft , mais vient pas pleurer que certaines personnes les conspuent.
Attaque stupide sans aucun rapport. Allons conspuer OpenOffice.org, c'est vrai ils implémentent des technos de MS, allons conspuer Wine qui ne fait que copier (sans valeur ajoutée). Du grand n'importe quoi, tous ces projets apporte un plus indéniable à l'environnement Linux.
[^] # Re: Partisant ?
Posté par TImaniac (site web personnel) . En réponse à la dépêche La guerre contre l'ODF et le RGI fait rage.... Évalué à 3.
Non faut arrêter c'est du n'importe quoi que tu nous racontes là, il n'y a aucune raison d'agir différement pour l'un ou l'autre produit.
Faut se rendre à l'évidence, MS fait aussi des produits qui ne sont pas "troués" de partout. IIS depuis 2 ans c'est 3 failles de sécu, comme pour Apache2.
[^] # Re: echange de freebox ?
Posté par TImaniac (site web personnel) . En réponse au journal Free n'est pas prêt pour assumer le téléphone. Évalué à 3.
Pure connerie non étayée. Si tu mattes la plupart des sondages de satisfaction des clients des différents FAI, tu verras que Free n'est pas pire (sans doute pas mieux non plus) qu'un autre. Mon expérience dans mon entourage (ca vaut ce que ca vaut) m'a montré qu'ils ont tous des problèmes, que ce soit chez Free, Orange ou autre Neuf.
[^] # Re: echange de freebox ?
Posté par TImaniac (site web personnel) . En réponse au journal Free n'est pas prêt pour assumer le téléphone. Évalué à 4.
D'où l'idée de faire faire au client quelques tests pour savoir si ca vient de la ligne (FT ou Free), de la Freebox (Free) ou de l'utilisateur. Et c'est pour ca que je disais qu'un client coopératif est toujours mieux servi qu'un client à la con qui gueule en disant uniquement "m'en fou je paie faut que ca marche".
Ils se bougent le cul ?
Ben globalement si le problème vient de FT, ils envoient un ticket GAMOT et attende la réponse. Tu remarqueras que c'est le seul FAI qui propose une console de suivi des tickets GAMOT à ses clients pour qu'ils soient informés de ce qui est fait. SI c'est un problème de Freebox, Free propose un échange standard sans frais d'expédition pour le client. Si le problème est insoluble, ils se déplacent chez toi. Quand aux frais téléphoniques, Free donne désormais des cartes prépayés de 30 minutes.
Enfin, je suppose que tu fais partie des gens qui trouvent qu'on devrait laisser une pleine liberté à toutes ces pauvres petites entreprises
Moi je dis juste qu'un minimum de coopération ne nuit à aucun des 2 parties, qu'il soit fournisseur de service ou client.
[^] # Re: echange de freebox ?
Posté par TImaniac (site web personnel) . En réponse au journal Free n'est pas prêt pour assumer le téléphone. Évalué à 4.
Et si c'est de TA faute que le service ne fonctionne pas ? Tu y as pensé à ca ? Globalement j'ai eu l'occasion de dépanner plein de monde dans mon entourage, si tu savais le nombre de fois que ca vient de l'utilisateur (le plus fréquent : un câble débranché, souvent : problème de configuration sur l'ordinateur)...
Faut-il encore le rappeler, Free s'engage à fournir un service en "collaboration" avec l'abonné, puisqu'une partie du service dépend de paramètres qui lui sont propres : toute la fin de la ligne, l'installation téléphonique finale, l'ordinateur, lui appartient.
Alors non, quand le service ne fonctionne pas, ca ne vient pas forcement de Free, et ca peut être TON problème.
En tout cas tout est explicitement mis dans l'article 21 de leur contrat, conformément à la directive ministérielle du début de l'année relative aux contrats de télécommunication :
http://adsl.free.fr/cgv/CGV_FORFAIT_hors_opt_19122006.pdf
L'usager est tenu d'être un minimum coopératif, dans SON intérêt.
[^] # Re: les questions
Posté par TImaniac (site web personnel) . En réponse au journal Recherche framework désepérement. Évalué à 8.
[^] # Re: echange de freebox ?
Posté par TImaniac (site web personnel) . En réponse au journal Free n'est pas prêt pour assumer le téléphone. Évalué à 3.
Non, si Free préfères avoir un service après vente de moins bonne qualité mais avec un prix inférieur, c'est leur problème, et personne ne te force à signer le contrat qu'ils te proposent où ils ne proposent aucune garantie quand au fonctionnement du service.
Dans leur contrat, c'est marqué nul part qu'ils s'engageaient à se déplacer chez toi pour résoudre tous tes problèmes. C'est marqué nul part qu'ils devaient te payer les frais de port en cas de problème. Et pourtant ils sont gentils, la plupart du temps, il se passe un échange entre l'ancienne et la nouvelle freebox, sans frais pour l'abonné.
Quand ils suggèrent de tester une autre freebox sur la ligne, c'est clairement pour gagner du temps : sans ca, Free doit tenter de vérifier sans la freebox d'où vient le problème, ce qui revient à demander à FT de vérifier le bon câblage de la ligne. Connaissant les délais de FT, la réponse risque d'être "lente"... A part faire chier le client, car c'est lui qui va devoir poireauter, c'est quoi l'intérêt ? Free ne force aucun client à tester avec une autre Freebox, tu peux très bien dire non (t'as pas d'amis toussa), et tu suis la procédure standard : tu attends qu'ils diagnostiquent. Ils peuvent même par exemple prendre la décision de se déplacer (avec ton accord) et s'apercevoir que le problème vient de toi (genre ton rezo téléphonique dans ton appart) et te faire payer le déplacement... C'est pas plus simple de tester une autre freebox par hasard ? C'est si simple !
Voilà c'est tout ce que je voulais dire, Free ne te force pas à les aider, mais c'est parfois dans ton intérêt de les aider d'une manière relativement "simple".
Mais bon, comme il y en a pour les défendre "parce que c'est eux" [ sur un air de parce que c'était lui, parce que c'était elle Abellard et Eloïse], c'est pas parti pour changer .
mais c'est pareil avec tous les FAIs, c'est le problème d'un techno avec des fournisseurs de service à distance. C'est comme le SAV d'un PC made in Taïwan, des fois faut attendre 6 mois que ton engin fasse l'aller-retour à Taïwan, c'est quand même plus simple de bêtement tester la pièce potentiellement défaillante si t'en es capable non ? C'est toi qui voit, c'est dans ton intérêt.
Etonnant comme on se retrouve encore 'rivaux' sur des sujet qui n'ont rien à voir non ?
Y dit qu'il voit pas l'rapport. Enfin si ca t'amuses de chercher des liens cachés...
[^] # Re: echange de freebox ?
Posté par TImaniac (site web personnel) . En réponse au journal Free n'est pas prêt pour assumer le téléphone. Évalué à 4.
Non, le plus intelligent reste effectivement de commencer à savoir si c'est un problème de freebox avant de la réexpédier, c'est préférable pour tout le monde. Ca sert à rien de faire le client bête et méchant qui ne veut rien comprendre, c'est toujours sur lui qui ca retombe.
[^] # Re: pas tout compris
Posté par TImaniac (site web personnel) . En réponse au journal Free n'est pas prêt pour assumer le téléphone. Évalué à 7.
Oué enfin ca Free peut pas y faire grand chose... N'empêche que t'es sûr d'avoir appelé le numéro "spécial" pour les dégroupagés total (valable aussi pour Freebox Only) ? Elle est réputée pour être joignable instantanément... Si c'est pas le cas, je soupçonne grandement ton opérateur de téléphonie mobile.
"Vous êtes abonné Dégroupage Total ou Freebox Only, c'est à dire que vous n'avez plus d'abonnement téléphonique avec l'opérateur historique, contactez le Centre Relation Utilisateur spécialisé au 08 92 13 51 61 (0,34 euros soit 2,21 F TTC /mn) Le Centre est disponible 7 jours sur 7, 24 heures sur 24."
PS : visiblement t'as un problème de synchro, mon expérience et celles de nombreuses personnes indiquent qu'il y a très très peut de chance que le problème vienne de Free, surtout si c'est pas en dégroupé : soit une fausse manip de FT, soit pire, un slamming d'un concurrent (et c'est en grande partie pourquoi éthiquement je ne conseillerai jamais un de ces concurrents, aussi compétents soient-ils techniquement)
PS2 : quand tu dépannes pour tata ou mémé, toujours se faire passer pour tata ou mémé, pas dire que t'es pas eux, comme ca ils te disent pas que c'est à eux d'appeler directement.
# pas tout compris
Posté par TImaniac (site web personnel) . En réponse au journal Free n'est pas prêt pour assumer le téléphone. Évalué à 8.
Sinon effectivement mon expérience perso confirme le fait que depuis certains opérateurs de portable (testé avec Orange), j'ai beaucoup plus de mal à joindre Free, je sais pas d'où ca vient (Orange ou Free ?). Certains constatent-ils la même chose avec Bouygues ou SFR ?
Sinon on a beau gueuler comme on veut, le service client ca coûte cher, je comprend aisement qu'ils n'ai pas envie d'appeler tous les clients qui en font la demande. Désolé mais Free c'est du "low-cost", dans les 30 euros y'a pas grand chose de dédié au support client. Faut se tourner vers d'autres FAI pour ca.
[^] # Re: Faut pas exagerer...
Posté par TImaniac (site web personnel) . En réponse à la dépêche Une plongée dans le développement de Linux. Évalué à 3.
Grosso merdo le projet Mono se base principalement sur les specifications de l'ECMA, sur la documentation des bibliothèques de la MSDN et bien sûr le comportement réel du framework .NET. Effectivement Mono a commencé avant la sortie "officielle" du framework .NET, mais ca faisait déjà un bon bout de temps qu'il était en version beta (plus d'1 an), que la doc existait. Evidemment, certaines infos proviennent également directement des ingénieurs de MS. (le plus souvent il suffit de leur poser les bonnes questions sur les forums de MSDN, à travers les mailing list ou directement par mail voir, en face :) )
[^] # Re: Faut pas exagerer...
Posté par TImaniac (site web personnel) . En réponse à la dépêche Une plongée dans le développement de Linux. Évalué à 3.
Merci, c'est beaucoup plus intéressant comme ca en plus ;)
Tu va me dire que ça donne le même résultat au final : soit on se fait intégrer upstream, soit on est condamné à rester à la bourre; mais sinon, ce serait le kernel qui serait tout le temps à la bourre.
Toutafé :)
jusqu'à maintenant, l'interface des drivers n'est pas une interface utilisateur car justement tout se passe en espace kernel, pas utilisateur.
Je n'employais pas le terme utilisateur au sens séparation espace noyau/espace utilisateur, mais au sens utilisation : le kernel offre des services et des points d'entrée pour s'interfacer avec lui. Pour moi les drivers sont un moyen d'utiliser le kernel (et réciproquement) au même titre que POSIX (même si c'est pas du tout le même cadre d'utilisation), les drivers ne doivent pas être "fagocités" par le kernel.
Quel rapport entre maintenir une API stable et la qualité du code ? Linux est très bien codé même si son API est changeante.
La stabilité de l'API constitue également une qualité. Il y a pleins de choses qui font qu'une brique logicielle est de qualité : qualité du code, qualité de la documentation, qualité de la conception, etc. J'ai essayé d'expliquer que des API non stables peut être véritablement handicapant, que ce n'est pas une simple question de compatibilité avec le proprio, que c'est un problème de qualité plus général.
D'un côté tu reproches l'API trop changeante, et après tu souhaites une réécriture complète (en parallèle avec l'ancienne, je suppose) ?
Oui, en parrallèle. On met en place un groupe "d'architecte" qui concoivent une API pensée avec les technos d'aujourd'hui et celle de demain, on fait un truc "propre" avec une certaine durée de vie. Et surtout on s'arrange pour que ca soit facile à "échanger" contre un nouvel API dans le futur, car c'est évident que le boulot devra être refait dans plusieurs mois/années. Si c'est bien foutu, on pourra créer une nouvelle version de l'API plus tard, migrer ceux qui sont important, et garder la compatibilité avec l'ancien. Un peu comme de nombreuses bibliothèques au niveau applicatif. Ca marche très bien, on conserve la compatibilité avec les "vieux" trucs qui personne ne veut plus toucher (le plus souvent "parceque ca marche") et de l'autre on propose du neuf.
Bon, depuis le début, tu parles de changements incessants : aurais-tu un exemple ?
Fut un temps ma clé USB était reconnue. Puis pouf plus reconnue. 1 an après re-reconnue. Relou. Pareil pour ma carte son, fut une époque où la sortie numérique fonctionnait, plus maintenant. Tu me diras sur ce coup je suis pas sûr, ca vient peut être du serveur de son qui a changé, je sais pas trop à quel niveau ca se passe ca.
.. alors oui c'est encore un autre problème, surtout quand on est sur un problème qui concerne peu de personnes
C'est pour ca que dire "on a les sources, c'est pas proprio, ca va évoluer avec le noyau", c'est illusoire. C'est pareil dans le monde proprio, les vieux trucs qui deviennent "anonymes" ne sont plus maintenu par manque d'intérêt de la part des dev. Et c'est pour ca que j'aimerai bien que les API restent stables pour que je puisse garder mon vieux driver-qui-marchait plutôt que de le voir évoluer vers le néant.
oui ça prend pas mal de temps de s'adapter, mais ce n'est pas du dev "fermé".
J'ai bien entendu forcé le trait. Mais l'idée est là : les dev du noyau veulent fagociter un maximum de chose, ils promettent le support du vieux matos mais le résultat n'est pas forcement là, et ca se comprend aisement. Et je suis près à parier que plus la base de driver va grossir, et plus on aura de problèmes.
Le problème, à mon avis, en tant que simple utilisateur, c'est que tu n'as pas à t'occuper de ces problèmes
Toutafé. Et moi en tant qu'utilisateur je constate parfois les "dégâts". Et j'ai la chance en tant que développeur de comprendre le contexte et le pourquoi du problème, et c'est pour ca que je gueule :)
Par contre, pour le matériel, les nouveaux bus, les nouvelles technologies, etc ... arrivent régulièrement, et il faut s'adapter.
Toutafé. Mais moi je dis que y'a d'autres manière de "s'adapter" à mon sens.
Sinon je plussois toute la fin de ton commentaire ;)
Moi ce que je trouve dommage c'est qu'un des problèmes majeurs de Linux est le support du matos, à cause du manque de disponibilité de doc de la part des constructeurs. J'ai l'impression qu'on ne fait rien pour mettre en évidence les avantages de drivers libres, à savoir la pérennité dans le temps, la réutilisation, toussa, et c'est bien dommage.
Pfff, vivement le Hurd ;)
[^] # Re: Faut pas exagerer...
Posté par TImaniac (site web personnel) . En réponse à la dépêche Une plongée dans le développement de Linux. Évalué à 2.
Ben concrêtement avant j'installait le driver Gatos, et j'avais la possibilité d'utiliser la sortie TV de la carte par exemple. Depuis "l'intégration" à X.org, marche plus. Et évidemment Gatos n'est plus maintenu en externe.
Et puis si tu n'est pas content , reste sous Windows !
Déjà faudrait que j'y sois :) Non, justement je préfèrerai profiter de ce qu'apporte les LL : à savoir des drivers qui peuvent être pérennes dans le temps. Mais visiblement le kernel en décide autrement.
[^] # Re: Faut pas exagerer...
Posté par TImaniac (site web personnel) . En réponse à la dépêche Une plongée dans le développement de Linux. Évalué à 2.
Je suis bien d'accord. C'est par contre un problème purement technique, lié au langage C (pourri pour ce qui est de faire des ABI stable). Mais à la limite je m'en cogne d'avoir des ABI stable, on est dans le monde libre, je veux bien me "taper" la recompilation d'un driver.
Je demande pas la compatibilité binaire, juste une compatibilité au niveau source. Bref, des API stables.
[^] # Re: Faut pas exagerer...
Posté par TImaniac (site web personnel) . En réponse à la dépêche Une plongée dans le développement de Linux. Évalué à 2.
Ah non non. On parle interface de driver. Et ce que justement je dénonce c'est cette volonté de vouloir "fermé" le noyau en déclarant "c'est de la tambouille interne".
Justement, ce qu'on dit c'est l'interface utilisateur <-> kernel est plus ou moins "standard" (de fait), contrairement aux API internes.
Pour moi l'interface des drivers du noyau constitue pleinement une interface utilisateur. Tout du moins ca devrait l'être.
Ho non, ça demande juste de recoder complètement une partie du noyau tout en en maintenant une autre, soit à peu près le double d'effort.
Ah bah oui, un code de qualité, c'est sûr, ca demande plus d'effort, que voulez vous ma petite dame, on peut pas tout avoir, la liberté et la qualité. Moi je dénonce au passage que ce manque de qualité est à mettre en corrélation avec un mode de développement fermé, ce que je trouve vraiment dommage dans le monde des logiciels libres.
Oui, ça les fait chier de garder des anciennes API pourries pour les beaux yeux de contructeurs qui font du proprio et veulent des API bien stables.
Mais je parle pas de proprio du remarqueras. Je parles aussi des drivers en général.
Ils ne perdent pas leur temps à adapter les drivers puisqu'ils devront bien s'adapter un jour à cette nouvelle API !
T'as déjà développé en groupe ou quoi ? Entre faire 15 passes successives sur un même code pour acoucher d'un truc bancal et une réécriture propre tu trouves que c'est où la perte de temps ?
Oui c'est mieux d'avoir une API stable, mais ce n'est pas toujours possible. Le kernel avance très vite, et c'est cela qui a beaucoup bousculé le monde proprio :
Ca c'est effectivement la situation actuelle. Moi je râle sur ces changements incessant. Evidemment qu'il ne faut pas rester avec des API "figés". Que y'es des gros changement de Linux 2.4 à 2.6, je comprend. Qu'il y en ai tous les mois voir toutes les semaines, ca devient hallucinant. Les API qui "cassent" la compatibilité avec l'existant devrait apparaître dans les versions majeures, tous les 2 ans (je donne l'ordre de grandeur).
N'importe quoi, les changements assez profonds sont prévus à l'avance, bien documentés.
C'est pas n'importe quoi, ca change beaucoup trop souvent.
C'est le même genre de tendance qu'on a vu arriver avec le changement d'ABI d'Xorg 7.1 : certains utilisateurs ce sont mis à critiquer les packageurs de mettre Xorg 7.1 dans leur distro car NVidia et ATI n'avaient pas encore sorti de drivers compatibles avec la nouvelle API !
Mouarf, arrête de parler du problème du proprio. Enlève du sujet le proprio tu veux bien. Moi tu vois lors de l'intégration du pilote libre Gatos dans X.org (gestion des tuner et I/O video des cartes Radeon AIW), j'ai tout simplement vu disparaître un grand nombre de fonctionnalité de ma carte graphique. Youplaboum. Je fais quoi : je reste avec l'ancienne version ? Je maintiens moi même dans mon coin un driver que je dois modifier à chaque fois que les API changent ? Merci bien. C'est pas un problème de proprio/libre, c'est un problème général. Et j'en ai marre d'entendre cette excuse à 2 francs, limite on casse les API exprès pour faire chier le proprio. Et c'est la même chose à chaque fois : "pourquoi vous cassez les API ?" "Proprio c mal toussa". Où comment chercher des excuses philosophiques à des problèmes techniques. Du grand n'importe quoi (:-p)
Encore du n'importe quoi, les changements sont généralement documentés.
Pour moi un API qui change tout le temps, ca revient à faire une API fermée. La documentation n'est pas le saint graal. "Ah j'ai documenté, demerdez vous !".
Arf, comme tu dis au début de ton commentaire, Linux est toujours compatible POSIX malgré les changements dont on parle ici, heureusement. Encore du n'importe quoi.
Arrête avec ton "n'importe quoi". Tu fais exprès de pas comprendre. Je voulais dire qu'une des seules normes que le noyau suit, c'est l'interface POSIX, imposée dans un monde proprio. Ils avaient des bonnes pratiques à l'époque, il n'y a pas de raison de ne pas les utiliser aujourd'hui dans le monde libre. C'est pour ca que j'ironisait au début en disant qu'il faudrait standardiser les API de drivers du noyau, histoire de.
tu utilises le mot liberté pour obtenir arbitrairement des choses des gens, ce qui montre bien ton intolérance.
Houlà, mais je suis pas intolérant, je respecte le choix des développeurs du noyau, je serais inccapable de faire ce qu'ils font, mais en tant qu'utilisateur je donne mon avis. Enfin si on me pertinente, c'est que certains sont peut être dans la même situation que moi, à savoir de simple utilisateur qui aimerait voir leur noyau plus stable.
PS: Désolé pour la vulgarité, mais te voir dire tant de bêtises et te faire plusser ça m'énerve
C'est vrai que quand on prend un tout petit bout d'une phrase, en virant le contexte, en faisant samblant de pas comprendre ce que le type a voulu dire, et en disant "n'importe quoi" toutes les 2 lignes, ont doit vite s'énerver.
Un truc aussi qui m'énerve dans cette situation : Linux s'impose comme impossible à forker. J'entend par là que c'est pas demain la veille qu'on aura une alternative à Linux. Pas d'API stables pour les drivers ? Pas de couche d'abstraction du fonctionnement sous-jacent. Et donc pas d'alternative possible au coeur du noyau sans un fork de l'ensemble des drivers. Moi j'aimerai bien avoir une banque de driver "réutilisable" avec des vrais alternatives quand au noyau utilisé dessous.