Catalina va créer un volume système en lecture seule, Réactions à la publication du 07/06/2019

[ekami]

C'est bien gentil de vouloir faire progresser la sécurité de macOS, mais ce qui est absolument consternant c'est qu'Apple ne fournisse aucun outil pour réaliser des clonages du disque interne.
Je ne parle pas de la fonction "Restaurer" qui efface le disque de destination et recopie l'intégralité du disque source (non testé sous Catalina, et sera-ce encore possible, mystère…) , mais d'une appli capable de réaliser des clonages et "pilotable" via AppleScript pour pouvoir lancer des clonages à heures.
Peut-être est-ce déjà possible sous Catalina via des commandes shell, mais ça ne semble pas être le cas puisque le développeur de l'application (la seule ?) Carbon Copy Cloner dit que ça va lui prendre des mois pour tenter d'y arriver.

[malloc]

Si mes réactions sont de moins en moins flateuses envers Apple depuis ces dernières années, c'est parce que les prix demandés sont de moins en moins justifiés. Et si le volume Read-only c’est juste pour plaire aux actionnaires, je regrette mais c'est du foutage de gueule pour eux et surtout les clients.

En plus de ne pas comprendre le second degré, en v'la un qui qui fait bien la part des choses, tiens... On parle filesystem il répond "politique tarifaire".
Ce serait pas plus simple de poster simplement #timcookrendlargent sous chaque news? Tu économiserais les touches de ton fragile clavier apple (à l'obsolescence programmée pour les actionnaires).

Ce message a été modifié par malloc - 8 Jun 2019, 12:49.

[radioman]

(Ou bien peut on formater un HDD en APFS)?

oui:



Ce message a été modifié par radioman - 8 Jun 2019, 12:57.

[vlady]

C'est bien gentil de vouloir faire progresser la sécurité de macOS, mais ce qui est absolument consternant c'est qu'Apple ne fournisse aucun outil pour réaliser des clonages du disque interne.
Je ne parle pas de la fonction "Restaurer" qui efface le disque de destination et recopie l'intégralité du disque source (non testé sous Catalina, et sera-ce encore possible, mystère…) , mais d'une appli capable de réaliser des clonages et "pilotable" via AppleScript pour pouvoir lancer des clonages à heures.
Peut-être est-ce déjà possible sous Catalina via des commandes shell, mais ça ne semble pas être le cas puisque le développeur de l'application (la seule ?) Carbon Copy Cloner dit que ça va lui prendre des mois pour tenter d'y arriver.

Déjà tu peux faire un clonage avec CCC (ligne de commande compris). Ensuite si ton target volume (pour la sauvegarde) est APFS tu peut utiliser Recovery pour copier le clone sur ton système (j'ai lu ça quelque part sur le site de CCC). Mais, peut être, le backup "multi-volume" (système + données modifiables visibles comme une seule unité) qui peut poser problème...

Ce message a été modifié par vlady - 8 Jun 2019, 13:47.

[ekami]

C'est bien gentil de vouloir faire progresser la sécurité de macOS, mais ce qui est absolument consternant c'est qu'Apple ne fournisse aucun outil pour réaliser des clonages du disque interne.
Je ne parle pas de la fonction "Restaurer" qui efface le disque de destination et recopie l'intégralité du disque source (non testé sous Catalina, et sera-ce encore possible, mystère…) , mais d'une appli capable de réaliser des clonages et "pilotable" via AppleScript pour pouvoir lancer des clonages à heures.
Peut-être est-ce déjà possible sous Catalina via des commandes shell, mais ça ne semble pas être le cas puisque le développeur de l'application (la seule ?) Carbon Copy Cloner dit que ça va lui prendre des mois pour tenter d'y arriver.

Déjà tu peux faire un clonage avec CCC (ligne de commande compris). Ensuite si ton target volume (pour la sauvegarde) est APFS tu peut utiliser Recovery pour copier le clone sur ton système (j'ai lu ça quelque part sur le site de CCC). Mais, peut être, le backup "multi-volume" (système + données modifiables visibles comme une seule unité) qui peut poser problème...

Merci Vlady, mais ta solution exige les manips.
Je parle de la possibilité de réaliser des clonages à heures fixes entièrement automatisés (quel que soit l'outil utilisé) "sans les mains", dans le cadre de sauvegardes mixtes (Time Machine et Clonage) pour avoir la possibilité de redémarrer depuis un clone en cas de crash du disque (ou du mac) principal.

[Hebus]

C'est bien gentil de vouloir faire progresser la sécurité de macOS, mais ce qui est absolument consternant c'est qu'Apple ne fournisse aucun outil pour réaliser des clonages du disque interne.
Je ne parle pas de la fonction "Restaurer" qui efface le disque de destination et recopie l'intégralité du disque source (non testé sous Catalina, et sera-ce encore possible, mystère…) , mais d'une appli capable de réaliser des clonages et "pilotable" via AppleScript pour pouvoir lancer des clonages à heures.
Peut-être est-ce déjà possible sous Catalina via des commandes shell, mais ça ne semble pas être le cas puisque le développeur de l'application (la seule ?) Carbon Copy Cloner dit que ça va lui prendre des mois pour tenter d'y arriver.

Déjà tu peux faire un clonage avec CCC (ligne de commande compris). Ensuite si ton target volume (pour la sauvegarde) est APFS tu peut utiliser Recovery pour copier le clone sur ton système (j'ai lu ça quelque part sur le site de CCC). Mais, peut être, le backup "multi-volume" (système + données modifiables visibles comme une seule unité) qui peut poser problème...

Merci Vlady, mais ta solution exige les manips.
Je parle de la possibilité de réaliser des clonages à heures fixes entièrement automatisés (quel que soit l'outil utilisé) "sans les mains", dans le cadre de sauvegardes mixtes (Time Machine et Clonage) pour avoir la possibilité de redémarrer depuis un clone en cas de crash du disque (ou du mac) principal.

CCC fait ça, je m’en suis déjà servi à certains moments. Avec plein d’options en prime. Tu planifies avec l’interface.

[vlady]

C'est bien gentil de vouloir faire progresser la sécurité de macOS, mais ce qui est absolument consternant c'est qu'Apple ne fournisse aucun outil pour réaliser des clonages du disque interne.
Je ne parle pas de la fonction "Restaurer" qui efface le disque de destination et recopie l'intégralité du disque source (non testé sous Catalina, et sera-ce encore possible, mystère…) , mais d'une appli capable de réaliser des clonages et "pilotable" via AppleScript pour pouvoir lancer des clonages à heures.
Peut-être est-ce déjà possible sous Catalina via des commandes shell, mais ça ne semble pas être le cas puisque le développeur de l'application (la seule ?) Carbon Copy Cloner dit que ça va lui prendre des mois pour tenter d'y arriver.

Déjà tu peux faire un clonage avec CCC (ligne de commande compris). Ensuite si ton target volume (pour la sauvegarde) est APFS tu peut utiliser Recovery pour copier le clone sur ton système (j'ai lu ça quelque part sur le site de CCC). Mais, peut être, le backup "multi-volume" (système + données modifiables visibles comme une seule unité) qui peut poser problème...

Merci Vlady, mais ta solution exige les manips.
Je parle de la possibilité de réaliser des clonages à heures fixes entièrement automatisés (quel que soit l'outil utilisé) "sans les mains", dans le cadre de sauvegardes mixtes (Time Machine et Clonage) pour avoir la possibilité de redémarrer depuis un clone en cas de crash du disque (ou du mac) principal.

CCC fait ça, je m’en suis déjà servi à certains moments. Avec plein d’options en prime. Tu planifies avec l’interface.

Exact ! Et surtout tu peux booter sur un disque de sauvegarde sans souci. Ce que j'ai fais quand le SSD interne de mon tash can était inutilisable, instantanément j'ai rebooté sur le SSD externe (de sauvegarde).

Ce message a été modifié par vlady - 8 Jun 2019, 16:10.

[Cekter]

Non mais critiquer Apple quand elle le mérite c’est très bien et il faut le faire. Mais critiquer pour critiquer c’est un peu absurde non ?

Clairement le fait de séparer les 2 volumes est une très bonne chose et n’a rien à voir avec « faire plaisir aux actionnaires » (qu’est ce que ça peut leur faire à eux...). Apple est toujours pertinente quand elle s’inspire de Linux tout en enlevant les lourdeurs. Autant le reconnaitre quand ça va dans le bon sens.

[ekami]

C'est bien gentil de vouloir faire progresser la sécurité de macOS, mais ce qui est absolument consternant c'est qu'Apple ne fournisse aucun outil pour réaliser des clonages du disque interne.
Je ne parle pas de la fonction "Restaurer" qui efface le disque de destination et recopie l'intégralité du disque source (non testé sous Catalina, et sera-ce encore possible, mystère…) , mais d'une appli capable de réaliser des clonages et "pilotable" via AppleScript pour pouvoir lancer des clonages à heures.
Peut-être est-ce déjà possible sous Catalina via des commandes shell, mais ça ne semble pas être le cas puisque le développeur de l'application (la seule ?) Carbon Copy Cloner dit que ça va lui prendre des mois pour tenter d'y arriver.

Déjà tu peux faire un clonage avec CCC (ligne de commande compris). Ensuite si ton target volume (pour la sauvegarde) est APFS tu peut utiliser Recovery pour copier le clone sur ton système (j'ai lu ça quelque part sur le site de CCC). Mais, peut être, le backup "multi-volume" (système + données modifiables visibles comme une seule unité) qui peut poser problème...

Merci Vlady, mais ta solution exige les manips.
Je parle de la possibilité de réaliser des clonages à heures fixes entièrement automatisés (quel que soit l'outil utilisé) "sans les mains", dans le cadre de sauvegardes mixtes (Time Machine et Clonage) pour avoir la possibilité de redémarrer depuis un clone en cas de crash du disque (ou du mac) principal.

CCC fait ça, je m’en suis déjà servi à certains moments. Avec plein d’options en prime. Tu planifies avec l’interface.

Exact ! Et surtout tu peux booter sur un disque de sauvegarde sans souci. Ce que j'ai fais quand le SSD interne de mon tash can était inutilisable, instantanément j'ai rebooté sur le SSD externe (de sauvegarde).

Je sais tout ça, je m'en sers déjà.
Mais imaginons que le développeur de CCC n'arrive pas à gérer les clonages des disques "APFS dual volumes" de Catalina et jette l'éponge…
D'où ma question: Apple a t'elle fait évoluer le binaire système diskutil avec Catalina pour éventuellement pouvoir faire des clonages via des shell scripts ?
Si qqun sait, je suis preneur !

[vlady]

Non mais critiquer Apple quand elle le mérite c’est très bien et il faut le faire. Mais critiquer pour critiquer c’est un peu absurde non ?

Clairement le fait de séparer les 2 volumes est une très bonne chose et n’a rien à voir avec « faire plaisir aux actionnaires » (qu’est ce que ça peut leur faire à eux...). Apple est toujours pertinente quand elle s’inspire de Linux tout en enlevant les lourdeurs. Autant le reconnaitre quand ça va dans le bon sens.

N'exécute jamais là où t'écris, n'écrit jamais là où t'exécute !!!

C'est bien gentil de vouloir faire progresser la sécurité de macOS, mais ce qui est absolument consternant c'est qu'Apple ne fournisse aucun outil pour réaliser des clonages du disque interne.
Je ne parle pas de la fonction "Restaurer" qui efface le disque de destination et recopie l'intégralité du disque source (non testé sous Catalina, et sera-ce encore possible, mystère…) , mais d'une appli capable de réaliser des clonages et "pilotable" via AppleScript pour pouvoir lancer des clonages à heures.
Peut-être est-ce déjà possible sous Catalina via des commandes shell, mais ça ne semble pas être le cas puisque le développeur de l'application (la seule ?) Carbon Copy Cloner dit que ça va lui prendre des mois pour tenter d'y arriver.

Déjà tu peux faire un clonage avec CCC (ligne de commande compris). Ensuite si ton target volume (pour la sauvegarde) est APFS tu peut utiliser Recovery pour copier le clone sur ton système (j'ai lu ça quelque part sur le site de CCC). Mais, peut être, le backup "multi-volume" (système + données modifiables visibles comme une seule unité) qui peut poser problème...

Merci Vlady, mais ta solution exige les manips.
Je parle de la possibilité de réaliser des clonages à heures fixes entièrement automatisés (quel que soit l'outil utilisé) "sans les mains", dans le cadre de sauvegardes mixtes (Time Machine et Clonage) pour avoir la possibilité de redémarrer depuis un clone en cas de crash du disque (ou du mac) principal.

CCC fait ça, je m’en suis déjà servi à certains moments. Avec plein d’options en prime. Tu planifies avec l’interface.

Exact ! Et surtout tu peux booter sur un disque de sauvegarde sans souci. Ce que j'ai fais quand le SSD interne de mon tash can était inutilisable, instantanément j'ai rebooté sur le SSD externe (de sauvegarde).

Je sais tout ça, je m'en sers déjà.
Mais imaginons que le développeur de CCC n'arrive pas à gérer les clonages des disques "APFS dual volumes" de Catalina et jette l'éponge…
D'où ma question: Apple a t'elle fait évoluer le binaire système diskutil avec Catalina pour éventuellement pouvoir faire des clonages via des shell scripts ?
Si qqun sait, je suis preneur !

Je n'y vois pas de difficulté insurmontable. CCC peut recréer la même structure sur le disque de sauvegarde. Ensuite le clonage nécessite l'accès "read only" pour le disque source, pas de soucis. Ensuite, quand on restaure, le disque cible (interne) est "froid" (non-booté) on peut y écraser tout ce qu'on veut. Le seule problème que je vois la dedans c'est le T2 avec son micro-usine-à-gaz embarquée (appelé bridgeOS aussi). Pour moi, il est encore trop tôt pour s'enflammer, on verra après la sortie officielle de Catalina et CCC compatible (ou pas).

Ce message a été modifié par vlady - 8 Jun 2019, 18:25.

[Hebus]

Je pense que pour Bombich software le challenge a été bien plus important au passage APFS, je viens d'essayer la derniere pre-release, ils indiquent une version mi juin pour la résolution du backup de Catalina ... don't worry , be happy

Ce message a été modifié par Hebus - 8 Jun 2019, 19:00.

[vlady]

Je pense que pour Bombich software le challenge a été bien plus important au passage APFS, je viens d'essayer la derniere pre-release, ils indiquent une version mi juin pour la résolution du backup de Catalina ... don't worry , be happy

Du coup, pas la peine de sauvegarder l'OS en entier, on sauvegarde juste la partie "writable" ? En cas de catastrophe, on re-installe l'OS et on écrabouille la partie "writable"...

[DefKing]

L'étape suivante, l'OS dans une puce dédiée et mise à jour non plus par lui-même, mais par un successeur de la puce T2.

C'était pas comme ça dans les premiers Macintoshs? Il me semble que la puce contenait la base du système ?

Faudra bien, un jour où l'autre, ne serait-ce que pour une mise à jour du système, le réécrire dans notre Mac. Par quel miracle Apple serait le seul à pouvoir faire ça sur notre disque dur? Quelqu'un trouvera bien un moyen d'en faire autant.

Ce message a été modifié par DefKing - 9 Jun 2019, 10:19.

[ekami]

L'étape suivante, l'OS dans une puce dédiée et mise à jour non plus par lui-même, mais par un successeur de la puce T2.

C'était pas comme ça dans les premiers Macintoshs? Il me semble que la puce contenait la base du système ?
Faudra bien, un jour où l'autre, ne serait-ce que pour une mise à jour du système, le réécrire dans notre Mac. Par quel miracle Apple serait le seul à pouvoir faire ça sur notre disque dur? Quelqu'un trouvera bien un moyen d'en faire autant.

Sur les premiers Macs, "La boîte à outils Macintosh" était est un ensemble de ressources, pilotes, routines et interfaces de programmation contenu dans la mémoire ROM et servait pour le boot (car cette ROM était plus rapide que la RAM, extrêmement chère à l'époque).
Old_World_ROM
A partir de l'iMac elle a abandonné cette approche pour celle que nous connaissons actuellement.
Mais si Apple décide un jour que l'installation de macOS ne peut se faire que depuis ses serveurs (sur les nouveaux Macs à venir donc (donc à puce T2 ou Tx), ça en serait fini de l'utilisation de macOS via une clé USB bootable. Il faudrait alors en passer par une procédure téléchargement, comme sous iOS. Aucun miracle là dessous, et personne ne pourrait "faire autrement".
Pour le moment ça ne semble pas être à l'ordre du jour dans macOS, mais quand tous les Macs seront équipés de la puce T2 (seul le MacBook actuel de 2017 n'en est pas encore équipé) pas mal de choses pourraient changer. Qui vivra verra…

[iAPX]

Je pense que pour Bombich software le challenge a été bien plus important au passage APFS, je viens d'essayer la derniere pre-release, ils indiquent une version mi juin pour la résolution du backup de Catalina ... don't worry , be happy

Du coup, pas la peine de sauvegarder l'OS en entier, on sauvegarde juste la partie "writable" ? En cas de catastrophe, on re-installe l'OS et on écrabouille la partie "writable"...

Je ne serais pas étonné que l'option soit offerte, mais par défaut CCC continuera à cloner Système+Données, permettant d'avoir un backup bootable, ce qui diminue incroyablement le downtime comparé à ce qui est "offert" avec Windows, et la raison pour laquelle j'utilise CCC en sus de TimeMachine.

CCC me permet d'avoir un backup bootable, dont de continuer à travailler immédiatement en cas de crash/vol/etc.
TimeMachine me permet d'avoir un second backup versionné, donc de pouvoir effectivement remonter le temps.

Ce message a été modifié par iAPX - 9 Jun 2019, 12:24.

[chammer]

Je ne serais pas étonné que l'option soit offerte, mais par défaut CCC continuera à cloner Système+Données, permettant d'avoir un backup bootable, ce qui diminue incroyablement le downtime comparé à ce qui est "offert" avec Windows, et la raison pour laquelle j'utilise CCC en sus de TimeMachine.

CCC me permet d'avoir un backup bootable, dont de continuer à travailler immédiatement en cas de crash/vol/etc.
TimeMachine me permet d'avoir un second backup versionné, donc de pouvoir effectivement remonter le temps.

La duplication des partitions système et données est transparente du fait des "Firmlinks".
Il est aussi facile de reproduire le schéma de partitionnement du conteneur APFS dans la sauvegarde en utilisant l'outil de mise à jour du système de fichiers.

L'Apple System Restore (ASR), avec son "stream défragmenté", est fortement recommandé au lieu des outils de copie bloc par bloc traditionnels.
L'ASR permet en effet de prendre en compte l'espace partagé, le cryptage et de ne sauvegarder qu'un delta entre les snapshots.

Cela semble donc une simple mise à jour des commandes de copie.

Mais une sauvegarde complète doit être effectivement bootable.. et idéalement sur tout autre Mac.
Par ailleurs des difficultés apparaissent quand on crée le fichier .rootro qui permet de se préparer à la lecture seule du volume système.
Tant mieux, c'est bien à cela que sert une beta.

Je suis de toute façon confiant. La transition se passera forcément mieux qu'au début de l'ère Gianpaolo/Tamura.

[Xdave]

"En réalité, le disque de démarrage que vous voyez dans le Finder est le volume système en lecture seule et ne contient aucune de vos données. Le volume "Data" est séparé et caché...."

Heu petite question, ce n'est pas plutôt l'inverse?
Quel est l'intérêt de voir un disque en lecture seul dans le Finder?

Je pige pas

Ce message a été modifié par Xdave - 9 Jun 2019, 16:43.

[Hebus]

"En réalité, le disque de démarrage que vous voyez dans le Finder est le volume système en lecture seule et ne contient aucune de vos données. Le volume "Data" est séparé et caché...."

Heu petite question, ce n'est pas plutôt l'inverse?
Quel est l'intérêt de voir un disque en lecture seul dans le Finder?

Je pige pas

Dans Disk Utility tu vois un container avec deux volumes, le système et les data.

Dans le Finder s'est unifié évidemment.

[Xdave]

"En réalité, le disque de démarrage que vous voyez dans le Finder est le volume système en lecture seule et ne contient aucune de vos données. Le volume "Data" est séparé et caché...."

Heu petite question, ce n'est pas plutôt l'inverse?
Quel est l'intérêt de voir un disque en lecture seul dans le Finder?

Je pige pas

Dans Disk Utility tu vois un container avec deux volumes, le système et les data.

Dans le Finder s'est unifié évidemment.

Oui, ça j'avais pigé mais la phrase est vraiment pas claire du tout. ça m'a confusé

[Edit]
Je viens de relire la VO et ça ne veut rien dire du tout d'un point de vue utilisateur. Si ce n'est pas le disque des Datas, qu'est-ce qu'il se passe quand on clique dessus?
On voit les Data à priori, sinon c'est complètement con.

C'est sans doute une question de terminologie. Merci de m'éclairer.

[EDit 2]
J'ai trouvé ça en faisant une petite recherche/
"That data volume is mounted as "Macintosh HD - Data" in /System/Volumes/Data. "

Ce message a été modifié par Xdave - 9 Jun 2019, 19:09.

[Hebus]

Pareil mais sans doute un problème de traduction

Selon comme on voit les choses, les deux volumes sont cachés ...

Pas de problème de traduction

In the Finder you'll only see one volume that represents your startup disk and it will appear as if everything is on that single volume. In reality, the startup disk that you see in the Finder is the read-only system volume and doesn't have any of your data on it; the "Data" volume is separate and hidden. CCC will have to find that hidden volume (don't worry, I know where to look :-) and back up its contents alongside the system volume. The current version of CCC can't do that, of course, it knows nothing about APFS volume groups. We're adding that functionality right now, though, and we'll be hard at work over the summer on some new documentation that will help explain everything that you're seeing (or not seeing!) on the newOS.

J'allais raconter une connerie, quand on fait 'df -a' on a un truc du genre :

Code

Filesystem    Mounted on
/dev/disk3s5.        /
/dev/disk3s1.       /System/Volumes/Data
/dev/disk3s4        /private/var/vm

Ce message a été modifié par Hebus - 9 Jun 2019, 19:13.

[Xdave]

Pareil mais sans doute un problème de traduction

Selon comme on voit les choses, les deux volumes sont cachés ...

Oui j'imagine bien que les deux sont masqués et qu'on "voit" un genre de lien symbolique vers ce point de montage

J'allais raconter une connerie, quand on fait 'df -a' on a un truc du genre :

Code

Filesystem      512-blocks      Used            Available      Capacity  iused       ifree                               %iused     Mounted on
/dev/disk3s5   976363488     36605144    78815600     32%       829747    9223372036853946060   0%                        /
/dev/disk3s1   976363488     825752616  78815600      92%        2167713  9223372036852608094     0%          /System/Volumes/Data
/dev/disk3s4   976363488     33554472    78815600     30%       3             9223372036854775804    0%         /private/var/vm

/ c'est le système donc?

Et c'est quoi ce /dev/disk3s4 - /private/var/vm[/code]?

[Hebus]

Pour le swap... avec des indirections tout est possible

[chammer]

Pareil mais sans doute un problème de traduction

Selon comme on voit les choses, les deux volumes sont cachés ...

Oui j'imagine bien que les deux sont masqués et qu'on "voit" un genre de lien symbolique vers ce point de montage

J'allais raconter une connerie, quand on fait 'df -a' on a un truc du genre :

Code

Filesystem      512-blocks      Used            Available      Capacity  iused       ifree                               %iused     Mounted on
/dev/disk3s5   976363488     36605144    78815600     32%       829747    9223372036853946060   0%                        /
/dev/disk3s1   976363488     825752616  78815600      92%        2167713  9223372036852608094     0%          /System/Volumes/Data
/dev/disk3s4   976363488     33554472    78815600     30%       3             9223372036854775804    0%         /private/var/vm

/ c'est le système donc?

Et c'est quoi ce /dev/disk3s4 - /private/var/vm[/code]?

Les commandes du et df n'ont pas été mises à jour depuis 15 ans.
Utilisez "diskutil ap list" pour comprendre la structure d'un ou des conteneurs APFS.

[Tom25]

Je ne vois pas trop pourquoi donner l'impression que le système et les datas (dossier utilisateurs en gros si j'ai bien compris) sont sur le même volume alors qu'ils ne le sont pas (plus).
Au contraire même, il y a un volume système avec le nom "système" et au moins si on va lire (ou écrire pour les mises à jour) on sait qu'on est au cœur, au point le plus sensible.

De toute façon, quelque soit le domaine, je ne supporte pas les écrans de fumée pour masquer la vérité sous couvert de simplicité ou de sécurité ou que sais-je encore.

[g4hd]

Depuis quelques temps, j’ai deux sessions :
- une session administrateur, vide de données utilisateur,
- ma session d’usage en mode standard…
Ça me paraît une bonne pratique contre les intrusions car les modifs qui touchent aux applis et au système sont toujours précédées d’une demande d’accès administrateur… ce qui force à la vigilance en plus de LittleSnitch.
Ce n’est sûrement pas parfait, mais mieux que laisser les portes ouvertes.
Il me semble…

[chammer]

Je ne vois pas trop pourquoi donner l'impression que le système et les datas (dossier utilisateurs en gros si j'ai bien compris) sont sur le même volume alors qu'ils ne le sont pas (plus).
Au contraire même, il y a un volume système avec le nom "système" et au moins si on va lire (ou écrire pour les mises à jour) on sait qu'on est au cœur, au point le plus sensible.

De toute façon, quelque soit le domaine, je ne supporte pas les écrans de fumée pour masquer la vérité sous couvert de simplicité ou de sécurité ou que sais-je encore.

Personne n'accepte d'être induit en erreur à cause de simplifications excessives.

Les données sont bien toutes dans le même magasin physique, c'est à dire sur la même partition du SSD.
Aucun écran de fumée.

L'organisation interne de ces données sur des volumes logiques différents n'a aucune importance au quotidien.
MacOS est un Unix. Le finder est agréable, car il ne révèle pas la complexité technique sous-jacente.
Il est heureux que des répertoires soient cachés (une vingtaine à la racine...), que les applications soient représentées par des icônes, que l'on ne se préoccupe pas des métadonnées, attributs étendus et autres. Une expérience utilisateur satisfaisante consiste à se libérer de ces rouages systèmes.

De toute façon les données sont physiquement écrites sur le SSD par un mapping de la Flash Translation Layer. Alors où sont réellement stockées nos données ?
Ce que l'on voit de nos données est *toujours* une interprétation, quel que soit le système de fichiers.

Le problème principal est que l'application "Utilitaire de disque" a été bien trop simplifiée et est devenue infantilisante.
Quand on utilise un utilitaire, même dans l'interface graphique, on doit avoir accès aux mêmes options qu'en CLI dans le terminal... sinon ça s'appelle windows.

[Sethy]

MacOS est un Unix. Le finder est agréable, car il ne révèle pas la complexité technique sous-jacente.
Il est heureux que des répertoires soient cachés (une vingtaine à la racine...), que les applications soient représentées par des icônes, que l'on ne se préoccupe pas des métadonnées, attributs étendus et autres. Une expérience utilisateur satisfaisante consiste à se libérer de ces rouages systèmes.

Je suis d'accord.

Cette séparation n'enlève absolument rien et apporte un surcroit de sécurité.

Il s'agit d'un surcroit de sécurité, pas d'une sécurité absolue mais tout est bon à prendre.

Evidemment, il convient d'être prudent. C'est une nouveauté.

[Benzebut]

Depuis quelques temps, j’ai deux sessions :
- une session administrateur, vide de données utilisateur,
- ma session d’usage en mode standard…
Ça me paraît une bonne pratique contre les intrusions car les modifs qui touchent aux applis et au système sont toujours précédées d’une demande d’accès administrateur… ce qui force à la vigilance en plus de LittleSnitch.
Ce n’est sûrement pas parfait, mais mieux que laisser les portes ouvertes.
Il me semble…

C'est une très bonne décision et la configuration que je préconise également sous macOS. Toujours avoir une session administrateur qui ne fait que de l'administration des mises à jour et des sessions utilisateurs pour le quotidien et gérer ses données personnelles.
Combien de fausses installations de Flash Player ont été contrôlées ainsi sur des machines utilisées par des utilisateurs pourtant avertis ...

[Pat94]

Si sainte pomme a dit, alors alleluia, vous ne voyez pas qu'en plus d'être infantilisé, soi-disant pour des raisons de sécurité, Apple boucle complètement son écosystème, enfin si cela vous convient bravo mais bientôt vous ne pourrez même plus installer le moindre truc qui ne sera pas adoubé par Apple.

Pour moi ce sera le signe pour quitter ce système, que j'adore mais qui à mon avis devrait rester un minimum ouvert.

Nous sommes sur MacBidouille, si plus de bidouilles ces forums n'auront plus de raison d'être.

[Hebus]

Aucun rapport avec la choucroute...

Je pense que çà va aussi grandement simplifier et rendre plus robuste les migrations des data lors d’un changement de disque ou de sauvegarde.

Ne pas oublier également le nouveau Driver Kit qui mets les extensions tierces du système dans l’espace user... pour augmenter la aussi le niveau de sécurité.

Ce message a été modifié par Hebus - 10 Jun 2019, 11:37.