OOo implémente des formats de document proprio de Microsoft.
Samba implémente un protocole proprio de Microsoft.
Tu veux dire que ces deux projets auraient été persona non grata dans la majorité des distributions Linux suite à l'accord Novell-Microsoft (qui est générique et ne cible pas tel ou tel logiciel) s'ils n'étaient pas protégés par l'OIN ?
Ils font comme tout le monde : ils commencent par faire des concerts dans les bars du coin, puis ils se font repérer et se retrouvent dans les petits festivals, ainsi de suite.
Comme ils font tous avant de rejoindre les majors en gros. Grosso merdo ils doivent tous se démerder pour faire leurs preuves avant de rentrer chez les "gros" et espérer faire de la thune.
Evidemment y'a le modèle inverse, où les majors tentent de créer des artistes de toute pièce à travers une campagne de promotion à la hauteur de leurs moyens. M'enfin le résultat artiste est généralement... comment dire... "artificiel".
Sinon le plus logique, c'est de shooter les majors : les artistes font eux même leur promotion en live, le bouche à l'oreille et internet fera le reste de la promo.
L'état met en place des studios d'enregistrement comme il met à disposition des équipements de sports dans les villes : l'artiste peut s'enregistrer à moindre frais.
L'artiste se rémunère sur ses performances live et sur la vente de trucs dérivés pour les fans (t-shirts & co) et la vente de CD/Vinyl si y'en a qui eu veulent.
Et on enmerde pas ceux qui arrive par eux même à reproduire et diffuser la musique.
Bah suffit de dumper la base de Last.fm et de menacer d'une coupure d'internet pendant 1 an pour tout défaut d'alimentation de son compte Last.fm avec des statistiques.
C'est quoi cette argumentation de merde ?
Allez, je te renvoi la question :
Cela fait combien de temps que le réveil fonctionne réellement sur une majorité de machine sous Linux ?
Combien de machine ne se réveille pas (ou ne s'endorme pas d'ailleur) !
De plus, je ne crois pas que Linux soit une référence en gestion d'énergie.
As-tu déjà codé un driver ? As-tu la moindre idée de la complexité
Et ? La complexité empêche d'avoir des API stables ?
Je dirais que plus c'est complexe, plus la nécessité d'avoir une indépendance est forte, et plus la présence d'une API stable est pertinente.
Je te le rappelle encore une fois : les hackers du kernel ont beau être des mecs hyper-compétents, ils n'ont pas les moyens de valider les modifs, aussi infîmes soient-elles, qu'ils effectuent sur les drivers.
C'est un choix qui va à l'encontre de la qualité.
Windows se traine n piles...
Le principal, c'est que ça marche : la qualité a un coût.
Tôt ou tard, faire des choix qui vont à l'encontre de la fiabilité du code produit l'effet inverse : bugs à analyser, reproduire, corriger.
c'est à lui de réparer les dégâts jusqu'à ce que tout compile
Tu n'a pas du bosser beaucoup dans une équipe de dev où y'a des contraintes qualité toi :)
Suffit pas que ca compile pour que ca marche ! D'où les régressions perpétuelles :-(
Mais à quel prix ? Le prix de la perte de drivers à chaque version de windows,
Déjà c'est tous les 3-4 ans, et souvent une API est stable pendant 2 versions de Windows, soit une durée de vie moyenne de 5 ou 6 ans.
Après si ca pète, c'est pas parcque Microsoft choisi de faire des API stables ! Si ca pète, c'est parcqu'il y a une lacune dans la maintenance. Parcque les drivers sont pas libre tout simplement. Ils seraient libres et utilisés, aucun doute qu'ils seraient migrés et maintenu !
Rien à voir avec les choix de stabilité des API du kernel.
Les vendeurs de hardware se foutent rapidement de leur driver quand il n'est plus vendu.
Z"ont qu'à faire des logiciels libres.
Je trouve que la solution actuelle est la moins couteuse pour avoir la meilleur qualité possible.
Et ben cette qualité est vraiment relative...
Il est question de drivers pas de programme !
Un driver n'est qu'un type de programme particulier ;)
tu parles sans doute de ce qui se fait de plus facile à comparer à ce qu'il y a de plus dur.
Oué bah comme toujours, les comparaisons ont leurs limites. Ensuite Gnome et KDE sont plus que des GUI hein, ces APIs peuvent s'incruster au coeur des applications (modèle objet, modèle de thread, etc). Les problématiques sont tout de même proche, il suffit de voir la transition de KDE3 vers KDE4 : la base de programmes basées sur KDE3 est énorme, à commencer dans KDE lui-même : la migration ne s'est pas faite sous le coude, le bout a été énorme de tout porté, heuresement que les API ne changent pas tous les 4 matins !
Tu crois franchement qu'avec une API figé c'est faisable ?
Quand l'interface est bien conçu et prévue pour être pérenne pendant 2 ou 3 ans, oui je penses. Sous Windows, ça marche.
Dans ce cas tu auras des drivers tout pourris qui ne seraient jamais corrigé.
? Pourquoi ?
Si des développeurs veulent bien maintenir les drivers dans le cadre du projet Linux, y'a pas de raison qu'ils ne veulent pas reprendre des drivers fourni par un constructeur et faire le même boulot, avec plus d'indépendance de l'équipe du kernel.
C'est la force du libre : tu peux reprendre/corriger/améliorer un logiciel tiers du moment que tu respectes la licence : tu forks le driver du constructeur si ca dérive trop.
Il y a des interactions assez forte avec le reste du kernel !
Je vois pas le rapport avec la stabilité dans le temps. Windows arrive à offrir cette stabilité, pourquoi pas Linux ?
?
Un développement libre n'implique absolument pas qu'il faut phagociter tout les composants dans un unique environnement.
Que je sache l'interface pour exécuter un programme est standardisé, je suis pas obligé d'inclure mon programme dans le repos du kernel il me semble. Ca m'empêche pas de faire du développement libre.
Que je sache Gnome ou KDE ont des interfaces relativement stables et je peux maintenir mes logiciels dans mon coin sans les déposer sur les repos des environnements respectifs !
Pourquoi devrait-il absolument en être autrement pour les drivers dans l'environnement kernel ?
Le libre prône il me semble l'indépendance à tous les niveaux, notamment à travers des standards.
Une API stable dans le temps irait beaucoup plus dans ce sens, mais ca fait chier l'équipe de dev du kernel, et les premiers à payer les pôts cassés sont les utilisateurs.
Sans parler que cette façon de tout vouloir phagociter décourage sûrement les fabriquants de hardware de faire leurs propres drivers pour Linux : ils n'ont aucune garantie de la stabilité des API/ABI : tout ce qu'ils peuvent faire, c'est intégrer leur code dans le repos de Linux, ce qu'ils ne veulent pas forcement faire pour diverses raisons (indépendance, contrôle du projet, des évolutions, de la maintenance).
Non, c'est le boulot des distributions
Les distributions SONT des utilisateurs.
Et les distributions ont pas plus les moyens de vérifier les régressions dans le kernel au vu du nombre de matos supporté. Donc c'est souvent l'utilisateur final qui trinque.
Et si tu veux un truc à qualité garanti, tu utilises une distrib "stable".
Vi c'est ce que je dis : l'administrateur il attend la debian stable, et l'utilisateur desktop qui veut utiliser son matériel un minimum récent, ben il fait office de beta-testeur.
tu te dis que heureusement, ils sont repris par les codeurs kernel !
Vu le nombre de régressions, je suis pas convaincu. Moi j'aime quand un truc qui marche on puisse continuer à l'utiliser tel quel. Je vois pas pourquoi un utilisateur devrait prendre le risque de perdre le support de sa carte son parcqu'il a voulu mettre à jour le kernel afin d'avoir le support d'un nouveau système de fichier.
Et puis ca n'empêcherait pas les mêmes développeurs de s'occuper des drivers dont ils s'occupent déjà. Je veux juste décorreler la maintenance des drivers des évolutions du kernel.
C'est ça le problème : c'est à l'utilisateur de mesurer les conséquences d'une upgrade. Il doit assumer les problèmes de compatibilité éventuels et revenir en arrière s'il constate une régression. Merci pour la qualité du service rendu.
Microsoft pousserait une upgrade du noyau NT qui explose le support de la carte graphique ou de tel imprimante, ça serait le scandale assuré. Pour Linux, c'est pas grave, le end-user il a pas besoin de qualité, et pour l'administrateur, il upgrade sa debian tous les 5 ans une fois que tous les end-users ont essuyés les plâtres.
Ca serait tellement plus simple de décorreler le dev/maintenance des drivers du dev/maintenance du noyau, mais non, Linus veut tout maîtrisé.
Je vois pas le rapport, c'est encore un autre choix là.
Une API peut être stable pendant 2-3 ans, c'est un autre choix de décider de garder la compatibilité avec l'ancienne API. Et tu peux garder une seule ou plusieurs génération, là encore c'est une question de choix.
Si tu veux mon avis sur cet autre choix décorrélé du premier, oui, il faut garder la compatibilité avec la version précédente (et uniquement la précédente) : ca a un coût, mais cela permet de laisser du temps pour "migrer" les drivers vers la nouvelle API, le temps qu'ils deviennent fiables et stables.
La qualité a un prix, ça c'est sûr. Mais assurer l'absence de régression en changeant plus souvent les API est encore plus coûteux, voir innaccessible pour la fondation Linux.
Ben c'est l'avantage l'API défini une interface unique pour tous les drivers d'un même type : faut mieux maintenir une seule API ou maintenir tous les drivers qu'il y a derrière, sachant qu'ils ont pas les moyens de vérifier les régressions ?
Va dire cela à ceux qui ont du matos qui n'est plus fonctionnelle sous Vista...
Je vois pas le rapport : là le problème c'est la maintenance des drivers : les API stables permettent justement de garantir que ca va marcher pendant quelques années. Evidemment les MAJ API arriveront tôt ou tard et là ca peut péter. Si le driver est pas maintenu, ben c'est la merde. D'où l'intérêt d'avoir des drivers open-source pour qu'on puisse les maintenir :)
Et non, doubler ou tripler l'effort de maintenance pour des bouts externes ne vaut pas le cout.
Tu sorts d'où ce chiffre ?
Les efforts de maintenance sont pour moi sur les drivers à chaque changement d'API. Des APIs qui changent moins souvent, ca demande moins de maintenance des drivers.
Et je suis persuadé que 80% de la différence de qualité (plantage) entre windows et Linux, c'est justement cette gestion des drivers par le noyau.
Tout à fait. Windows a fait évolué son modèle de driver pour que le gros du code des drivers graphiques tournent dans l'espace utilisateur : en cas de plantage, le kernel "redémarre" le driver incriminé. Ca marche, ca plante pas.
Cela a bien sûr nécessisté de casser totalement le modèle d'API, mais ils le modifient pas tous les 4 matins.
Je l'ai déjà lu et j'ai déjà trollé de nombreuses fois sur le sujet. Pour moi c'est un choix purement politique : Linus veut phagociter tout ce qui tourne autour du kernel et ne veut pas voir d'équipe qui puisse développer des composants de manière indépendante. Des API non-stables est une façon de dire aux dev : intégrez votre driver dans notre repos ou vous allez en chier pour la maintenance.
Ceux qui trinquent au final, c'est les utilisateurs, j'en ai ras le cul d'avoir ce petit coup de stress quand je vois le kernel dans les updates proposées par ma distri : est-ce que mon matos va encore fonctionné correctement après ?
La pratique montre que chez les concurrents (MacOSX et Windows), les API stables ça marche. Ce n'est donc pas un soucis technique mais bien un choix politique.
Je te renvoi à ce que t'as expliqué Nicolas plus haut
Nicolas ne dit rien du tout : il confirme que pour l'instant l'aspect composant en Lisaac n'existe pas.
Il précise qu'on peut faire des modules pour Linux (super), mais sans parler des perfs. Son message laisse uniquement sous-entendre que tout est une question de granularité, et qu'en Lisaac la granularité est plus grosse.
Bref, du blabla théorique.
'Fin étudie la question avant d'affirmer des choses de ce genre, parce qu'au niveau théorique, y répondre est assez difficile.
\o/ c'est la meilleur : pourquoi je demandes un exemple concrêt avec un découpage du compilateur MPEG2 à ton avis ? J'ai rien à prouvé moi : c'est Lisaac qui a tout à prouvé. Sur le papier, Lisaac permet d'avoir un gain de perf qui vient des optimisations globales. Pour moi le gain est forcement limité dès que tu procèdes à un découpage. A vous de me démontrer le contraire. Et toi comme Nicolas, vous ne faites que confirmer par des "ca dépend de la granularité" ou "y'aura moins d'optimisations possibles mais peut être que". Bref, vous pensez que la modularité ne pose pas de soucis, et de toute façon elle n'existe toujours pas en Lisaac.
Mais t'es comme la plupart du ingés javaiste/csharpiste (j'en ai plein dans ma boite), tu connais rien à la compilation. (ça c'est la petite méchanceté ;-)
Quel argument :) Même si je suis un ingé csharpiste, j'ai fais des études et suivi des cours de compilation et d'optimisation hein, j'ai peut être pas le niveau de pratique et théorique que vous avez, m'enfin j'ai suffisament de compréhension du sujet pour voir qu'optimisations globales et modularité peuvent être contradictoire. A vous de me montrer que cette contradiction est à l'avantage des perfs dans tous la majorité des cas.
Ben, on fait pareil, vu que c'est du C derrière.
Encore une fois tu esquives : je te rappelle qu'on parle de ta solution modulaire suivante : "il y a toujours la possibilité de découper le C en petits bouts, et de coller un .h pour lier le tout. Ce qui implique que s'il y a modif, seul le morceau modifié est recompilé. "
C'est ce truc que j'attend de voir dans un environnement de dev carré.
Inclure des méta donnée : tu peux avec les contrats, en les détournant un peu il est vrai,
En gros avec les contrats je peux "lire" les méta-données" d'un composant binaire écrit en Lisaac ? Ou bien tout est limité à la phase de compilation ?
Tu peux m'expliquer ce qu'est "mocker dynamiquement le code "
Ben, un outil qui utilises l'introspection et les méta-données inclus dans le binaire pour générer dynamiquement un composant qui se fait passer pour un autre.
Exemple avec Rhino en C# : http://www.ayende.com/projects/rhino-mocks/api/files/MockRep(...)
c'est quasi implémenté.
Et ben voilà, ca avance :)
Chez nous, ça s'appelle "shorter".
Url ? Exemple ?
chargement dynamique (plugins) : C'est quoi ?
Ben c'est : je regarde tous les composants binaire dans tel répertoire, je les charges à la volée, je cherche dedans les implémentation de mon contrat IPlugin et j'instancie un objet de ce type que je manipule ensuite. Un mécanisme de plugin quoi.
Bien sûr, je charge ce plugin dans un espace mémoire sécurisé pour pas qu'il vienne planter mon appli, mais pas dans un process différent hein, pas envie de nicker les perfs en faisant de la comm inter-process :)
abstraction hardware : C'est quoi ? (si c'est ce que je pense, on est largement en avance)
Ben, l'abstraction hardware, ca s'appelle une machine virtuelle qui fait totalement abstraction de la machine sur laquelle tourne le code. Pas de différence dans le code, une seule compil, un seul composant à déployer quelque soit la plateforme hardware cible.
déploiement à distance : C'est quoi ?
Si j'ai une application qui "cherche" des plugins sur un serveur distant, il faut que je puisse le télécharger, lui assigner un degré de confiance (en fonction d'une signature numérique par exemple) et l'exécuté dans un contexte sécurisé.
USB 1 : 1996
USB 1.1 : 1998
USB 2 : 2000
USB 3 : 2010
C'est compatible avec l'ordre de grandeur que j'ai donné.
Je parle pas d'autoriser la modification de l'ensemble des ABI tous les 3 ans, mais pour un type de périphérique donné. Et 3 ans c'est un ordre de grandeur, pas un truc figé dans le marbre.
alors t'aura bien plus de rétro-compatibilité à faire, et donc tu bloate ton noyau
Des fois la rétro-compatibilité est "imposée" par la norme : que tu le veuille ou non, une implémentation de USB 2 doit supporter les périphériques USB 1. M'enfin bon USB est un mauvais exemple puisque c'est déjà une interface un minimum générique.
Le sql integre au langage me parait pas forcement indispensable quand on voit la qualite d'un ORM tel qu'hibernate
Je penses qu'il fait référence à la syntaxe LINQ disponible en C# et issu de SQL, pas directement à SQL.
Explique moi un peu mieux, parce que si tu codes un kernel en C, tu fais de la compilation séparée, avec le défaut de perf qui vient avec (mais C est tellement bas niveau que ça ne se voit pas trop, tout est fait à la main).
Tout est dans les parenthèses que tu as mis : en C tu ne fais pas de compromis au final, ca ne change pas grand chose sur les perfs.
Dans un langage à compilation globale (je répète, SMartEiffel, Lisaac et d'autres), tu as toujours la possibilité de compiler globalement tes petits bouts, ce qui ne te fera perdre aucun avantage par rapport à C, tout en gagnant le haut niveau
Ben non, parcque en Lisaac le fait de ne pas compiler globalement ca va te faire "réellement" perdre des perfs (sinon c'est que le compiler global n'apporte pas de gain).
Je sais pas moi, découper votre encodeur MPEG2 en par exemple 10 modules séparés, et remesurez les perfs. Soit il n'y a quasiment pas de perte et on se rend compte que l'optimisation globale ne sert quasiment à rien, soit les perfs sont nettement dégradées et ca justifie l'optimisation globale tout en mettant en avant la contradiction de la modularité.
De plus, pour info, il existe pas mal de techniques pour faire de la compilation globale à partir de compilation séparée
Oué bah c'est pour ça que je dis : "quand est ce que Lisaac va résoudre le problème".
Ils font comment quand ils développent en C/C++ ?
Ben la chaîne de production à partir de modules est parfaitement prise en compte par les outils (compilo, linker, makefile, IDE). Je te demande comment on fait en Lisaac.
Je te rappelle que le but du projet, c'est l'embarqué, pas d'être un concurrent de Java et C# pour des logiciels de gestion.
Euh, le troll du journal cible le kernel Linux, même si Linux tourne sur de l'embarqué, c'est un projet pour moi "énorme", les problématiques de modularité sont pleinement à prendre en compte.
la compilation séparée pour être un langage "moderne" couvrant les problèmes de "dev en équipe à l'exécution en passant par les tests, la documentation et le déploiement."
C'était une remarque plus général sur Lisaac, pas spécialement lié à la compilation séparée.
Tests : possibilité d'inclure des méta-données, de mocker dynamiquement le code (nécessite l'introspection et la génération dynamique de code).
Documentation : syntaxe spécialisée et utilisable par le compilateur pour générer automatiquement une documentation externe synchronisée à chaque compil
ation (cf C#).
Déploiement : composants "versionnable", "signables", introspection et chargement dynamique (plugins), abstraction hardware, déploiement à distance, etc.
Linux passe directement de la case je casse l'API à la case je corrige tous les drivers.
Euh, quand ils changent une API, c'est pas pour "corriger" les drivers, c'est généralement pour offrir de nouvelles possibilités (nécessaire pour le kernel ou les améliorations des périphériques supportés). Donc ils ne corrigent rien, au contraire, ils sont obligés de modifier tous les drivers (alors que certains étaient sans doute stable et éprouvés) en prenant le risque d'introduire de nouveaux bugs/régression. Ceci est d'autant plus dangereux que la fondation Linux n'a pas les moyens de faire des tests de non-régression sur l'ensemble du matos. Bref, ca se fait globalement au détriment de la qualité, sans parler du fait que ces bugs va falloir les corriger, et ca prend du temps.
Si l'API introduit une faille de sécurité tu la gardes ?
Bien sûr que non. Celà dis le cas est rare et justifie une évolution.
[^] # Re: il est ou le blog de icaza ?
Posté par TImaniac (site web personnel) . En réponse au journal La réponse de Miguel de Icaza à Richard Stallman. Évalué à -5.
Samba implémente un protocole proprio de Microsoft.
Tu veux dire que ces deux projets auraient été persona non grata dans la majorité des distributions Linux suite à l'accord Novell-Microsoft (qui est générique et ne cible pas tel ou tel logiciel) s'ils n'étaient pas protégés par l'OIN ?
[^] # Re: Sinon le plus logique
Posté par TImaniac (site web personnel) . En réponse au journal Répartition d'une licence global. Évalué à 2.
[^] # Re: rentrons dans le vif du sujet
Posté par TImaniac (site web personnel) . En réponse au journal Linux un bloat, ah bon ?. Évalué à 2.
Tiens un autre GPL : http://sourceforge.net/projects/ext2fsd/develop
[^] # Re: La licence globale, c'est bof
Posté par TImaniac (site web personnel) . En réponse au journal Répartition d'une licence global. Évalué à 4.
Comme ils font tous avant de rejoindre les majors en gros. Grosso merdo ils doivent tous se démerder pour faire leurs preuves avant de rentrer chez les "gros" et espérer faire de la thune.
Evidemment y'a le modèle inverse, où les majors tentent de créer des artistes de toute pièce à travers une campagne de promotion à la hauteur de leurs moyens. M'enfin le résultat artiste est généralement... comment dire... "artificiel".
# Sinon le plus logique
Posté par TImaniac (site web personnel) . En réponse au journal Répartition d'une licence global. Évalué à 10.
L'état met en place des studios d'enregistrement comme il met à disposition des équipements de sports dans les villes : l'artiste peut s'enregistrer à moindre frais.
L'artiste se rémunère sur ses performances live et sur la vente de trucs dérivés pour les fans (t-shirts & co) et la vente de CD/Vinyl si y'en a qui eu veulent.
Et on enmerde pas ceux qui arrive par eux même à reproduire et diffuser la musique.
# facile
Posté par TImaniac (site web personnel) . En réponse au journal Répartition d'une licence global. Évalué à 6.
[^] # Re: rentrons dans le vif du sujet
Posté par TImaniac (site web personnel) . En réponse au journal Linux un bloat, ah bon ?. Évalué à 3.
Allez, je te renvoi la question :
Cela fait combien de temps que le réveil fonctionne réellement sur une majorité de machine sous Linux ?
Combien de machine ne se réveille pas (ou ne s'endorme pas d'ailleur) !
De plus, je ne crois pas que Linux soit une référence en gestion d'énergie.
[^] # Re: rentrons dans le vif du sujet
Posté par TImaniac (site web personnel) . En réponse au journal Linux un bloat, ah bon ?. Évalué à 2.
Et ? La complexité empêche d'avoir des API stables ?
Je dirais que plus c'est complexe, plus la nécessité d'avoir une indépendance est forte, et plus la présence d'une API stable est pertinente.
Je te le rappelle encore une fois : les hackers du kernel ont beau être des mecs hyper-compétents, ils n'ont pas les moyens de valider les modifs, aussi infîmes soient-elles, qu'ils effectuent sur les drivers.
C'est un choix qui va à l'encontre de la qualité.
Windows se traine n piles...
Le principal, c'est que ça marche : la qualité a un coût.
Tôt ou tard, faire des choix qui vont à l'encontre de la fiabilité du code produit l'effet inverse : bugs à analyser, reproduire, corriger.
[^] # Re: rentrons dans le vif du sujet
Posté par TImaniac (site web personnel) . En réponse au journal Linux un bloat, ah bon ?. Évalué à 4.
Tu n'a pas du bosser beaucoup dans une équipe de dev où y'a des contraintes qualité toi :)
Suffit pas que ca compile pour que ca marche ! D'où les régressions perpétuelles :-(
Mais à quel prix ? Le prix de la perte de drivers à chaque version de windows,
Déjà c'est tous les 3-4 ans, et souvent une API est stable pendant 2 versions de Windows, soit une durée de vie moyenne de 5 ou 6 ans.
Après si ca pète, c'est pas parcque Microsoft choisi de faire des API stables ! Si ca pète, c'est parcqu'il y a une lacune dans la maintenance. Parcque les drivers sont pas libre tout simplement. Ils seraient libres et utilisés, aucun doute qu'ils seraient migrés et maintenu !
Rien à voir avec les choix de stabilité des API du kernel.
Les vendeurs de hardware se foutent rapidement de leur driver quand il n'est plus vendu.
Z"ont qu'à faire des logiciels libres.
Je trouve que la solution actuelle est la moins couteuse pour avoir la meilleur qualité possible.
Et ben cette qualité est vraiment relative...
[^] # Re: rentrons dans le vif du sujet
Posté par TImaniac (site web personnel) . En réponse au journal Linux un bloat, ah bon ?. Évalué à 1.
Un driver n'est qu'un type de programme particulier ;)
tu parles sans doute de ce qui se fait de plus facile à comparer à ce qu'il y a de plus dur.
Oué bah comme toujours, les comparaisons ont leurs limites. Ensuite Gnome et KDE sont plus que des GUI hein, ces APIs peuvent s'incruster au coeur des applications (modèle objet, modèle de thread, etc). Les problématiques sont tout de même proche, il suffit de voir la transition de KDE3 vers KDE4 : la base de programmes basées sur KDE3 est énorme, à commencer dans KDE lui-même : la migration ne s'est pas faite sous le coude, le bout a été énorme de tout porté, heuresement que les API ne changent pas tous les 4 matins !
Tu crois franchement qu'avec une API figé c'est faisable ?
Quand l'interface est bien conçu et prévue pour être pérenne pendant 2 ou 3 ans, oui je penses. Sous Windows, ça marche.
[^] # Re: rentrons dans le vif du sujet
Posté par TImaniac (site web personnel) . En réponse au journal Linux un bloat, ah bon ?. Évalué à 2.
? Pourquoi ?
Si des développeurs veulent bien maintenir les drivers dans le cadre du projet Linux, y'a pas de raison qu'ils ne veulent pas reprendre des drivers fourni par un constructeur et faire le même boulot, avec plus d'indépendance de l'équipe du kernel.
C'est la force du libre : tu peux reprendre/corriger/améliorer un logiciel tiers du moment que tu respectes la licence : tu forks le driver du constructeur si ca dérive trop.
Il y a des interactions assez forte avec le reste du kernel !
Je vois pas le rapport avec la stabilité dans le temps. Windows arrive à offrir cette stabilité, pourquoi pas Linux ?
[^] # Re: rentrons dans le vif du sujet
Posté par TImaniac (site web personnel) . En réponse au journal Linux un bloat, ah bon ?. Évalué à 2.
Un développement libre n'implique absolument pas qu'il faut phagociter tout les composants dans un unique environnement.
Que je sache l'interface pour exécuter un programme est standardisé, je suis pas obligé d'inclure mon programme dans le repos du kernel il me semble. Ca m'empêche pas de faire du développement libre.
Que je sache Gnome ou KDE ont des interfaces relativement stables et je peux maintenir mes logiciels dans mon coin sans les déposer sur les repos des environnements respectifs !
Pourquoi devrait-il absolument en être autrement pour les drivers dans l'environnement kernel ?
Le libre prône il me semble l'indépendance à tous les niveaux, notamment à travers des standards.
Une API stable dans le temps irait beaucoup plus dans ce sens, mais ca fait chier l'équipe de dev du kernel, et les premiers à payer les pôts cassés sont les utilisateurs.
[^] # Re: rentrons dans le vif du sujet
Posté par TImaniac (site web personnel) . En réponse au journal Linux un bloat, ah bon ?. Évalué à 2.
[^] # Re: rentrons dans le vif du sujet
Posté par TImaniac (site web personnel) . En réponse au journal Linux un bloat, ah bon ?. Évalué à 1.
Les distributions SONT des utilisateurs.
Et les distributions ont pas plus les moyens de vérifier les régressions dans le kernel au vu du nombre de matos supporté. Donc c'est souvent l'utilisateur final qui trinque.
Et si tu veux un truc à qualité garanti, tu utilises une distrib "stable".
Vi c'est ce que je dis : l'administrateur il attend la debian stable, et l'utilisateur desktop qui veut utiliser son matériel un minimum récent, ben il fait office de beta-testeur.
tu te dis que heureusement, ils sont repris par les codeurs kernel !
Vu le nombre de régressions, je suis pas convaincu. Moi j'aime quand un truc qui marche on puisse continuer à l'utiliser tel quel. Je vois pas pourquoi un utilisateur devrait prendre le risque de perdre le support de sa carte son parcqu'il a voulu mettre à jour le kernel afin d'avoir le support d'un nouveau système de fichier.
Et puis ca n'empêcherait pas les mêmes développeurs de s'occuper des drivers dont ils s'occupent déjà. Je veux juste décorreler la maintenance des drivers des évolutions du kernel.
[^] # Re: rentrons dans le vif du sujet
Posté par TImaniac (site web personnel) . En réponse au journal Linux un bloat, ah bon ?. Évalué à 2.
Microsoft pousserait une upgrade du noyau NT qui explose le support de la carte graphique ou de tel imprimante, ça serait le scandale assuré. Pour Linux, c'est pas grave, le end-user il a pas besoin de qualité, et pour l'administrateur, il upgrade sa debian tous les 5 ans une fois que tous les end-users ont essuyés les plâtres.
Ca serait tellement plus simple de décorreler le dev/maintenance des drivers du dev/maintenance du noyau, mais non, Linus veut tout maîtrisé.
[^] # Re: rentrons dans le vif du sujet
Posté par TImaniac (site web personnel) . En réponse au journal Linux un bloat, ah bon ?. Évalué à 2.
Une API peut être stable pendant 2-3 ans, c'est un autre choix de décider de garder la compatibilité avec l'ancienne API. Et tu peux garder une seule ou plusieurs génération, là encore c'est une question de choix.
Si tu veux mon avis sur cet autre choix décorrélé du premier, oui, il faut garder la compatibilité avec la version précédente (et uniquement la précédente) : ca a un coût, mais cela permet de laisser du temps pour "migrer" les drivers vers la nouvelle API, le temps qu'ils deviennent fiables et stables.
La qualité a un prix, ça c'est sûr. Mais assurer l'absence de régression en changeant plus souvent les API est encore plus coûteux, voir innaccessible pour la fondation Linux.
[^] # Re: rentrons dans le vif du sujet
Posté par TImaniac (site web personnel) . En réponse au journal Linux un bloat, ah bon ?. Évalué à 2.
[^] # Re: rentrons dans le vif du sujet
Posté par TImaniac (site web personnel) . En réponse au journal Linux un bloat, ah bon ?. Évalué à 2.
Je vois pas le rapport : là le problème c'est la maintenance des drivers : les API stables permettent justement de garantir que ca va marcher pendant quelques années. Evidemment les MAJ API arriveront tôt ou tard et là ca peut péter. Si le driver est pas maintenu, ben c'est la merde. D'où l'intérêt d'avoir des drivers open-source pour qu'on puisse les maintenir :)
Et non, doubler ou tripler l'effort de maintenance pour des bouts externes ne vaut pas le cout.
Tu sorts d'où ce chiffre ?
Les efforts de maintenance sont pour moi sur les drivers à chaque changement d'API. Des APIs qui changent moins souvent, ca demande moins de maintenance des drivers.
Et je suis persuadé que 80% de la différence de qualité (plantage) entre windows et Linux, c'est justement cette gestion des drivers par le noyau.
Tout à fait. Windows a fait évolué son modèle de driver pour que le gros du code des drivers graphiques tournent dans l'espace utilisateur : en cas de plantage, le kernel "redémarre" le driver incriminé. Ca marche, ca plante pas.
Cela a bien sûr nécessisté de casser totalement le modèle d'API, mais ils le modifient pas tous les 4 matins.
[^] # Re: rentrons dans le vif du sujet
Posté par TImaniac (site web personnel) . En réponse au journal Linux un bloat, ah bon ?. Évalué à 2.
Ceux qui trinquent au final, c'est les utilisateurs, j'en ai ras le cul d'avoir ce petit coup de stress quand je vois le kernel dans les updates proposées par ma distri : est-ce que mon matos va encore fonctionné correctement après ?
La pratique montre que chez les concurrents (MacOSX et Windows), les API stables ça marche. Ce n'est donc pas un soucis technique mais bien un choix politique.
[^] # Re: rentrons dans le vif du sujet
Posté par TImaniac (site web personnel) . En réponse au journal Linux un bloat, ah bon ?. Évalué à 2.
Nicolas ne dit rien du tout : il confirme que pour l'instant l'aspect composant en Lisaac n'existe pas.
Il précise qu'on peut faire des modules pour Linux (super), mais sans parler des perfs. Son message laisse uniquement sous-entendre que tout est une question de granularité, et qu'en Lisaac la granularité est plus grosse.
Bref, du blabla théorique.
'Fin étudie la question avant d'affirmer des choses de ce genre, parce qu'au niveau théorique, y répondre est assez difficile.
\o/ c'est la meilleur : pourquoi je demandes un exemple concrêt avec un découpage du compilateur MPEG2 à ton avis ? J'ai rien à prouvé moi : c'est Lisaac qui a tout à prouvé. Sur le papier, Lisaac permet d'avoir un gain de perf qui vient des optimisations globales. Pour moi le gain est forcement limité dès que tu procèdes à un découpage. A vous de me démontrer le contraire. Et toi comme Nicolas, vous ne faites que confirmer par des "ca dépend de la granularité" ou "y'aura moins d'optimisations possibles mais peut être que". Bref, vous pensez que la modularité ne pose pas de soucis, et de toute façon elle n'existe toujours pas en Lisaac.
Mais t'es comme la plupart du ingés javaiste/csharpiste (j'en ai plein dans ma boite), tu connais rien à la compilation. (ça c'est la petite méchanceté ;-)
Quel argument :) Même si je suis un ingé csharpiste, j'ai fais des études et suivi des cours de compilation et d'optimisation hein, j'ai peut être pas le niveau de pratique et théorique que vous avez, m'enfin j'ai suffisament de compréhension du sujet pour voir qu'optimisations globales et modularité peuvent être contradictoire. A vous de me montrer que cette contradiction est à l'avantage des perfs dans tous la majorité des cas.
Ben, on fait pareil, vu que c'est du C derrière.
Encore une fois tu esquives : je te rappelle qu'on parle de ta solution modulaire suivante :
"il y a toujours la possibilité de découper le C en petits bouts, et de coller un .h pour lier le tout. Ce qui implique que s'il y a modif, seul le morceau modifié est recompilé. "
C'est ce truc que j'attend de voir dans un environnement de dev carré.
Inclure des méta donnée : tu peux avec les contrats, en les détournant un peu il est vrai,
En gros avec les contrats je peux "lire" les méta-données" d'un composant binaire écrit en Lisaac ? Ou bien tout est limité à la phase de compilation ?
Tu peux m'expliquer ce qu'est "mocker dynamiquement le code "
Ben, un outil qui utilises l'introspection et les méta-données inclus dans le binaire pour générer dynamiquement un composant qui se fait passer pour un autre.
Exemple avec Rhino en C# : http://www.ayende.com/projects/rhino-mocks/api/files/MockRep(...)
c'est quasi implémenté.
Et ben voilà, ca avance :)
Chez nous, ça s'appelle "shorter".
Url ? Exemple ?
chargement dynamique (plugins) : C'est quoi ?
Ben c'est : je regarde tous les composants binaire dans tel répertoire, je les charges à la volée, je cherche dedans les implémentation de mon contrat IPlugin et j'instancie un objet de ce type que je manipule ensuite. Un mécanisme de plugin quoi.
Bien sûr, je charge ce plugin dans un espace mémoire sécurisé pour pas qu'il vienne planter mon appli, mais pas dans un process différent hein, pas envie de nicker les perfs en faisant de la comm inter-process :)
abstraction hardware : C'est quoi ? (si c'est ce que je pense, on est largement en avance)
Ben, l'abstraction hardware, ca s'appelle une machine virtuelle qui fait totalement abstraction de la machine sur laquelle tourne le code. Pas de différence dans le code, une seule compil, un seul composant à déployer quelque soit la plateforme hardware cible.
déploiement à distance : C'est quoi ?
Si j'ai une application qui "cherche" des plugins sur un serveur distant, il faut que je puisse le télécharger, lui assigner un degré de confiance (en fonction d'une signature numérique par exemple) et l'exécuté dans un contexte sécurisé.
[^] # Re: rentrons dans le vif du sujet
Posté par TImaniac (site web personnel) . En réponse au journal Linux un bloat, ah bon ?. Évalué à 2.
[^] # Re: rentrons dans le vif du sujet
Posté par TImaniac (site web personnel) . En réponse au journal Linux un bloat, ah bon ?. Évalué à 2.
USB 1.1 : 1998
USB 2 : 2000
USB 3 : 2010
C'est compatible avec l'ordre de grandeur que j'ai donné.
Je parle pas d'autoriser la modification de l'ensemble des ABI tous les 3 ans, mais pour un type de périphérique donné. Et 3 ans c'est un ordre de grandeur, pas un truc figé dans le marbre.
alors t'aura bien plus de rétro-compatibilité à faire, et donc tu bloate ton noyau
Des fois la rétro-compatibilité est "imposée" par la norme : que tu le veuille ou non, une implémentation de USB 2 doit supporter les périphériques USB 1. M'enfin bon USB est un mauvais exemple puisque c'est déjà une interface un minimum générique.
[^] # Re: Rien de transcendant dirait-on
Posté par TImaniac (site web personnel) . En réponse au journal Noop : encore un nouveau langage ou bien nouvelle génération de langage. Évalué à 3.
Je penses qu'il fait référence à la syntaxe LINQ disponible en C# et issu de SQL, pas directement à SQL.
[^] # Re: rentrons dans le vif du sujet
Posté par TImaniac (site web personnel) . En réponse au journal Linux un bloat, ah bon ?. Évalué à 2.
Tout est dans les parenthèses que tu as mis : en C tu ne fais pas de compromis au final, ca ne change pas grand chose sur les perfs.
Dans un langage à compilation globale (je répète, SMartEiffel, Lisaac et d'autres), tu as toujours la possibilité de compiler globalement tes petits bouts, ce qui ne te fera perdre aucun avantage par rapport à C, tout en gagnant le haut niveau
Ben non, parcque en Lisaac le fait de ne pas compiler globalement ca va te faire "réellement" perdre des perfs (sinon c'est que le compiler global n'apporte pas de gain).
Je sais pas moi, découper votre encodeur MPEG2 en par exemple 10 modules séparés, et remesurez les perfs. Soit il n'y a quasiment pas de perte et on se rend compte que l'optimisation globale ne sert quasiment à rien, soit les perfs sont nettement dégradées et ca justifie l'optimisation globale tout en mettant en avant la contradiction de la modularité.
De plus, pour info, il existe pas mal de techniques pour faire de la compilation globale à partir de compilation séparée
Oué bah c'est pour ça que je dis : "quand est ce que Lisaac va résoudre le problème".
Ils font comment quand ils développent en C/C++ ?
Ben la chaîne de production à partir de modules est parfaitement prise en compte par les outils (compilo, linker, makefile, IDE). Je te demande comment on fait en Lisaac.
Je te rappelle que le but du projet, c'est l'embarqué, pas d'être un concurrent de Java et C# pour des logiciels de gestion.
Euh, le troll du journal cible le kernel Linux, même si Linux tourne sur de l'embarqué, c'est un projet pour moi "énorme", les problématiques de modularité sont pleinement à prendre en compte.
la compilation séparée pour être un langage "moderne" couvrant les problèmes de "dev en équipe à l'exécution en passant par les tests, la documentation et le déploiement."
C'était une remarque plus général sur Lisaac, pas spécialement lié à la compilation séparée.
Tests : possibilité d'inclure des méta-données, de mocker dynamiquement le code (nécessite l'introspection et la génération dynamique de code).
Documentation : syntaxe spécialisée et utilisable par le compilateur pour générer automatiquement une documentation externe synchronisée à chaque compil
ation (cf C#).
Déploiement : composants "versionnable", "signables", introspection et chargement dynamique (plugins), abstraction hardware, déploiement à distance, etc.
[^] # Re: rentrons dans le vif du sujet
Posté par TImaniac (site web personnel) . En réponse au journal Linux un bloat, ah bon ?. Évalué à 2.
Gni ?
Linux passe directement de la case je casse l'API à la case je corrige tous les drivers.
Euh, quand ils changent une API, c'est pas pour "corriger" les drivers, c'est généralement pour offrir de nouvelles possibilités (nécessaire pour le kernel ou les améliorations des périphériques supportés). Donc ils ne corrigent rien, au contraire, ils sont obligés de modifier tous les drivers (alors que certains étaient sans doute stable et éprouvés) en prenant le risque d'introduire de nouveaux bugs/régression. Ceci est d'autant plus dangereux que la fondation Linux n'a pas les moyens de faire des tests de non-régression sur l'ensemble du matos. Bref, ca se fait globalement au détriment de la qualité, sans parler du fait que ces bugs va falloir les corriger, et ca prend du temps.
Si l'API introduit une faille de sécurité tu la gardes ?
Bien sûr que non. Celà dis le cas est rare et justifie une évolution.