Bon quoi de neuf sous le soleil de NERF (pour rappel acronyme de Non Extensible Reduced Firmware a contrario d'UEFI). Depuis ce matin on peut installer une distribution linux sur une machine qui boot sous NERF. En soit l'exploit n'en est pas un, je pensais même y arriver rapidement, mais j'ai fait la "bêtise" de partir sur une Ubuntu Xenial, et me suis empêtré dans le décryptage de l'installer debian. Idiotement je pensais qu'il me suffirait de placer un paquet debian au bon endroit dans l'ISO. En fait c'est bien plus complexe que ça et c'est une vrai usine a gaz tout est signé dans tous les sens avec des checksums et tout le toutim, sans compter que le build du kernel pour créer les udeb, ben je connaissais pas.
Bon au final après une semaine, j'y suis arrivé (en même temps je fais ça le soir quand j'ai le temps), et on a enfin une clef USB (ok on rigole pas, je sais qu'on installe plus les serveurs comme ça), qui boot un installer Ubuntu Xenial 16.04.3 LTS sur notre bon vieux Winterfell. Vous allez me dire super, un serveur qui boot linux, rien de neuf sous le soleil. Sauf que celui-ci démarre sans les services UEFI à partir d'un kexec depuis un kernel basique qui tient dans la flash qui d'habitude contient le code du BIOS.
J'ai publié pour les plus curieux un script vraiment quick and dirty de l'exercice (https://github.com/vejmarie/linuxboot-nerf-toolbox) pour ceux qui voudraient en apprendre plus.
On va mettre en ligne la machine demain sur le net chez Data4, elle tournera donc NERF -> Ubuntu Xenial avec VTd et KVM, et me servira de serveur de compilation et netboot pour le cluster que l'on déploiera par la suite. Le projet progresse donc, il reste encore pas mal de boulot, et notamment faire le même exercice avec CentOS et tester un peu dans tous les sens les O/S, secouer le système et voir comment ça se comporte.
Si il y en a qui veulent donner un coup de main n'hésitez pas ! Bon ok le seul hic il faut avoir accès à du matériel Open Compute, mais si besoin je peux regarder comment traiter ce problème avec les machines que l'on a chez Data4. Après ce qui est galère c'est quand un BIOS démarre pas, ben c'est un peu la loose. Mais si vous voulez bosser sur des installer de distro, je dois pouvoir vous donner accès dans les prochains jours à un ou deux serveurs pour faire des tests.
On se fixe toujours pour objectif de livrer les premières machines sur Q2 ;). Ceux qui ont des Winterfell et/ou en voudraient sous NERF aujourd'hui ben je crois qu'on va pouvoir commencer a vous en livrer sur Q1 en version bêta. Je suis assez étonné par la stabilité de KVM sur Ubuntu/NERF ;). Comme quoi les choses simples ont du bon.
Les modifs sur le kernel portent principalement sur le fait qu'il n'y a plus EFI, et évidemment le kernel de la plupart des distros cherche ce support et il faut donc adapter un peu
Sinon, autre nouvelle, le projet a été retenu par la fondation linux, et cocorico, pour une fois que des français arrivent à s'associer avec Google, Facebook et un Hedge Funds nord américain, on a réussi à coordonner les développements et efforts pour sécuriser l'avenir de cette technologie qui sera déployé à une échelle improbable rapidement. Le seul regret que j'aurai c'est les nombreux refus essuyé auprès des hébergeurs français pour s'impliquer dans ce projet initié avec Ron qui est venu au meetup que nous avons organisé chez Criteo (merci Matthieu !) à Paris depuis la Californie. Les TPE françaises ne sont donc toujours pas crédible en leur contrée, c'est la vie, et le NIH est toujours bien présent chez nous :(. Allez un effort et l'Open Hardware pourrait devenir un franc succès hexagonal faut juste y croire un peu. Conclusion, les serveurs de Google et nord américains seront sécurisés avant les serveurs d'OVH, Online et consort, c'est juste un peu bébête.
# pas mal
Posté par Anonyme . Évalué à 2. Dernière modification le 26 janvier 2018 à 10:03.
mais la partie programmation de l'eeprom n'est pas super user friendly ?
Flashing the firmware : :O
https://trmm.net/NERF
je n'ai pas de conseil a donner mais mon avis : ta description n'est pas super glamour, trop technique et nécessite probablement a ton interlocuteur un fort niveau de compréhension des parties basse du hardware.
je dis ca pour les français :), peut importe ton niveau d'anglais, il est probable que tu simplifie de toi même pour le parler -> les anglais comprennent mieux ton projet.
j'opterais pour que tu parle anglais a tes contacts français, ou que tu fasse une gymnastique français -> anglais -> français :D
[^] # Re: pas mal
Posté par vejmarie (site web personnel) . Évalué à 4.
Tram est un peu hardcore dans sa technique de flashage. Perso j'utilise flashrom et un petit dediprog ca marche tres bien ;).
[^] # Re: pas mal
Posté par Anonyme . Évalué à 5.
Oui son programmateur SPI est plus impressionnant parce qu'il est fait-maison et laissé à nu mais ce n'est qu'une carte façon Arduino préassemblée avec un microcontroleur possédant une interface USB et un environnement logiciel contenant déjà des bibliothèques pour le protocole SPI. La commande par discussion série est assez rudimentaire mais certaines cartes ou microcontroleurs sont compatibles avec flashrom.
Autre solution, on peut aussi utiliser les broches GPIO destinées au SPI sur un nano-ordinateur monocarte (SBC) de type Raspberry, Olinuxino, etc. et ici flashrom est 100% compatible vu que c'est le système d'exploitation qui gère directement les broches.
Dans les deux cas, on trouve plein de tutoriels en ligne sur la fabrication, l'installation et l'utilisation. Il faut seulement faire attention à la tension de fonctionnement et au brochage de la puce qu'on veut flasher donc d'abord trouver la fiche technique du composant.
Une fois qu'on s'est familiarisé avec le processus de flashage, c'est assez abordable d'installer une ROM Coreboot, me_cleaner, Linuxboot… ou de réinstaller celle du fabricant.
Au passage, merci Jean-Marie pour ce billet. Ton contenu est toujours très intéressant à lire. :)
[^] # Re: pas mal
Posté par vejmarie (site web personnel) . Évalué à 10.
C'est un sujet qui peut difficilement etre glamour. Les personnes qui sont responsables d'infrastructure cloud a grande echelle et d'heberger des milliers de serveurs devraient etre capable de comprendre ce que l'on raconte dans linuxboot, sinon ils ont un serieux probleme de comprehension de leur metier ce que je ne pense pas. Apres, c'est soit on fait confiance a Intel et consort pour assurer la securite de ses systemes soit on est capable de le faire, et il vaut mieux le faire de maniere collaborative tellement le sujet est complexe.
# J'en rêve...
Posté par ZeroHeure (site web personnel) . Évalué à 8.
C'est toujours aussi génial, excitant et passionnant à lire!
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: J'en rêve...
Posté par Le Gab . Évalué à 1.
@vejmarie: Avez-vous un forum/chatroom (irc/xmpp)?
[^] # Re: J'en rêve...
Posté par Faya . Évalué à 5.
"Google, Facebook et un Edge Funds nord américain"
[^] # Re: J'en rêve...
Posté par vejmarie (site web personnel) . Évalué à 3.
En effet y a une slack room -> u-root et dedans y a qqs sous ensemble comme linuxboot. La tchat room est en anglais et il commence a y avoir du monde
[^] # Re: J'en rêve...
Posté par Le Gab . Évalué à 4.
lapin compris.
[^] # Re: J'en rêve...
Posté par Faya . Évalué à 5.
Les décideurs pressés n'utilisent pas IRC ou XMPP, ils utilisent Slack (pas Slackware ! )
# Services UEFI ?
Posté par trancheX . Évalué à 4.
Du coups c'est quoi exactement les services UEFI ?
J'avoue qu'en allant voir sur wikipedia : autant "Variable service" pourquoi pas mais quand je vois que le "Time services" peut faire ça :
Alors là je me demande : le BIOS gère donc tous les fuseaux horaires et changements d'heure !!?? mais pourquoi faire ? C'est pas plutôt à l'OS de gérer ça ? … soit j'ai mal compris : l'UEFI ne calcule pas lui même les changements d'heure mais dispose juste d'un champ "timezone" et d'un champ "DST rules" qui permet à l'OS de le faire ; soit les concepteurs d'UEFI sont des consommateurs de drogues dure durant les heures de travail.
Donc ma question est plutôt : y a vraiment que des trucs qui servent à rien dans les UEFI services ?
Par exemple l'OS va chercher comment l'heure du BIOS sans l'UEFI "Time service" ?
[^] # Re: Services UEFI ?
Posté par Renault (site web personnel) . Évalué à 9.
C'est ça, en gros l'UEFI permet aux différents OS de gérer l'heure matérielle de la machine proprement de manière univoque.
Cela évite les soucis du passé où Windows et Linux n'interprétait pas le BIOS de la même façon à ce sujet, donnant des heures différentes selon l'OS que tu employait si tu passais de l'un à l'autre.
[^] # Re: Services UEFI ?
Posté par trancheX . Évalué à 0.
OK, outre le fait que c'est un peu bête un OS qui met l'heure locale dans le BIOS.
C'est à dire que l'UEFI a les champs nécessaires au calcul de l'heure locale, mais rassurez moi il ne calcul pas lui même les changement d'heure (été/hiver) suivant la location ?
[^] # Re: Services UEFI ?
Posté par vejmarie (site web personnel) . Évalué à 5.
UEFI fonctionne comme un O/S pratiquement (le machin fait plusieurs millions de ligne de code) donc tu peux envisager qu'il sait faire ce que tu decris.
[^] # Re: Services UEFI ?
Posté par Renault (site web personnel) . Évalué à 3.
Ce qui soit dis en passant n'est pas un problème. Pourquoi l'UEFI de la carte mère devrait être incapable d'afficher l'heure réelle de chez moi quand j'y vais dedans ? D'autant que ce n'est pas si compliqué avec un OS qui supervise cela au dessus de lui.
[^] # Re: Services UEFI ?
Posté par vejmarie (site web personnel) . Évalué à 10.
Le probleme c'est qu'il accede avec un niveau de privilege superieur aux resources materielles et ce meme lorsqu'il a passe la main a un O/S. En clair un petit malin peut recuperer l'ensemble de tes donnees si il le souhaite grace a cette magnifique technologie qu'est UEFI. Ca reste complique a exploiter, mais ca reste faisable, alors on peut faire toutes les mises a jours contre spectre, meltdown et tout le reste, mais quand on voit ce que l'on peut faire avec UEFI et bien si tu fais confiance aux serveurs de Cloud de ton hebergeur prefere, ben c'est pas tres tres serieux, surtout si on rajoute la partie ME dans la discussion. Le role d'un BIOS c'est juste d'initialiser le hardware et de s'effacer lorsqu'un O/S demarre, si il fait plus c'est dangereux. On a fait qqs demos avec linuxboot qui ont perturbe des specialistes securites. Le truc le plus marrant c'est le secure boot alors qu'on peut changer les filesystemes de flash BIOS par un kernel linux et booter ce kernel sans que la machine s'en rende compte. C'est secure serieusement ?
[^] # Re: Services UEFI ?
Posté par Renault (site web personnel) . Évalué à 7.
Tout à fait, de même s'il a inséré une porte dérobée dans ton processeur, le firmware de ton espace de stockage ou le noyau de ton OS.
L'UEFI est un composant parmi d'autres qui a de grandes possibilités sur ta machine, mais heureusement son accès n'est pas aisé, généralisable à grand échelle (l'UEFI d'un constructeur n'est pas compatible avec un autre en terme de code et d'initialisation, seule l'API l'est). Et ce n'est pas le seul dans ce cas.
C'est un point de vue, mais qui globalement ne colle pas à la réalité.
Même avec l'UEFI, si tu dialoguais directement avec le BIOS tu pouvais jouer à faire des trucs rigolo. Le BIOS sur x86 ne s'est jamais totalement effacé devant l'OS en fait.
Et c'est d'ailleurs un intérêt du BIOS que de fournir une petite abstraction de la machine en dessous pour aider le noyau dans cette tâche. N'oublions pas que c'est en partie cela qui fait que l'ARM est une plaie à gérer car la l'initialisation et la découverte du matériel doit se faire à la main.
Il faut faire attention à distinguer un standard sécurisé et son implémentation qui peut ne pas l'être.
[^] # Re: Services UEFI ?
Posté par xcomcmdr . Évalué à 5.
LOL non ?
Les BIOS ont toujours fait bien plus, BIEN plus. Donner l'heure, la possibilité de modifier le contenu d'une disquette, essayer de détecter certains virus de boot (!), permettre de modifier l'affichage, décider de la politique de sauvegarde de l'énérgie (quand et comment éteindre l'écran, les disques durs, face à quel évènement l'ordi doit se réveiller, décider du mode ATA (ACHI ou IDE), si l'IDE est en mode UDMA ou PIO, donner et régler l'heure, permettre de 'tatouer' l'ordi et d'empêcher d'installer autre chose que Windows, décider si on est compatible OS/2 ou non, si on met un 'trou' dans la mémoire à je ne sais plus quel endroit pour des sombres histoires de compatibilité, décider du comportement de la Gate A20, modifier le FSB, et j'en passe…
Voir : https://en.wikipedia.org/wiki/BIOS_interrupt_call
Voir aussi : http://www.ctyme.com/rbrown.htm
Et l'UEFI c'est le même combat : ça en fait trop et c'est un nid à failles bordélique et trop complexe.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Services UEFI ?
Posté par Tonton Th (site web personnel, Mastodon) . Évalué à 6.
En fait oui, tout ce que tu listes était dans le BIOS, mais en tant que "service", de fonctions qu'un programme devait appeler (eg: lire un secteur de disque), ou qu'un utilisateur devait explicitement actionner (eg: mettre l'horloge permanente à l'heure). Le BIOS en lui même, une fois un système démarré, n'avait quasiment plus d'autonomie. Et une bonne partie des OS n'utilisaient plus trop ou pas du tout ces appels aux fonctions du BIOS après démarrage.
En revanche, l'usinagaz autour de UEFI est beaucoup plus avancée, elle a son autonomie, elle contient des fonctionnalités activables à distance, elle peut communiquer avec des processeurs auxiliaires faisant tourner d'autres logiciels, toussa. C'est quand même un autre monde…
[^] # Re: Services UEFI ?
Posté par trancheX . Évalué à 10.
Alors là non, que la carte mère dispose des champs mémoire nécessaire à un OS pour calculer l'heure locale, ok ; qu'elle sache le faire toutes seule là non. Car :
- Si chez toi c'est sur l'île de Lord Howe alors (comme chacun sait) l'heure d'été ne fait un offset que de 30min ici
- Si chez toi c'est au Maroc alors il y 4 changements d'heure dans l'année
- Si chez toi c'est au Brésil la fin du changement d'heure est décalé d'une semaine si elle tombe en même temps que le Carnaval de Rio
- Si chez toi c'était en Israël la carte mère aurait nécessité une MAJ pour calculer la bonne heure depuis 2013 car les autorité locales on changé le changement d'heure
- Si chez toi c'était en Jordanie en tu n'as fait qu'un changement d'heure entre 2012 et 2013, puis en 2014 les changement d'heure on repris une activité normale
- Si chez toi c'était au Chili tu n'as pas changé d'heure en 2015 puis en 2016 c'est reparti en changeant la règle de changement d'heure
- Si chez toi c'est en Iran les changement d'heure se font aux equinoxe, comment calculer les équinoxes ?
Comme on peut s'en douter la plupart de ces cas impliquent un programme complexe et surtout des mise à jour régulière, quel intérêt à faire ce genre de chose au niveau de la carte mère ?
Tant qu'on y est pourquoi pas y mettre un OS ? au wait
[^] # Re: Services UEFI ?
Posté par Renault (site web personnel) . Évalué à -1.
Merci je sais très bien la difficulté de représenter le temps, je suis d'ailleurs en plein dedans.
Mais comme mentionné dans d'autres sujets, parfois il vaut mieux quelque chose qui fonctionne bien pour 90% des cas et dont le problème pour les autres est mineurs que de n'avoir rien du tout.
Et comme cela a été indiqué, l'UEFI peut jouer avec ces données pour en tirer quelque chose (à l'affichage de son menu par exemple). Cela n'en est pas une obligation, et globalement l'OS au dessus est responsable de maintenir l'heure réelle sous-jacente (après tout, c'est lui qui a accès au NTP et à la configuration de l'utilisateur directement).
La question est : pourquoi pas ? Est-ce grave si la carte mère pour de l'affichage essaye d'afficher une donnée intéressante même si ça peut être faux dans quelques cas ?
Tu vas reprocher à des constructeurs de proposer l'affichage de leur interface UEFI en chinois mais pas en français car tant que toutes les langues ne seront pas dispo ce ne sera pas parfait ? (cas d'une carte mère chez moi, anglais ou mandarin). Je trouve vraiment que tu t'emportes pour pas grand chose dans ce cas-ci.
Et l'UEFI a au moins unifié la politique de manière universelle (car à priori d'autres architectures que l'x86 vont reprendre la spec). Et quelque soit l'OS. Avec les BIOS d’antan, c'était un peu la loterie, suffit de constater les bogues de l'heure quand tu passais de Windows à Linux en dualboot…
Quel est le problème ?
Le matériel est devenu un centre de technologie très complexe. Le processeur Intel / AMD / IBM / ARM / autre n'est plus maître à 100% de la machine. Il est guidé par des dizaines de processeurs ou microcontrôleurs avec leur propres logiciels voire mini-OS dedans. Et je ne parle même pas des cartes graphiques qui sont presque des ordinateurs complets à eux seuls. Il est naïf de croire que tu vas retrouver le contrôle de l'ensemble avec ton Linux logé dans le disque dur.
Mais cela a aussi un avantage, comme le processeur principal ne gère pas cela lui même, Linux n'a pas à le faire non plus, et avec la quantité astronomique de combinaison possible, c'est une bonne chose pour la portabilité de nos systèmes et leur fiabilité.
[^] # Re: Services UEFI ?
Posté par trancheX . Évalué à 4. Dernière modification le 26 janvier 2018 à 16:57.
C'est plus du tout pareil que :
… mais bon pour le cas présent ça va l'UEFI n'essait pas de faire ça (en tout cas la spec ne dit pas ça)
Le problème c'est que ce genre de chose ne sert à rien, ça ajoute beaucoup de complexité pour rien.
Tout comme traduire l'interface de la configuration de la carte mère, je préfères que tous les constructeurs fassent une interface avec les même termes en anglais; les utilisateurs qui voudrons changer quelque chose sauront très bien retrouver ce qu'ils souhaitent même sans aucune maitrise de l'anglais (juste un coup baidu/yandex/google/ddg/…)
ça sera 1000x mieux qu'une interface passé au google-translate
Je comprend bien que l'UEFI permet une abstraction qui standardise et fait qu'on peut installer n’importe quel OS sur n’importe quel PC; mais l'UEFI n'as pas besoin d'être un OS pour faire ça.
[^] # Re: Services UEFI ?
Posté par Renault (site web personnel) . Évalué à 3.
Je parlais de la représentation accessible aux OS. Que l'UEFI travaille sur ces données ou non est une question totalement indépendante.
La méthode simple (qui marche souvent, à savoir faire UTC + fuseau horaire + décalage d'heure d'été) ne prend que quelques lignes et apparemment quelques octets seulement pour sauvegarder ces infos. Très compliqué en effet.
La véritable difficulté c'est de faire une fonctionnalité parfaite, mais apparemment personne ne s'en préoccupe outre mesure. Et sans mises à jour régulière c'est voué à l'échec.
Comme beaucoup d'UEFI sont programmés en Asie, en réalité c'est l'anglais qui est une traduction. :-)
Honnêtement tu te focalises sur des détails de l'UEFI, c'est quand même assez fou. L'UEFI fait beaucoup de chose bien plus complexes (tout comme le BIOS en son temps) c'est dans l'ordre des choses que ce soient des OS à part entière. D'ailleurs NERF semble les remplacer par du noyau Linux, preuve que cela fait sens.
Tu sais que GRUB, U-boot et tout qui ne sont que des chargeurs de démarrage sont également d'une complexité importante ? Bah oui, initialiser le matériel, gérer des systèmes de fichier, de la cryptographie, du réseau, etc. c'est du gros boulot.
[^] # Re: Services UEFI ?
Posté par trancheX . Évalué à 4.
Pour la représentation de l'heure, c'est quand même une mauvaise idée : le client au brésil qui aura pas de bol et sera trop perfectionniste va chercher pendant une semaine pourquoi son parc de machine affiche une mauvaise heure dans l'UEFI pendant la semaine du Carnavale lui ça le dessert d'avoir l'heure quand il va dans le BIOS.
Alors qu'aucun utilisateur ne reprochera de devoir regarder sa montre/son telephone pour avoir l'heure lorsqu'il modifi son BIOS/UEFI.
Le fait de calculer un décalage d'heure indique de pouvoir calculer genre le dernier ou le 3eme dimanche du mois ou le premier lundi (enfin tous ça dépend des pays) + de stocker les régles de changement d'heure.
Ok ça fait pas des milliers de ligne mais un peu plus que quelque lignes
Tous le problème n'est pas là effectivement il y a des choses complexe mais si elle doivent être faite c'est normal de le faire (U-Boot, PXE etc sont des exemples).
Le problème c'est que j'ai l'impression que ce genre de chose participe à un bordel ambiant chez les concepteurs de carte mère (je veux dire bordel dans leur code).
En fait, ce que je reproche aux UEFI des fabricants c'est justement de ne pas se concentrer sur l'essentiel :
- être sécurisé
- être auditable
- booter rapidement
- booter rapidement
- booter rapidement
et booter plus rapidement
Franchement pas mal de PC le BIOS/UEFI est plus lent que le démarrage du kernel et pour les serveurs c'est encore plus flagrant.
[^] # Re: Services UEFI ?
Posté par Tonton Th (site web personnel, Mastodon) . Évalué à 3.
On 5 August 2015, the North Korean government decided to return to UTC+08:30, effective 15 August 2015, and said the official name would be Pyongyang Time or (PYT) https://en.wikipedia.org/wiki/Time_in_North_Korea#IANA_time_zone_database
[^] # Re: Services UEFI ?
Posté par oinkoink_daotter . Évalué à 4.
C'est écrit icitte, chapitre 7.3.
Shorter: si j'étais toi, j'irai cramer des cierges, parce que c'est pas très clair, a priori.
[^] # Re: Services UEFI ?
Posté par trancheX . Évalué à 1.
Merci.
C'est pas hyper clair mais de ce que je comprends l'UEFI ne fait heureusement pas les calculs de changement d'heure : page 255 :
[^] # Re: Services UEFI ?
Posté par Tonton Th (site web personnel, Mastodon) . Évalué à 6.
Question suivante : comment se fait la mise à jour de
tzdatadans le machin ?# Faux ami ou typo ?
Posté par Glandos . Évalué à 2.
Euh, c'est Edge Funds ou Hedge Funds ? Le premier n'a pas l'air d'exister pour moi.
[^] # Re: Faux ami ou typo ?
Posté par vejmarie (site web personnel) . Évalué à 3.
C'est Hedge ;)
[^] # Re: Faux ami ou typo ?
Posté par Benoît Sibaud (site web personnel) . Évalué à 3.
Corrigé, merci.
# lwn en parle
Posté par gaston . Évalué à 5.
Au détour d'un article sur lwn annoncant linuxboot, je suis tombé sur ce très bon lien expliquant relativement bien la problématique: https://lwn.net/Articles/738649/ - c'est effectivement passionant, et effrayant en même temps..
# Le NIH ?
Posté par lagou . Évalué à 1.
Qu'est-ce le NIH ?
[^] # Re: Le NIH ?
Posté par Tonton Th (site web personnel, Mastodon) . Évalué à 1.
Not Made In Redmond[^] # Re: Le NIH ?
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 4.
Not Invented Here
[^] # Re: Le NIH ?
Posté par Anonyme . Évalué à 5.
Not invented here
# Aucun hébergeur français??
Posté par fredoche . Évalué à 4.
Hello,
Tu abordes un point que je trouve hyper intéressant, et je comprendrais que tu bottes un peu de nouveau en touche, vu qu'on parle de potentiels futurs partenaires.
Pourquoi les hébergeurs français ne sont pas à FOND avec votre projet?
Est ce que ça n'est pas le signe que non, vraiment, les hébergeurs "tier-2" ne sont pas à la page de l'innovation en terme de sécurité?
Entre les pannes chez OVH et les pannes chez Online (rares mais qui font tout de même le buzz), ces hébergeurs n'auraient il pas intérêt à se mettre un peu à l'avant garde de ce qui se fait en matière de dé-plombage de serveurs, ne serait-ce que pour, en terme d'image, indiquer aux prospects qu'entre eux et GCP ou AWS, il n'y a pas tant d'écart..?
[^] # Re: Aucun hébergeur français??
Posté par Tonio (site web personnel) . Évalué à 3.
L'innovation devrait être une priorité.
Pour ma part, il y a Quanta Cloud Technology qui ont l'air de chercher des marchés et vu qu'ils sont partis prenantes OpenCompture. Je les ai rencontré fin 2016, ils étaient assez ouvert.
https://qct.io/Contact-QCT/index
http://www.opencompute.org/products/
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.