Il vient d'en faire preuve une fois de plus en affirmant que Linux est devenu un bloat.
Personnellement, cela ne m'étonne pas pour plusieurs raisons :
- L'informatique est vaste aujourd'hui, avec énormément de fonctions, de standards mais aussi de possibilité (ce qui est heureux) de par la débauche de puissance que tout un chacun peut avoir à disposition
- En lien avec la première, avec toutes les normes à gérer (ACPI, BIOS, EFI, USB, FireWire, IDE, SATA, etc...), on ne peut passer outre une inflation du code
- Les drivers deviennent de plus en plus nombreux, ce qui est encore heureux, influant sur la taille du code [TROLL]
- Enfin, le plus polémique pour la fin, sinon ce ne serait pas drôle, le langage C est en grande partie responsable de cette taille.
Le C, excellentissime assembleur de haut niveau, est un langage procédurale, et même si le code est extrêmement bien écrit (je pense qu'on peut difficilement trouver mieux) dans le noyau, il n'en garde pas moins les défauts de ce paradigme. Je ne reviens pas dessus, ce point de génie logiciel a été étudié en long en large en travers.
C est bas niveau : pas de chaînes (mais dans un noyau c'est pas très grave), pas de collections, etc...
Mais surtout pas de jeu possible avec de l'héritage, dont l'idéal serait qu'il fut dynamique, car cela permet de limiter la taille de l'OS de par son design
Bref, tout ça pour dire qu'un OS grand public codé en C est condamné au bloat.
[/TROLL]
Sources :
http://www.theregister.co.uk/2009/09/22/linus_torvalds_linux(...)
http://www.osnews.com/story/22207/Linus_Linux_Bloated_and_Hu(...)
http://linux.slashdot.org/story/09/09/22/1239254/According-t(...)
# Tanenbaum avait-il raison ?
Posté par windu.2b . Évalué à 7.
J'ai suivi la discussion sur la news de PCI[1] parlant de cette déclaration de Linus, et plusieurs semblent arriver à cette conclusion : tôt ou tard, Linux (et les noyaux en général) devront se tourner vers les micro-noyaux...
patrick_g, tes impressions ? :-)
1 http://www.pcinpact.com/actu/news/53158-linus-torvalds-kerne(...)
[^] # Re: Tanenbaum avait-il raison ?
Posté par Ontologia (site web personnel) . Évalué à 2.
http://www.reddit.com/r/programming/comments/9mt4k/linus_cal(...)
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Tanenbaum avait-il raison ?
Posté par psychoslave__ (site web personnel) . Évalué à 2.
[^] # Re: Tanenbaum avait-il raison ?
Posté par Ummon . Évalué à 10.
Je pense que ce qui manque à Linux c'est un peu de 'refactoring', nettoyage et documentation ... ce que les gens ont toujours de la peine à faire ;). Un logiciel qui ne passe pas de temps-en-temps par ces phases est condamné.
[^] # Re: Tanenbaum avait-il raison ?
Posté par Brioche4012 (site web personnel) . Évalué à 5.
Le fait que les pilotes sont en réalité des traducteurs en user space permet aussi comme tu le précise d'avoir un systeme tres robuste et facilite énormément l'écriture et débogage des pilotes.
Le point noir est alors le controle d'accès aux ressources. Il faut mettre des verrous un peu partout, sinon on fait ce que Hurd était au début et on en a pour 200 ans à gérer les accès concurrents...
[^] # Re: Tanenbaum avait-il raison ?
Posté par patrick_g (site web personnel) . Évalué à 5.
J'ai juste retrouvé cette citation ici : http://tunes.org/wiki/microkernel_20debate.html
"Thinking that microkernels may enhance computational performance can stem but from a typical myopic analysis: indeed, at every place where functionality is implemented, things look locally simpler and more efficient. Now, if you look at the whole picture, and sum the local effects of microkernel design all over the place, it is obvious that the global effect is complexity and bloat in as much as the design was followed, i.e. at every server barrier.
For an analogy, take a big heavy beef, chop it into small morsels, wrap those morsels within hygienic plastic bags, and link those bags with strings; whereas each morsel is much smaller than the original beef, the end-result will be heavier than the beef by the weight of the plastic and string, in a ratio inversely proportional to the small size of chops (i.e. the more someone boasts about the local simplicity achieved by his µK, the more global complexity he has actually added".
[^] # Re: Tanenbaum avait-il raison ?
Posté par Brioche4012 (site web personnel) . Évalué à 1.
Ca veut dire que le noyau ne sera jamais un obèsiciel. Bien au contraire, sa maintenance devient simplifiée et laisse le temps à ses développeurs d'optimiser les mécanismes qui le composent sans avoir à trainer tous les boulets que linux se tape (qui a dit le pilote foireux de microsoft?)
Le reste se passe en userspace. Les pilotes qui accedent a votre beau scanner tout neuf y sont. Si il leur prend l'envie de planter, le noyau ne tombera pas avec.
Pour moi c'est tout bénéfique comme système, et je ne vois pas en quoi ça peut se raprocher d'un obésiciel.
On dirait que le mec qui a écrit ça discutait surtout des perfs, c'est vrai qu'un systeme sur micronoyau serait sans doute un peu plus lent. Mais du temps des AMDel Corenom X36, je doute qu'on ressente quoi que ce soit. Ce commentaire a du être rédigé a l'époque ou Bill Gates disait qu'on n'aurait jamais besoin de plus de 64ko...
[^] # Re: Tanenbaum avait-il raison ?
Posté par Gof (site web personnel) . Évalué à 3.
(Quand Xorg plante, au final, toutes mes applications doivent être redémarrées. Même dans les cas ou le kernel tourne toujours. Et je dois aussi redémarrer quand mon clavier se blo
[^] # Re: Tanenbaum avait-il raison ?
Posté par lasher . Évalué à 3.
[^] # Re: Tanenbaum avait-il raison ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
"La première sécurité est la liberté"
[^] # Re: Tanenbaum avait-il raison ?
Posté par romi . Évalué à 1.
en théorie un micro noyau en fonctionnement est moins un bloat qu'un noyau monolithique à matériel égal car en théorie seuls les modules nécessaires sont chargés
par contre c'est au prix d'une complexité supplémentaire...
mais n'est-ce pas justement le sens de l'évolution? complexité vs entropie?
[^] # Re: Tanenbaum avait-il raison ?
Posté par pasBill pasGates . Évalué à 3.
La difference entre les 2 elle se situe au niveau de la separation des droits entre les modules et le coeur.
[^] # Re: Tanenbaum avait-il raison ?
Posté par romi . Évalué à 1.
atterrissage en douceur...
merci pour l'éclaircissement!
[^] # Re: Tanenbaum avait-il raison ?
Posté par Gof (site web personnel) . Évalué à 3.
(La différence avec un micro noyaux est que, sous Linux, les modules ont accès direct à l'espace kernel et tournent en mode privilègié.)
# Commentaire supprimé
Posté par Anonyme . Évalué à 10.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Le troll
Posté par Ummon . Évalué à 4.
à propos de ce magnifique site : http://isaacproject.u-strasbg.fr/
---» []
[^] # Re: Le troll
Posté par Ontologia (site web personnel) . Évalué à 3.
Sinon, je te ferai la même réponse que GCU : tout le monde n'est pas hyper fort en HTML, toussa
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Le troll
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: Le troll
Posté par Ummon . Évalué à 0.
[^] # Re: Le troll
Posté par Ontologia (site web personnel) . Évalué à 4.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Le troll
Posté par nomorepost . Évalué à 10.
Il parait qu'il te relooke en 30s un site top moumoute et pour pas cher !
# Et ben tous au Hurd!
Posté par Maclag . Évalué à 10.
Finalement, tout le monde va l'aider à le finir, son noyau! \o/
[^] # Re: Et ben tous au Hurd!
Posté par Brioche4012 (site web personnel) . Évalué à 4.
Sinon, Hurd fonctionne déjà à peu pres. Il n'est pas trés stable par contre. Il faut aussi remarquer que Hurd est maintenu par 10 gars qui y bossent sur le temps libre, alors que linux est maintenu par plus de 2000 contributeurs réguliers, dont beaucoup sont à temps plein.
Sur le papier, les micro-noyaux ont sans aucun doute d'indéniables avantages sur les noyaux monolythiques. Après, il faudrait pourvoir réussir à en faire aboutir un...
Allez Linus, un petit coup de slim fast et on sort GNU/Hurd/Linux3.0 ^^
[^] # Re: Et ben tous au Hurd!
Posté par psychoslave__ (site web personnel) . Évalué à 7.
Genre QNX ?
# On ne parle pas de la meme chose...
Posté par MiniMoi . Évalué à 10.
Petite citation de l'article :
Citing an internal Intel study that tracked kernel releases, Bottomley said Linux performance had dropped about two per centage points at every release, for a cumulative drop of about 12 per cent over the last ten releases. 'Is this a problem?' he asked.
'We're getting bloated and huge. Yes, it's a problem,' said Torvalds.
La taille du code n'est que peu en rapport avec la vitesse du kernel, meme si on pourrait argumenter que si, parce que du code plus gros pollue plus le cache L1/L2, voire ne rentre pas dans le cache L2, et donc c'est la cause d'une perte de performances.
Ceci est vrai... mais... la plupart du code (de l'ordre de 95% il me semble, de memoire d'apres un Google Tech Talk de Greg KH) est consitue des drivers, et l'immense majorite d'entre eux ne sont pas charges en memoire a l'execution (je n'ai pas 200 cartes graphiques differentes, merci).
La baisse de performance est sans doute plus liee au fait que Linux s'enrichit de nouvelles fonctions comme le support de la virtualisation, les LSM (Linux Security Modules), le support des architectures NUMA, l'isolation des processus, le passage a l'echelle jusqu'a 4096 coeurs, etc...
[^] # Re: On ne parle pas de la meme chose...
Posté par Thomas Douillard . Évalué à 6.
C'est un bon exemple, c'est difficile de conçevoir un algo robuste pour traiter efficacement du monoprocesseur aussi bien que du 4096 coeurs.
J'ai l'impression, mais je peux me tromper que l'aspect généraliste de Linux n'aide pas: on peut mettre Linux sur un téléphone ou sur un énorme serveur, sur des matériels qui ont des caractéristiques très très différentes ...
[^] # Re: On ne parle pas de la meme chose...
Posté par thomas . Évalué à 4.
C'est un bon exemple, c'est difficile de concevoir un algo robuste pour traiter efficacement du monoprocesseur aussi bien que du 4096 coeurs.
Solaris ?
/Troll Mode
[^] # Re: On ne parle pas de la meme chose...
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
"La première sécurité est la liberté"
[^] # Re: On ne parle pas de la meme chose...
Posté par neologix . Évalué à 1.
HZ, CONFIG_PREEMPT, HIGHMEM, 4KSTACKS...
[^] # Re: On ne parle pas de la meme chose...
Posté par windu.2b . Évalué à 6.
RMS ? Linus ? Theo ? Steve Jobs ? Jayce ?
[^] # Re: On ne parle pas de la meme chose...
Posté par imalip . Évalué à 10.
Linus : "Dieu m'a dit que j'avais cree le meilleur noyau de systeme d'exploitation"
RMS : "Dieu m'a dit que j'avais cree le meilleur editeur de texte"
Knuth : "Eh, attendez, j'ai jamais dit ca !"
[^] # Re: On ne parle pas de la meme chose...
Posté par Brioche4012 (site web personnel) . Évalué à 3.
[^] # Re: On ne parle pas de la meme chose...
Posté par auve . Évalué à 1.
1/ Ça implique tout de même un modèle commun, ne serait-ce qu'au niveau des interfaces.
2/ Certains sous-systèmes ne sont pas configurables, comme l'ordonnanceur par exemple.
[^] # Re: On ne parle pas de la meme chose...
Posté par Thomas Douillard . Évalué à 2.
On en a eu un exemple récent avec le troll scheduler / réactivité. Je ne sais pas ou ça en est, mais on a bien vu que le scheduler intégré actuellement dans Linux était jugé trop peu réactif sur du monocoeur, et qu'il n'était pas vraiment d'actualité de maintenir plusieurs scheduler dans Linux en l'état actuel des choses ...
# Tss...
Posté par jigso . Évalué à 10.
[^] # Re: Tss...
Posté par galactikboulay . Évalué à 8.
[^] # Re: Tss...
Posté par Maclag . Évalué à 8.
[^] # Re: Tss...
Posté par matthieu bollot (site web personnel, Mastodon) . Évalué à 5.
[^] # Re: Tss...
Posté par imalip . Évalué à 3.
-- Jimmy Carr
[^] # Re: Tss...
Posté par alpentux . Évalué à 1.
--
Et ça m'arrange...
# ...
Posté par cosmocat . Évalué à 4.
Je lu que des sociétés utilisant linux dans l'embarqué étaient resté (pour des raisons de coût) à la version 2.4 du noyau car sa taille une fois compilé était sensiblement moins conséquente.
De plus, je pense que Linus parle de code constituant le coeur du noyau et non pas des drivers car ça on le savait par avance que plus il y a de matériel supporté plus la taille du code (et non --forcemment-- du binaire) est grosse.
# Loi de Wirth
Posté par pampryl . Évalué à 8.
"software gets slower faster than hardware gets faster"
http://fr.wikipedia.org/wiki/Loi_de_Wirth
[^] # Re: Loi de Wirth
Posté par aedrin . Évalué à 6.
Mon préféré étant l'obésiciel...
PS : il faudrait mettre à jour le correcteur orthographique de linuxfr
[^] # Re: Loi de Wirth
Posté par Kerro . Évalué à 2.
Je trouve que boufficiel est très adapté pour un logiciel qui "bouffe" les ressources systèmes inutilement (et donc pas forcément un obésiciel).
# Euh
Posté par cedric . Évalué à 4.
[^] # Re: Euh
Posté par Ontologia (site web personnel) . Évalué à 3.
2/ Ca dépend comment c'est implémenté : si c'est de la CFT à la mano en C, les perfs sont catastrophiques (les processeurs, mêmes modernes ont du mal à optimiser une fonction dont l'adresse est dans pointeur en mémoire et non en statique). Mais je pense pas qu'ils aient fait comme ça.
Le sujet de mon troll est fondamentalement : il me parait difficile à un humain d'écrire un C lisible qui permette de profiter des optims d'un C illisible mais optimisé au mieux qui serait généré par un compilateur.
Mais je te laisse le bénéfice du doute, vu le niveau de compétence impressionnant des codeurs du noyau.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Euh
Posté par Ontologia (site web personnel) . Évalué à 3.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Euh
Posté par BAud (site web personnel) . Évalué à 3.
[^] # Re: Euh
Posté par Ontologia (site web personnel) . Évalué à 2.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Euh
Posté par BAud (site web personnel) . Évalué à 1.
(/me n'a pas compris les shootout je pense, d'où un certain décalage de la réponse)
mais pour Lisaac, bin tu nous tiens au courant, moi je ne retiens pas ma respiration en attendant :-)
[^] # Re: Euh
Posté par liberforce (site web personnel) . Évalué à 3.
# rentrons dans le vif du sujet
Posté par TImaniac (site web personnel) . Évalué à 4.
Alors quand est-ce qu'on peut développer de façon modulaire avec compilation séparée en Lisaac ?
Non parcque bon le principal soucis du kernel Linux, son côté bloatware, c'est pas tant le fait que le langage utilisé ne propose d'héritage, c'est surtout que l'architecture monolithique retenue en fait un gros bouzin là où les micro-noyaux apporte "bydesign" une plus grande modularité.
Evidemment ca suppose que le langage soit "utilisable" pour cela...
[^] # Re: rentrons dans le vif du sujet
Posté par pampryl . Évalué à 2.
[^] # Re: rentrons dans le vif du sujet
Posté par Croconux . Évalué à 3.
Le problème d'embompoint du noyau ne me semble pas imputable au choix d'une architecture monolithique mais à des choix plus politiques. On peut penser modulaire dans passer forcément par un micro noyau.
La question n'est pas ici ce qui doit tourner en mode noyau/mode utilisateur mais ce qui doit être livré avec le noyau ou pas. De version en version le noyau est de plus en plus gros parce qu'il inclue des drivers pour tous les périphériques possibles et imaginables, y compris des trucs obscurs qu'on a peur de décocher de peur de faire une connerie.
On pourrait déjà commencer par établir des interfaces claires que les pilotes doivent implémenter et ne livrer de base dans le noyau que le strict minimum. Quel intérêt de se taper le téléchargement d'un noyau contenant les sources de drivers dont on n'a pas besoin ? Quel intérêt de recompiler tout le bordel pour avoir juste une mise à jour d'un pilote qui corrige un problème ? Ne pourrait-on pas commencer par faire comme avec beaucoup d'autres OS : J'ai un problème avec un driver, j'installe la version mise à jour sans me retaper la compilation du reste.
Linus a toujours refusé de standardiser les ABI pour ne pas être bridé si des changements sont nécessaires (s'il faut casser la compatibilité, on casse) et après on s'étonne que ça devienne difficilement gérable. Pour gagner en maintabilité, je pense qu'il faudra bien passer par une dose de standardisation.
[^] # Re: rentrons dans le vif du sujet
Posté par fleny68 . Évalué à 3.
ah oui, comme la fois ou j'avais décoché ramfs et que le initrd ne se chargeait plus.
[^] # Re: rentrons dans le vif du sujet
Posté par Maclag . Évalué à 2.
(Et ne me faites pas croire que tous les pilotes inclus de base ont tous un développeur disponible et réactif, prêt à réécrire la moitié du code au gré des changements d'ABI...).
Après, c'est sûr qu'un pilote peu maintenu, c'est pas bien, mais d'un autre côté, demander à des développeurs de refaire leur pilote qui marchait très bien avant alors qu'ils ont très peu de temps pour s'en occuper, ça risque de les pousser à abandonner le pilote rapidement.
Qui souhaiterait voir le pilote de ses périphériques être présent aléatoirement d'un noyau à l'autre suivant le temps disponible du mainteneur?
[^] # Re: rentrons dans le vif du sujet
Posté par TImaniac (site web personnel) . Évalué à 3.
Je penses qu'il voulait dire "stabilisé" plutôt que "standardisé" : en gros faut pas qu'il change, ou rarerement.
On peut imaginer une ABI "stable" pendant 3 ans. Au bout de 3 ans une nouvelle version arrive, moyennant un coût supplémentaire le noyau peut gérer l'ancienne qui devient "deprecated" mais qui pête pas les drivers existants. Au bout de 3 nouvelles années, tu vires la vieille interface (on va pas la maintenir 107 ans) : en tout on a eu 6 ans de compatibilité binaire et 3 ans pour migrer les drivers encore maintenus/utilisés.
Ca me paraît totalement réalisable.
[^] # Re: rentrons dans le vif du sujet
Posté par windu.2b . Évalué à 2.
Ma question est donc : les changements apparus entre ces 2 versions ne sont-ils pas trop importants ?
[^] # Re: rentrons dans le vif du sujet
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Linux passe directement de la case je casse l'API à la case je corrige tous les drivers.
Si l'API introduit une faille de sécurité tu la gardes ?
"La première sécurité est la liberté"
[^] # Re: rentrons dans le vif du sujet
Posté par TImaniac (site web personnel) . É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.
[^] # Re: rentrons dans le vif du sujet
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: rentrons dans le vif du sujet
Posté par TImaniac (site web personnel) . É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 Nicolas Boulay (site web personnel) . Évalué à 2.
Va dire cela à ceux qui ont du matos qui n'est plus fonctionnelle sous Vista...
Et non, doubler ou tripler l'effort de maintenance pour des bouts externes ne vaut pas le cout. 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. (sous linux, une bonne source de plantage, c'était le serveur X comme par magie en espace utilisateur, alors que c'est normalement une garantie de stabilité...)
"La première sécurité est la liberté"
[^] # Re: rentrons dans le vif du sujet
Posté par TImaniac (site web personnel) . É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 Nicolas Boulay (site web personnel) . Évalué à 2.
il faut bien maintenir ton API qui est connecté qq part !
"La première sécurité est la liberté"
[^] # Re: rentrons dans le vif du sujet
Posté par TImaniac (site web personnel) . Évalué à 2.
[^] # Re: rentrons dans le vif du sujet
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: rentrons dans le vif du sujet
Posté par TImaniac (site web personnel) . É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 Nicolas Boulay (site web personnel) . Évalué à 2.
Si il y a une regression, rien n'empèche d'utiliser le noyau précédent. Il sera corrigé ensuite. Personne n'a besoin d'avoir un nouveau kernel fonctionnel toutes les 6 semaines.
"La première sécurité est la liberté"
[^] # Re: rentrons dans le vif du sujet
Posté par TImaniac (site web personnel) . É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 Nicolas Boulay (site web personnel) . Évalué à 3.
Et franchement quand tu vois la qualité moyenne des drivers offert pour le noyau linux, tu te dis que heureusement, ils sont repris par les codeurs kernel !
mais non, Linus veut tout maîtrisé.
Et cela marche mieux ! Regarde le bordel autour de X11 et des accélérations graphique, et de udev/hotplug.
"La première sécurité est la liberté"
[^] # Re: rentrons dans le vif du sujet
Posté par TImaniac (site web personnel) . É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 Nicolas Boulay (site web personnel) . Évalué à 2.
Faire un drivers, ce n'est pas faire une petit appli KDE dans son coin. Il y a des interactions assez forte avec le reste du kernel !
"La première sécurité est la liberté"
[^] # Re: rentrons dans le vif du sujet
Posté par TImaniac (site web personnel) . É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 Nicolas Boulay (site web personnel) . Évalué à 2.
Quand un gusse pète une api kernel, c'est à lui de réparer les dégâts jusqu'à ce que tout compile. Il sait ce qu'il change c'est infiniment plus rapide que de compter sur la personne qui ne comprendra pas forcément la subtilité du changement.
Je vois pas le rapport avec la stabilité dans le temps. Windows arrive à offrir cette stabilité, pourquoi pas Linux ?
Mais à quel prix ? Le prix de la perte de drivers à chaque version de windows, Linux n'a rien perdu !
Les vendeurs de hardware se foutent rapidement de leur driver quand il n'est plus vendu.
windows a aussi la force d'avoir 90% du marché, cela oblige les constructeurs à suivre. L'obligation n'est pas la même pour Linux !
Je trouve que la solution actuelle est la moins couteuse pour avoir la meilleur qualité possible.
"La première sécurité est la liberté"
[^] # Re: rentrons dans le vif du sujet
Posté par pasBill pasGates . Évalué à 1.
Et ce gus, tu crois qu'il comprend tous les drivers qui font usage de l'API ? Moi j'en doutes...
Mais à quel prix ? Le prix de la perte de drivers à chaque version de windows, Linux n'a rien perdu !
Les vendeurs de hardware se foutent rapidement de leur driver quand il n'est plus vendu.
Mais ca n'a RIEN a voir...
Le driver, si il reste libre, tu peux toujours l'adapter a la prochaine version de l'API. Le fait de changer d'API tous les 3 jours n'a aucune incidence sur la possibilite de corriger le code du driver, si tu peux le faire tous les 3 jours, tu peux le faire tous les 3 ans.
La seule difference c'est qu'il y a une periode de stabilite, plutot qu'une ABI qui change tous les 3 matins.
[^] # Re: rentrons dans le vif du sujet
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Ou alors, c'est de la grosse factorisation de code comme pour la pile wifi mais dans ce cas il ya une transition entre 2 drivers.
Et ce gus, tu crois qu'il comprend tous les drivers qui font usage de l'API ? Moi j'en doutes...
Sauf que comprendre un drivers est plus simple que comprendre le noyau.
"La première sécurité est la liberté"
[^] # Re: rentrons dans le vif du sujet
Posté par pasBill pasGates . Évalué à 2.
Petit bout ou pas, au final il y a cassage d'interface, et cela arrive trop frequemment. Ca emmerde les utilisateurs, ca emmerde ceux qui ecrivent des drivers, pour pas grand-chose.
Ou alors, c'est de la grosse factorisation de code comme pour la pile wifi mais dans ce cas il ya une transition entre 2 drivers.
Moi je vois la realite : le noyau Windows a des perfs equivalentes, des features equivalentes. Bref, son modele de developpement n'empeche en rien d'avancer, pourtant il amene une stabilite au niveau de l'API des drivers
Sauf que comprendre un drivers est plus simple que comprendre le noyau.
Tout a fait, mais comprendre 42 drivers differents, pas forcement.
[^] # Re: rentrons dans le vif du sujet
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Si, à long terme, cela réduit la maintenance.
Moi je vois la realite : le noyau Windows a des perfs equivalentes, des features equivalentes. Bref, son modele de developpement n'empeche en rien d'avancer, pourtant il amene une stabilite au niveau de l'API des drivers
tu sais très bien que c'est faux. Linux surpasse windows dans beaucoup de domaine : scalabilité, faible latence, IO...
Tout a fait, mais comprendre 42 drivers differents, pas forcement.
Tous les drivers d'un même type se ressemble beaucoup.
"La première sécurité est la liberté"
[^] # Re: rentrons dans le vif du sujet
Posté par pasBill pasGates . Évalué à 2.
Latence(dans le sens real-time) probablement, pour le reste permets moi d'en douter fortement.
Tous les drivers d'un même type se ressemble beaucoup.
En partie oui, mais il y a des limites, et niveau scalabilite, inutile de dire que c'est invivable.
[^] # Re: rentrons dans le vif du sujet
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Il existe des machines windows à 4096 processeurs ?
Concernant les IO, j'ai encore en mémoire les benchs de serveurs http statique, certe, cela date, mais Linux était bien devant.
En partie oui, mais il y a des limites, et niveau scalabilite, inutile de dire que c'est invivable.
C'est sans doute pour ça qu'il y a bien plus de matos supporté par linux que par Vista
"La première sécurité est la liberté"
[^] # Re: rentrons dans le vif du sujet
Posté par pasBill pasGates . Évalué à 2.
Vois pas le rapport, je regardes Redhat, elle ne tourne pas sur 4096 processeurs.
Concernant les IO, j'ai encore en mémoire les benchs de serveurs http statique, certe, cela date, mais Linux était bien devant.
Ah oui, celui ou ils comparaient un Linux avec un mini-serveur web dans le kernel (TUX) compare a un serveur web en user-mode, ca ne dit absolument rien sur les perfs I/O de l'OS ca
C'est sans doute pour ça qu'il y a bien plus de matos supporté par linux que par Vista
Tu m'expliqueras le rapport, en quoi est-ce que Windows empeche d'avoir des drivers libres que la communaute maintient ?
[^] # Re: rentrons dans le vif du sujet
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Regardes SGI alors.
Ah oui, celui ou ils comparaient un Linux avec un mini-serveur web dans le kernel (TUX) compare a un serveur web en user-mode, ca ne dit absolument rien sur les perfs I/O de l'OS ca
Windows faisait pareil.
"La première sécurité est la liberté"
[^] # Re: rentrons dans le vif du sujet
Posté par pasBill pasGates . Évalué à 2.
Je le regardes, et je vois un cas unique, sur un hardware unique, chose que MS ne fait pas.
La ou je veux en venir c'est que le fait que MS bloque le scenario pour raisons de support et test ne signifie pas qu'il n'est pas realisable techniquement pas le noyau.
Windows faisait pareil.
Justement non, on a developpe http.sys specifiquement pour "contrer" TUX...
[^] # Re: rentrons dans le vif du sujet
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
La licence du dev kit ?
"La première sécurité est la liberté"
[^] # Re: rentrons dans le vif du sujet
Posté par TImaniac (site web personnel) . Évalué à 2.
Tiens un autre GPL : http://sourceforge.net/projects/ext2fsd/develop
[^] # Re: rentrons dans le vif du sujet
Posté par TImaniac (site web personnel) . É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 Ontologia (site web personnel) . Évalué à 2.
Il suffirait qu'on maintienne un outil pour vérifier que le driver soit bien propre, respecte bien les interfaces.
Le fait que les ABI changent tout le temps décourage définitivement les industriels, qui en plus de se foutre complètement d'écrire un driver pour un os qui a 2% du marché, on pas envie de le faire parce que c'est inmaintenable ou être obligé de le libérer.
Résultat, l'utilisateur gueule parce que sa carte wifi marche pas, et les windowsiens sont bien mort de rire quand tu parles d'installer Linux sur la machine de madame Michu...
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: rentrons dans le vif du sujet
Posté par TImaniac (site web personnel) . Évalué à 2.
[^] # Re: rentrons dans le vif du sujet
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: rentrons dans le vif du sujet
Posté par TImaniac (site web personnel) . É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 Nicolas Boulay (site web personnel) . Évalué à 2.
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.
Il est question de drivers pas de programme !
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 !
Comparer des GUI et un noyau, c'est super gonflé. tu parles sans doute de ce qui se fait de plus facile à comparer à ce qu'il y a de plus dur.
Pourquoi devrait-il absolument en être autrement pour les drivers dans l'environnement kernel ?
Parce que cela n'a rien à voir ?
Le libre prône il me semble l'indépendance à tous les niveaux, notamment à travers des standards.
Quand cela a un sens, oui.
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.
Pour te donner un exemple, en ce moment, la mode est à la basse consommation. Cela implique que les drivers puissent déterminer quoi sauver en cas de perte de contexte et comment restaurer tout cela, quand le faire, quel contrainte de latence cela pose au système, quel genre et comment un évènement externe peuvent réveiller le système.
Tu crois franchement qu'avec une API figé c'est faisable ?
"La première sécurité est la liberté"
[^] # Re: rentrons dans le vif du sujet
Posté par TImaniac (site web personnel) . É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 Nicolas Boulay (site web personnel) . Évalué à 2.
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.
Linux a changer 3 fois de pile USB pour des raisons de perf ou de gestion d'énergie. Windows se traine n piles...
"La première sécurité est la liberté"
[^] # Re: rentrons dans le vif du sujet
Posté par TImaniac (site web personnel) . É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 Nicolas Boulay (site web personnel) . Évalué à 3.
Cela empèche que n'importe qui se penche sur le problème.
Le principal, c'est que ça marche : la qualité a un coût.
C'est exacte. Moyen que le libre n'a pas. Il ne fait pas 80% de marge sur des milliards !
"La première sécurité est la liberté"
[^] # Re: rentrons dans le vif du sujet
Posté par pasBill pasGates . Évalué à 3.
Et ? A part une orthographe differente c'est quoi la difference ?
Comparer des GUI et un noyau, c'est super gonflé. tu parles sans doute de ce qui se fait de plus facile à comparer à ce qu'il y a de plus dur.
Moi si je prends Gecko ou autre composant de ce genre et je le compares a a peu pres tous les drivers, il est plus complexe, et de loin.
Quand cela a un sens, oui.
De nombreux OS avant Linux ont montre que ce n'etait absolument pas un probleme.
Pour te donner un exemple, en ce moment, la mode est à la basse consommation. Cela implique que les drivers puissent déterminer quoi sauver en cas de perte de contexte et comment restaurer tout cela, quand le faire, quel contrainte de latence cela pose au système, quel genre et comment un évènement externe peuvent réveiller le système.
Tout a fait, ca implique que l'API pour les drivers soit bien fait, et c'est tout a fait possible, cf. Windows
[^] # Re: rentrons dans le vif du sujet
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
Combien de machine ne se réveille pas !
De plus, je ne crois pas que Windows soit une référence en gestion d'énergie.
"La première sécurité est la liberté"
[^] # Re: rentrons dans le vif du sujet
Posté par pasBill pasGates . Évalué à 3.
Sacrement plus longtemps que sous Linux...
Combien de machine ne se réveille pas !
Une minorite, et certainement moins qu'avec Linux
De plus, je ne crois pas que Windows soit une référence en gestion d'énergie.
Pourtant sur la majorite des laptops, Windows tient plus longtemps que Linux:
- http://www.linuxinsight.com/files/ols2006/brown-reprint.pdf
- http://www.phoronix.com/scan.php?page=article&item=880&a(...)
Alors oui, il y a certainement des ameliorations possibles dans Windows(si je ne me trompes pas Mac OS X fait mieux), mais au final, en comparant les resultats de Windows et de Linux sur ces points, Linux ne sort pas gagnant, donc son modele de developpement ne ressort pas comme un avantage de ce cote la.
[^] # Re: rentrons dans le vif du sujet
Posté par TImaniac (site web personnel) . É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 Batchyx . Évalué à 2.
Et si tu réduit cette période, alors t'aura bien plus de rétro-compatibilité à faire, et donc tu bloate ton noyau
[^] # Re: rentrons dans le vif du sujet
Posté par TImaniac (site web personnel) . É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: rentrons dans le vif du sujet
Posté par TImaniac (site web personnel) . Évalué à 2.
[^] # Re: rentrons dans le vif du sujet
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Linux n'est pas un microkernel pourtant tout les sous systèmes sont clairement identifié en interne. Les drivers ont un système objet pour se déclarer et être utilisé par l'OS.
Concernant le coté compile global de Lisaac, c'est une faiblesse qui est à relativiser. La compilation par fichier .c a été faite à cause de la faiblesse des machines de l'époque. Depuis la définition du C, les cpus ont gagné en vitesse, et la raison du saucissonnage du code n'a plus lieu d'être.
On sait que Lisaac doit être capable de gérer des millions de lignes de code. Aujourd'hui, on sait que 50000 lignes se compilent en une dizaine de seconde sur un atom, mais derrière gcc rament franchement (qq minutes ?). Cela laisse de la marge.
"La première sécurité est la liberté"
[^] # Re: rentrons dans le vif du sujet (Compilation globale/séparée)
Posté par Ontologia (site web personnel) . Évalué à 2.
Il y a quelques réglages à revoir d'ici la release à ce propos, mais on peut sans trop de problèmes générer des .o et les linker ensemble de sortes à ce qu'ils se parlent (via la section external).
Il reste à faire en sorte que ce soit manipulable aisément par le programmeur, qui devra s'assurer à la main que les interfaces puissent discuter ensemble.
La gestion de l'interface avec des programmes C classiques a été grandement améliorée et fonctionne assez bien maintenant (problèmes de gestion de la mémoire essentiellement).
On peut même générer des modules linux !
Le fait de pouvoir générer des lib C en lisaac et pouvoir les linker de manière classique tiendra lieu de compilation séparée dans un premier temps.
Au pire, pour vérifier l'interfacage, on pourra lancer un début de compilation globale sur le tout, et séparer en petit morceau si le compilateur ne trouve rien à redire.
Dans un second temps, ce sera essentiellement un problème de performance ie. comment ne pas faire chuter les perfs parce que chaque partie du programme n'a pas été optimisé en fonction des autres.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: rentrons dans le vif du sujet (Compilation globale/séparée)
Posté par BAud (site web personnel) . Évalué à 2.
[^] # Re: rentrons dans le vif du sujet (Compilation globale/séparée)
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: rentrons dans le vif du sujet
Posté par barmic . Évalué à 3.
Il y a des langages qui font les choses vachement bien aussi. Je pense à des trucs comme erlang par exemple.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: rentrons dans le vif du sujet
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
"La première sécurité est la liberté"
[^] # Re: rentrons dans le vif du sujet
Posté par TImaniac (site web personnel) . Évalué à 1.
Il faut également pouvoir charger des modules dans des espaces mémoires différents avec des droits différents (séparation userland/kernelland). Tout ca suppose qu'on passe par une autre étape qu'une bonne grosse compilation du bouzin qui contient tout vu quon connait pas la machine cible.
Sans parler que même si ca prend "seulement" 5 minutes à compiler sur ton quadri-coeur de la mort, pour le développeur c'est attroce comme environnement de test/déboggage.
Bref autant de critère qui rend la séparation en module indispensable pour tout gros projet, et un kernel est un gros projet.
[^] # Re: rentrons dans le vif du sujet
Posté par Ontologia (site web personnel) . Évalué à 2.
Euh, c'est vrai, une compil kernel ça prend 30s sur un Atom.
Sans parler que même si ca prend "seulement" 5 minutes à compiler sur ton quadri-coeur de la mort, pour le développeur c'est attroce comme environnement de test/déboggage.
A ces deux affirmation je répond : Pour tout langage qui font de la compilation globale (et par exemple génèrent du C), et il y en a qqun, 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é.
Smart Eiffel le fait.
Alors il est vrai que de la compil globale fait bouger assez facilement pas mal de chose, mais pas toujours.
C'est donc un faux problème, ou en tout cas aisément contournable.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: rentrons dans le vif du sujet
Posté par TImaniac (site web personnel) . Évalué à 2.
Tu réponds pas au problème : pour des questions d'emprunte mémoire, de sécurité, de spécificité matérielle, on a pas envie de charger tout le bouzin en mémoire. Comment en Lisaac je charge dynamiquement des modules en mémoire sans passer par une compilation/déploiement séparée ?
Faut savoir : le principal intérêt de Lisaac, c'est la compil globale qui apporte un gain de perf. Si le code est "modulable" et compilable/déployable séparrement, le compilo peut plus faire son boulot de compilation globale, on perd une bonne partie de l'intérêt de Lisaac.
Lisaac est "bydesign" conçu pour mettre en contradiction les gains de perf avec la modularité du code. Faut vous faire une raison, Lisaac se focalise sur des objectifs qui sont loins des préocupations des développeurs et packageurs.
Peut être que sur de l'embarqué où le kernel n'est pas trop complexe et qu'il y a un seul mainteneur ca peut servir à quelque chose... ou pas.
il y a toujours la possibilité de découper le C en petits bouts, et de coller un .h pour lier le tout.
\o/ J'attend de voir ça dans une équipe de développement et son environnement SVN/GIT+IDE+makefile...
J'attend aussi de voir le débuggueur...
Les langages modernes s'occupe de toutes les problématiques de la réalisation d'un soft, du dev en équipe à l'exécution en passant par les tests, la documentation et le déploiement.
On a l'impression qe Lisaac se focalise uniquement sur le dev et l'exécution.
[^] # Re: rentrons dans le vif du sujet
Posté par Ontologia (site web personnel) . Évalué à 2.
- N'embarque que le code que tu utilise dans ta lib
- Optimise l'utilisation de celui-ci
Donc même si ton noyau est un petit morceau de code (et heureusement), il est déjà assez gros pour que tu profite d'un gain plus que substanciel par rapport à de la compilation séparée.
Lisaac est "bydesign" conçu pour mettre en contradiction les gains de perf avec la modularité du code. Faut vous faire une raison, Lisaac se focalise sur des objectifs qui sont loins des préocupations des développeurs et packageurs.
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). 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 (des collections type array, liste chainées, tables de hashage, etc...)
De plus, pour info, il existe pas mal de techniques pour faire de la compilation globale à partir de compilation séparée
par exemple :
http://www2.lifl.fr/lmo2004/slides_lmo2004/privat.pdf
http://docs.google.com/gview?a=v&q=cache:onvvYLCD35UJ:ww(...)
\o/ J'attend de voir ça dans une équipe de développement et son environnement SVN/GIT+IDE+makefile...
J'attend aussi de voir le débuggueur...
Ils font comment quand ils développent en C/C++ ?
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.
De plus, c'est débile comme argument :
Dans la SSII où je travaille, on utilise maven. Alors c'est clairement plus sophistiqué que Makefile, d"accord, mais c'est tout aussi bloat et lent.
Et lors du debug, c'est toujours aussi peu maniable à utiliser (souvent le temps d'aller chercher un café, le temps que ça compile). Le seul intérêt étant le tracage à la main dans Eclipse, et le watching sur les variables.
En SmartEiffel (compilation globale), Ils l'ont ! Certes pas couplés à Eclipse, mais ce ne serait pas un énorme boulot, car il s'agirait juste d'interpréter du mode texte.
Les langages modernes s'occupe de toutes les problématiques de la réalisation d'un soft, du dev en équipe à l'exécution en passant par les tests, la documentation et le déploiement.
Pour les tests, tu as la programmation par contrat, ainsi qu'une lib de tests unitaires, et je parle pour SmartEiffel aussi.
Pour la documentation, tu as un outil dans chaque langage pour générer de la doc, qui ressemble à une javadoc d'ailleurs.
Tu as un debugger intégré en SmartEiffel, embarqué dans le code.
Pour le dev en équipe, le nouveau système (LIP) est fonctionnel, et il a juste besoin d'être un peu maturé pour s'assurer que même les cas les plus tordus ne posent pas problèmes.
Donc, j'aimerai bien que tu m'expliques en quoi il faut absolument de 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."
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: rentrons dans le vif du sujet
Posté par TImaniac (site web personnel) . É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 Ontologia (site web personnel) . Évalué à 2.
Je te renvoi à ce que t'as expliqué Nicolas plus haut (plus je te connais plus j'ai l'impression que tu es rétif à tout apprentissage): http://www.linuxfr.org/comments/1068755.html#1068755
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é.
C'est difficile de savoir réellement parce que ça dépend du type d'appli sue tu compile, et le compilateur peu découvrir plein de trucs grace à la globalité... ou pas.
Au niveau global, c'est surtout la prédiction de type qui est faite et donc la suppression d'appels polymorphique (plus que 2% à la fin en moyenne).
Mais ça peut se faire aussi assez localement. Genre avec 3 prototypes et ta lib collection, ce qui est un code petit comme un module Linux, tu va avoir quand même pas mal d'optim. Surtout que la dernière version du compilateur effectue pas mal de détection d'optims locales.
Si tu veux, on peut déjà considérer que le simple fait d'optimiser sur ton objet + la lib de base que tu utilises (nombre + string + collections) ça optimise pas mal déjà.
Mais plus tu globalise mieux c'est.
Donc pour le MPEG 2, tu dois déjà avoir pas mal d'optims même en découpant en 10 parties.
'Fin étudie la question avant d'affirmer des choses de ce genre, parce qu'au niveau théorique, y répondre est assez difficile.
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é ;-)
Oué bah c'est pour ça que je dis : "quand est ce que Lisaac va résoudre le problème".
Quand Ben aura le temps de s'y mettre, c'est absolument pas prioritaire.
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.
Ben, on fait pareil, vu que c'est du C derrière.
Comment ils font en Eiffel d'après toi.
Dans ma boite, en java, on a maven le gros bousin pour "compilo, linker, makefile", et eclipse pour l'IDE.
En Lisaac, tu as eclipse comme IDE, et le compilateur pour compiler (et shorter pour te générer la doc).
La chaine de production est là.
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.
Je répète : lit 10 fois http://www.linuxfr.org/comments/1068755.html#1068755 , tu vas peut être finir par comprendre....
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).
Inclure des méta donnée : tu peux avec les contrats, en les détournant un peu il est vrai, mais le mécanisme est généralisé pour ça (en fait c'est une dose d'aspect programming).
Tu peux poser des contrats sur du code, des données, en tant qu'invariant de prototype.
Tu peux m'expliquer ce qu'est "mocker dynamiquement le code " ? Parce que moi, j'ai du me les taper à la main, les mock, et je vois pas ce que c'est en "dynamique" (et ça m'intéresse parce que c chiant les mocks...).
Pour l'introspection, je devrais pouvoir jouer avec dans 2 ou 3 mois, c'est quasi implémenté.
Documentation : syntaxe spécialisée et utilisable par le compilateur pour générer automatiquement une documentation externe synchronisée à chaque compilation
Chez nous, ça s'appelle "shorter".
Déploiement : composants "versionnable", "signables", introspection et chargement dynamique (plugins), abstraction hardware, déploiement à distance, etc.
composants "versionnable", "signables" : Dans la section header (en passant, en Java, je sais pas comment on fait)
Introspection, voir plus haut.
chargement dynamique (plugins) : C'est quoi ?
abstraction hardware : C'est quoi ? (si c'est ce que je pense, on est largement en avance)
déploiement à distance : C'est quoi ?
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: rentrons dans le vif du sujet
Posté par TImaniac (site web personnel) . É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 Nicolas Boulay (site web personnel) . Évalué à 2.
Pas du tout, c'est même complètement idiot comme argument. Lisaac favorise la découpe en horizontal et optimise en vertical.
En gros, toute lib est compilé en global mais si tu veux faire des modules pour Linux, tu pourra à terme. Le coté "composant" de Lisaac n'existe pas encore, mais il pourra exister plus tard en ayant toujours la compilation global sur les libs. Le grain est bien plus gros que le fichier C.
"La première sécurité est la liberté"
[^] # Re: rentrons dans le vif du sujet
Posté par lasher . Évalué à 3.
Je ne suis pas tout à fait d'accord. Lorsqu'on active les optimisations inter-procédurales, c'est-à-dire l'optimisation de code entre des fichiers objets séparés, si le code est vraiment gros, ça peut vraiment faire exploser le temps de compilation. Au point que parfois c'est carrément le compilateur qui abandonne (j'ai déjà vu le cas se présenter avec les compilateurs d'Intel pour Fortran et C, avec des codes assez énormes, et où on avait activé l'IPO).
[^] # Re: rentrons dans le vif du sujet
Posté par BAud (site web personnel) . Évalué à 2.
exemple ?
euh pas OOo, ça s'est amélioré en dual core depuis longtemps
[^] # Re: rentrons dans le vif du sujet
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: rentrons dans le vif du sujet
Posté par lasher . Évalué à 2.
Est-ce vraiment pour des raisons de perf que GCC (au sens Compiler Collection) ne permet pas ça ?
[^] # Re: rentrons dans le vif du sujet
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
De plus, vu le peu d'info disponnibles, peu d'optimisation sont possible.
"La première sécurité est la liberté"
[^] # Re: rentrons dans le vif du sujet
Posté par lasher . Évalué à 2.
# approche local vs. globale?
Posté par suJeSelS . Évalué à 5.
Je prends l'exemple tout simple de NFS. Si je compile son support dans le noyau, je vais l'alourdir un peu, le faire mouliner bien plus pour avoir mon serveur au meilleur de sa forme. Alors qu'au contraire, si je fais tourner NFS en espace utilisateur, je vais avoir des performances horribles mais un noyau se portant comme un charme.
Pareil pour l'indexation des fichiers, ça fonctionne beaucoup mieux avec le module qui va bien plutôt qu'avec tout en espace utilisateur avec un processus qui passerait son temps à mouliner pour rien. Et pourtant là encore ça ne va toujours pas aider mon noyau à s'alléger.
[^] # Re: approche local vs. globale?v
Posté par Thomas Douillard . Évalué à 1.
[^] # Re: approche local vs. globale?v
Posté par pasBill pasGates . Évalué à 3.
[^] # Re: approche local vs. globale?v
Posté par Nicolas Boulay (site web personnel) . Évalué à 5.
"La première sécurité est la liberté"
[^] # Re: approche local vs. globale?v
Posté par TImaniac (site web personnel) . Évalué à 2.
# Peut être une approche encore plus découpée ?
Posté par barmic . Évalué à 1.
A quoi ça me sert que mon noyau puisse gérer 4096 unités de calcul ? Intel ne va pas sortir de chipset/carte mère pour ce genre de choses avant une dizaine d'année.
C'est un exemple. Ce que je pense c'est qu'il pourrait être découpé en deux ou trois genre serveur, desktop et embarqué. Chacun utilise une base commune et garde ses spécificités (et donc ces algo et ses drivers).
Je sais que c'est un travail plus que colossale mais ça ne me semble pas si impossible.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Peut être une approche encore plus découpée ?
Posté par suJeSelS . Évalué à 5.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.