Enfin bref ! Je vois bien que tu sous-entend que notre MacoManiac est un tantinet ardu à lire et que je promets plus que je peux tenir... 
Votre avis sur macOS 10.12 Sierra
- Créateur du sujet Anthony
- Date de début
On s'en branle.Enfin bref ! Je vois bien que tu sous-entend que notre MacoManiac est un tantinet ardu à lire et que je promets plus que je peux tenir...
Car, malgré le caractère éminemment technique de ses interventions, macomaniac reste lisible en n'oubliant aucune ligne à son exposé et fait preuve dans d'autres fils d'une grande culture, d'un vocabulaire riche et qui plus est, d'humour.
Même sa ponctuation est correcte.
Je le considère donc comme un être détestable au plus haut degré et j'affirme que je n'achèterai jamais aucun des bouquins qu'il pourrait écrire…
par pure jalousie.
ps : je ne dis pas que je n'enverrai jamais quelqu'un d'autre l'acheter pour mon compte…
L'avis sur Sierra se confondrait avec celui sur Macomaniac ???
Lequel des deux est le plus technique ?
Je sais du moins celui des deux qui bugge le moins !
Lequel des deux est le plus technique ?
Je sais du moins celui des deux qui bugge le moins !
ça serait la mort du forum !!! :eek: l'OS sans bugs !!!
Quelqu'un a-t-il pu vérifier si la màj 10.12.1, comme le suggère le descriptif (anglais) des améliorations apportées, a pu résoudre le problème avec les imprimantes Pixma de Canon ? (le fameux "Filter Error" ou un truc du genre) J'ai une Pixma IP8750 et suis encore sous El Capitan pour cette raison. Si vous avez un retour d'expérience, merci d'avance.
Bonjour, depuis l'installation sur MacBookAir mid 2013, à l'ouverture j'ai à choisir entre mon identifiant ou invité. Je me demande si Apple à vraiment pensé que l'on prête notre MacBookAir sans mot de passe pour la session?
Cette session est limité à l'accès internet.
Je me demande si je suis en présence d'un piratage ?
Cette session est limité à l'accès internet.
Je me demande si je suis en présence d'un piratage ?
... et créer un autre utilisateur "Zorglub" auquel tu attribueras un mot de passe en évitant de lui accorder les droits d'administrateur
M
Membre supprimé 1060554
Invité
Puisqu'une bande de lascars s'est payé ci-devant ma fiole > je m'en vais te les arroser d'une rasade de rhétorique - destinée à remplir l'espace de la « page manquante »...
Salut trebor
«FileVault» a manifestement été activé dans ton macOS Sierra. En conséquence, la partition-Système se trouve entièrement chiffrée > ce qui empêche le volume Macintosh HD, verrouillé, de monter et d'être chargeable.
Dans de telles conditions, comment le Mac peut-il bien démarrer (se demande l'esprit curieux) ? - eh bien ! il démarre par la bande, càd. la partition de récupération Recovery HD. Le Programme Interne du Mac (ou EFI) lancé à la pression sur le bouton d'allumage exécute le boot_loader (démarreur) boot.efi de la Recovery HD > en lui passant des instructions spéciales le détournant de lancer le Système de secours > mais au contraire d'afficher un écran de login inaugural.
Deux affichages au moins apparaissent à cet écran :
Par conséquent, il n'y a dans cet affichage d'un écran inaugural offrant 2 logins : Admin => démarrage de l'OS vs Guest => Safari en mode Recovery rien d'un piratage accidentel - mais la situation « normale » en cas d'activation de «FileVault». Situation « normale » qui a consisté, pour les ingénieurs de la à l'époque de la création de ce dispositif inouï («Lion 10.7») > à « pirater réglementairement » le mécanisme de démarrage de la Recovery > en détournant le boot_loader boot.efi de sa fonction de démarreur du Système de secours pour l'affecter à une fonction de booter du Système de l'OS (et seulement secondairement à récupérer, pour l'invité, sa fonction de démarreur de la Recovery). Par « piratage » - j'entends : un arraisonnement logique détournant un élément de sa fonction pour l'annexer à une autre (la génération d'un « fonction vicariante » de l'organe logique).
Ce boot_loader boot.efi de la Recovery HD logiquement annexé à la fonction de booter du Système de l'OS en cas de partition chiffrée (mais, plus généralement, en cas de présence d'un format CoreStorage - condition logique spécifique de la possibilité de chiffrer une partition - sur la partition Macintosh HD) > ne peut donc plus être reconnu par le gestionnaire de démarrage de l'EFI (appelé par la touche "alt") comme l'indicateur d'un volume Recovery démarrable > ce qui fait que la partition Recovery HD ne peut plus être affichée à cet écran de choix d'un disque de démarrage. Reste comme seule option pour démarrer en mode Recovery la combinaison de touches ⌘R.
Oui mais... cette combinaison de touches spéciale va-t-elle pouvoir activer le boot_loader boot.efi de la Recovery HD "comme si rien ne s'était passé", càd. comme s'il était toujours le boot.efi franc du collier en charge de démarrer le Système de secours, alors même qu'il a été « logiquement piraté » pour devenir le booter du Système de l'OS blindé par une architecture CoreStorage ? Eh bien non ! Car la commande ⌘R ne démarre jamais le boot_loader boot.efi original (détourné logiquement de sa fonction) > mais déclenche un processus encore plus contourné : la création en RAM d'un RAMDisk, montant un volume Untitled dans lequel les composants du Système Recovery se trouvent clonés à la volée (de la même manière que s'il s'agissait d'un démarrage par internet) > suite à quoi le clone en RAM du Système Recovery va être démarré par le clone de son boot_loader boot.efi entièrement dédié, lui, à cette fonction.
Ce qui me fascine dans le processus de génération de ce dispositif d'ensemble sans équivalent en informatique > c'est son caractère opiniâtre de « fuite en avant logique »... La seule façon d'arrêter ces montages de montages logiques à l'échelle d'un Mac particulier : c'est de désactiver «FileVaut» - ce qui déconstruit le dispositif CoreStorage impliqué sur la partition-Système Macintosh HD.
Je dis : la rose page et voici que se lève
l'absente de tous lesbouquets livres
l'absente de tous les
Salut trebor
«FileVault» a manifestement été activé dans ton macOS Sierra. En conséquence, la partition-Système se trouve entièrement chiffrée > ce qui empêche le volume Macintosh HD, verrouillé, de monter et d'être chargeable.
Dans de telles conditions, comment le Mac peut-il bien démarrer (se demande l'esprit curieux) ? - eh bien ! il démarre par la bande, càd. la partition de récupération Recovery HD. Le Programme Interne du Mac (ou EFI) lancé à la pression sur le bouton d'allumage exécute le boot_loader (démarreur) boot.efi de la Recovery HD > en lui passant des instructions spéciales le détournant de lancer le Système de secours > mais au contraire d'afficher un écran de login inaugural.
Deux affichages au moins apparaissent à cet écran :
- l'affichage de l'utilisateur admin qui a initié l'activation de «FileVault» et, de ce fait même, a habilité son mot-de-passe d'ouverture de session à servir de mot-de-passe de déverrouillage du Volume Logique de la partition chiffrée. S'il y a plusieurs autres utilisateurs dans l'OS > le même admin a pu activer également ces autres utiisateurs, càd. habiliter leurs mots-de-passe de session à pouvoir jouer le même rôle de déverrouillage inaugural du Volume Logique (mais, comme le renseignement de ces mots-de-passe est requis lors de cette activation > il a dû alors leur demander de les saisir confidentiellement chacun le sien).
Le mot-de-passe de session de l'utilisateur « activé » (à la capacité de déverrouiller le volume de la partition chiffrée) joue donc un double rôle : déverrouiller inauguralement le volume-Système de manière à permettre son remontage et par suite le chargement de l'OS > authentifier l'utilisateur afin d'ouvrir la session correspondante. Normalement, donc : le volume déverrouillé par le mot-de-passe de l'utilisateur > l'OS se charge > et à la fin la session s'ouvre "automatiquement" sans demande redondante de saisie du mot-de-passe qui serait le même que celui de départ.
Mais si jamais l'utilisateur en venait à changer son mot-de-passe de session (sans répercuter cette modification pour «FileVault») alors le mot-de-passe de déverrouillage inaugural du Volume Logique resterait l'ancien mot-de-passe > et ce dernier ne pouvant plus opérer l'authentification requise à l'ouverture de la session > un 2è écran de login s'afficherait à la fin du chargement de l'OS, exactement comme lorsque la partition-Système n'est pas chiffrée, afin que l'utilisateur puisse se logger dans sa session.
- l'affichage d'un utilisateur invité (Guest) lequel en tant qu'invité ne dispose d'aucun mot-de-passe préétabli pour ouvrir une session. Ledit invité ne pouvant donc en aucune façon, sorte, espèce ni manière déverrouiller le Volume Logique Macintosh HD de l'OS > que peut-il donc bien faire ? - eh bien ! tout ce qu'il peut faire, c'est lancer le Système de... la Recovery. On a donc affaire ici à un aiguillage logique, où le même boot_loader boot.efi de la Recovery HD - principalement assume la fonction de booter du Système de l'OS pour l'utilisateur habilité (admin) & secondairement assume la fonction de démarreur du Système de secours pour l'utilisateur invité (guest). L'esprit épris de minutie notera que cet aiguillage logique inverse exactement les priorités classiques, en ce que le boot_loader boot.efi n'assume plus son rôle de démarreur du Système de secours qu'en tant qu'option dérivée (pour l'invité) et prend comme fonction réglementaire (booter le Système de l'OS) une autre que sa fonction naturelle (booter la Recovery).
Cet invité qui peut donc lancer le Système Recovery avec le boot_loader de la Recovery > il ne peut nonobstant ouvrir dans ce Système qu'une session réduite à la portion congrue par rapport à la session standard d'un utilisateur de la Recovery : il ne possède à sa disposition qu'une et une seule application : «Safari» avec laquelle il peut se ballader sur le Net, au lieu de disposer de la fenêtre des 4 Utilitaires OS X plus les applications du menu Utilitaires en cas de session standard.
Le mot-de-passe de session de l'utilisateur « activé » (à la capacité de déverrouiller le volume de la partition chiffrée) joue donc un double rôle : déverrouiller inauguralement le volume-Système de manière à permettre son remontage et par suite le chargement de l'OS > authentifier l'utilisateur afin d'ouvrir la session correspondante. Normalement, donc : le volume déverrouillé par le mot-de-passe de l'utilisateur > l'OS se charge > et à la fin la session s'ouvre "automatiquement" sans demande redondante de saisie du mot-de-passe qui serait le même que celui de départ.
Mais si jamais l'utilisateur en venait à changer son mot-de-passe de session (sans répercuter cette modification pour «FileVault») alors le mot-de-passe de déverrouillage inaugural du Volume Logique resterait l'ancien mot-de-passe > et ce dernier ne pouvant plus opérer l'authentification requise à l'ouverture de la session > un 2è écran de login s'afficherait à la fin du chargement de l'OS, exactement comme lorsque la partition-Système n'est pas chiffrée, afin que l'utilisateur puisse se logger dans sa session.
----------
- l'affichage d'un utilisateur invité (Guest) lequel en tant qu'invité ne dispose d'aucun mot-de-passe préétabli pour ouvrir une session. Ledit invité ne pouvant donc en aucune façon, sorte, espèce ni manière déverrouiller le Volume Logique Macintosh HD de l'OS > que peut-il donc bien faire ? - eh bien ! tout ce qu'il peut faire, c'est lancer le Système de... la Recovery. On a donc affaire ici à un aiguillage logique, où le même boot_loader boot.efi de la Recovery HD - principalement assume la fonction de booter du Système de l'OS pour l'utilisateur habilité (admin) & secondairement assume la fonction de démarreur du Système de secours pour l'utilisateur invité (guest). L'esprit épris de minutie notera que cet aiguillage logique inverse exactement les priorités classiques, en ce que le boot_loader boot.efi n'assume plus son rôle de démarreur du Système de secours qu'en tant qu'option dérivée (pour l'invité) et prend comme fonction réglementaire (booter le Système de l'OS) une autre que sa fonction naturelle (booter la Recovery).
Cet invité qui peut donc lancer le Système Recovery avec le boot_loader de la Recovery > il ne peut nonobstant ouvrir dans ce Système qu'une session réduite à la portion congrue par rapport à la session standard d'un utilisateur de la Recovery : il ne possède à sa disposition qu'une et une seule application : «Safari» avec laquelle il peut se ballader sur le Net, au lieu de disposer de la fenêtre des 4 Utilitaires OS X plus les applications du menu Utilitaires en cas de session standard.
----------
Par conséquent, il n'y a dans cet affichage d'un écran inaugural offrant 2 logins : Admin => démarrage de l'OS vs Guest => Safari en mode Recovery rien d'un piratage accidentel - mais la situation « normale » en cas d'activation de «FileVault». Situation « normale » qui a consisté, pour les ingénieurs de la à l'époque de la création de ce dispositif inouï («Lion 10.7») > à « pirater réglementairement » le mécanisme de démarrage de la Recovery > en détournant le boot_loader boot.efi de sa fonction de démarreur du Système de secours pour l'affecter à une fonction de booter du Système de l'OS (et seulement secondairement à récupérer, pour l'invité, sa fonction de démarreur de la Recovery). Par « piratage » - j'entends : un arraisonnement logique détournant un élément de sa fonction pour l'annexer à une autre (la génération d'un « fonction vicariante » de l'organe logique).
Ce boot_loader boot.efi de la Recovery HD logiquement annexé à la fonction de booter du Système de l'OS en cas de partition chiffrée (mais, plus généralement, en cas de présence d'un format CoreStorage - condition logique spécifique de la possibilité de chiffrer une partition - sur la partition Macintosh HD) > ne peut donc plus être reconnu par le gestionnaire de démarrage de l'EFI (appelé par la touche "alt") comme l'indicateur d'un volume Recovery démarrable > ce qui fait que la partition Recovery HD ne peut plus être affichée à cet écran de choix d'un disque de démarrage. Reste comme seule option pour démarrer en mode Recovery la combinaison de touches ⌘R.
Oui mais... cette combinaison de touches spéciale va-t-elle pouvoir activer le boot_loader boot.efi de la Recovery HD "comme si rien ne s'était passé", càd. comme s'il était toujours le boot.efi franc du collier en charge de démarrer le Système de secours, alors même qu'il a été « logiquement piraté » pour devenir le booter du Système de l'OS blindé par une architecture CoreStorage ? Eh bien non ! Car la commande ⌘R ne démarre jamais le boot_loader boot.efi original (détourné logiquement de sa fonction) > mais déclenche un processus encore plus contourné : la création en RAM d'un RAMDisk, montant un volume Untitled dans lequel les composants du Système Recovery se trouvent clonés à la volée (de la même manière que s'il s'agissait d'un démarrage par internet) > suite à quoi le clone en RAM du Système Recovery va être démarré par le clone de son boot_loader boot.efi entièrement dédié, lui, à cette fonction.
Ce qui me fascine dans le processus de génération de ce dispositif d'ensemble sans équivalent en informatique > c'est son caractère opiniâtre de « fuite en avant logique »... La seule façon d'arrêter ces montages de montages logiques à l'échelle d'un Mac particulier : c'est de désactiver «FileVaut» - ce qui déconstruit le dispositif CoreStorage impliqué sur la partition-Système Macintosh HD.
Dernière édition par un modérateur:
Je l'achète si la langue est en gascon-informatique; deviendra sûrement une espèce d'incunable dans 1500 ans.
Fi diable un livre? Que nenni, une encyclopédie en XXX volumes.
On consultera alors le macO'Universalis.
Fi diable un livre? Que nenni, une encyclopédie en XXX volumes.
On consultera alors le macO'Universalis.
Dernière édition:
Pour ma part plantage à répétition :
Aucunes (oui oui aucunes) applications ne se lancent : Rebondis dans le dock, obligé de forcer l'arrêt et quand je relance, elles se lancent... Retour en arrière via trackpad fait planté safari. Impossible de changer de mois dans iCal. Bref gros gros plantage, Onyx n'y fait rien : Retour en 10.12.
Aucunes (oui oui aucunes) applications ne se lancent : Rebondis dans le dock, obligé de forcer l'arrêt et quand je relance, elles se lancent... Retour en arrière via trackpad fait planté safari. Impossible de changer de mois dans iCal. Bref gros gros plantage, Onyx n'y fait rien : Retour en 10.12.
