Il nous manque 2 ressources critiques sur la partie test UEFI. Le temps, 10 000 boot sur une meme machine c'est long en UEFI tres long. Sur une meme machine que celle executant NERF, (meme hardware), le boot s'arrete de maniere aleatoire apres une cinquantaine de demarrage, comme si il y avait de la resilience entre chaque boot. Ce qu'on a constate c'est qu'UEFI utilise la flash du BIOS comme un systeme de fichiers et y stock des informations, on imagine qqs soucis dans la gestion entre boot, mais ce ne sont que des suppositions. NERF utilise les devices drivers de linux pour initialiser le hardware, ils sont publics, ouverts, testes a grande echelle et bien plus sollicite que ceux contenus dans le code UEFI qui en general croise les doigts pour reussir a faire un PXE/TFTP. NERF ne stock aucune information entre boot et recommence ineluctablement toujours la meme tache.
[^] # Re: 104
Posté par vejmarie . En réponse au journal Vers des serveurs libres, ouverts et sécurisés : NERF (2). Évalué à 10.
Il nous manque 2 ressources critiques sur la partie test UEFI. Le temps, 10 000 boot sur une meme machine c'est long en UEFI tres long. Sur une meme machine que celle executant NERF, (meme hardware), le boot s'arrete de maniere aleatoire apres une cinquantaine de demarrage, comme si il y avait de la resilience entre chaque boot. Ce qu'on a constate c'est qu'UEFI utilise la flash du BIOS comme un systeme de fichiers et y stock des informations, on imagine qqs soucis dans la gestion entre boot, mais ce ne sont que des suppositions. NERF utilise les devices drivers de linux pour initialiser le hardware, ils sont publics, ouverts, testes a grande echelle et bien plus sollicite que ceux contenus dans le code UEFI qui en general croise les doigts pour reussir a faire un PXE/TFTP. NERF ne stock aucune information entre boot et recommence ineluctablement toujours la meme tache.