Contribution à l’histoire d’Unix chez Bull René J. Chevance©
télécharger 307.27 Kb.
|
La recherche d’un partenaire RISC-UnixDans la foulée de la désillusion MIPS56 et sous l’égide de la Direction Stratégie de Bull (avec Steve Bagby et Georges Lepicard), la phase active de la recherche de partenariat Unix fut entreprise en octobre 1991. L’objectif de cette recherche était de développer une alliance stratégique avec un partenaire majeur dans le domaine des systèmes Unix. Un autre objectif était de procurer du travail aux équipes d’Echirolles et de Prégnana. Trois constructeurs avaient été retenus pour le premier tour de piste : Digital, HP et IBM. Digital ne fut pas retenu pour le second round. Deux groupes de travail furent constitués côté Bull pour mener cette investigation : un groupe de niveau « manager » et un groupe technique appelé Back Office. Histoire de brouiller les pistes, deux noms de code furent attribués à nos partenaires potentiels : HP était Austin et IBM était Waco (ville US rendue tristement célèbre par la fin tragique des membres d’une secte). Pour IBM, Bull était Dallas et pour HP, Bull était China me semble-t-il (la signification étant peu flatteuse : « Elephant in a China shop »). Le groupe technique était composé de : René Chevance, Michel Guillemet, Carlos Michberg, Bernard Nivelet, Jean-Jacques Pairault et Angelo Ramolini. Plusieurs meeting furent organisés, en France et aux Etats Unis. Il apparut très rapidement que les possibilités de coopération avec HP étaient beaucoup plus limitées qu’avec IBM. En effet, HP avait une gamme de systèmes complète avec des multiprocesseurs alors qu’IBM venait d’introduire des systèmes monoprocesseurs à base de sa nouvelle architecture Power. Cette architecture faisait suite à l’introduction malheureuse du RT PC57. IBM ne disposait pas d’une version d’Unix multiprocesseur. IBM avait signé un accord stratégique autour de la technologie Power PC avec Motorola et Apple. Dans le cadre de ce partenariat, un centre commun de conception (le Somerset Design Center) avait été créé, entre IBM et Motorola à Austin (Pete Wilson qui y fut détaché par Bull pourrait apporter son témoignage ; Pete est actuellement chez Motorola). Plusieurs microprocesseurs étaient au programme : 601, 603 (monoprocesseur et basse consommation), 604 et le 620. Le bus multiprocesseur du Power PC s’inspirait de celui du 88000 de Motorola. Nous eûmes un meeting avec Motorola sur le programme microprocesseur Power PC en novembre 1991. Dès cette époque, nous avions émis quelques doutes sur la faisabilité d’un programme aussi ambitieux : il était prévisible qu’il y ait quelques loupés d’autant que Motorola était intéressé par les objets à grand volume (Apple) plutôt que par des microprocesseurs haut de gamme à faible volume. On peut dire, que, contrairement aux affirmations ayant présidé à son lancement, que Power PC n’a pas été une architecture ouverte, IBM se réservant notamment la possibilité de développer ses propres microprocesseurs pour son propre usage (nous y reviendrons)….. En ce qui concerne HP, je me souviens d’un meeting à Palo Alto, en décembre 1991, au cours duquel HP nous présenta Emerald, son système haut de gamme à 8 processeurs. A la question, « Que pourrions-nous faire comme développement ? », HP nous répondit « Vous pourriez faire, sur la base de cette technologie, un système optimisé à 4 processeurs ». Constat peut enthousiasmant qui fut encore assombri quelques petites semaines plus tard lors d’un meeting à Paris où HP nous présenta Kitty Hawk, un système quadri-processeur optimisé réalisé sur une seule carte…. Pour l’anecdote et pour illustrer l’attitude de HP vis-à-vis des partenariats, lors d’une visite à Palo Alto, je vis un système Séquoia (système Unix Fault Tolerant que j’avais analysé dans le cadre d’une investigation Fault Tolerant, voir le paragraphe spécifique). Pour les besoins du marché des Telcos, HP venait de signer un accord de distribution avec Sequoia. J’étais avec Wim Roelands (VP Unix), et je l’interrogeais sur ce système, il partit alors dans une diatribe contre les systèmes développés en dehors du sérail…. Un heureux présage pour les partenaires potentiels ! L’accord avec IBM se présentait sous de meilleurs auspices, IBM n’avait pas de version multiprocesseur d’AIX tandis que Bull possédait une telle version, le plan microprocesseur était supporté par un fabricant important, Apple ne se présentait pas comme un concurrent, …. A l’opposé, HP maîtrisait la technologie multiprocesseur Unix, ne fournissait que lui-même en microprocesseurs,…. Bien évidemment, l’aspect favorable de l’accord avec IBM ne valait que pour le court terme. Comme on le verra dans la suite de l’exposé, IBM ayant acquis ma maîtrise du matériel et du logiciel Unix multiprocesseur n’avait plus besoin de la compétence de Bull. L’accord avec IBM se fit sur la base technique suivante (dans les grandes lignes) :
Nous eûmes un grand meeting technique organisé à Austin chez IBM autour de cet accord en décembre 1991. Nous avons trouvé une certaine communauté d’état d’esprit avec nos homologues d’IBM : mêmes expériences, mêmes difficultés,… Une anecdote pour illustrer cette communauté : lors d’un dîner texan organisé par IBM dans les environs d’Austin, nous avions raconté à nos partenaires les notions de base de gestion de projet chères à Lucien Nègre : le RQCV et le RQCM59. Ces abréviations rencontrèrent immédiatement un vif succès ce qui fut pour nous une double satisfaction : l’apport de Lucien Nègre avait franchi l’Atlantique (en dehors du contexte Bull) d’une part et nos nouveaux partenaires avaient suffisamment vécu pour en percevoir tout le sel d’autre part. Le développement de Pegasus a subi les aléas habituels accentués par les retards des microprocesseurs. Dans ce domaine, le 620 a établi des records, on peut dire qu’il n’est jamais réellement « tombé en marche » alors que Bull avait fondé de grands espoirs sur cette puce. Le système Pegasus était commercialisé conjointement par Bull et par IBM. En ce qui concerne AIX, Bull avait l’ambition d’utiliser le nom BOS-X (Bull Operating System) pour désigner le système AIX. C’est là que l’on commença à percevoir les limites d’un partenariat avec IBM : les fournisseurs de logiciel (tel Oracle par exemple) demandaient alors des redevances pour la qualification du portage du produit (portage parfaitement virtuel puisqu’il ne s’agissait que d’un changement « marketing » du nom). La solution la plus rapide et la plus économique qui s’imposait était alors un alignement strict sur IBM en abandonnant le sigle BOS-X60. Sur la base de Pegasus, on décida de développer un système optimisé pour 4 processeurs : Pegakid en ciblant le 620, une solution de repli sur le 604 a été demandée lors de la revue de conception. Avec Alain Couder à la direction d’OSS (Open Systems ans Software) et l’arrivée de Didier Bretonen tant que manager d’Unix et du pôle Echirolles/Pregnana Bull a été entraîné progressivement dans une dépendance de plus en plus grande vis-à-vis d’IBM61. Didier Breton, en outre, poursuivait le rêve d’un accord OEM avec Apple autour d’un système bas de gamme (station/serveur) qui aurait été un produit à grand volume. Un tel accord ne s’est jamais matérialisé mais la poursuite de ce mythe eut des effets négatifs sur les possibilités de différentiation de Bull : les investissements qui n’étaient pas dans l’axe de ce produit à grand volume étaient systématiquement mis en veilleuse. Cette dérive fut plus marquée à Echirolles qu’à Pregnana ; ceci amena Jean Papadopoulo à formuler sa célèbre règle de trois :
Cette formulation peut sembler brutale et il convient de ne pas en rendre le personnel d’Echirolles totalement responsable. Après la phase de participation active lors de transformation d’AIX en multiprocesseur, l’alignement systématique sur IBM et la dépendance qui en résultait, a placé les gens d’Echirolles dans une situation particulièrement inconfortable : soit on ne fait rien et cela se remarque, , soit on rame à contre courant et cela est mal perçu, soit on « bricole » en coopération avec IBM et cela est bien perçu car cela va dans le sens du courant…. Dans d’autres contextes, on a connu sous le nom de « job protection » ou avec la technique des « deux vestes » des comportements tout aussi efficaces et tout aussi rentables. Cette stratégie OEM « à tout prix » a eu des conséquences fâcheuses tant sur la rentabilité de l’activité que sur les initiatives de développement. A toute proposition de développement, même modeste, la réponse était invariablement :
Je me souviens d’avoir un peu bagarré lors d’une CDR à Echirolles pour que l’on investisse sur Fibre Channel alors que les équipes ne voulaient que suivre IBM et sa technologie propriétaire SSA. Une autre illustration est avec le File System « clusterisé » (i.e. vision unique du File System dans un environnement cluster quels que soient les nœuds qui supportent les fichiers). Dans le cadre d’un projet de recherche sur une technologie de mémoire distribuée partagée, j’avais suggéré que l’on démontre cette technologie en développant un File System « clusterisé ». IBM tardait à introduire un tel File System dans son offre HACMP, il y avait là une bonne opportunité pour Bull (la trajectoire logique consistant à revendre ensuite cette implémentation à IBM62). Le prototype existait et était fonctionnel : pas de décision. Résultat, les personnes (de bon niveau) qui avaient développé ce File System ont quitté Bull… Un effet de bord de cet alignement sur IBM s’est manifesté dans les équipes des Clayes en charge du High End (voir ci-après la Saga du High End) : le plus important était de monter une coopération avec IBM, la définition et l’adéquation du système au marché étant assez secondaires… (en exagérant à peine). J’avais déjà rencontré cette situation lors de l’accord avec Convergent Technologies (CT) autour du Questar 400. Périodiquement, lors des meetings avec les représentants marketing de ses OEMs, CT testait les projets potentiels avec quelques présentations baptisées « Coming Attractions ». Les hommes du marketing avaient tendance à prendre ces présentations comme argent comptant et refusaient toute initiative dans les domaines concernés. J’avais même surnommé, par dérision, ces présentations de « Comic Attractions ». Une petite note sur la culture du cycle de vie des produits. J’ai participé à deux CDR : Pegasus le 2 juin 1992 et Pegakid le 27 février 1995. Il s’agissait de CDR mixtes tant au niveau du « board » qu’au niveau de l’équipe projet intégrant des représentants de Bull et d’IBM ou de Motorola. Ces revues se sont parfaitement déroulées, nos partenaires étant parfaitement rompus à cet exercice, les quelques différences de vocabulaire ayant été rapidement aplanies. En ce qui concerne les activités, Echirolles se consacrait au logiciel63 tandis que Pregnana se consacrait au matériel. La dépendance de plus en plus accrue vis-à-vis d’IBM conduisit Bull à se séparer de Pregnana avec la création d’une société indépendante de développement nommée, non sans humour, CIAO Engineering. A partir du développement de Pegasus et de Pegakid, les sujets de coopération avec IBM s’étaient raréfiés. IBM avait acquis, grâce à Bull, la maîtrise de la dimension SMP dans AIX. IBM n’attendait plus Bull pour développer du matériel SMP. L’échec du 620 et la fin de l’opération Somerset Design Center eurent pour conséquence que Motorola se cantonna dans le développement de microprocesseurs pour Apple et pour les applications embarquées et que le développement des microprocesseurs pour SMP haut de gamme était le seul fait d’IBM64. Sur ce dernier point, IBM était peu enclin a donner à Bull un accès à ses microprocesseurs65, IBM préférait largement vendre des systèmes en OEM à Bull. Afin de faire le point sur les développements futurs Power PC chez IBM, j’eu, en mars 1999, un meeting à Austin66. Ce meeting fut très instructif mais il confirma (si besoin était) qu’en dehors de l’OEM il n’y avait point de salut. Pour être complet, on mentionnera le système d’entrée de gamme monoprocesseur baptisé Estrella en provenance de Motorola (système qui accumula aussi quelques retards). Ce système fonctionnait soit sous AIX soit sous NT 3.51. Il y avait, pour Didier Breton en particulier, l’espoir d’atteindre avec NT des produits à grand volume. Cet espoir disparut fin 1996 avec l’abandon de la filière NT sur Power PC. En plus de ces difficultés structurelles, Didier Breton, auquel il convient de reconnaître un dynamisme et une capacité d’entraînement, avait une façon très personnelle (au sens du jeu sportif, formule que les amateurs de sports collectifs comprendront aisément) de gérer les relations avec IBM ainsi qu’avec Motorola. Si quelques personnes étaient au fait de certains aspects des dossiers, personne, en dehors de Didier Breton, n’en avait une vision globale. Comme on l’a évoqué ci-dessus, Didier Breton souhaitait prendre le maximum d’éléments chez IBM, on a ainsi faillit introduire le SP d’IBM. Tout ceci entraîna Bull dans une dépendance de plus en plus grande vis-à-vis d’IBM. Comme par ailleurs, le Power PC n’avait pas attiré suffisamment de partenaires « système » et que Motorola ne jouait pas et n’avait apparemment pas l’intention de jouer, sur la base de Power PC, le même jeu qu’Intel67, tout ceci contribua à placer Bull dans une position de dépendance de plus en plus étroite vis-à-vis d’IBM (avec des conséquences désastreuses sur les marges). |
similaire:
 |  | «Les piétons sont obligés de marcher sur la chaussée, notamment les mères de famille qui poussent des landaus et les handicapés en... | |
| «Le commentaire de Gersonide au livre de Daniel : histoire, eschatologie et messianisme chez un rationaliste juif. Travail préparatoire... | | |
| | ||
| ... | | |
| «les peuples heureux n’ont pas d’histoire»; et permanence, pour que l’histoire ait malgré tout un sens qui la rende intelligible | | «vulgaire» est le plus répandu : IL est épisodique, récidivant et évolue par poussées aussi bien chez l’adulte que chez l’enfant.... |