zyvad a écrit 38 commentaires

Merci d'avoir essayé de m'expliquer : le rôle de chaque composant me semble maintenant beaucoup plus clair.

Je te remercie notamment de _ce_ point-clé :

"Globalement, l'idée de tout ce bordel est de simplifier la mise en oeuvre d'applications réparties, c'est-à-dire implémentées par plusieurs machines qui se partagent le boulot. On peut bien sûr faire autrement que d'utiliser ces mécanismes, mais franchement, ça devient vite très difficile. J'ai un cours sur les systèmes répartis (http://apiacoa.org/teaching/distributed/(...) ) qui peut te donner une vague idée des difficultés."

Si je comprends bien, l'un des points-clés de la chose repose sur la difficulté dans l'absolu de paralléliser un algorithme arbitraire.

Même si effectivement, il y aurait matière à débat, a-t-on une idée même vague de l'apport en termes de performances brutes qu'offre la parallélisation sur N machines d'une tâche +/- arbitraire ainsi implémentée par rapport à une implémentation plus traditionnelle sur un système non-scalable, mais non-pénalisée par la méthode ? Ou doit-on considérer l'ensemble des bénéfices (par exemple, inclure le bénéfice conjecturé de l'emploi de Java sur la robustesse du code produit, ou la souplesse supposée de l'approche "web services" dans la communication ou la présentation) dans l'évaluation globale de l'intérêt de l'ensemble ?

On peut éventuellement mettre cet article en parallèle avec un autre du même groupe d'analystes expliquant l'existence et les causes d'une percée significative du logiciel libre dans les administrations :

http://www.gartner.com/resources/114500/114562/114562.pdf(...)

(j'ai hésité à proposer cet article à linuxfr, mais son contenu me semble trop sujet à polémiques diverses)

Est notamment pointé (entre autres considérations bien intéressantes à entendre) du doigt le rôle d'acteurs commerciaux locaux qui préconisent du libre autour d'eux car ils trouvent visiblement intérêt à prescrire un produit qu'ils peuvent maîtriser plutôt qu'un produit commercial générique (très souvent venu de fort loin).

L'article "grand public" que j'ai proposé met au moins le doigt sur quelques fausses idées reçues et permet à chacun d'approfondir le débat (même si je pense que, dans le fond, une réflexion bein informée profite bien plus au libre qu'elle ne le dessert).

Attentio : le lien ne sera probablement pas valide très longtemps.

ERREUR de ma part : IBM a accepté le procès.

N'hésitez pas à me désintégrer au score, j'ai dit des conneries.

> On pourrait avoir un peu plus d'explications ?

SCO est en faillite : son fond de commerce (les unxies sur PC) est ravagé par les alternatives librement disponibles.

Mais SCO est l'héritier histoire des droits (brevets, techniques, etc.) historiques d'AT&T sur Unix-le-vrai, et chercher à obtenir de l'argent en contrepartie de supposées atteintes à ces droits.

IBM a payé sans procès. C'est normal : leur intérêt est de consolider SCO de sorte à ce qu'il soit en meilleur position contre les concurrents d'IBM sur le marché Linux commercial. En payant, ils renforcent la valeur des prétentions de SCO et espèrent que SuSE et RedHat paieront, donc perdront de l'argent, donc s'affaibliront : IBM s'en fout, IBM a plein de ronds, et son intérêt est d'exterminer les petites sociétés concurrentes.

Accessoirement, toute société faisant du Linux commercial (Mandrake, par exemple) risque d'être menacée à son tour dès qu'elle aura de quoi payer :-)

Note annexe : en choisissant d'utiliser des produits qui ne sont pas distribués par des sociétés à but lucratif, on peut éviter tout problème d'approvisionnement futur ou risquer de voir son fournisseur ruiné par les agissements de ses concurrents.

Je sens que je vais passer pour l'idiot du village, mais tant pis : ce n'est pas un troll, je ne comprends vraiment _rien_ de ce qui se dit

- à quoi ça sert tout ce bazar Java/Beans/Tomcat/Objetcs/Web ?
- qu'est-ce que ça a de mieux pour faire des applications que tout ce qui existe déjà ?
- qu'est-ce que ça sait faire et qu'on ne peut pas faire autrement ?
- qu'est-ce que ça peut apporter dans l'avenir ?
- existe-t-il un service de taille raisonnable accessible par le Web par lequel on puisse se faire une idée de l'intérêt de l'approche ?

XML est l'une des solutions utilisables, même si ce n'est pas forcemment la meilleure : mais on s'en fout, on est payé à l'heure :-), les disques durs et les CPUs, et même les parsers les plus apocalyptiques sont moins chers et plus faciles à manager que du personnel. Je crois surtout que XML est perçu comme "étant suffisamment à la mode" pour que les dissaydeurs (qui de toute façons ne comprennent pas le problème, hein : ils ont fait l'ENA, pas fac de sciences) aient confiance en la capacité de l'industrie à fournir les outils dont ils auront besoin pour résoudre des problèmes qu'ils ne comprennent pas.

ça peut faire rigoler, mais c'est quand même un algo qui a de bonnes chances de fonctionner.

Les modèles, ce n'est pas ce qui manque. à la limite, un modèle peut aider à résoudre un problème. Qui dit problème postule l'existence d'un énoncé. Dans le cas de l'administration, le problème est que personne ne connait l'énoncé du problème qu'il faudrait résoudre à supposer qu'il existe.

Il est plus simple de tout oublier et tout refaire, brique par brique, en faisant en sorte que chaque brique dialogue avec le reste par interfaces contractuelles (on triture le bébé jusqu'à ce qu'il existe une définition formelle de l'interface pour laquelle il existe une implémentation conforme aux attentes des utilisateurs). Au bout du compte, on obtient l'énoncé, auquel cas résoudre le problème consiste simplement à appliquer l'une des innombrables méthodes utilisables.

En pratique, pour l'administration, XML est surtout intéressant pour les échanges de données entre bases et applications n'ayant jamais été pensées pour communiquer. Pour cela, il suffit (enfin, "yaka") d'un schema : d'où (l'énorme) projet de Schema XML pour l'administration, avec à côté les instructions du genre "les administrations doivent", "la circulaire du Premier Ministre blabla".

Tu pourrais à juste titre remarquer qu'il s'agit de permettre à des applications propriétaires de communiquer, et tu auras raison : cependant, ça me semble une étape dans la bonne direction, car le nombre d'applications en fonctionnement (fonctionnant par exemple sous Infomix/ACE+4gl ou Oracle) est très important et que pour migrer d'une application fermée vers une application ouverte, on ne peut pas tout faire d'un coup : généralement, on commence par refaire les interfaces VT320 en interfaces +/- Web (avec un "médiateur" logiciel libre), puis, petit à petit, on confie les données à des bases de données libres... grâce à XML qui facilite et aide à contractualiser les échanges entre bases.

On peut se faire une idée de ce qui se passe en regardant les intitulés des rubriques de :

http://www.adae.gouv.fr(...)

Mais les informations sont très diluées dans un monceau de paperasse. Au hasard, on repère : "Le poste de travail alternatif", "5ème journée du libre dans l'administration", "solutions LAMP (Linux/Apache/Mysql/Php)" "bouquet du libre" voir par exemple :

On voit aussi que des acteurs du libre comme des acteurs du monde propriétaires sont invités à débattre au niveau national depuis des années, et que l'évolution se fait sans révolution.

On remarque également qu'apparemment, l'usage de formats ouverts basés sur XML semble plus ou moins obligée (enfin, c'est ce que j'en comprends).

En lisant en diagonale l'ensemble des docs du site on remarque l'existence de nombreux projets serveurs utilisant du logiciel libre, mais, effectivement, pas d'annonces fracassantes.

"VM" veut dire "virtual memory", qui est une abréviation pour "Linux Virtual Memory Manager", qu'on pourrait traduire par "gestionnaire de la mémoire virtuelle de Linux".

Très grossièrement, il s'agit de l'ensemble des fonctions et algos internes au noyau Linux qui gèrent à la fois l'allocation de "morceaux" de la mémoire physique ou du swap aux différents processus d'un système, mais aussi tente d'anticiper les besoins de l'utilisateur de la manière à la fois la plus souple et la plus efficace possible. La "bonne" manière de gérer la mémoire fait toujours l'objet de débats houleux, car les besoins et logiques de fonctionnement d'un serveur ronronnant ou d'une station de travail lançant à tout bout de champs des applications diverses ne sont pas les mêmes. Par ailleurs, des algos trop sophistiqués ne peuvent être utilisés, parce qu'ils seraient trop coûteux en temps CPU, et qu'il n'est pas envisageable de lancer des calculs faramineux simplement pour décider où ranger une donnée en mémoire : donc, le sujet est à la fois complexe et très intéressant, mais très ardu pour le néophyte.

à l'époque des 2.0, on admettait comme une fatalité le fait que quand linux swappait, ça "grippait" un peu, ou que quand il n'y avait pas assez de mémoire pour lancer d'énormes applis, on obtenait des résultats un peu troublants. Depuis 2.2, mais surtout 2.4, on essaie de faire mieux, avec plus ou moins de bonheur.

Si tu as _beaucoup_ de courage (et du temps), tu peux éventuellement t'attaquer à :

http://www.csn.ul.ie/~mel/projects/vm/guide/html/understand/(...)

avec une boîte d'aspirine et cinquante litres de café (mais note quand même que ce document est en partie obsolète dans ses détails).

Du peu que j'en comprends, il me semble que l'architecture Xtensa est atypique au sens ou le composant inclut une partie reprogrammable, c'est à dire probablement à la fois une CPU classique, quelque chose qui ressemble à un FPGA et son controlleur, ce qui en fait un système hybrique entre un microprocesseur classique et un DSP reprogrammable. Le processeur en lui-même ressemble à un RISC 32 bits simple (comme un MIPS) assez classique. Du point de vue performances, on doit pouvoir le comparer à un Geode, un gros MediaGX ou un Winchip.

(mais qu'un lecteur averti n'hésite pas à corriger).

Ce qui est sûr, c'est que cette architecture s'exprime certainement mieux dans un appareil spécialisé en traitement du signal que comme CPU d'une appareil généraliste. Le fait que le Xtensa V dispose d'une MMU rend le mutitâche bien plus réaliste que sur Xtensa IV, ce qui permet d'envisager Xtensa comme processeur principal d'un appareil interactif genre un gros PDA, mais qui ne prendrait son sens que s'il dispose de fonctions dédiées au traitement du signal (au hasard, la compression de sons et d'images :-) ). Reste le fait que l'utiliser sera plus cher qu'utiliser una architecture dédiée, et qu'il ne sera jamais concurrentiel en terme de rapport coût/performances à un x86 fabriqué en grande série.

Du coup, toujours au pifomètre, je pense que cette architecture aura plus facilement du succès dans l'embarqué très spécialisées en petite série (machines industrielles interactives spécialisées) que pour un appareil grand public, où le coût est très déterminant, sauf peut être comme appareil de salon très orienté audiovisuel ou peut-être jeux.

J'avoue ne pas être étonné de constater que l'accès du plus grand nombre aux réseaux informatiques suscite des conflits dans les grandes villes.

Au delà de l'image très négative que ces conflits peuvent renvoyer, on peut éventuellement remarquer que, pour les habitants de zones rurales comme moi, le WiFi est une véritable chance. Aucun opérateur ne réalisera quelque investissement que ce soit dans des villages/villes de moins de 5000 habitants, et seule une technologie simple et à peu près dérèglementée, appropriée par les citoyens a une chance de fournir un service même minime à la communauté

C'est pourquoi j'appelle toutes les bonnes volontés à se manifester sur les newsgroups/forums consacrés au WiFi, et tout particulièrement sur usenet, qui reste particulièrement adapté à être utilisé par RTC (seul accès courant en zone rurale) pour aider à partager l'expérience acquise avec ceux qui sont loin de la rue Montgallet, qui n'ont pas facilement accès à des informations pertinentes et objectives sur le matériel, pour aider ceux qui essaient à réaliser leurs installations et obtenir les licences expérimentales ART.

Rien de bien réjouissant, sauf si on remarque que des produits comme l'Archos Multimedia Jukebox 20 (http://www.archos.com(...) ) soient se passent d'OS, soient exigent un OS plus ou moins temps réel. En fait, plus l'OS mérite la dénomination de temps-réel, moins le hardware pour le faire tourner pour ce genre de fonctions coûte cher.

Quelques gugusses parient actuellement leur chemise sur le fait que les ventes d'appareils de ce type (nomades, embarqués, audiovisuels et communicants) dépasseront en chiffre d'affaire le marché du PC en 2005 (voir linuxdevices.com ). C'est envisageable avec une fondation logicielle solide et ouverte, comme par exemple un linux temps-réel, mais certainement pas une distribution classique ou une javabouse.

On verra ce qu'on verra : j'ai vu l'Archos 20, et franchement, ça roxerise grave pour un truc fait par une petite boîte de banlieue parisienne. C'est moins gros, plus simple et moins cher qu'un Linux classique pour les mêmes fonctions, et si le logiciel fourni ne te va pas, il y en a d'autres faits par la communauté des utilisateurs. Mais ça me ferait quand même bien plaisir d'avoir du pingouin dedans, même si ce ne sera certainement pas une Debian sur PC.