Se connecter
Se connecter
Mot de passe oublié ?
ou
Créer un compte
ou
Se connecter avec Facebook
Notifications
< Retour vers Bidouille & Développement Informatique
Agrandir
Bidouille & Développement Informatique
Les Mains dans le Cambouis
Bidouille & Développement Informatique
Actu 1 1
Articles
Médias 33 33
Tutoriels
Forums 326 326

Le pub des programmeurs

  • 1 925 réponses
  • 117 participants
  • 123 197 vues
  • 130 followers
Sujet de la discussion Le pub des programmeurs
Salut :coucou: y a des programeurs sur AF si oui vous bossez sous quoi ?
Afficher le sujet de la discussion
911
Vous vous souvenez des échanges enflammés entre Andrew Tanenbaum (célèbre universitaire spécialiste des systèmes d'exploitation) et le jeune étudiant Linus Torvalds ?

( résumé - thread entier )

Il y a eu une sorte de reprise du débat (15 ans après... :mrg: ) :
article de Tanenbaum
réaction de Torvalds (long)
point de vue d'un tiers réputé

C'est bien l'homme qui cause le dérèglement climatique - AudioFanzine sans PUBlicité

912
Je trouve l'argumentaire de Tannenbaum et du tiers repute plutot pauvre, personellement. Typiquement, lorsque le gars donne tout son blabla sur l'IDL, la "componentization" (sic), c'est un peu a cote de la plaque, car Torvald n'a jamais dit qu'il fallait faire des systemes non structures, mais au contraire que l'avantage du micro kernel (differents composants avec une interface bien definie) peut se retrouver dans les noyaux monolithiques, sans les problemes lies au non partage de l'adressage (ou plus exactement ce qu'il appelle access space separation).

Ensuite, l'argument de coherence est un peu bidon je trouve (d'ailleurs, comme par hasard, la partie ou Linux explique cette partie n'est pas citee :

Citation :
Seperating some things is a wonderful thing, and not ten
years behind. Almost all lockless algorithms depend on
per-cpu data structures, and that's fine.

The problem is doing it for "everything". It doesn't work.

Doing it for the filesystem caches, for example, is a total
disaster. It increases memory pressure by huge amounts, and
makes synchronization much harder.

(snip)

So replication simply isn't a generally acceptable model.
It works fine sometimes, and when it works, it's
wonderful, and monolithic kernels will certainly do it too.
It's just not a "generic" solution.



Ce qui repond plutot bien au "The last sentence is obviously wrong: when you do not share data structures, there is no coherency problem by definition. Technically, it is possible to share memory in microkernel-based applications, but the statement is true in the sense that this practice is philosophically discouraged."

Ce que je trouve assez revalateur, c'est de voir toutes les previsions de Tannenbaum en 92, et de voir le monde d'aujourd'hui. Il a eu tord sur a peu pres toute la ligne (RISC, micro kernel partout, etc...).
913
Pour completer, je dirais que Linux en general a pu produire/rendre possible en 15 ans tout un ecosysteme qui a plus ou moins contredit tout ce que l'on pensait possible sur la programmation et le design de software. Deja, la portabilite: un des arguments de A.T en 92; aujourd'hui, Linux est l'OS qui a ete le plus porte au monde, qui peut fonctionner de l'embarque aux super ordinateurs a partir du meme source tree. C'est le SEUL exemple a ma connaissance dans toute l'histoire de l'informatique.

Rien que ca, ca contredit completement l'argumentaire de la plupart des contradicteurs a mes yeux: si le code de Linux, son organisation etait si mauvais, comment se fait-il qu'il ait put aller aussi loin ?

Ensuite, sur le probleme des drivers: Linux permet a de plus en plus de drivers d'etre en dehors de l'espace noyau (USB, filesystem avec FUSE, et une autre infrastructure dont le nom m'echappe qui est en train de se mettre en place).

Enfin, tout le truc sur l'OO, franchement, je trouve que c'est bidon. Deja, presenter l'OO comme super truc des 20 dernieres annees, c'est loin d'etre evident. Puis quand tu vois la liste que donne A.T http://www.cs.vu.nl/~ast/reliable-os/


    * QNX
    * Integrity
    * PikeOS
    * Symbian
    * L4Linux
    * Singularity
    * K42
    * Mac OS X
    * HURD
    * Coyotos


Franchement... Deja, j'ai jamais vu quelqu'un en dehors d'apple pretendre que mac os X a un meilleur noyau que Linux, plutot le contraire (d'ailleurs, personne n'a jamais utilise le noyau de Mac OS X, alors qu'il est open source); quand tu regardes un peu les sources, c'est plutot darwin en est la ou etait linux il y a 10 ans; en plus, c'est pas du tout micro kernel, vu que tous les drivers sont dans le meme espace d'adressage. L4Linux n'a jamais vraiment servi a rien, HURD n'est toujours pas utilisable (et en plus, pour la version base sur MACH, tous les drivers sont aussi dans l'espace d'adressage du noyau).

Quand Tannenbaum dit que Torvald n'est pas interesse par l'embarque, c'est aussi de mauvaise foi. Surtout que Linux est vachement utilise en embarque.
914
J'ai une question un peu HS : est-ce que vous utilisez les unités mebibit, mebioctet etc...

Un de mes stagiaires me fait la leçon la -dessus, j'aurai ma revanche quand il devra prononcer "mebibit" en soutenance ou c'est vraiment utilisé maintenant ?

Affiliation : Dirigeant Fondateur d'Orosys - Two notes Audio Engineering

915
Perso, je dois dire que je suis plutôt enclin à suivre Tanenbaum sur ce coup.
En embraque, on a Linux, oui, mais lorsqu'il s'agit de systèmes temps réel, on se rabat sur les noyaux qu'il a cité.

Je pense aussi comme lui, chacun poursuit son idée, et que le meilleur gagne en toute sportivité, il y a des avantages et des inconvénients aux deux approches.

PS : Il faut tout de même penser non-structuré comme non-structuré de l'extérieur, je pense, car Linux est structuré. D'ailleurs, les modifications actuelles (sortir les drivers du noyaux) sont en train d'être faites par tous les suystèmes qui ne le faisaient pas et Microsoft tente de modulariser son OS de la même manière. D'ailleurs, si on réfléchit bien, modulariser, c'est créer des composants qui s'assembleront, donc un micro-kernel à terme. C'est tout de même plus simple à maintenir.

http://blog.audio-tk.com/

Audio Toolkit: http://www.audio-tk.com/

916

Citation : J'ai une question un peu HS : est-ce que vous utilisez les unités mebibit, mebioctet etc...

Un de mes stagiaires me fait la leçon la -dessus, j'aurai ma revanche quand il devra prononcer "mebibit" en soutenance ou c'est vraiment utilisé maintenant ?


Pour ce que j'en ais vu il semblerais que c'est "la norme" etc comme cédérom...
917

Citation :
En embraque, on a Linux, oui, mais lorsqu'il s'agit de systèmes temps réel, on se rabat sur les noyaux qu'il a cité.



Il y a aussi des noyaux non micro en embarque. En fait, il ne demontre en rien que le design micro kernel est ce qui fait la puissance de ces OS la; et encore une fois, il s'agit la de systemes ultra specialises, qui ont un domaine ultra limite par rapport a linux. Faire un OS temps reel quand tu ne fais que de l'embarque, c'est beaucoup plus simple.

Ce que je n'aime pas dans son argument, c'est de dire que les micro noyaux, c'est plus adapte que d'autres design; la preuve, voila des OS micro noyaux en embarque. Mais le lien de causalite micro noyau => meilleur OS, il est pas du tout evident !

Linux est aussi utilise pour du temps reel (Montavista, par exemple: c'est en train de devenir une plateforme de choix pour les smart phones).

Citation :
D'ailleurs, si on réfléchit bien, modulariser, c'est créer des composants qui s'assembleront, donc un micro-kernel à terme.



Justement, c'est la le point d'achoppement: pour Torvald, tu peux creer des composants sans faire de micro kernel (qui impose un espace d'adressage different pour chaque composant). En fait, la ou A. T dit que le micro noyau est question de design, Torvald repond que c'est un un probleme d'implementation (qui a un impact fort sur les performances).

La aussi, je pense que le resultat parle de lui meme: Linux est modulaire, car a partir du meme source tree, tu peux faire des noyaux qui tiennent sur quelques Mo de ram, et des noyaux pour du HPC. A.T dit que le seul moyen de faire un truc modulaire, c'est le micro noyau, et Linus dit que non.

Un autre site sur le debat:

http://tunes.org/wiki/microkernel.html

Citation :
PS : Il faut tout de même penser non-structuré comme non-structuré de l'extérieur, je pense, car Linux est structuré.



Qu'est ce que tu entends par la ?
918
J'ai oublie aussi de poster les dernieres reponses de Torvald, qui sont interessantes concernant l'idee de separation d'espace d'adressage:

http://www.realworldtech.com/forums/index.cfm?action=detail&id=67263&threadid=66595&roomid=2
919

Citation : Rien que ca, ca contredit completement l'argumentaire de la plupart des contradicteurs a mes yeux: si le code de Linux, son organisation etait si mauvais, comment se fait-il qu'il ait put aller aussi loin ?


Ta passion t'enflamme jeune padawan ! :mrg:

Pour ce genre de débat il y a truc vicié dès l'origine : croire ou prétendre que un truc est mieux que l'autre. Les deux solutions (et comme le disent certains, il y en a beaucoup plus que 2) ont de nombreuses caractéristiques différentes. En fonction des usages étudiés, ces caractéristiques peuvent être importantes ou non, avantageuses ou pas.

Croire que "one size fits all" est une erreur évidente, que tous les deux commettent un peu. Il y a deux trucs que j'ai relevés, qui m'ont fait marrer (et que je considère comme grossièrement faux) :

Citation : I know that computer software is different from car software, but users just want them both to work and don't want lectures why they should expect cars to work and computers not to work. I want to build an operating system whose mean time to failure is much longer than the lifetime of the computer so the average user never experiences a crash.


A coût constant, évidemment que l'on préfère un truc fiable que buggé. Mais si les évolutions doivent être 3 fois moins rapides, si le logiciel doit coûter 2 ou 5 fois plus, pas sûr que l'utilisateur soit intéressé. C'est même sûr que non. Rarement l'histoire a privilégié la meilleure techno. Digital Unix (=Tru64) était proche d'un micro-noyau si je ne m'abuse? Ils avaient aussi le meilleur hardware, le meilleur Unix, et le meilleur compilo C++ ; donc tout faux par rapport à M$. :mrg:

Citation : Anybody who has ever done distributed programming should know by now that when one node goes down, often the rest comes down too.


Heureusement que non ! Systèmes bancaires, salles de marchés, salles de contrôle satellite/fusées, centrales nucléaires, trucs militaires, réservations avion ou train... ;)


En deux mots, je pense que le gain de fiabilité dont parle Tanenbaum existe (et donc qu'il a raison sur ce point), mais qu'en fait le marché associé est ridiculement petit. 90% se contentent de Windows, pour 9% Linux est hautement satisfaisant et peut-être qu'une partie du pourcent restant pourrait être intéressé.

Cela dit, soit ce sont des systèmes avec des contraintes physiques ou prix (téléphone portable, jouet, UA1D :mrg: ...) et on prend rarement un OS généraliste ; soit ce sont des système encombrants, et là on traite le fiabilité d'un manière globale : que ce soit l'application, l'OS ou le hardware qui déconne, le mécanisme de tolérance de panne utilisé est le même. Donc le fait que "So what do microkernels have to do with this goal? They make it possible to build self-healing systems." on s'en tape pas mal. D'ailleurs il n'est pas rare de redémarrer la machine (= le noeud) si une appli critique (genre middleware) a planté.

Du coup je vois peu de cas d'applications. Menfin je prétends pas tout connaître !

Par contre, ce qui m'a surpris, amusé et intéressé, c'est de voir que l'on retrouve au niveau application, voire appli distribuée cette opposition "partage de données" (noyau monolithique) / "recopie de données" (micro-noyau).

Et là, le choix de la recopie est très sain, et très viable. C'est assez courant ; et quand on ne le fait pas, c'est souvent des problèmes insolubles ensuite. Dans ce contexte, même si l'inconvénient soulevé par Torvalds est parfaitement vrai, ce choix est généralement meilleur :

Citation : The fundamental result of access space separation is that you can't share data structures. That means that you can't share locking, it means that you must copy any shared data, and that in turn means that you have a much harder time handling coherency. All your algorithms basically end up being distributed algorithms.

C'est bien l'homme qui cause le dérèglement climatique - AudioFanzine sans PUBlicité

920

Citation :
Ta passion t'enflamme jeune padawan !



Bof, je crois pas etre si passione que ca, et Torvald sort souvent des anneries aussi, je cherche pas a le defendre a tout prix.

Citation :

Croire que "one size fits all" est une erreur évidente,



Peut etre, mais "Linux fits many more sizes than any other OS ever has before" (c'est la loi de Gabou).

Plus serieusement, Linux tourne sur enormement de plateformes differentes, avec des contraintes tres differentes aussi. Est ce que tu connais un autre OS qui est utilise aussi bien sur des computing farms, des supercomputers, des telephones portables (motorola par exemple investit pas mal dans linux maintenant) a partir du meme code ? Moi non. Ca n'a jamais ete fait avant. Ca montre bien qu'il y a quelque chose qu'il y a quelque chose qui fait que le design et plus globalement tout le process autour de linux marche extremement bien.

Citation :
Heureusement que non ! Systèmes bancaires, salles de marchés, salles de contrôle satellite/fusées, centrales nucléaires, trucs militaires, réservations avion ou train...



Mais tout ca, ce ne sont pas des systemes distribues au sens ou Torvald l'entend.

[edit] D'ailleurs, dans quasiment tous ces domaines, Linux est de plus en plus utilise. Salle de marche ? Wall Street est de plus en plus interesse par Linux (j'ai pas trop suivi non plus); controle de fusee/satellites, la, je sais pas trop, c'est pas un domaine que je suis non plus.

Citation :

Et là, le choix de la recopie est très sain, et très viable. C'est assez courant ; et quand on ne le fait pas, c'est souvent des problèmes insolubles ensuite. Dans ce contexte, même si l'inconvénient soulevé par Torvalds est parfaitement vrai, ce choix est généralement meilleur :



Oui mais Torvald n'a toujours parle que de son domaine, la ou les performances comptent enormement.