Reprise du message précédent :

Toi, ta partie sombre, c’est ta queue.

PQ Harko

Tu t'es fait mal au genou ?

trop dommage

dernz au taf

euh, oui, sans pb.

http://www.lemagit.fr/technologie/ [...] se-que-ca/

Dernz (certainement pas au taf )

Preums.

bonjour,

Windows 7 fait
Windows 8 fait
Ubuntu fait
Fedora fait
Mint fait
Shellx64.efi : me fait chier.
 
Heureusement, j'ai des kinder schokobon !

Ponchour,

Bonjour,
 
puisqu'on aime bien les infographies ici, en voilà une intéressante bien que fort limitée :

 
Il manque, je trouve, tout le côté masculin de la chose. Après tout, les massages prostatiques, ce n'est pas utile que pour le hoquet.

C'est plus intéressant que les spams sur le cloud/big data  

 
Pour une fois que j'en trouve une bien :>

 
aucune idée

 
   
 
Par contre ça casse tout.  

Faut voir quoi

 
3.8.0  

Ah, j'avais l'impression que c'était une capture d'une appli d'il y a 10 ou 15 ans

C'est franchement pas au point les bios UEFI/EFI ...
Entre le bios qui brick de peur quand tu touche a sa vram, celui qui a son CSM a moitié vérolé, le secure boot qui reste active sans key, sans oublier la version qui oublie de commit les firmware vers l'OS >_>
Moralité sur ma machine test, mon install multiboot tourne sans soucis, merci le bios UEFI modifié a l'arrache ... Mais arrivé sur la machine test du client ça brick 2 fois sur 3.
Bon, l'avantage quand même c'est que c'est unifié, tu t'emmerde vraiment plus pour savoir comment partitionner : tout est géré "logiciellement" avec les stub EFI dans la partition fs0\efi.
J'ai vraiment l'impression qu'on prend les admins déploiement pour des beta testeurs là quand même.

Bon, je retourne m'amuser a compiler des shell UEFI compatible, merci tianocore et Matthew Garret pour leurs super taff open source (BSD like) et leurs support doc

preums à l'heure d'été

Parce qu'il l'a vue avant moi, pardi
 

T'as mis les chattes au chinon ?

 
Feyd Harkonnen je pense.

Il était bon l'agneau de pâques ? :>

Euh, non, doit encore être un coup de spanghero <_<

J'ai juste mise un drapeau !

Faudrait que tu jette un oeuil coté réseau SOHO ou microsoft, des fois c'est croustillant aussi, le dimanche je regarde et je me poile sévère xD
Un café mon n'Oggy chéri ?

en chine il y a eu une affaire de canard trempé dans de l'urine d'agneau pour lui donner le goût

Je suis en train de mettre mes procédures de validation a jour pour UEFI et faire un truc idiotproof ...
Mais j'en arrive a la conclusion que :
-Dans l'état actuel des choses UEFI/EFI secure boot ou pas, le problème ne viens pas du software.
-Dans l'état actuel des choses, l'implémentation des technologies est aussi foireuse que la gestion de l'ACPI dans les anciens BIOS
-Ce sont les fabricants de carte mère qui sont lazy
-L'UEFI, quand ça tourne bien, ça facilite grandement les choses, encore faut-il que ça tourne bien ...
-Pour bien faire tourner les choses faut savoir créer et manipuler un shell EFI
-Pour bien faire tourner les choses faut savoir créer et manipuler un firmware UEFI pour carte mère, au minimum, voir savoir créer et manipuler des firmware compatible UEFI pour le reste du matériel (CG notamment)
-Les firmware de base fournis au grand publique sont pour la plupart bloatés et brickés, de base ...
-Les outils pour corriger les problèmes de bloat/brick sont difficilement disponible
 
Je vais pour finir prendre l'exemple de ma station "test". C'est une station qui tourne avec un ivybridge sur 2 cartes mères, une asus P8Z77-v Deluxe (très peu de puces additionnelles) et une gigabyte G1.sniper 3 (dite "papa Linus en fait des cauchemar la nuit tellement y'a de puces additionnelles qui demandent des blob binaires" ). J'ai eu moins de problèmes a faire supporter un boot UEFI multiplateforme sur la GGB que sur l'Asus. Et a la question du "pourquoi", la réponse est simple :  
Les fournisseurs d'OS ont des prérequis de validation, la compilation des firmware et autre BIOS, pour avoir l'aval de ces fournisseurs d'OS doit répondre a des impératifs.
Quand on fabrique un firmware ou un BIOS, on récupère le programme de base chez phoenix, AMI ou autre, puis on configure des modules, qu'on compile avec un compilo dédié, on va modifier le programme de base (ou on peu carrément récupérer les sources > attention c'est pas "open" hein, faut avoir certaines autorisations pour que AMI ou autre donne ses BIOS ou ses sources), on "signe" son BIOS/Firmware et on monte le tout sur la mobal.
Intel pour la création des modules fourni 3 choses : un compilo, les sources des modules et des modules binaires précompilé "standards". Pas de problème a ce niveau là, ils sont très coopératif (j'ai pu récupérer par exemple tout ce qu'il faut pour gérer un Z77 en mode "base" et même un peu plus) AMD, fourni aussi mais faut avoir l'aval d'une autorité ayant pignon sur rue (une inscription a un sig, payante ...) mais uniquement pour la partie "carte mère et procos" pour la partie graphique ... Les 3/4 du temps si vous êtes pas "partenaire" ou fabricant c'est niet (en bossant dans un labo de tests hard ou de certification, ça peut être possible et en leurs expliquant ses besoins ... Bref c'est compliqué.), AMD n'a pas de compilo propre, faut passer par l'un des deux seuls compilos disponibles microsoft ou AMD.
Les fabricants de puces additionnelles, le support est assez aléatoire, marvell sont coopératif pour fournir par exemple mais aucuns support apporté. Nvidia c'est binaire only, et là encore faut faire partit des fameux partenaires/fabricants. Bref ... C'est la jungle.
Mais là ou le bat blesse surtout c'est au niveau de la compatibilité et revenons a nos moutons, les "validations".
Ainsi pour avoir le droit au "label" eRPready, ACPI compliant, Microsoft Windowsready, ou autre, faut certaines validations et je vais prendre l'exemple de Microsoft, qui nous fait chier, disont le clairement, depuis un bon moment (déjà avec l'ACPI c'était la même merde) : les fabricants visent principalement cette certif, le reste ils s'en tapent pour beaucoup.
 
Là ou GGB va faire un effort d'utiliser presque exclusivement des procédures intel pour créer leurs firm UEFI, et va effectuer par exemple un vrai travail d'adaptation des firmware, Asus va se glander clairement les burnes et vont juste implémenter les requis microsoft et donc on va se retrouver avec soit du bloat, soit du brick, soit carrément des fonctions non standards (salut les tables custom d'annonciation des periph de stockage de masse passé par le firm/bios ? Salut l'acpi processeur intel non standard avec une gestion énergétique extravagante qui marche que sous windows).
 
Vous l'aurez compris, on ne peu pas demander aux utilisateurs finaux de connaitre tout ces prérequis, et pour le bien de l'innovation, ou "justifier" l'évolution technologique, faut quand même que les fabricants de puces additionnelles gardent certains secrets de fabrication/conception, tout en biensur, respectant les standards au minimum de connectivité, voir d'interopérabilité (gestion des VRM en mode compatibile ?).
Donc au juste on en arrive ou là ? Pour faire simple : on en arrive au fait que les utilisateurs finaux doivent réclamer, comme actuellement, c'est devenu la "norme" sauf que ça devrait pas l'être hein, on est bien d'accord. Mais on doit réclamer tout le temps la coopération de ceux qui ont les outils pour fournir, non pas du matériel qui fonctionne, mais du matériel qui n'ira pas bricker ou du moins qui respecte un minimum ce qu'il y a d'écrit sur la boite. Parce que bon, entre nous, arriver a devoir recompiler un firmware UEFI complet pour faire tourner un système qui suis une specification que même Microsoft en l'ayant créer a du mal a tenir, faut le faire ! (et accessoirement, chez certains fabricant de matériel arrêter de jouer aux apprentis sorcier, et d'un peu plus respecter les spec parce qu'entre nous, Asus, Asrock et MSI, avec leurs implémentation foireuses font clairement chier leurs monde.)
Faut vraiment une participation active de ces acteurs pour arriver a ce que l'informatique, qu'elle soit open source ou qu'elle soit closed source, soit utilisable sans soucis par l'utilisateur final. Actuellement c'est pas encore le cas.

C'est sur maintenant, t'as pas de vie
beau pavé sinon.

 
Les spécif EFI sont énormes et "design by comittee", on va droit au désastre.
 

 
 
Mets toi en relation avec Matthew Garret, vous avez beaucoup en commun (désolé o'gure) et il pourrait peut être t'aider.  
Est ce que coreboot pourrait quelque chose pour toi dans ce genre de cas ?

 
Non, il n'y pourrait rien. La le mieux a faire franchement, c'est continuer d'ouvrir les spec EFI, et fournir les outils a ceux qui veulent bosser pour la communauté, et certes créer une informatique a deux vitesses, mais au moins, on pourrait apporter nos propres solutions. UEFI est fait pour être ouvert, et l'est dans un certain sens, ce qui l'est moins, c'est les implémentations qui tournent sur du matos fermé (on peu pas y faire grand chose, parce qu'autant quitter windows/os X ca reste du domaine du possible, autant passer sur cell ... donc on reste sur du x86_64) pour des questions économiques (ben oui dév sa propre archi, coute autrement plus cher de d'adapter sur du x86_64 qui reste relativement ouvert comparé a ... du arm, par exemple), pour des questions de brevet (dans un certain sens, je suis d'accord sur le fait que les devs, faut les payer, ils bossent pas pour la gloire, et actuellement, le seul moyen de rémunérer un dev, c'est de le faire bosser sur des archis fermés et sous brevet. Faut pas se leurrer aussi, un dev seul, il peut pas se payer un environement de dev complet).
Non, franchement, faut être réaliste quand même, et continuer a faire ce qu'on fait de mieux ... Parce qu'au fond, EFI/UEFI c'est quand même une avancée pour le monde libre. (oui oui)
 
Et entre nous coreboot, y'a rien qui tourne dessus, et le peu de matos qui tourne dessus est encore moins utilisable (faut dev un kernel spécifique coreboot, une procédure de boot spécifique coreboot, faut compiler limite son propre coreboot pour arriver a quelque chose de potable, déjà testée hein ...)

c'est chiant un graveur de dvd qui veut pas graver, ou alors c'est ubuntu qui fait son chiant.
Enfin, réussi à installer par usb, c'était pas gagné.

bonjour,

Chéri qui parle de trap SNMP et d'interco, c'est beau :')

'soir

même pas de poisson d'avril pour le QR