M
Membre supprimé 1060554
Invité
Pereira
Ta trouvaille permet de circonscrire le problème en pratique : « Éviter l'arobase ! ». Quant à concevoir théoriquement parlant les raisons qui font que le seul arobase pose problème à l'écran de déverrouillage d'un Volume Logique Chiffré : comme disait Rudyard Kipling : « c'est une autre histoire »...
Un OS est un univers logique. Le philosophe Leibniz disait de l'Univers qu'il ressemble à un « étang plein de poissons dont chaque poisson est lui-même un étang plein de poissons ». L'architecture logique du CoreStorage impliquée par le chiffrement «FileVault» est elle-même un pareil étang plein de poissons dans l'étang plein de poissons de macOS.
Le CoreStorage (avec le chiffrement «FileVault-2» comme dispositif particulier) a été créé logiquement avec l'OS «Lion 10.7». Ce dispositif implique notamment d'affecter la partition de récupération «Recovery HD» au rôle de démarreur logique (« booter ») du Volume Logique CoreStorage. L'écran de déverrouillage du Volume Logique Chiffré, en cas d'activation de «FileVault», est donc déployé par cette fonction « booter » de la «Recovery HD» (dont la ressource de Recovery OS - OS de secours démarrable - passe au second rang).
Mon § précédent était destiné à suggérer la complexité logique impliquée dans ce simple affichage de l'écran initial de déverrouillage d'un Volume Logique Chiffré. Lorsque cet écran s'affiche > aucun kernel (noyau) n'est encore démarré > aucun jeu de kexts (extensions su noyau) injecté dans le kernel > aucun OS initialisé (ce n'est pas comme le LoginWindow classique, qui intervient après l'initialisation du Système) => on a affaire à un fonctionnement a minimo (témoin : la lenteur de déplacement du pointeur à cet écran). Régler l'affaire du bogue de reconnaissance de l'arobase à cet écran dans un clavier non-US : pas sûr que le problème se laisse circonscrire à une ou deux lignes de code.
Il faudrait alors une décision politique d'entreprise d'affecter une équipe d'ingénieurs à l'examen de ce problème pendant un temps x > examen s'inscrivant nécessairement dans le cadre du fonctionnement logique d'ensemble du CoreStorage : un détail impliquant un « étang plein de poissons » - et un « étang » logique particulièrement redoutable a priori > celui de la création logique la plus sophistiquée de l'histoire d'Apple. Pas sûr que ce type de décision se prenne à la légère.
Même si je conçois ta déception > je ne te suivrai donc pas dans ta généralisation : « Tout fout le camp » > car le domaine du CoreStorage est théoriquement super-intriqué : un détail y implique l'ensemble et l'ensemble est super-complexe.
après différents tests, le seul caractère accentué qui bloque à l'ouverture c'est l'@, les autres passent
Ta trouvaille permet de circonscrire le problème en pratique : « Éviter l'arobase ! ». Quant à concevoir théoriquement parlant les raisons qui font que le seul arobase pose problème à l'écran de déverrouillage d'un Volume Logique Chiffré : comme disait Rudyard Kipling : « c'est une autre histoire »...
ce bug [...] n'est pas traité pour le moment par Apple alors qu'il en a connaissance depuis 2 ans, ce qui me déçois de la part d'une marque qui n'a à gérer que ses propres machines sur son propre système. Tout fout le camp.
Un OS est un univers logique. Le philosophe Leibniz disait de l'Univers qu'il ressemble à un « étang plein de poissons dont chaque poisson est lui-même un étang plein de poissons ». L'architecture logique du CoreStorage impliquée par le chiffrement «FileVault» est elle-même un pareil étang plein de poissons dans l'étang plein de poissons de macOS.
Le CoreStorage (avec le chiffrement «FileVault-2» comme dispositif particulier) a été créé logiquement avec l'OS «Lion 10.7». Ce dispositif implique notamment d'affecter la partition de récupération «Recovery HD» au rôle de démarreur logique (« booter ») du Volume Logique CoreStorage. L'écran de déverrouillage du Volume Logique Chiffré, en cas d'activation de «FileVault», est donc déployé par cette fonction « booter » de la «Recovery HD» (dont la ressource de Recovery OS - OS de secours démarrable - passe au second rang).
Mon § précédent était destiné à suggérer la complexité logique impliquée dans ce simple affichage de l'écran initial de déverrouillage d'un Volume Logique Chiffré. Lorsque cet écran s'affiche > aucun kernel (noyau) n'est encore démarré > aucun jeu de kexts (extensions su noyau) injecté dans le kernel > aucun OS initialisé (ce n'est pas comme le LoginWindow classique, qui intervient après l'initialisation du Système) => on a affaire à un fonctionnement a minimo (témoin : la lenteur de déplacement du pointeur à cet écran). Régler l'affaire du bogue de reconnaissance de l'arobase à cet écran dans un clavier non-US : pas sûr que le problème se laisse circonscrire à une ou deux lignes de code.
Il faudrait alors une décision politique d'entreprise d'affecter une équipe d'ingénieurs à l'examen de ce problème pendant un temps x > examen s'inscrivant nécessairement dans le cadre du fonctionnement logique d'ensemble du CoreStorage : un détail impliquant un « étang plein de poissons » - et un « étang » logique particulièrement redoutable a priori > celui de la création logique la plus sophistiquée de l'histoire d'Apple. Pas sûr que ce type de décision se prenne à la légère.
Même si je conçois ta déception > je ne te suivrai donc pas dans ta généralisation : « Tout fout le camp » > car le domaine du CoreStorage est théoriquement super-intriqué : un détail y implique l'ensemble et l'ensemble est super-complexe.
Dernière édition par un modérateur: