Interview de l'équipe F-CPU

Posté par  (site web personnel) . Modéré par Benoît Sibaud.
0
2
mar.
2003
Matériel
Nous vous avions demandé dix questions à poser aux développeurs de F-CPU (qui travaillent au design d'un processeur libre) dans une dépêche précédente.

Voici donc leurs réponses en version intégrale. YG : Yann Guidon
Nico : Nicolas Boulay

[DLFP] : « Qu'est-ce que vous pensez des projets TCPA/LaGrande, Palladium/"next-generation secure computing base" ? L'équipe F-CPU envisage-t-elle d'avoir ou de rajouter des composants spécialement dédiés à la crypto ou aux DRM dans son processeur ? » (question de Benoît Sibaud)

[YG] : « F-CPU n'est pas manchot quand il s'agit de chiffrer et déchiffrer des données, mais tout se fait en logiciel en utilisant des instructions qui peuvent tout aussi bien servir au graphisme, au traitement de son ou n'importe quoi d'autre. Les fonctions "crypto" ne sont pas rajoutées si elles n'ont pas une autre utilité, car le coeur commence à devenir assez lourd comme ça.

Quant à faire une Fritz .... on en est très loin (enfin, l'équipe F-CPU) »

[Nico] : « That's sux ! (tm) même si Palladium et TCPA ne sont finalement pas identiques.

Il y a des instructions qui permettent d'accélerer des codes de crypto mais pas plus.

F-CPU n'est pas LA réponse à ses puces DRM car n'importe qui veut faire un F-CPU pourra toujours rajouter un "core" TCPA à côté du F-CPU. Au mieux, on peut obliger l'utilisation de la GPL pour tout code qui s'attache à l'interface mémoire principal (DRAM). Mais il restera les caches internes pour cacher certaines exécutions. »

[DLFP] : « La licence logicielle (L)GPL est-elle adaptée au matériel Libre ? Quelles sont les spécificités et risques non couverts par cette licence ? Avez-vous des besoins/moyens pour y remédier ? » (question de Nÿco)

[Nico] : « La (L)GPL est adaptée à tout ce qui a des sources et qui produit un résultat. Des plans et de sources HDL peuvent donc rentrer dans la catégorie.

La GPL a le désavantage d'exiger la mise à disposition entière de la puce sous GPL. Ce qui ne sera pas du goût de futurs utilisateurs. En effet, les puces se conçoivent aujourd'hui avant tout comme l'on considérait une carte il y a quelques temps (cf. Omap de TI avec un ARM 9 pour l'applicatif, un arm7+C55 pour la radio sur le même die !)

La LGPL est utilisée par LEON un proc sparc v8 de l'ESA (http://www.gaisler.com).

La GPL avec exception sur certaines interfaces (bus io) devrait être suffisant. Cela ressemblerait à la licence du noyau linux. Mais cela
n'engage que moi dans le projet. »

[YG] : « Tu as beau dire, mais la GPL en a pris un coup.

Malheureusement, RMS semble vraiment aussi autiste qu'on le dit et j'ai peur qu'on se trimbale la licence GPL très longtemps avant de passer à une licence spécifique F-CPU ou Free Hardware qui justement traiterait AUSSI des problèmes style TCPA. »

[Nico] : « J'avais déjà essayer au FOSDEM l'an passé.

Coté juridique : il faut savoir qu'il n'est pas l'auteur de la GPL. Qu'un juriste a confirmé que la GPL pouvait protéger du code HDL. Que l'ESA utilise la LGPL pour le Leon. Écrire une licence est extrémement difficile sans risquer de faire des bêtises.

Coté pratique : la GPL couvrirait tout le code d'une puce, ce qui n'est pas acceptable, c'est comme si linux interdisait du code non GPL de tourner sous lui. On peut tout à fait rajouter des API ou le propriétaire est accepté comme pour le noyau linux, les noyaux temps réel comme ecos et autre...

TCPA : si notre licence attaque le TCPA ou autre, cela ne sera plus une licence "libre" et les effets pervers pourraient être encore pire (comme rendre la puce inutilisable par un industriel) »

[YG] : « Il y a au moins un gros problème, très sérieux, pour l'utilisation de la xGPL par F-CPU. Je ne parle pas au nom d'autres projets, plus dans la mouvance "Open quelquechose".

Le principe du Copyleft est brillant mais son application par la GPL est intrinsèquement limitée au logiciel applicatif car une clause permet à un vendeur de modifier les sources, et le vendeur n'est tenu de ne diffuser les sources modifiées qu'au client.

Or, dans le cadre de F-CPU, du moins, le "business model" est de faire les bénéfices sur la vente des puces. Il n'y a donc pas de raison de limiter la diffusion des sources modifiées aux seuls clients.

Je milite donc pour qu'une version "Libre HW" de la GPL contienne la clause selon laquelle un fabricant est tenu de diffuser le source modifié dès la fabrication et disponibilité du produit dérivé.

Partons du principe que F-CPU appartienne idéalement à tout le monde, il n'y a pas de raison pour laquelle il appartiendrait plus à certaines
personnes que d'autres. »


[DLFP] : « Où en est le projet ? Êtes-vous en mesure de produire les spécs complètes d'un microcontroleur RISC simple un jour (par exemple) ? » (question de Nÿco)

[Nico] : « Cela existe déjà sur opencores.org, cela n'est pas drôle de réinventer la roue. Faire un cpu simple est facile à faire. Pousser les perfs, cela devient carrément plus dur ! »

[DLFP] : « quelles solutions envisagez-vous pour faire fabriquer un fcpu ?

Autrement dit, la réutilisation du design de fcpu par un grand fondeur (AMD, VIA) est-elle la seule solution ?

Ou bien fcpu est-il suffisament simple pour utiliser les services de "moyens" fondeurs (par exemple ceux qui fabriquent des puces bon marché
pour les cartes graphiques ou pour les chipsets), voir de petits fabricants de puces (je pense notamment aux nouvelles techniques de fabrication de circuits par "imprimante" sur des supports bon marché) ? » (question de Free2.org)


[Nico] : « Faire fabriquer une puce coûte une fortune en petite série.

Je pencherais pour la création d'un "core" qui serait réutiliser pour faire des SoC (system on chip) pour faire des puces plus grosses. Dans le but de faire des palms ou autres trucs du même genre.

Les fabrications par imprimantes ne sont qu'au stade d'expérimentation. Toute technologie est utilisable. Si la puce est fabriquée en faible
exemplaire, une vieille techno coûtera moins cher car les coûts fixes seront inférieurs mais les perfs seront en baisse aussi. »

[DLFP] : « quels logiciels (libres ?) utilisez-vous pour vos conceptions/simulations ?

Utilisez-vous un système de distribution de la charge sur plusieurs machines ? » (question de Free2.org)

[Nico] : « Coté logiciel libre de CAO. C'est simple : il n'y a rien ou quasiment rien !

En gros, en simulation, il y a simili (http://www.symphonyeda.com) qui est gratuit sous Linux mais pas libre du tout. Pour la synthèse, il n'y a rien. Peut-être xilinx en version gratuit pour synthétiser sur des petits trucs (genre XCV300). Il n'y a sinon que les programmes proprio (design compiler,...).

Seul gtkwave est un programme libre qui permet de faire un truc en CAO : afficher des waveformes ! »

ghdl.free.fr est un projet de front end vhdl pour gcc : c'est super prometteur. Si le projet arrive au bout, cela va être terrible ! »

(NdDLFP : d'autres logiciels cités dans les commentaires. Sur vdt/ivsim: http://poppy.snu.ac.kr/VDT/vdt.html, http://poppy.snu.ac.kr/vdt-ivsim/vhdlsim.html, http://www.csee.umbc.edu/help/VHDL/index.shtml#free, http://inspire.snu.ac.kr/inspire.html. Sur CDFG http://poppy.snu.ac.kr/CDFG/cdfg.html)

[DLFP] : « Que pensez-vous des projets suivant ? f-cpu est-il lié à ces projets et si oui de quelle manière ?

www.opencores.org
www.opencollector.org
www.openhardware.net
www.simputer.org » (question de Benoît Sibaud)


[Nico] : « Opencores.org, c'est le plus actif. Opencollector.org et Openhardware.net, à peu près la même chose que opencores. Simputer.org, un truc sympathique pour prouver que le matériel libre, c'est possible. »

[YG] : « Opencores.org est un grand catalogue de fonctions écrites en VHDL ou en Verilog, c'est relativement intéressant si quelqu'un désire fabriquer une puce (presque) complétement libre ou tout simplement pour ne pas payer les royalties de composants commerciaux équivalents (même si généralement, les responsables de tels projets préfèrent "payer pour la vitesse et la sécurité" au lieu de risque de découvrir des bugs ou assembler des pièces qui ne sont pas faites pour cohabiter).

Opencollector.org est une excellente ressource permettant de mieux comprendre la richesse et le manque de coordination des projets. On peut cependant y trouver des projets très intéressants.

Openhardware.net ne me semble pas avoir fait beaucoup de vagues.

Simputer.org n'est pas lié, mais le projet a fait pas mal de bruit (positif). »

[DLFP] : « Quelqu'un s'est-t-il déjà montré interessé pour construire ce processeur ?

Que pensez-vous de LEON, le processeur (comp. SPARC) développé par l'Agence Spatiale Européenne lui aussi sous LGPL ? http://www.gaisler.com/leon.html » (question de mammique)

[Nico] : « Plus ou moins.

Léon, c'est l'exemple pour dire que l'open hardware peut marcher ! Il a déjà été fondu 3 fois. Il tourne correctement et est tout petit. Et surtout il
existe... »

[YG] : « Plusieurs personnes, au fil des années, m'ont contacté (c'est mon adresse email qui est sur f-cpu.org) pour voir dans quelle mesure ils pourraient implémenter F-CPU ou l'aider, mais rien de vraiment sérieux pour l'instant, la meilleure preuve étant qu'ils veulent souvent garder l'anonymat.

Par contre, la situation économique actuelle rend F-CPU beaucoup moins ridicule auprès des "décideurs". Enfin, quand les sources seront suffisamment avancées pour qu'un coeur fonctionne correctement, les fabricants seront bien plus intéressés. »

[DLFP] : Dans combien de temps pensez vous que l'on pourrait créer/utiliser un pc dont les composants seraient libres ? Par exemple un pc à base de f-cpu + linuxbios (+ f-gpu*) . (question de Elihu)

[Nico] : « Aucune idée.

Faire un cpu, n'a rien à voir à faire un ordinateur. Un ordinateur est surtout une plateforme avec des IO spécifics (liens séries/ PCI/ISA/hypertransport/...). A mon avis, changer le CPU est ce qui doit être le plus facile si l'on fait un ordinateur car il "suffit" de changer de compilateur et modifier légèrement l'OS. »

[YG] : « Il faut aussi rappeler quelque chose de très important, puisque les débats dérivent souvent dans cette impasse :

Le but du projet F-CPU n'est pas de fabriquer ni d'industrialiser un processeur ou quoique ce soit d'autre, seulement de concevoir et d'écrire les sources d'un coeur de CPU en VHDL.

Ensuite, les gens font ce qu'ils veulent avec (enfin, dans la limite de la licence)

FC0 est un processeur RISC superpipeliné, SIMD et paramétrable, ce qui est déjà assez compliqué comme ça. Pour faire un ordinateur, il "suffit" de rajouter une alimentation et les périphériques désirés, qui peuvent être trouvés facilement sur le Net (mais pas toujours en état de fonctionner). »

[DLFP] : « Est-ce que les participants au projet f-cpu s'impliquent aussi dans le développement des logiciels nécessaires à sa mise en oeuvre (comme le ghdl évoqué plus haut) ou son utilisation (comme le port de gcc pour l'architecture f-cpu) ? » (question de Elihu)

[Nico] : « plus ou moins. Le projet fcpu est suffisament compliqué pour ne pas se mettre également à créer des outils qui réclament des compétences très différentes. On "suit" ghdl et je suggère des fonctionnalités :) Le port du f-cpu sous gcc est en court. Un nouveau cpu sans compilo ne sert à rien. »

[DLFP] : « À quel type de machine est destiné f-cpu ? Quelles performances en attendent ses développeurs ? À quel processeur ressemble(ra)-t-il le plus ? À moins que ces questions n'aient pas encore de réponses ... » (question d'Etienne Labaume)

[Nico] : « F-cpu était destiné aux workstations mais sera plutôt utiliser dans l'embarqué, set-top box et autre PDA à mon avis.

Les perfs... disons qu'il est "one way" ce qui simplifie les choses mais le rend moins performant. D'un autre coté, le jeu d'instructions est riche. Si ton compilo sait utiliser le SIMD, il peut être très rapide.

Le F-CPU ressemble beaucoup au SH5/ST50. »

[YG] : Petites précisions : "disons qu'il est "one way"" signifie (dans ce contexte) que la première lignée de F-CPU, appelée FC0, exécute une instruction par cycle.

Comme le dit nicO, le jeu d'instruction riche, orthogonal (enfin, on essaie) et les fonctions SIMD sont destinées à garantir des performances élevées pour du code de calcul lourd, où le ratio MOPS/MIPS est avantageux. D'un autre côté, les simplifications architecturales (permettant d'obtenir des hautes fréquences de fonctionnement) font que les accès de type pile ou sous-programmes sont moins sophistiqués et avantagés. Mais comme le but est de prouver qu'on peut obtenir des performances intéressantes, et ces performances sont ordinairement critiques en images, vidéo, son, chiffrement, et pas en vitesse d'exécution de MS Word, on peut accepter facilement les "simplifications" et concevoir des compilos capables de tirer parti des techniques utilisées par F-CPU. Plus tard, FC1 (ou autre) pourra exécuter plus d'instructions par cycle.

L'application de F-CPU est large, et dans l'absolu ne se limite pas à l'embarqué ou les stations de travail, mais il n'a pas de sens dans des applications 32-bits ou en tant que microcontrôleur car d'autres architectures sont bien mieux adaptées. À moins que le critère de liberté justifie le surcoût des registres et unités 64 bits.

Pour ce qui est du SH5, je ne le connais pas bien mais c'est le processeur qui ressemblerait le plus à FC0, si on ne regarde pas de trop près.

Pour terminer, je sais que ça va faire râler, mais ce qui me ferait le plus tripper serait une machine multi-F-CPU modulaire sur laquelle GNU/Hurd pourrait fonctionner à plein régime :-) Mais cela demande trop de choses à la fois : que le Hurd soit correctement porté sur F-CPU pour bénéficier de certaines possibilités, que F-CPU soit prêt et surtout qu'on résolve tous les problèmes d'architecture NUMA. »

Aller plus loin

  • # Re: Interview de l'équipe F-CPU

    Posté par  (site web personnel) . Évalué à 10.

    J'ai eu l'occasion de rencontrer Yann Guidon et j'ai été très impressionné en voyant comment et avec quoi il travaillait. Ce qui est aussi impressionnant, c'est de voir qu'un petit groupe de personnes arrive à progresser sur un projet aussi ambitieux. Une des raisons est peut être le choix d'une excellente architecture prise dès le départ.
    Un exemple : il suffit de déclarer la taille des mots à un seul endroit pour que FCPU soit un processeur 32, 64 ou 128 bits ou encore une autre valeur.

    Si les élèves ingénieurs électroniciens pouvaient faire leur projet de fin d'étude sur FCPU, ce projet avancerait beaucoup plus vite.
    Ce n'est pas une idée en l 'air car en ce moment, je suis chargé d'encadrer un groupe de huit élèves ingénieurs de l'ENSEIRB qui travaillent sur un projet GPL. C'est une pratique que l'on peut généraliser sans inconvénient.
    • [^] # Re: Interview de l'équipe F-CPU

      Posté par  (site web personnel) . Évalué à -5.

      c'est bon, il te reste encore du cirage ? :-)

      (patapé ! patapé !)
    • [^] # Re: Interview de l'équipe F-CPU

      Posté par  . Évalué à 10.

      Mmmhh. Et c'est indiscret de demander sur quel projet GPL ? Pas XBlast quand meme ;)

      Luzerne, ex-eleve de l'ENSERB, qui aurait ete bien interressé par faire son projet de fin d'etude sur le FCPU

      PS : meme si depuis mon diplome, mon investissement dans le projet s'est limité a m'inscrire sur les listes de diffusion pour suivre ce qui s'y passe... le probleme est que je ne vois aucune tache (pour electronicien, pas informaticien) compatible avec les 2 a 4 heures par semaine que je serais pret a consacrer au projet. Et donc forcement, j'hesite a me taper la doc dans le details sans savoir sur quoi je pourrai ensuite porter mes efforts. Mais je suis peut etre passé a coté du document expliquant aux nouveaux arrivés sur le projet quoi faire apres : s'etre inscrit sur les listes, et avoir lu la documentation du FC0.

      PPS : je pense qu'il pourrait etre profitable au projet de poster un message sur la liste fcpu pour demander aux gens inscrits a la liste en simple spectateur, ce qui les inciterait a participer plus activement au projet, ou ce qui au contraire les retient de le faire. C'est du moins le type de message qui m'inciterait moi a poster au moins une fois sur la liste au lieu de seulement jouer les voyeurs :).
      • [^] # Re: Interview de l'équipe F-CPU

        Posté par  (site web personnel) . Évalué à 5.

        chez F-CPU, on a un proverbe :
        "c'est çui qui dit qui fait" :-P

        allez, envoie-nous un petit message ....

        YG (trop la flemme)
        • [^] # Re: Interview de l'équipe F-CPU

          Posté par  (site web personnel) . Évalué à 1.

          Comme je t en aii deja parle dans un mail, je trouve vos travaux tres interessants, et je me suis bien amuse en VHDL, mais j ai un petit soucis en tant qu etudiant: est ce que coder le FCPU me donnera a manger pendant les mois ou je vais le coder ?

          Si la reponse est non, alors il me faudra trouver un emploi qui donne a manger, et qui du meme coup, occupera le plus clair de mes journees ...

          Si la reponse est oui, dis le moi tres vite, et je vous rejoins le lundi 2 juin 2003 ...

          Ok ce pb n est psa inherent au FCPU, j ai le meme probleme avec les mecs du Hurd ... ils veulent pas me payer pour les aider a coder ...

          Pas d'tune, pas d'pain
          pas d'pain, je meurs !

          Et vous, vous faites commen ?
      • [^] # Re: Interview de l'équipe F-CPU

        Posté par  (site web personnel) . Évalué à 3.

        Et c'est indiscret de demander sur quel projet GPL ? Pas XBlast quand meme ;)

        Il me semble qu'ils travaillent sur la mise en place d'une plateforme de diffusion utilisant le format libre Ogg Vorbis, projet lancé suite aux discussions avec Radio France lorsqu'ils ont changé de format de diffusion.
  • # C est koi une architecture "Numa" ?

    Posté par  (site web personnel) . Évalué à 5.

    Qu est ce que c'est une "architecture NUMA" ?
    ( derniere ligne )
    • [^] # Re: C est koi une architecture

      Posté par  (site web personnel) . Évalué à 10.

      Non Uniform Memory Access.

      Concretement, si tu accedes à de la mémoire vive se trouvant sur une autre machine physique du réseau, ca prendra plus de temps que de la mémoire locale à coté du CPU. Mais l'interface est la même.
    • [^] # Re: C est koi une architecture

      Posté par  . Évalué à 4.

      Non-uniform Memory Access

      en gros, ya plusieurs processeurs , plusieurs stock de mémoire, les temps d'acces à la mémoire varie( cache , ram , a travers un réseau ? ), faut gerer au mieux ...
      • [^] # Re: C est koi une architecture

        Posté par  (site web personnel) . Évalué à 6.

        C'est ça. C'est le principe de fonctionnement des mainframes et des supercalculateurs (et aussi de l'athlon64 en biproc). Si le réseau est trop lent la machine à toutes les chances d'être plus lente un multi proc qu'en bi-processeurs.

        "La première sécurité est la liberté"

        • [^] # Re: C est koi une architecture

          Posté par  (site web personnel) . Évalué à 6.

          mais ça dépend du type de workload, si tu est CPU-bound ça va mieux qu'en memory-bound, où les access patterns et la corrélation des paquets peut avoir des effets non linéaires sur le wallclock time ...

          mais on s'égare.

          YG
          • [^] # Re: C est koi une architecture

            Posté par  . Évalué à 10.

            ça dépend du type de workload, si tu est CPU-bound ça va mieux qu'en memory-bound, où les access patterns et la corrélation des paquets peut avoir des effets non linéaires sur le wallclock time ...

            Idée : ajouter une "citation du jour" à la une de Linuxfr.
            • [^] # Re: C est koi une architecture

              Posté par  (site web personnel) . Évalué à 7.

              <note pour plus tard>
              penser à être clair quand je parle en public,
              sinon ya risque d'effets de bords ...
              </note pour plus tard>
              • [^] # Re: C est koi une architecture

                Posté par  (site web personnel) . Évalué à 6.

                Surtout quand cela ne veut rien dire...

                memory bound/cpu bound c'est un gros la méme chose (programme limité par la puissance de calcul ou par la bande passante mémoire). On l'oppose en général à IO bound, genre bande passante disque ou réseau type ethernet qui est l'affaire des mainframes de sgbd, server web et autre serveur de fichiers...

                Concernant la deuxième partie de la phrase... euh... va dormir :)

                "La première sécurité est la liberté"

                • [^] # Re: C est koi une architecture

                  Posté par  (site web personnel) . Évalué à 1.

                  désolé, memory-bound n'est pas du tout la même chose que CPU bound :
                  L'un c'est quand le programme passe la plupart de sont temps à attendre la mémoire centrale, l'autre c'est quand il y a saturation des unités de calcul.
                  Pour le premier, dans F-CPU, c'est quand on traite des grosses listes chainées et ce genre de trucs avec des accès aléatoires. Du LISP ou du Java risque de ramer à mort si ça tient pas en cache.
                  Pour le deuxième, c'est typiquement la crypto classique, peu de variales mais des passes nombreuses et des traitements zarbs. Là on peut faire.

                  bon, j'arrête les leçons pour ce soir.

                  • [^] # Re: C est koi une architecture

                    Posté par  (site web personnel) . Évalué à 1.

                    Sauf que l'on est jamais cpu bound, sinon intel ne gagnerait pas 30% de performance avec l'hyperthreading. Et avec un ratio de 1/10 pour la bande passante et 1/150 pour la latence avec la mémoire, c'est logique d'être "souvent" (toujours ?) memory-bound.

                    "La première sécurité est la liberté"

    • [^] # Re: C est koi une architecture

      Posté par  . Évalué à 7.

      Voir aussi la FAQ NUMA du kernel Linux:
      http://lse.sourceforge.net/numa/faq/(...)
  • # Pour ceux qui veulent aider

    Posté par  (site web personnel) . Évalué à 8.

    Un des meilleurs trucs à faire pour aider Fcpu ou tout projet libre est de développer des outils en rapport avec la CAO.

    Le plus simple est de tester/debugué ghdl qui est à ghdl.free.fr.

    Ce programme, quand il deviendra pleinement fonctionnel et du même ordre de grandeur de vitesse des produits commerciaux, devraient avoir le même impact sur la CAO que gcc dans le domaine des compilateurs c.

    Il n'y a qu'une personne qui le développe. Bref, si vous voulez prendre le train en route, c'est le moment.

    "La première sécurité est la liberté"

    • [^] # Re: Pour ceux qui veulent aider

      Posté par  . Évalué à 0.

      MDR ;)

      Une seule personne qui développe un truc sensé reléguer les tools-chains proprios aux oubliettes....

      Méthode Coué detected...
      • [^] # Re: Pour ceux qui veulent aider

        Posté par  . Évalué à 7.

        C'est pas toi qui avait envoyé ce genre de message à Linus en 1991 ? :)
      • [^] # Re: Pour ceux qui veulent aider

        Posté par  (site web personnel) . Évalué à 5.

        Dans la série on ne sait pas de quoi on parles et ferait mieux de se la fermer...

        La version 0.3 fait déjà tourner le bench du LEON qui est loin d'être un hello world.

        Ghdl est un front-end à Gcc (hmm... en Ada pour les courageux...) donc la partie génération de code (backend) existe déjà.

        M'enfin, si tu te permets se genre de remarque c'est que tu dois bosser pour cadence ou synopsys ?

        Je te rappelle juste que je parlais "d'ordre de grandeur" de vitesse car vu le prix des soft, cela couteras toujours moins chère d'acheter 10 machines au lieu d'une + une licence propriétaire...

        "La première sécurité est la liberté"

        • [^] # Re: Pour ceux qui veulent aider

          Posté par  (site web personnel) . Évalué à 2.

          De memoire, un prof de mon universite m a dis que la liscence pour une universite (donc differente de la liscence etudiante ) pour un post de Pscice coute 20kf/an, et celle de Xilinx entre 30 et 40kf/an
          ( je parle des frais d entretiens des liscences reseau en milliers de francs par an par poste, a multiplier par le nombre de posts ... plus le cout d achat la premiere annee )

          Donc vous imaginez combien peut couter une version FULL-professionelle

          a ce rythme, je comprends qu'il coute moins cher d utiliser un cluster de 10 pc avec n importe quel soft libre qu un seul pc avec une liscence proprio ...

          Des gens pour confirmer les valeurs? ou donner des chiffres exactes ?
  • # Re: Interview de l'équipe F-CPU

    Posté par  . Évalué à 5.

    Un grand bravo pour l'idée des interview !!
    Cela ajoute du contenu de grande qualité à linuxfr.

    Merci à toi Benoît et à tous les intervenants qui ont posés d'excellentes questions.
  • # Re: Interview de l'équipe F-CPU

    Posté par  (site web personnel) . Évalué à 1.

    Bravo pour l'interview, très intéressante. Par contre le site http://www.f-cpu.org,(...) c'est vraiment super laid et surtout super mal organisé.

    J'ai galéré comme pas possible pour trouver ou télécharger le manuel, et j'ai toujours pas trouvé comment télécharger les sources du bazar. Bref, je pense que si un webmaster a envie de se lacher pour leur faire un truc correct, faut y aller ;-)

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.