Je suis en ce moment plongé toute la journée dans ce logiciel médiocre. Je ne vais pas faire la liste des trucs complètement crétins ni de l'ergonomie quasi inutilisable des trucs de base auxquels je suis confronté à longueur de temps, ni encore des corruptions de mémoire qui semblent se produire en gros une fois par jour, décorant les fenêtres de toutes sortent de jolis pixels rigolo (quoiqu'en y repensant, si c'est une fois par jour de manière visible, ça peut bien être 1 fois par heure dans des zones hors rendu graphique, et bien plus critiques...), qui me font perdre 1 min à chaque fois le temps de tout sauver, complètement quitter le logiciel, et le relancer par précaution.
Je doute fortement que les "défenseurs" d'OpenOffice qui nous ressassent les traditionnels "c'est pas grave que ça soit tout pourri, C'EST LIBREUHHHH, TU DOIS CONTRIBUER" utilisent sérieusement ce soft (et à fortiori qu'ils y contribuent - quoique vu le résultat je doute finalement que la majorité des contributeurs utilisent sérieusement le soft...).
Non le fait qu'un logiciel soit libre n'est pas une fin en soit (sauf pour Stallman) - d'autant plus pour les utilisateurs... Oui on a le droit de dire que les (grosses) bouses en sont - libre ou pas. Et surtout, j'ai très peur de l'image du "libre" que ce soft va donner aux gens que certaines personnes personnes poussent à utiliser OpenOffice à la place de MS Office.
1. Il faut savoir s'il y a vraiment une sous-représentativité des femmes dans le LL (par rapport au milieu du logiciel en général, peut-être à pondérer de plus avec d'autres milieux proches de certaines valeurs sous-jacentes aux LL). J'aurais tendance à dire oui, mais sans être catégoriquement sûr. Il faut s'assurer que les études qui sortent 2% dans le LL vs 30% ailleurs comparent bien des catégories identiques.
3. Si problème il y a, par exemple de comportement déplacé, éliminer les problèmes activement. Quand à aller au delà, je ne vois pas au nom de quoi on pourrait être contre ceux qui en ont envie tant qu'ils ne gênent pas ceux qui ne s'en préoccupent pas plus que cela. De même, si des mesures rationnelles, simples, efficaces et peu coûteuses peuvent être prises, alors pourquoi ne pas les prendre, mais encore une fois remplacer les ML par des forums avec des avatars et utiliser des wiki à la place de CVS/Subversion/Git est tout simplement stupide.
Or je pense que l'on peut affirmer que dans tous les domaines (armée, plateforme pétrolière, informatique, mathématiques, échecs, cuisine, pâtisserie, puériculture ...) il y a au moins 1 homme et au moins 1 femme ... donc les hommes et les femmes ont potentiellement les mêmes centres d'intérêts.
Les stats ne reflètent donc que l'influence de l'environnement social.
J'ai du mal à suivre le raisonnement. Pour autant j'aurais tendance à avoir le même avis concernant l'environnement social, néanmoins le fait que l'on puisse trouver au minimum 1 femme ou 1 homme dans un domaine ne prouve en rien la parité du potentiel d'attraction du domaine...
Certes, mais quand on va lire les "débats" sur la ML on a d'un côté des tonnes d'arguments sensés en faveur de tarball, de l'autre le mainteneur qui fait son gros caprice et raconte que les tarball c'est révolu (pourquoi ? personne ne le sait), tout en utilisant CVS... J'ai un peu l'impression qu'il manque un _vrai_ mainteneur sur ce composant, et que les développeurs ne font pas forcement de bon mainteneurs...(en plus d'occasionnellement raconter n'importe quoi)
Enfin bon c'est pas comme si toutes les décisions concernant la glibc avaient été rationnelles par le passé.
Mais oui tout est libre donc c'est la fête, faisons tous n'importe quoi et insultons nous les uns les autres quand on ose faire la remarque que c'est pas pratique. Vous comprenez c'est libre, alors faut _jamais_ se pleindre des trucs absurdes, _JAMAIS_ (ni des bugs, ni de rien du tout, mangez vos bits libres en silence pauvres manants).
Sincèrement, les développeurs sérieux ont des scripts qui font les release à leur place, le coût est donc de taper une ligne de commande. Refuser de faire ça par un espèce de principe crétin pas convainquant du tout c'est entraîner une duplication des efforts, certes modeste quand cela concerne un tarball, mais néanmoins multipliée par un nombre... grand quand on parle de quelque chose aussi populaire que la glibc.
Merde j'espère que tu as pas expliqué ça à grand monde, pcq c'est tellement faux que tu vas être obligé de tous les revoir pour leur dire que tu t'étais trompé et corriger ton erreur avant qu'elle ne fasse d'autres victimes :p
Néanmoins ça ne change rien du point de vue du résultat chez Opera et Skype ; ils utilisent bien une licence QT propriétaire, mais pas parce qu'ils font un usage commercial de leur logiciels, simplement parce qu'ils distribuent leurs logiciels sous une licence propriétaire.
Il y a un critère simple pour éviter ce genre d'erreur : une licence libre ne peut pas, par définition, interdire un usage commercial.
Ceci étant certaines boites s'amusent à entretenir un espèce d'amalgame en parlant de licence "Open Source" d'un côté (en parlant de GPLv2 ou 3) et "Commercial" de l'autre, dans le seul but d'entretenir une ambiguïté pour gratter des achats supplémentaires. Chez Trolltech ils n'hésitent pas à écrire dans ce but des trucs d'une imprécision telle que j'aurais tendance à dire que c'est tout simplement faux :(
If you wish to use the Qt Open Source Edition, you must contribute all your source code to the open source community in accordance with the GPL or Qt Software's GPL Exception when your application is distributed. <== faux : la GPL s'applique aux gens à qui on distribue le programme (et les autorisent certes entre autres à le republier sous des conditions identiques, notamment sur Internet si ça les amuse, mais s'ils ont pas que ça à faire ils ne le feront pas), pas au concept indéfini d'"Open Source Community".
Tu veux dire un truc qui affiche à des instants qui semblent aléatoires pour l'utilisateur des fenêtres hypermodales (avec le déroulement de dizaines de milliard d'instructions à chaque fois et ptêt même des allocations démentielles de RAM à chaque fois) ? Toutes les interfaces graphiques concurrentes font mieux sur ce point :p
C'est surtout bien inintéressant et quand même un cran de folie en dessous de MultideskOS. À mon avis c'est plutôt un trip d'ado manquant encore un peu de maturité et d'expérience :p ( vécu (en (beaucoup) moins grâve ;) inside ).
Néanmoins je note que sûr certains points ils ont du goût : ils n'aiment pas Gnome ni Firefox ni Thunderbird ;)
Au mon dieu, publier la libc, ça va sûrement les faire couler les pauvres, surtout qu'ils ont déjà le noyau à faire !
Quand à la modifier, c'est probablement pas non plus l'idée du siècle...
Enfin bon, Google vient de prouver qu'on peut faire un système Linux probablement largement incompatible avec tous les autres systèmes Linux qui existent. Soit. C'est pas énormément plus débile que Cisco qui code son propre Unix (légèrement buggué...) pour faire tourner ses téléphones. Oublions ce gadget useless et reprenons une activité normale.
Je n'ai aucune idée si l'achat de musique à télécharger sur le site de la FNAC fonctionne sous Linux et si il y a des DRM, mais même si ça fonctionnait et qu'il n'y avait pas de DRM, ça couterait plus cher pour ne pas avoir de support physique et perdre sa musique si son disque dur lache....
mais tu crois sérieusement qu'"on" (je parle dans l'abstrait) à que ça à foutre d'expliquer son métier à chaque client ou fournisseur pendant 3h à chaque fois qu'il ne connait pas un concept de base ? Ptet que t'arrives à imposer des prestas de formation de 1000 euros à tous ceux avec qui tu travailles pour couvrir tes frais induits par l'incompétence des tiers, mais c'est loin d'être le cas de tout le monde...
Si le support de plus bas niveau n'est pas capable ou pas sûr de comprendre un terme, il faut qu'il élève le problème. S'il ne fait pas ça c'est de l'incompétence (peut-être institutionnalisé, j'en sais rien)
1. Une partie du problème vient du matos sataniste d'Intel qui accepte de s'auto-détruire sans aucune précaution.
2. Il y a un workaround dans le 2.6.27 : le matos est explicitement configuré pour qu'il se s'auto-détruise pas.
3. Si un pilote en userspace décide de détruire du matériel en le flashant avec n'imp ou en corrompant violemment la NVRAM, et qu'il demande poliment au mécanisme quelqu'il soit d'effectuer cette opération, le matériel sera détruit.
4. Cela provient peut-être d'X.
5. Cela n'entraîne pas de crash de l'hôte.
Conclusion => très très faible probabilité d'avoir un rapport avec l'histoire de noyau micro / pas micro.
Peut-être qu'en faisant des trucs tordus on pourrait y arriver vaguement (mais la complexification que cela induirait aurait ses propres bugs qui ôteraient tout intérêt), mais ce qu'il faut bien comprendre c'est qu'un module de noyau monolithique n'est _PAS_ analogique à un processus serveur de micro noyau.
Par exemple un module implémentant un pilote va typiquement enregistrer un ISR, gérer des appels synchrones en provenance de l'userspace, et des fois lancer des threads perso ou autre mécanisme d'exécution asynchrone (tasklet, etc...). Il va de plus s'allouer tout un tas de ressources qui ne sont pas forcement managées (je crois qu'il y a un peu de management possible dans les Linux modernes).
Les oops que tu vois avec backtrace sont dans un contexte en provenance de l'userspace. Le noyau tente dans ce cas d'éviter de paniquer, en tuant le processus appelant (et encore, uniquement quand certaines conditions sont vérifiées). Ce n'est qu'une manière de mitiger le problème ! Si tu vois un kernel oops, sauf si tu es absolument sûr de toi (donc entre autre que tu connais _très_ _très_ bien le code correspondant), sauve tout ce que tu peux et reboot immédiatement !
Maintenant si un pb se produit dans une ISR, ... il n'y a rien d'autre de malin à faire que de paniquer.
rhum rhum - ptet il y a 20 ans sur le papier ? (quand il s'agissait de coder NT OS/2......)
Sous Linux aussi je pourrais regarder les répertoires kernel/ lib/ et mm/ ainsi que la pléthore de threads qui tournent et s'échangent des messages, et m'exclamer : "ouah, mais c'est un espèce de micro-noyau en fait !" - et j'aurais tout aussi tord car le concept de micro-noyau est vraiment une question d'isolation et d'espace d'adressage.
Si mes souvenirs sont bons les anti-virus venaient se hooker anarchiquement un peu n'importe où sous NT jusqu'à il n'y a pas si longtemps. Encore une raison de ne pas parler de micro-noyau : avec une vrai archi de micro noyau il n'y aurait probablement pas de hook anarchique ni même d'interface dédiée mais une simple utilisation des interfaces standards.
Enfin, comme sous Linux, on peut sous NT mettre du swap dans un fichier. Je ne pense vraiment pas que ça soit possible (où à la limite viable) avec un micro noyau sans faire de sérieuses concessions - qui ôteraient sans ambiguïté le titre de micro noyau au final.
J'adore SQL, les regexp, Caml dans son aspect filtrage de type + type somme, bref tous ces "métalangage" où je me contente de définir en déclaratif ce que je veux obtenir sans me prendre la tête à expliquer à la machine comment elle va faire.
hm est-ce que ça "mérite" vraiment le titre de "metalangage" parce que c'est plutôt déclaratif qu'impératif ? Utilisé à bon escient c'est certes très supérieur à un spaghetti impératif buggué et 30x plus long, mais je vois pas pourquoi ça serait "méta" pour autant ? Je mettrais plus volontier du "méta" sur les trucs du genre bison.
Je suis d'accord. Ma réaction faisait suite à ton passage concernant "3 processeurs différents" : je disais simplement que l'environnement était souvent plus primordial que le processeur en soit - si je prend un soft quelconque et ciblant GNU/Linux, codé par quelqu'un qui a entendu parlé une fois dans sa vie de little et de big endian (et du nombre de bits des mots machines) et qui a fait attention depuis (ou alors tout simplement si le soft n'est pas susceptible d'être affecté par l'endianess), il n'y aura pas de problème à le porter sur un autre processeur - gcc + glibc feront tout le boulot (ou la VM Java ou Python ou whatever - auxquels cas on n'a souvent - mais pas toujours - même plus besoin de se soucier des mots machines)
Maintenant si tu changes, au delà du simple changement d'ISA du processeur, un truc quelconque de l'environnement (compilateur, bibliothèques, noyau, implémentation de la VM) là tu as beaucoup plus de risques de mettre à jour des problèmes de portabilité.
Les pilotes de cartes réseau sont en général assez simple et peu buggués... et quand on considère le système complet choisir de faire le test en tuant le pilote de la carte réseau et biaisé car le support de l'userspace est probablement très bon dans sa globalité en ce qui concerne les coupures impromptues du réseau. De plus les pilotes et stacks réseaux interagissent peu avec le reste du système.
Un test plus intéressant consisterait à tuer le pilote du HD alors que le système est à pleine charge d'un peu tout et n'importe quoi (et en train de swapper, gniarf :P ) et de voir ce qu'il se passe.
Dans la série des problèmes ouverts il faudrait aussi voir comment intégrer les monstrueux pilotes actuels de carte graphique dans un tel environnement, avec de bonnes performances. Bref tout un programme, qui reste encore dans le domaine de la recherche.
la conception de MINIX3 est plus solide face à Linux si on compare la tolérance aux pannes.
Peut-être vis à vis de certaines défaillances soft ; mais de toute manière les systèmes fault-tolerant ont tendance à être complètement redondant au niveau matériel et il y a des cas où ça peut mitiger le risque de défaillance soft, alors est-ce que tous les inconvénients valent la peine, alors même que les systèmes Linux sont déjà très fiable (et rapide) ?
Je vois un domaine où les micro-noyaux peuvent apporter un énorme plus : les phases de développement et mise au point sont grandement facilitées.
La très grande majorité des verrous ne pose pas de problème de contention. Lorsqu'il y a un problème de contention, il est structurel et confiné à un niveau très fin (du moins dans Linux, qui utilise une politique de verrouillage fin), et le problème ne disparaîtrait pas magiquement par l'emploi d'un micro-noyau et le déport de la gestion de la ressource dans un processus (selon les cas il pourrait même au contraire être exacerbé).
De plus les systèmes asynchrones introduisent leur propres soucis (précisément du fait de l'asynchronisme) et dans la pratique ils sont de plus souvent partiellement encapsulés dans une couche supplémentaire pour fournir des services synchrones... L'overhead par rapport à un appel de fonction classique est ... grand.
Linux utilise aussi des primitives thread-safe lock-free très avancées et très performantes (ex: RCU) qu'il serait probablement très difficile (si ce n'est impossible) d'adapter pour l'userspace.
Dans certains cas les spinlocks conviennent tout à fait et la solution serait nécessairement plus complexe en userspace, par exemple pour de la communication ISR / partie synchrone d'un driver, sous certaines hypothèses.
Pour finir l'expérience a montré que le confinement des défaillances qu'on pensait être une des killer feature des micro-noyau n'est pas si effectif que cela (le système peut tout de même s'effondrer par effet domino dans de nombreux cas), en plus de n'être plus si nécessaire aujourd'hui (les noyaux modernes plantent peu).
[^] # Re: Marrant, moi c'est le contraîre
Posté par Guillaume Knispel . En réponse au journal Open Merdoffice. Évalué à 3.
Tu regardes un film ?
# Je suis de tout coeur avec toi
Posté par Guillaume Knispel . En réponse au journal Open Merdoffice. Évalué à 0.
Je doute fortement que les "défenseurs" d'OpenOffice qui nous ressassent les traditionnels "c'est pas grave que ça soit tout pourri, C'EST LIBREUHHHH, TU DOIS CONTRIBUER" utilisent sérieusement ce soft (et à fortiori qu'ils y contribuent - quoique vu le résultat je doute finalement que la majorité des contributeurs utilisent sérieusement le soft...).
Non le fait qu'un logiciel soit libre n'est pas une fin en soit (sauf pour Stallman) - d'autant plus pour les utilisateurs... Oui on a le droit de dire que les (grosses) bouses en sont - libre ou pas. Et surtout, j'ai très peur de l'image du "libre" que ce soft va donner aux gens que certaines personnes personnes poussent à utiliser OpenOffice à la place de MS Office.
# Problème à qualifier plus en détails + éviter les solutions stupides
Posté par Guillaume Knispel . En réponse à la dépêche 2% de femmes dans le développement de logiciel libre - 10 propositions pour y remédier. Évalué à 2.
2. Certaines des "Dix façons d'attirer facilement la gent féminine vers votre projet libre" proposées sont particulièrement stupides.
J'adhère au lien déjà cité : http://blog.printf.net/articles/2008/10/18/response-to-ten-e(...)
3. Si problème il y a, par exemple de comportement déplacé, éliminer les problèmes activement. Quand à aller au delà, je ne vois pas au nom de quoi on pourrait être contre ceux qui en ont envie tant qu'ils ne gênent pas ceux qui ne s'en préoccupent pas plus que cela. De même, si des mesures rationnelles, simples, efficaces et peu coûteuses peuvent être prises, alors pourquoi ne pas les prendre, mais encore une fois remplacer les ML par des forums avec des avatars et utiliser des wiki à la place de CVS/Subversion/Git est tout simplement stupide.
[^] # Re: Discrimination positive partout?
Posté par Guillaume Knispel . En réponse à la dépêche 2% de femmes dans le développement de logiciel libre - 10 propositions pour y remédier. Évalué à 2.
[^] # Re: L'obsession de la parité
Posté par Guillaume Knispel . En réponse à la dépêche 2% de femmes dans le développement de logiciel libre - 10 propositions pour y remédier. Évalué à 2.
De là à dénigrer, à la limite de l'insulte, tous les militaires...
[^] # Re: un parallèle avec le jeu d'échecs
Posté par Guillaume Knispel . En réponse à la dépêche 2% de femmes dans le développement de logiciel libre - 10 propositions pour y remédier. Évalué à 5.
Les stats ne reflètent donc que l'influence de l'environnement social.
J'ai du mal à suivre le raisonnement. Pour autant j'aurais tendance à avoir le même avis concernant l'environnement social, néanmoins le fait que l'on puisse trouver au minimum 1 femme ou 1 homme dans un domaine ne prouve en rien la parité du potentiel d'attraction du domaine...
[^] # Re: Releases are available by CVS branch checkout only.
Posté par Guillaume Knispel . En réponse au journal glibc m'a tuer. Évalué à 1.
Enfin bon c'est pas comme si toutes les décisions concernant la glibc avaient été rationnelles par le passé.
[^] # Re: Releases are available by CVS branch checkout only.
Posté par Guillaume Knispel . En réponse au journal glibc m'a tuer. Évalué à 2.
Sincèrement, les développeurs sérieux ont des scripts qui font les release à leur place, le coût est donc de taper une ligne de commande. Refuser de faire ça par un espèce de principe crétin pas convainquant du tout c'est entraîner une duplication des efforts, certes modeste quand cela concerne un tarball, mais néanmoins multipliée par un nombre... grand quand on parle de quelque chose aussi populaire que la glibc.
[^] # Re: y'a écoles et écoles
Posté par Guillaume Knispel . En réponse au journal Geogebra: logiciel libre mais seulement en anglais et sans doc.. Évalué à 4.
Néanmoins ça ne change rien du point de vue du résultat chez Opera et Skype ; ils utilisent bien une licence QT propriétaire, mais pas parce qu'ils font un usage commercial de leur logiciels, simplement parce qu'ils distribuent leurs logiciels sous une licence propriétaire.
Il y a un critère simple pour éviter ce genre d'erreur : une licence libre ne peut pas, par définition, interdire un usage commercial.
Ceci étant certaines boites s'amusent à entretenir un espèce d'amalgame en parlant de licence "Open Source" d'un côté (en parlant de GPLv2 ou 3) et "Commercial" de l'autre, dans le seul but d'entretenir une ambiguïté pour gratter des achats supplémentaires. Chez Trolltech ils n'hésitent pas à écrire dans ce but des trucs d'une imprécision telle que j'aurais tendance à dire que c'est tout simplement faux :(
If you wish to use the Qt Open Source Edition, you must contribute all your source code to the open source community in accordance with the GPL or Qt Software's GPL Exception when your application is distributed. <== faux : la GPL s'applique aux gens à qui on distribue le programme (et les autorisent certes entre autres à le republier sous des conditions identiques, notamment sur Internet si ça les amuse, mais s'ils ont pas que ça à faire ils ne le feront pas), pas au concept indéfini d'"Open Source Community".
[^] # Re: Pas plus que ça...
Posté par Guillaume Knispel . En réponse au journal Le compte bancaire de Sarkozy piraté (suite). Évalué à 7.
[^] # Re: Troll inside ....
Posté par Guillaume Knispel . En réponse au journal Jayce est de retour ! (Alléluia). Évalué à 2.
# mwairf
Posté par Guillaume Knispel . En réponse au journal Jayce est de retour ! (Alléluia). Évalué à 3.
Néanmoins je note que sûr certains points ils ont du goût : ils n'aiment pas Gnome ni Firefox ni Thunderbird ;)
[^] # Re: Le code, le code...
Posté par Guillaume Knispel . En réponse au journal Quelle est la valeur d'une distribution Linux ?. Évalué à 3.
Mais bon ça ne reste qu'une estimation tout ça, un ordre de grandeur.
[^] # Re: En bref
Posté par Guillaume Knispel . En réponse au journal Sources d'android disponibles.. Évalué à 6.
Quand à la modifier, c'est probablement pas non plus l'idée du siècle...
Enfin bon, Google vient de prouver qu'on peut faire un système Linux probablement largement incompatible avec tous les autres systèmes Linux qui existent. Soit. C'est pas énormément plus débile que Cisco qui code son propre Unix (légèrement buggué...) pour faire tourner ses téléphones. Oublions ce gadget useless et reprenons une activité normale.
# clair
Posté par Guillaume Knispel . En réponse au journal Téléchargement légal.... Évalué à 10.
Et avoir un son de moins bonne qualité !
[^] # Re: Blackberry
Posté par Guillaume Knispel . En réponse au journal Le compte bancaire de Sarkozy piraté. Évalué à 2.
Ils sont vraiment à la rue alors, pcq si mes souvenirs sont bons c'était interdit bien avant dans certains milieux sensibles (et publiques)
Enfin bon le mystère des administrations...
[^] # Re: Par curiosité...
Posté par Guillaume Knispel . En réponse au journal Le compte bancaire de Sarkozy piraté. Évalué à 10.
____________
[^] # Re: Politesse ?
Posté par Guillaume Knispel . En réponse au journal [off libre]Auto psychanalyse. Évalué à 4.
Si le support de plus bas niveau n'est pas capable ou pas sûr de comprendre un terme, il faut qu'il élève le problème. S'il ne fait pas ça c'est de l'incompétence (peut-être institutionnalisé, j'en sais rien)
[^] # Re: Petite question: noyau monolithique?
Posté par Guillaume Knispel . En réponse à la dépêche Nouvelle version 2.6.27 du noyau Linux. Évalué à 2.
2. Il y a un workaround dans le 2.6.27 : le matos est explicitement configuré pour qu'il se s'auto-détruise pas.
3. Si un pilote en userspace décide de détruire du matériel en le flashant avec n'imp ou en corrompant violemment la NVRAM, et qu'il demande poliment au mécanisme quelqu'il soit d'effectuer cette opération, le matériel sera détruit.
4. Cela provient peut-être d'X.
5. Cela n'entraîne pas de crash de l'hôte.
Conclusion => très très faible probabilité d'avoir un rapport avec l'histoire de noyau micro / pas micro.
[^] # Re: Petite question: noyau monolithique?
Posté par Guillaume Knispel . En réponse à la dépêche Nouvelle version 2.6.27 du noyau Linux. Évalué à 2.
Par exemple un module implémentant un pilote va typiquement enregistrer un ISR, gérer des appels synchrones en provenance de l'userspace, et des fois lancer des threads perso ou autre mécanisme d'exécution asynchrone (tasklet, etc...). Il va de plus s'allouer tout un tas de ressources qui ne sont pas forcement managées (je crois qu'il y a un peu de management possible dans les Linux modernes).
Les oops que tu vois avec backtrace sont dans un contexte en provenance de l'userspace. Le noyau tente dans ce cas d'éviter de paniquer, en tuant le processus appelant (et encore, uniquement quand certaines conditions sont vérifiées). Ce n'est qu'une manière de mitiger le problème ! Si tu vois un kernel oops, sauf si tu es absolument sûr de toi (donc entre autre que tu connais _très_ _très_ bien le code correspondant), sauve tout ce que tu peux et reboot immédiatement !
Maintenant si un pb se produit dans une ISR, ... il n'y a rien d'autre de malin à faire que de paniquer.
[^] # Re: Petite question: noyau monolithique?
Posté par Guillaume Knispel . En réponse à la dépêche Nouvelle version 2.6.27 du noyau Linux. Évalué à 2.
ok, envois ;)
a la base c'est un micro-kernel
rhum rhum - ptet il y a 20 ans sur le papier ? (quand il s'agissait de coder NT OS/2......)
Sous Linux aussi je pourrais regarder les répertoires kernel/ lib/ et mm/ ainsi que la pléthore de threads qui tournent et s'échangent des messages, et m'exclamer : "ouah, mais c'est un espèce de micro-noyau en fait !" - et j'aurais tout aussi tord car le concept de micro-noyau est vraiment une question d'isolation et d'espace d'adressage.
Si mes souvenirs sont bons les anti-virus venaient se hooker anarchiquement un peu n'importe où sous NT jusqu'à il n'y a pas si longtemps. Encore une raison de ne pas parler de micro-noyau : avec une vrai archi de micro noyau il n'y aurait probablement pas de hook anarchique ni même d'interface dédiée mais une simple utilisation des interfaces standards.
Enfin, comme sous Linux, on peut sous NT mettre du swap dans un fichier. Je ne pense vraiment pas que ça soit possible (où à la limite viable) avec un micro noyau sans faire de sérieuses concessions - qui ôteraient sans ambiguïté le titre de micro noyau au final.
[^] # Re: SQL et LINQ
Posté par Guillaume Knispel . En réponse à la dépêche Mono 2.0 : le singe continue ses grimaces. Évalué à 3.
hm est-ce que ça "mérite" vraiment le titre de "metalangage" parce que c'est plutôt déclaratif qu'impératif ? Utilisé à bon escient c'est certes très supérieur à un spaghetti impératif buggué et 30x plus long, mais je vois pas pourquoi ça serait "méta" pour autant ? Je mettrais plus volontier du "méta" sur les trucs du genre bison.
[^] # Re: backports ?
Posté par Guillaume Knispel . En réponse au journal Le choix d'une distribution Linux. Évalué à 2.
Maintenant si tu changes, au delà du simple changement d'ISA du processeur, un truc quelconque de l'environnement (compilateur, bibliothèques, noyau, implémentation de la VM) là tu as beaucoup plus de risques de mettre à jour des problèmes de portabilité.
[^] # Re: Petite question: noyau monolithique?
Posté par Guillaume Knispel . En réponse à la dépêche Nouvelle version 2.6.27 du noyau Linux. Évalué à 6.
Un test plus intéressant consisterait à tuer le pilote du HD alors que le système est à pleine charge d'un peu tout et n'importe quoi (et en train de swapper, gniarf :P ) et de voir ce qu'il se passe.
Dans la série des problèmes ouverts il faudrait aussi voir comment intégrer les monstrueux pilotes actuels de carte graphique dans un tel environnement, avec de bonnes performances. Bref tout un programme, qui reste encore dans le domaine de la recherche.
la conception de MINIX3 est plus solide face à Linux si on compare la tolérance aux pannes.
Peut-être vis à vis de certaines défaillances soft ; mais de toute manière les systèmes fault-tolerant ont tendance à être complètement redondant au niveau matériel et il y a des cas où ça peut mitiger le risque de défaillance soft, alors est-ce que tous les inconvénients valent la peine, alors même que les systèmes Linux sont déjà très fiable (et rapide) ?
Je vois un domaine où les micro-noyaux peuvent apporter un énorme plus : les phases de développement et mise au point sont grandement facilitées.
[^] # Re: Petite question: noyau monolithique?
Posté par Guillaume Knispel . En réponse à la dépêche Nouvelle version 2.6.27 du noyau Linux. Évalué à 6.
De plus les systèmes asynchrones introduisent leur propres soucis (précisément du fait de l'asynchronisme) et dans la pratique ils sont de plus souvent partiellement encapsulés dans une couche supplémentaire pour fournir des services synchrones... L'overhead par rapport à un appel de fonction classique est ... grand.
Linux utilise aussi des primitives thread-safe lock-free très avancées et très performantes (ex: RCU) qu'il serait probablement très difficile (si ce n'est impossible) d'adapter pour l'userspace.
Dans certains cas les spinlocks conviennent tout à fait et la solution serait nécessairement plus complexe en userspace, par exemple pour de la communication ISR / partie synchrone d'un driver, sous certaines hypothèses.
Pour finir l'expérience a montré que le confinement des défaillances qu'on pensait être une des killer feature des micro-noyau n'est pas si effectif que cela (le système peut tout de même s'effondrer par effet domino dans de nombreux cas), en plus de n'être plus si nécessaire aujourd'hui (les noyaux modernes plantent peu).