Archives de catégorie : macOS

Mac M1 : le miracle premier d’Apple

Je n’ai pas voulu réagir à chaud sur le lancement des Mac M1 (on aura l’occasion d’y revenir prochainement), préférant attendre d’avoir les machines dans les mains pour en parler plus en détails.

Le processeur M1 d'Apple.

J’ai donc réussi à me procurer un MacBook Air M1 (256 Go, 8 Go de RAM, l’entrée de gamme, simple, basique) ce vendredi 20 novembre (le jour de l’anniversaire de ma fille, joyeux anniversaire ma chérie ! Et non le MBA n’est pas pour toi…), merci la Fnac, vu qu’Apple a du mal à livrer en ce moment. Rentré à la maison, déballage du Mac, démarrage…

Une boite de MacBook Air équipé de processeur M1.

Ah oui, ça démarre vite. Vraiment vite. Mais plus encore, c’est la fluidité constante de la machine qui surprend. Et évidemment, pas de chaleur, pas de bruit.

Côté performances… ça dépote.

Pour le fun, je me suis amusé à réaliser un de mes tests favoris : lancer un lot d’applications à la chaine… genre toutes les apps des dossiers Applications et Utilitaire . Les apps se lancent à une vitesse impressionnante, mais surtout, la machine reste réactive ET silencieuse. Là où le même test sur un MacBook Air de 2019 déclenche les ventilateurs en quelques secondes. Impressionnant.

Puisque je parlais de fluidité, un petit test rapide. J’ai installé Office 2019 sur ce Mac, et j’ai lancé Excel. Comme on peut le voir, côté consommation de RAM, c’est pas vraiment ça :

Capture d'écran du logiciel Moniteur d'activité sur macOS avec Excel sur processeur M1 via Rosetta.

Comme vous pouvez le constater, la consommation de RAM est très élevée, même avec un simple document Excel lancée. Rosetta 2 fonctionne très bien, mais semble gourmand en RAM : presque 1 Go direct. Ouch.

De même, côté fluidité de l’affichage, c’est pas encore ça sous Rosetta. Redimensionnez une page, et ça saccade pas mal. Mais attention : ça reste totalement, parfaitement utilisable, autant que sur un processeur Intel natif, voire meilleur ! Et rien que ça, c’est déjà très impressionnant. J’ai par exemple lancé Pixelmator sur le MacBook Air, et je me suis seulement posé la question après de savoir si j’avais une version native… et en fait, non (en fait seul Pixelmator Pro aura une version native, à priori… enfin, en dispose déjà).

Mais quand on installe la version native M1 (encore en beta) d’Excel & co, les comportements changent radicalement. La consommation de RAM devient totalement délirante : au lancement, Excel ne consomme plus que 200 Mo de RAM, voire moins (là il est à près de 110 Mo…), le système semblant beaucoup plus rapide à allouer la RAM aux apps, ou également à la récupérer.

Capture d'écran du logiciel Moniteur d'activité sur macOS avec Excel sur processeur M1 en version native.

Ces différences de comportement sur la consommation de RAM sont très intéressantes et très enthousiasmantes, et permettent de se poser la question de la pertinence de prendre des machines avec plus de mémoire vive. Pour 95% des utilisateurs, 8 Go devraient être suffisants pour les années à venir. Si vous avez cependant des doutes, prenez 16 Go, mais dites-vous juste que ça devrait être quand même OK avec 8 Go pour la plupart des cas.

Mais là encore, ce qui étonne toujours, c’est la réactivité de l’application qui impressionne, là où Excel pouvait rester lourdingue même avec un Mac récent. Là, ça reste toujours ultra fluide. Utilisez Mission Control, même avec 40 fenêtres, et l’effet reste toujours fluide là où le MBA tire la langue.

Et l’autonomie ? Là aussi, ça reste très impressionnant puisque j’utilise ce MBA depuis hier soir 21h30 environ, et je n’ai pas à chercher à le charger, et à 15 heures, il a encore 38% de batterie, alors que j’ai installé des logiciels, surfé, regardé des vidéos sur Twitch… En revanche, je pense qu’il a quand même perdu pas mal de batterie durant la nuit (environ 10% je dirais, après environ 10h de mise en veille). À vérifier. Mais dans tous les cas, je trouve la consommation très raisonnable, surtout vu les performances derrière.

Et ce n’est que le début

Je complèterai mes impressions durant les prochains jours, mais pour le moment, je suis totalement bluffé par les performances de ces nouveaux Mac, leur autonomie, et ceci même s’il s’agit finalement des mêmes machines extérieurement parlant. Et à moins de disposer d’apps très spécialisées pour lesquelles Rosetta pourrait poser problème , je vous invite à considérer sérieusement l’option M1 si vous envisagez de changer de Mac. Certes, peut-être que les premiers mois seront un peu rock’n’roll, le temps que les apps M1 débarquent en masse.

Et puis, reste évidemment les problèmes liés à l’absence de compatibilité Windows. Peut-être rédhibitoire pour certains, pas tellement pour la majorité. Là aussi, si vous devez utiliser des VM en masse, les Mac Intel restent la solution à privilégier.

Je tâcherai de revenir prochainement sur des points un peu plus techniques sur ces nouvelles machines. Mais aujourd’hui, je ne peux qu’applaudir Apple d’avoir osé faire ce pas très audacieux vers des Mac intégralement basés sur son propre silicium. Si la première génération de processeurs M1 dédiés aux Mac donne des performances aussi décoiffantes (corroborées par l’ensemble des tests que j’ai pu lire), je ne peux qu’être impatient de voir ce que ça donnera pour les futures machines professionnelles.

Comment bloquer l’installation de macOS Big Sur

Ça y est, macOS Big Sur est enfin disponible depuis jeudi 12 novembre ! Et du coup, en tant qu’administrateur système, vous êtes extrêmement pressé de voir tout votre parc adopter la nouvelle version…

Attendez, non, c’est pas ça ! Vous n’avez plutôt pas trop envie que vos utilisateurs basculent sur cette nouvelle version de macOS, parce que ça risque de vouloir dire incompatibilités en tout genre.

Faire le point sur les incompatibilités

Il faut d’abord regarder où se trouvent les éventuelles incompatibilités logicielles. En particulier :

  • Les applications encore 32-bit. Tout comme pour Catalina, celles-ci ne feront pas le saut vers macOS Big Sur.
  • Les applications reposant sur des extensions de noyau (les fameux kext). Même si macOS Big Sur ne les abat pas encore totalement (pour certaines, un redémarrage peut suffire), ces dernières n’ont pas vocation à rester et peuvent poser problème. Il faut pour certaines extensions de noyau déployer un profil pour les valider, et il faut redémarrer le poste… Pas idéal. Si l’éditeur d’un logiciel utilisant des extensions de noyau vous annonce qu’il n’est pas encore compatible pour macOS Big Sur, et qu’il ne sait pas quand ça arrivera… Il est peut-être temps de changer de crémerie.
  • Vérifiez aussi la compatibilité de vos matériels avec macOS Big Sur, en particulier vos imprimantes, traceurs… Si certains constructeurs assurent un bon suivi dans le temps, ce n’est pas toujours le cas. Donc, méfiance.
  • Certaines apps web, si vous utilisez Safari. Même si ça semble peu probable, mais si cela vous arrive, il faudra peut-être changer de navigateur.
  • Historiquement, on sait que les versions point zéro de macOS peuvent contenir des bugs parfois réhdibitoires voire critiques. Du coup, attendre la version 11.0.2 est sûrement un choix raisonnable. Et j’ai bien écrit 11.0.2 et non pas 11.0.1 puisque la version finale de macOS cette année est la 11.0.1, et non pas la 11.0 comme la tradition le veut. Bref, attendre quelques semaines n’est pas totalement déconnant.

Je ne veux pas que mes utilisateurs passent sur Big Sur, je fais quoi ?

À une époque où le modern management des ordinateurs devient une idée de plus en plus courante (accès administrateur autorisé à l’utilisateur, sous supervision du système informatique) , il est important de communiquer sur les raisons du blocage. Certains utilisateurs souhaiteront avoir accès dès que possible au dernier macOS, d’autres n’y verront aucun intérêt, mais c’est l’administrateur du parc qui doit assurer la continuité de service. Donc, si vous pouvez bloquer… bloquez.

Pour cela, il existe différentes méthodes.

Déployer un profil de configuration pour retarder les mises à jour via MDM

Si vos Mac sont intégrés dans un MDM (si ce n’est pas le cas aujourd’hui, c’est mal) ou un outil de déploiement de profil comme Munki, vous pouvez déployer un profil masquant les mises à jour pour une certaine durée. Pour cela, utilisez la clé enforcedSoftwareUpdate du payload Restrictions.

Vous pouvez créer ce profil à la main, avec un outil comme ProfileCreator ou configurer directement le réglage dans votre MDM s’il supporte ce payload, par exemple ici dans Jamf Pro :

Attention à bien choisir de retarder les mises à jour de logiciels. Il faudra macOS 10.13.4 minimum pour déployer ce profil.

Le défaut de cette méthode est qu’elle masque toutes les mises à jour, y compris d’éventuelles nouvelles mises à jour de sécurité pour l’OS actuel.

Utiliser une règle de restriction pour empêcher le lancement de l’app d’installation de macOS Big Sur

Quid des utilisateurs qui copient le logiciel d’installation de macOS Big Sur depuis un autre poste pour le lancer ? Dans ce cas, il peut être intéressant de bloquer complètement l’app d’installation de macOS Big Sur pour empêcher toute installation. Sur Jamf Pro, il suffit de bloquer le processus Install macOS Big Sur pour empêcher son lancement.

Déployer un package pour bloquer complètement macOS Big Sur

Une autre solution consiste à installer un package qui bloquera l’installation de macOS Big Sur : BigSurBlocker. Installez le package via votre outil de gestion habituel, et hop, l’utilisateur aura le droit à un petit message pour lui dire que non, nope, c’est pas pour tout de suite. La page liste également une méthode pour désinstaller BigSurBlocker proprement via un script.

Bloquer l’affichage de la mise à jour

Un point agaçant : quelque soit la solution utilisée, la mise à jour macOS Big Sur continuera d’apparaître dans la préférence Système Mise à jour de logiciels. Pour la masquer définitivement, utilisez la commande suivante (en root) :

softwareupdate --ignore "macOS Big Sur"

Cependant, cette commande ne sera efficace que si votre Mac est intégré dans un MDM. Si ce n’est pas le cas, elle ne fera absolument rien. Si votre Mac fonctionne sous mac OS Catalina, elle ne devrait être fonctionnelle que pour macOS 10.15.6 avec les dernières mises à jour de sécurité (Apple ayant apporté quelques changements pénibles sur les versions précédentes de la commande softwareupdate).

Si vous souhaitez à nouveau faire apparaître la mise à jour, envoyez la commande :

softwareupdate --reset-ignored

iCloud Photos : impossible d’activer la synchronisation sur le système de fichiers actuel

Petit problème curieux : depuis quelques jours, mon Mac refuse de synchroniser les données d’iCloud Photos. Et quand j’ouvre la préférence Système iCloud, il est impossible d’activer la synchro iCloud Photos, et j’obtiens ce message curieux :

Photos iCloud est uniquement disponible sur les volumes aux formats macOS standard, macOS étendu et APFS.

Bon. Alors autant je peux comprendre pour l’APFS ou macOS étendu, mais… macOS Standard ? Sérieusement ? On parle d’un système de fichiers qui n’est plus accessible qu’en lecture seule depuis Mac OS X 10.6 (Snow Leopard). Il y a onze ans…

Bref. Passée la surprise de ce message plutôt incongru, j’ai cherché un peu sur le web, et la solution est finalement très simple : redémarrez sur la partition Recovery (Cmd + R au démarrage), et lancez une réparation du volume APFS avec Utilitaire de disque. Redémarrez normalement, et la case devrait pouvoir être cochée sans problème (chez moi elle s’est même automatiquement cochée à nouveau).

De la taille des mises à jour de macOS et des mises à jour de macOS en général

Dans l’ensemble, j’aime toujours autant macOS depuis plus de 25 ans que je travaille sur Mac. Mais il y a une tendance sur laquelle Apple n’a pas vraiment fait d’effort depuis si longtemps : la taille des mises à jour. Et ça devient un vrai problème, à plein de niveaux, qu’Apple devrait traiter urgemment.

Des mises à jour colossales

Prenons exemple sur macOS 10.15. Nous devons aujourd’hui télécharger plus de 8 Go pour avoir un système complet à déployer sur un Mac. Mais si vous avec commencé avec macOS 10.15.0 (fous que vous êtes !), et que vous effectuez régulièrement les mises à jour système, vous aurez téléchargé :

MacOS 10.15.1 : 4,53 Go

MacOS 10.15.2 : 3,04 Go

MacOS 10.15.3 : 2,99 go

macOS 10.15.4 : 3 Go

(J’ai la flemme de mettre les liens, mais vous me croirez sur parole, hein ?)

Donc, si on résume, depuis l’arrivée de Catalina, on a du télécharger plus de 13,5 Go de mises à jour de macOS, soit une fois et demi la taille du système original. Sur seulement quatre mises à jour. C’est colossal. Et probablement inutile : Apple a-t-elle réellement besoin de mettre à jour un tiers de son système à chaque mise à jour ? Ou alors, est-ce la preuve de déficiences plus colossales dans le développement de macOS ? C’est d’autant plus surprenant que le problème, qui a existé avec iOS, a depuis été largement mis sous contrôle : même si les mises à jour restent parfois importantes, on n’en est plus au point où une mise à jour de sécurité pour résilier un certificat (soit un fichier à retirer) exige un téléchargement complet d’iOS….

Des mises à jour opaques

Mais au fait, pour corriger quoi ? Penchons-nous donc sur les notes qui accompagnent ces mises à jour. Si celles de macOS 10.15.1 sont correctes, je me dis qu’il y a des Go dépensés pour rien, quand par exemple je vois la mise à jour 10.15.3 :

La mise à jour 10.15.3 de macOS Catalina améliore la stabilité, la fiabilité et la sécurité de votre Mac. Elle est recommandée à tous les utilisateurs. 

  • Optimisation de la gestion gamma des niveaux de gris faibles sur le Pro Display XDR pour les flux opérationnels SDR lors de l’utilisation de macOS.
  • Amélioration des performances de montage vidéo multiflux pour les vidéos 4K encodées au format HEVC et H.264 sur le MacBook Pro (16 pouces, 2019).

Deux. Correctifs.

Pour 3 Go de mises à jour. Sur du matériel que vous n’avez probablement pas (parce que bon, les Mac Pro et les écrans XDR, ça ne court pas les rues).

La réalité est que cette mise à jour corrige probablement d’autres problèmes, certains pourtant jamais documentés par Apple ou déclarés comme tel par Apple, parce que j’ai du mal à croire qu’il faut 3 Go de données pour corriger deux problèmes sur du matériel hautement spécifique (et dans ce cas : pourquoi ne pas diffuser une mise à jour uniquement pour ce matériel ?).

Par exemple, le fameux bug des portails captifs dont j’ai parlé ici a été corrigé… par macOS 10.15.2 ! Pourtant, les notes de macOS 10.15.2 ne mentionnent pas de correction de ce bug. Donc, oui, cette mise à jour a un intérêt, mais Apple ne communique pas du tout dessus, ce qui est encore plus irritant.

De même, je suis ravi qu’Apple mette à jour Apple News… sauf qu’en France et dans de nombreux autres pays, on n’a pas Apple News pour raison de droits de diffusion. Donc pourquoi imposer une app et une mise à jour qu’un public très restreint peut utiliser ?

Ah mais attendez, il y a aussi des mises à jour de sécurité ! C’est vrai, et elles constituent sûrement une bonne partie du poids des mises à jour système… mais dans ce cas, pourquoi ne pas séparer les mises à jour de sécurité intégralement des mises à jour de macOS ? Apple le fait bien pour ses anciens systèmes, qui n’ont alors plus de mises à jour fonctionnelles ou de bugs logiciels, mais bien des correctifs de sécurité ?

Des patchs plus fréquents… et moins lourds ?

Le poids des mises à jour est d’autant plus énervant quand on est confronté à un vrai problème et que le correctif aurait pu être disponible bien avant, peut-être dans un patch intermédiaire bien plus léger, plutôt que de proposer une mise à jour monolithique à chaque fois.

Même s’il est clair que macOS repose sur de nombreux frameworks interdépendants, il doit être possible pour Apple de trouver moyen de mettre à jour partiellement macOS pour corriger les bugs les plus urgents ou les plus courants. Je reviens une nouvelle fois sur ce problème de portail captif : le correctif (développé à l’arrache) pèse quelques Ko, et ne requière même pas de démarrage. Pourquoi Apple ne serait pas capable de faire de même ?

Et si Apple allégeait macOS ?

Et en général, Apple pourrait de toute façon mettre un peu macOS au régime. Par exemple, en ne forçant pas le téléchargement systématique de tous les fonds d’écran, mais proposer de les récupérer uniquement à la demande, par exemple en affichant une version basse définition le temps de télécharger la version HD ou 5K, ou même en les proposant juste sur l’App Store (pourquoi pas dans une catégorie dédiée ?). Rien que ça, on économiserait entre 1 et 2 Go. Apple le fait déjà bien pour les voix de Siri…

Encore mieux : Apple pourrait proposer des patchs plus fréquents et plus légers, plutôt que des grosses mises à jour monolithiques. À quoi ça sert de faire patienter 4 mois ses clients avec un bug, qui peut être corrigé en modifiant un fichier ? Je suis sûr que certains développeurs viendront m’expliquer qu’Apple ne peut pas le faire, pour une raison technique X ou Y. Je pense pourtant que si Apple veut, Apple peut. Les obstacles techniques, ce n’est pas vraiment ce qui lui fait peur. La volonté politique, probablement plus… Microsoft a déjà choisi cette approche depuis plusieurs années, avec les Patch Tuesdays1 pour les mises à jour de sécurité. Avantage énorme de cette approche : on sait quand les patchs de sécurité tombent. De même, Apple pourrait faire en sorte que les petits patches qui ne nécessitent pas de redémarrage soient déployées silencieusement. S’il n’y a pas besoin de redémarrer, le patch peu probablement être déployé en dehors du reste. Ou au pire, juste demander une fermeture de session.

Pour la WWDC 2020, j’aimerais donc qu’Apple annonce :

  • Un OS plus léger à installer ;
  • De meilleures notes de mises à jour quand les bugs sont connus et corrigés ;
  • Des mises à jour de taille réduite, si possible découplées des mises à jour de sécurité ;
  • Oh, et j’adorerais qu’Apple remette en ligne une liste des articles de support régulièrement mise à jour, comme elle le faisait à l’époque glorieuse de la TIL FR (les vrai savent), avec un flux RSS, à l’ancienne, pour qu’on soit mis au courant des problèmes connus et des éventuelles solutions (y compris temporaires).

C’est pas forcément énorme, mais ça serait déjà bien. Les gens qui n’ont pas une fibre à domicile et les techniciens de support informatique lui diront déjà bien merci.

Oh, et moins de bugs. Quitte à ce qu’il y ait moins de fonctionnalités. Si on pouvait avoir un Snow Catalina, ça serait pas mal du tout.

  1. C’est une approche non officielle, mais elle semble quand même assez standardisée.

Comment intégrer des polices supplémentaires dans iOS

MacG a publié hier soir un article très intéressant 1 sur  les nouvelles polices intégrées dans les documents Pages, Numbers et Keynote. L’article note qu’il n’y a pas d’équivalent au Livre des polices et du coup semble impliquer qu’il est impossible d’ajouter des polices sur iOS. Et pourtant, c’est tout à fait possible, même sans Livre de polices ! Ce n’est pas cependant pas totalement évident (euphémisme), car il faut les importer à l’aide d’un profil de configuration.

Première étape : installer Apple Configurator

Pour ajouter des polices, vous pouvez utiliser une application Apple gratuite à installer sur macOS : Apple Configurator 2, un outil utilisé en général pour gérer le déploiement en masse d’appareils. Mais il permet aussi de créer des profils de configuration pour forcer certains réglages sur des appareils iOS 2

Installez donc Apple Configurator 2, lancez-le, puis cliquez sur le menu Fichier > Nouveau profil.

Apple Configurator 1

Tapez un nom pour votre fichier de configuration. Vous pouvez aussi rajouter d’autres informations, comme une description du profil. Il n’est normalement pas nécessaire de changer l’identifiant unique.

Apple Configurator 4

Dans la colonne de gauche, cliquez ensuite sur Polices, et cliquez sur le bouton Configurer.

Apple Configurator 2

Sélectionnez maintenant une police à ajouter. Attention : seules les polices OpenType (.otf)  ou Truetype (.ttf) seront prises en charge. Pas de police PostScript !

Apple Configurator 3

Si vous souhaitez ajouter d’autres polices, cliquez sur le bouton + en haut à droite.

Enregistrez maintenant votre profil (menu Fichier > Enregistrer) sous le nom de votre choix. Notez que le fichier généré est un profil de configuration avec l’extension .mobileconfig.

Deuxième étape : transférer le profil sur votre appareil iOS

La deuxième étape consiste donc à envoyer le fichier .mobileconfig vers votre iPhone, iPad ou iPod Touch3. Une des méthodes les plus simples : passer par AirDrop (mais vous pouvez aussi envoyer le fichier par mail, ou le mettre à dispo en téléchargement). 

Apple Configurator 5

Côté iPhone, ça donne quoi ? Si vos appareils sont reliés via iCloud, le profil sera directement accepté. 

IMG 7307

Ouvrez l’app Réglages, et cliquez sur Profils téléchargés.

Transferrt Polices 2

Cliquez maintenant sur Installer… 

Transferrt Polices 3

Tapez ensuite votre code de sécurité…

Transferrt Polices 4

Puis cliquez sur Installer, et encore Installer.

Transferrt Polices 5

Transferrt Polices 6

Et voilà ! Cliquez sur OK

Transferrt Polices 7

VOILÀ. Votre profil est bien installé, et il contient la ou les polices sélectionnées.

Transferrt Polices 8

Et maintenant, si vous ouvrez Pages ou n’importe quelle autre app, vous pouvez sélectionner votre police !

Transfert Polices Pages

 

Mais quid des nouvelles polices de Pages & co ?

Les nouvelles polices intégrées pourraient être intégrées… si on pouvait les exposer depuis le Livre des polices de macOS ! Ce n’est cependant pas le cas : on peut juste exporter la collection de polices (au format .ttc), mais celle-ci ne peut pas être intégrée dans le profil. Apple a sûrement voulu restreindre l’usage de ces polices pour des raisons de licence. Dommage… mais ça n’empêche pas la manipulation ci-dessus à vous aider à rapatrier quelques-unes de vos polices préférées sur vos iDevices (dans le respect de leur licence d’utilisation, bien entendu).

  1. Comme très souvent, je vous invite d’ailleurs à vous abonner au Club MacG !)
  2. Et aussi macOS, mais ce n’est pas le sujet aujourd’hui.
  3. mais oui, n’oublions pas les iPod touch !

Installer Windows 10 avec Boot Camp sur macOS 10.13

Pour diverses raisons, j’ai décidé de réinstaller macOS et Windows sur mon Mac Pro 2013 il y a quelques jours. Et comme j’avais pas trop envie de casser certains outils que j’utilise, j’ai décidé de rester sur macOS 10.13 High Sierra (en partie parce que j’utilise une vieille version de GarageBand pour monter mes podcasts, comme Plombiers et Champignons).

Après réinstallation de macOS 10.13, j’ai donc tenté de réinstaller Windows 10.

Spoiler alert : ça n’a pas été fun.

Sur ce modèle de Mac (et pour d’autres d’ailleurs), il faut savoir que l’installation se fait en deux étapes :

  • Choisir la taille de la partition Windows ;
  • Télécharger les pilotes Boot Camp.

Mais après le téléchargement, j’ai eu droit à ce charmant message :

Échec de l’installation de Boot Camp. Une erreur s’est produite lors de la copie des fichiers d’installation de Windows.

BootCamp Erreur

Après plusieurs tentatives infructueuses, j’ai trouvé la solution sur cette vidéo. En résumé, le problème vient d’un détail idiot : le logiciel d’installation de Windows 10 contient un fichier qui pèse plus de 4 Go. Or, la partition temporaire OSXRESERVED créée par Boot Camp pour installer Windows est formatée en FAT-32… qui ne supporte pas de fichier de plus de 4 Go. Ballot.

La solution :

  1. Avec Utilitaire de disque, reformatez la partition OSXRESERVED au format ExFAT. Ce format est rapide et gère très bien les fichiers de plus de 4 Go.
  2. Ouvrez le fichier ISO de Windows 10, et copiez son contenu dans la partition OSXRESERVED.
  3. Relancez l’Assistant Boot Camp.
  4. Dans le menu Actions, cliquez sur Télécharger le logiciel de prise en charge de Windows.
  5. Copiez les fichiers téléchargés du logiciel de Boot Camp…

Sauf que là… ça coince à nouveau. La taille des fichiers Windows 10 + fichiers Boot Camp est trop importante pour la partition de 8 Go ! À 200 Mo près.

Solution dans la solution : dégager les fichiers d’installation des pilotes nVidia, vu que de toute façon ce Mac n’a qu’une carte AMD (enfin deux, pour ce modèle).

  1. Ouvrez le dossier WindowsSupport tout juste téléchargé ;
  2. Copiez les fichiers $WinPEDriver$ et AutoUnattend.xml
  3. Créez un dossier BootCamp.
  4. Copiez les fichiers Setup.exe et BootCamp.xml du dossier WindowsSupport.
  5. Créez un dossier Drivers.
  6. Copiez dans ce dossier tous les dossiers du dossier Drivers dans WindowsSupport SAUF le dossier nVidia.
  7. Ouvrez le fichier BootCamp.xml avec un éditeur de texte.
  8. Supprimez tous les paragraphes (tout ce qui se trouve entre les balises <name>…</name>) qui comprennent le mot nVidia. Par exemple, si vous trouvez :
<Name>NVIDIA System Driver
 <InfName>nvsmbus.inf</InfName>
 <Class> System</Class>
 <ClassGUID> {4D36E97D-E325-11CE-BFC1-08002BE10318}</ClassGUID>
 <CatalogFile> nvsmb.cat</CatalogFile>
 <Provider>NVIDIA</Provider>
 <DriverVer> 03/22/2010, 4.7.9</DriverVer>
 <ServiceBinary></ServiceBinary>
 <HardwareID></HardwareID>
 <isX64>no</isX64>
 </Name>

Supprimez tout ce paragraphe.

Enregistrez le fichier, et redémarrez sur l’installation de Windows en enfonçant la touche Option au démarrage et en choisissant la partition d’installation Windows.

Pfiouuuuuuu ! Tout ça pour ça.

Quand Dropbox rame vraiment, vraiment trop

J’ai constaté depuis quelques semaines que Dropbox sur mon Mac consommait toujours 100% d’un CPU, même sans rien faire. Ce qui est assez irritant : nos ordis chauffent déjà assez sans se taper en plus d’avoir un processeur occupé par un logiciel qui ne fout rien.

Après avoir essayé un paquet de solutions tirées de cet article de Dropbox, j’ai constaté que les lenteurs étaient aussi dans l’interface même de Dropbox : cliquer par exemple sur l’icône Dropbox ne faisait apparaitre le menu qu’après un petit délai, et l’ouverture des préférences était affreusement lente, en particulier l’accès aux notifications. Décocher une case de cet onglet pouvait prendre entre cinq et dix secondes ! Pas normal du tout…

Je me suis bien pris le chou, mais j’ai finalement trouvé. Le problème a été résolu en cliquant dans les préférences de Dropbox sur l’onglet Réseau puis sur Bande passante, et là, j’ai basculé l’option Limiter automatiquement à Ne pas limiter

Miracle : d’un seul coup, l’interface est devenue hyper rapide, les synchronisations se sont accélérées, et la charge CPU est passée à seulement quelques pour-cents ! Et même quand on ajoute ou supprime un fichier, la synchronisation ne met plus le processeur à genoux.

Je ne dis pas que c’est une solution ultime, mais dans le doute, vous pouvez toujours tenter…

Dropbox réglage de réseau

Oublier un package d’installation pour pouvoir le réinstaller

Problème curieux rencontré il y a quelques jours : impossible de réinstaller un package sur le poste d’un client. Sur les autres postes, aucun souci, mais pas sur le sien. Il s’agissait d’un package Cisco AnyConnect customisé pour installer uniquement la partie VPN. Quand on veut le réinstaller via le Self Service de Jamf, l’installation semble se passer… mais rien n’apparaît sur le Mac. Idem si on essaye avec la commande installer. Et quand on veut l’installer par l’interface graphique… rien à faire, car le logiciel d’installation bloque au moment de choisir les options disponibles pour l’installation.

Solution :

  • Lancer le Terminal ;
  • Taper :
pkgutil --pkgs

Ce qui vous donnera déjà le Package ID de tous les packages installés. Dans cette liste, cherchez le package qui correspond au logiciel installé. Dans mon cas, c’était com.cisco.AnyConnect.

  • Tapez maintenant :
sudo pkgutil --forget Package ID

En remplaçant le Package ID par celui trouvé précédemment, donc par exemple :

sudo pkgutil --forget com.cisco.AnyConnect

Tapez votre mot de passe d’administrateur, et validez. La présence du package est désormais oubliée par le système, et le package devrait être installé correctement.

Comment restaurer BridgeOS sur un Mac T2 ?

J’ai rencontré il y a quelques mois un problème sur un MacBook Air 2018, qui d’un seul coup redémarrait dès qu’il avait affaire à un élément d’interface lié à Touch ID (l’Assistant réglages, préférence système…). Systématique, avec une erreur liée à BridgeOS, la partie qui gère la Touch Bar et la sécurité Touch ID du Mac. Réinstallation de système, pareil, formatage du disque, idem, j’y ai passé pas mal de temps. À la fin, j’ai quand même découvert qu’il était possible d’utiliser la procédure DFU… comme sur iOS, pour restaurer BridgeOS sur le Mac, à l’aide d’Apple Configurator (je connaissais déjà la procédure avec l’iMac Pro, mais je n’avais pas vu qu’Apple avait mis à jour la documentation pour les Mac plus récents).

Cet article du site Mr Macintosh récapitule en anglais toutes les informations liées à la restauration de BridgeOS, et en particulier comment mettre le Mac en mode DFU. Et croyez-moi, c’est bien moins facile qu’il y paraît, entre le bon modèle de câble à utiliser et le timing qui est moins évident que ce qu’Apple indique… 

Et pour mon MacBook Air ? J’ai réussi à le passer en DFU et à restaurer BridgeOS… Et ça n’a rien changé. Zou, retour atelier, non mais !

(PS : merci à Darkomen pour le rappel ^^)

L’affaire Zoom : quand la simplicité prévaut (trop) sur la sécurité

Zoom us SelfServiceIcon 512x512

Hier, l’affaire Zoom a éclaté au grand jour, avec la révélation de l’installation d’un serveur web tournant en loucedé sur tous les Mac sur lesquels cette application populaire de gestion de visioconférence est installée (et elle n’est à priori pas la seule à agir ainsi).

Tout ça pour quoi ? Pour éviter un clic de plus par l’utilisateur dans Safari quand ce dernier ouvre une conférence, car la page en question veut demander à ouvrir une autre application, ce que Safari n’aime pas vraiment (en fait c’est Apple qui n’aime pas ça, mais du coup Safari non plus).

Répétez cela avec moi :

Pour contourner une fonction de sécurité de macOS, un éditeur installe un serveur web local sur un Mac.

Alors, je veux bien que parfois, les alertes de macOS soient un peu pénibles (et ça ne va pas aller en s’arrangeant), mais personnellement, je trouve le comportement du développer absolument extraordinaire de désinvolture en disant « c’est pas si grave ». Ben si, un peu quand même…

Mais il n’y a pas que ça. J’ai du coup profité de l’occasion pour installer Zoom sur une machine de test, avec le package fourni par défaut sur le site de Zoom. Et là… surprises. En pagaille.

Le package se lance sans alerte particulière, puis on a une fenêtre d’alerte comme quoi le package veut lancer un script de vérification, ce qui peut sembler logique.

Sauf que.

Si vous cliquez sur Continuer, le logiciel d’installation… quitte. Directement. Pas de dialogue supplémentaire, rien.

Zoom Installer

L’application Zoom est déjà dans votre dossier /Applications. Vous n’avez pas accepté de licence, rien. Pas vu de Lisez-moi. Rien. Pas d’acceptation de licence, que dalle. Même pas besoin de taper votre mot de passe administrateur. Le logiciel s’installe et se lance tout seul. J’ai répété plusieurs fois le processus, sur différents Mac, même résultat.

Et effectivement, le package d’installation, au lieu de faire ce qu’il devrait faire, à savoir vous inviter à faire quelques clics, est juste tué sans condition, car le script de pré-installation…est devenu un script d’installation en force.

Ah, et au passage, il va aussi télécharger un fichier MacRetinaRes.zip qu’il va coller… quelque part. Aucune info.

Et comme l’application d’installation a été tuée direct… pas de trace de l’installation dans les reçus d’installation du système. C’est juste complètement n’importe quoi.

Bref, le logiciel d’installation de Zoom fait pas mal de trucs assez dégueulasses d’un point de vue déploiement. Alors qu’il aurait été tout aussi simple de proposer d’installer l’application à partir d’un DMG téléchargé, le mettre dans /Applications à la main et zou.

Mais il y a encore mieux (ou pire, c’est selon).

Zoom propose un package pour les administrateurs. C’est sur leur site, en haut à droite. Et le package d’installation IT est… tout à fait standard. Il installe proprement, il ne tue rien, bref… c’est presque propre.

Mais pourquoi gérer deux packages différents, dans ce cas, bon sang ? Pourquoi se compliquer ainsi la vie ?

La réponse pour Zoom semble finalement assez simple à comprendre :

Pour éviter toute friction entre la visioconférence et l’utilisateur.

D’un point de vue technique, ce que fait Zoom (et ils le disent), c’est vouloir limiter le nombre de clics entre le moment où une conférence est mise en route et un lancement de l’application est effectué, avec un téléchargement allégé. Ce qui ne part pas d’une mauvaise intention : les employés dans les entreprises perdent souvent beaucoup de temps à lancer une conférence, c’est souvent un moment de stress. Zoom essaye de limiter au maximum la friction1 pour éviter ce stress.

Malheureusement, à partir du moment où on contourne des sécurités fondamentales d’un système d’exploitation pour supprimer des clics, le développeur fait à mon goût une grave erreur. On ne peut pas dire « je vais faire sauter la serrure de votre porte, car le jour où un livreur doit déposer un colis chez vous, ça pourrait être gênant si la porte est fermée ».

La sécurité informatique n’est pas une option de nos jours, et qu’une société comme Zoom se permette de contourner ces sécurités est dangereux. Mieux vaut éduquer les utilisateurs que faire n’importe quoi sur un ordinateur, au risque de perdre la confiance de ses clients, actuels ou potentiels.

Zoom est revenu en arrière, a fait amende honorable (après avoir dit quand même au départ « ouais, OSEF »), mais les dégâts sont déjà faits en terme d’image, et ils mettront du temps à s’estomper.

  1. coucou Mourad !