Collanews

🔒
❌ À propos de FreshRSS
Il y a de nouveaux articles disponibles, cliquez pour rafraîchir la page.
À partir d’avant-hierVos flux RSS

Beats Updater et son intégration bizarre

Par Pierre Dandumont

J’ai depuis quelques mois un casque Apple Beats, et l’intégration des logiciels est… étonnante.

Pour mettre à jour le casque ou le renommer, il faut aller télécharger un logiciel : Beats Updater. Il mélange un vrai logiciel avec une page Web : une fois lancé et le casque branché en filaire, il est possible de mettre à jour le firmware ou gérer le nom, mais dans un navigateur. Mais ce logiciel m’étonne sur deux points. Premièrement, il n’est pas distribué dans le Mac App Store mais sur le site de Beats, et deuxièmement – plus étonnant – il se met à jour dans les Préférences Système de macOS. Pas dans le Mac App Store ni en lançant le logiciel, donc, mais dans la zone réservée aux mises à jour de l’OS. Jusqu’à maintenant, je n’avais vu qu’un logiciel « tiers » dans cette zone : la version de développement de Safari.

Pas sur le Mac App Store


Une interface qui passe par le navigateur


Une intégration poussée dans macOS

C’est assez bizarre de voir qu’Apple intègre l’outil dans son OS mais ne le distribue pas réellement avec les outils classiques.

Approuver la commande sudo avec l’Apple Watch (et ses limites)

Par Pierre Dandumont

J’en parlais hier, il est possible d’utiliser l’Apple Watch pour s’authentifier dans certains cas avec macOS Catalina. Mais ça ne fonctionne pas partout, tout comme Touch ID. Par exemple, avec la commande sudo, il faut entrer le mot de passe. Mais macOS offre une solution.

En fait, la méthode utilisée pour High Sierra fonctionne sous Catalina. Il faut éditer un fichier et ajouter une ligne. La première commande édite, la seconde contient la ligne à ajouter est la suivante. Le tid de pam_tid indique clairement Touch ID.

sudo nano /etc/pam.d/sudo
auth sufficient pam_tid.so

Une fois que c’est fait, la commande sudo proposera la fenêtre classique qui demande d’utiliser Touch ID, mais ça fonctionne aussi avec l’Apple Watch.

Dans les limites, outre le fait que presser un bouton sur la montre semble un peu moins sécurisé qu’un vrai mot de passe, ça ne fonctionne pas quand l’écran du Mac est fermé avec un écran externe. Ca vient du fait que l’authentification attend Touch ID, qui n’est évidemment pas disponible quand le capot du Mac est fermé. Du coup, l’authentification Apple Watch saute en même temps. Il y a visiblement une solution qui consiste à modifier des fichiers du système, mais c’est plutôt une mauvaise idée avec macOS Catalina. Enfin, il existe une autre façon de le faire, parfois mise en avant, mais très franchement je préfère ne pas passer par du code externe (même open source) pour l’authentification. Malgré tout, ça reste une solution si votre Mac n’est pas équipé de Touch ID.

Avec la commande sudo

Approuver une demande de mot de passe avec l’Apple Watch et macOS Catalina [MAJ]

Par Pierre Dandumont

Avec macOS Catalina, Apple a ajouté une fonction intéressante : la possibilité d’utiliser l’Apple Watch pour approuver certaines demandes de mot de passe. Ca ne marche pas dans tous les cas, j’en parlerai demain, mais c’est assez efficace.

Les contraintes sont classiques : il faut un Mac qui accepte le déverouillage avec l’Apple Watch (en simplifiant, un modèle avec une carte Wi-Fi 11ac), macOS Catalina et une montre sous watchOS 6 (donc pas la première génération). Il faut bien évidemment avoir activé l’option dans les Préférences Système, section Sécurité et confidentialité, onglet Général : c’est la case Utilisez l’Apple Watch pour déverrouiller des apps et votre Mac.

Ensuite, c’est simple : la montre va vous prévenir avec une vibration haptique, en vous demandant de presser deux fois le bouton. Quel bouton ? Celui présenté sur l’écran avec une petite animation, c’est-à-dire le bouton qui se trouve sous la couronne digitale. Il faut presser le bouton assez vite, à la manière d’un double clic. Attention, tout de même, macOS n’indique pas explicitement que c’est possible sur la montre : c’est la vibration haptique qui vous préviendra. Enfin, de façon assez logique, ça ne fonctionne que si vous êtes à proximité du Mac, comme pour le déverrouillage classique.

Dans Safari


Un menu classique (ici dans les Préférences système)


Sur la montre

C’est fonctionnel pour les notes, les menus de Safari, les préférences, etc. Il y a quelques cas qui imposent tout de même un mot de passe, comme sudo, mais ça peut éventuellement se régler (on en parle demain).

MAJ : Comme le fait remarquer maxou56 en commentaires, ça affiche bien une Apple Watch… mais uniquement sur les Mac qui n’ont pas Touch ID. Donc sur un iMac, un Mac mini, un MacBook, etc. Et merci maxou56 pour les captures !

Avec une Apple Watch


Avec une Apple Watch

Si vous ne voulez pas passer à zsh sous macOS Catalina

Par Pierre Dandumont

Avec macOS Catalina, Apple abandonne le shell Bourne-Again (bash) pour le Z Shell (zsh). Mais la transition peut poser quelques petits désagréments visuels.

Alors, je ne vais pas parler du choix du shell, c’est assez subjectif, même si zsh est plus moderne. Mais je vais parler de la façon de gérer la transition. Par défaut, Apple va imposer zsh lors d’une nouvelle installation, mais laisser bash activé lors d’une mise à jour… avec un petit message.

Le message

The default interactive shell is now zsh.
To update your account to use zsh, please run `chsh -s /bin/zsh`.
For more details, please visit https://support.apple.com/kb/HT208050.

Il renvoie vers une page de support qui explique bien le problème, mais si vous n’avez pas pris la peine d’aller la lire, elle explique comment forcer zsh par défaut. Soit dans l’interface de macOS, soit – plus simple – avec une ligne de commande :

chsh -s /bin/zsh

Vous pouvez remplacer /bin/zsh par /bin/bash si vous voulez revenir au bash après une installation propre de macOS Catalina.

L’autre commande intéressante est celle qui permet de faire disparaître le message, si vous voulez garder le bash. Il faut éditer le fichier ~/.bash_profile (avec la commande nano ~/.bash_profile par exemple) et ajouter cette ligne.

export BASH_SILENCE_DEPRECATION_WARNING=1

macOS Catalina protège encore mieux l’EFI (à vos risques et périls)

Par Pierre Dandumont

Avec Catalina, Apple a introduit une nouvelle possibilité pour protéger l’EFI. Il est maintenant possible de bloquer la solution « de dernier recours » d’Apple. Je m’explique.

Le mot de passe EFI (ou Open Firmware; il y a longtemps) permet notamment d’empêcher de démarrer un Mac sur un autre disque que celui choisi par défaut. Mais à une époque, ce mot de passe sautait assez facilement, en enlevant la RAM (oui…) ou en flashant la puce contenant l’EFI quand elle était accessible (ce qui n’est plus le cas). Mais une faille venait aussi d’Apple, même si je comprends parfaitement la raison de son existence. Pour faire simple, AppleCare peut effacer le mot de passe EFI à distance, avec une méthode assez précise. Elle nécessite de démarrer d’une façon très particulière (il faut presser shift + control + option + command + S) pour récupérer un code à envoyer à Apple, qui en retour envoie un fichier SCBO qui va permettre de démarrer le Mac et effacer le mot de passe.

Si ça vous intéresse, le fonctionnement exacte de ce SCBO est expliqué en détail là, mais en simplifiant il contient du code exécuté par l’EFI (et signé par Apple) qui va effacer le mot de passe. En théorie, seul Apple peut générer le fichier en question, mais on trouve visiblement des gens qui peuvent le faire. L’auteur de l’article explique que les chances qu’un générateur existe sont faibles, et que les vendeurs ont potentiellement accès aux outils d’Apple directement, mais ça ne change rien au problème : il reste potentiellement possible de débloquer un Mac de cette façon.

Avec Catalina, il existe dont une nouvelle option qui permet de désactiver cette option.

sudo firmwarepasswd -disable-reset-capability

La commande ne fonctionne que si vous avez mis un mot de passe (logique) et elle a un défaut : si vous perdez le mot de passe, vous n’aurez plus la solution de dernier recours d’Apple. En réalité, il reste parfois des solutions physiques : (re)flasher la puce sur les modèles avec une puce accessible ou utiliser une MattCard par exemple. Mais ça ne fonctionne que sur les Mac un peu anciens : les modèles avec une puce T2 protègent bien mieux l’EFI. Donc si vous avez un Mac moderne, cette option empêchera a priori toute récupération ou effacement du mot de passe, c’est important de s’en rendre compte. Et on peut penser que « ça n’arrive qu’aux autres », mais ce n’est pas réellement le cas : on peut oublier un mot de passe, mettre une protection dans la précipitation parce qu’un Mac a été volé, etc., et se retrouver très bête. La méthode d’Apple, si elle induit effectivement une faille de sécurité, sert aussi de filet de sécurité.

macOS Catalina et le HDR

Par Pierre Dandumont

Avec macOS Catalina, Apple active en théorie la prise en charge du HDR dans l’OS. Mais assez bizarrement, je n’ai pas réussi à le faire.

Pour faire simple et rapide, le HDR nécessite d’envoyer des métadonnées à l’écran, qui va les interpéréter. La lecture d’une vidéo encodée avec du HDR nécessite donc un support de l’OS (pour passer dans le bon mode), de la carte graphique (pour transmettre les données) et de l’écran, pour interpréter. Sous Windows 10 avec une version à jour de l’OS, ça ne pose généralement pas de soucis : l’activation du HDR se voit assez facilement, et l’écran lui-même passe en HDR. Dans les effets visibles, il devient impossible de régler la luminosité et l’image devient terne.

Mais chez Apple, ce n’est pas si simple. Sur la page dédiée à Catalina, on trouve cette note : « Contenus 4K, 4K HDR, 4K Dolby Vision, Dolby Atmos et HDR10 disponibles sur tous les modèles de Mac introduits en 2018 ou ultérieurement disposant d’écrans à résolution 4K. » (le texte est le même en anglais). La limitation aux machines de 2018 et plus est un peu étonnante de prime abord, mais a une logique chez Apple : la gestion des DRM pour les vidéos en 4K (et a priori le HDCP 2.2) passe par la puce T2. Dans le monde PC, les lecteurs se basent généralement sur l’implémentation Intel dans les puces de la génération Kaby Lake (Core de 7e génération) mais avec un défaut rédhibitoire : ça nécessite d’utiliser la puce Intel. Le problème, c’est que les iMac, le Mac Pro ou même les MacBook Pro avec un GPU dédié n’utilisent pas le GPU Intel pour la sortie vidéo. Mais Apple a visiblement fait un pack : pour décoder du HDR, même sans DRM, il faut passer par le décodage matériel d’une puce T2. Pas par le décodage matériel d’une carte Intel ou AMD.

Dans la pratique, j’ai testé avec deux écrans PC qui sont HDR (et compatibles HDR sous Windows) sans succès. Impossible d’activer la fonction sur mon MacBook Pro de 2017, avec ou sans le eGPU (Vega 64). QuickTime voit bien du HDR10 sur une vidéo de test, mais l’écran reste en SDR.

QuickTime voit bien le HDR10

A noter aussi que la page sur les contenus Apple semble assez restrictive : elle indique que le HDR fonctionne sur l’écran interne de l’iMac Pro et sur le Mac Pro, le MacBook Pro 16 pouces ou le MacBook Pro 15 pouces 2018 avec un écran XDR. Elle n’indique pas, contrairement à la page de Catalina, que ça fonctionne sur un Mac de 2018 (aka en T2) avec un écran compatible. Du coup, si quelqu’un a de quoi tester, ça m’intéresse : il faut un Mac en T2, un écran ou un téléviseur HDR et une vidéo de test (ou un abonnement AppleTV+, qui diffuse en 4K/HDR).

L’accélération vidéo dans HandBrake

Par Pierre Dandumont

J’utilise HandBrake depuis des années pour (re)compresser des vidéos ou passer d’un format un peu atypique à quelque chose de plus standards, et je me suis rendu compte récemment que depuis la version 1.2, HandBrake peut utiliser l’accélération vidéo sous macOS.

L’encodage chez Apple passe parce une technologie appelée VideoToolbox. Il y a assez peu d’options dans HandBrake (et sous macOS), et la technologie est supportée depuis pas mal de temps. Pour le HEVC (H.265), ça doit marcher sur tous les Mac sortis après 2015. Le principal problème de VideoToolbox va être « Qui encode ? ». La question n’est absolument pas triviale, les Mac intègrent plusieurs encodeurs différents.

Premièrement, il y a les fonctions des GPU Intel, disponibles sur les Mac avec un IGP (les portables, quelques iMac, les Mac mini, etc.). La technologie porte le nom de QuickSync et permet d’encoder plus ou moins bien en H.264 ou en H.265 sur les appareils récents. Sur d’autres Mac, c’est le GPU dédié qui prend la main, généralement à base d’AMD. Et en fonction de la carte graphique, les résultats varient. Enfin, sur les Mac avec une puce Apple T2, l’encodage (et le décodage) passent par cette dernière (et c’est a priori plus rapide, mon Mac n’a pas de T2).

Attention, l’encodage sur le GPU peut être moins bon que sur le CPU. Les encodeurs ont des fonctions fixes et la qualité diminue, un bon encodeur CPU évite les erreurs, compressent mieux et offre un résultat meilleur, mais généralement bien plus lent. Mais pour un usage grand public basique, genre regarder un film sur l’Apple TV, l’encodeur GPU suffit généralement. Il va manger quelques détails, mais il va aller 5 à 10x plus vite, ce qui n’est pas négligeable. L’encodeur Apple, on va le voir, a un défaut gênant pour HandBrake : il demande un bitrate précis (le débit). Avec le x264 ou le x265, on peut définir une qualité à obtenir, et l’encodeur va se débrouiller en fonction de la scène. Avec l’encodeur Apple, il faut définir une valeur de débit, et c’est tout. En pratique, on a donc des fichiers plus gros par défaut, et il faut tester pour atteindre le bon rapport débi/qualité (pas très pratique).

Avec HandBrake, une fois la vidéo choisie et les paramètres définis, il faut se rendre dans l’onglet Vidéo et modifier l’Encodeur vidéo. Par défaut, HandBrake va souvent proposer le x264, un encodeur logiciel efficace. Il suffit de passer sur un encodeur VideoToolbox pour activer l’accélération. Attention, surtout avec l’encodeur H.265, le résultat n’est visiblement pas toujours parfait, mais je n’ai pas eu de soucis.

HandBrake


Deux options VideoToolbox

Quelques tests

Je suis parti d’une vidéo d’une dizaine de minutes en 1080p (Big Buck Bunny) et j’ai testé plusieurs cas de figures. La machine est un MacBook Pro 2017, avec un CPU quatre coeurs (Core i7 7700HQ), une Radeon Pro 560 et un eGPU à base de Radeon Vega 64.

L’encodage en H.264 (x264) utilise le CPU pour encoder, et le processeur reste aux alentours de 2,9 GHz en permanence (entre sa fréquence de base, 2,8 GHz, et son Turbo à 3,4 Ghz). Il encode en 7 minutes et 23 secondes (~32 fps) pour un fichier final de 278 Mo.

L’encodage en H.264 par VideoToolbox utilise le GPU (l’Intel, j’y reviens). Le CPU reste utilisé pour pas mal de tâches, mais l’encodage prend seulement 2 minutes et 18 secondes (~104 fps). Petit défaut, le fichier final est plus gros : 459 Mo. Je n’ai pas remarqué de dégradations visuelles flagrantes. Pour la taille du fichier, c’est normal : l’encodeur Apple a peu d’options, et HandBrake sélectionne un bitrate fixe (6 Mb/s) avec ce dernier, contre un réglage de qualité sur l’encodeur software (RF 22).

Le second essai a été d’encoder de la même façon, mais en débranchant le eGPU. Le résultat ne bouge pas : 2 minutes et 17 secondes. C’est bien l’IGP Intel qui encode en H.264. Le dernier essai (uniquement avec l’IGP) confirme bien que c’est l’IGP qui encode : le GPU ne s’active pas, le temps ne bouge pas.

L’encodage en H.265 (x265) avec les mêmes réglages (RF 22) utilise le processeur. Il prend nettement plus de temps (14 minutes et 33 secondes, ~16 fps). Le fichier est un peu plus petit qu’en H.264 (243 Mo). Je suppose qu’il y a des réglages plus efficaces, ceci dit.

L’encodage en H.265 par VideoToolbox utilise le GPU, et plus spécifiquement dans mon cas l’eGPU (une Radeon RX Vega 64). C’est un peu tendu à voir, mais l’augmentation de la température montre bien que c’est cette carte précise qui encode. Il faut 2 minutes et 21 secondes (~101 fps) pour un fichier de 472 Mo. C’est aussi logique : HandBrake ne permet qu’un bitrate fixe.

On voit que la Vega 64 travaille un peu

Le seconde essai, là aussi, passe par le débranchement du eGPU. L’encodage s’effectue ici sur l’IGP Intel (on peut le voir avec Moniteur d’activité) mais une partie passe aussi par le GPU dédié (Radeon Pro 560 dans mon Mac). Vu l’occupation, je peut supposer que le décodage s’effectue sur le GPU et l’encodage sur l’IGP. Malgré tout, c’est nettement moins rapide : 5 minutes 19 secondes (~45 fps). Le troisième essai confirme : il faut le même temps et macOS force l’activation du GPU.

Ici, Radeon et Intel HD travaillent de concert


L’encodage force bien le GPU

Conclusion

L’encodage H.264 s’effectue visiblement uniquement via QuickSync, et rapidement. Pour le H.265 (HEVC), ça va dépendre de votre Mac, mais un eGPU peut donner un gros gain. Le jour ou j’ai une machine sans GPU ou une autre avec une puce T2 sous la main, j’effectuerais d’autres tests.

Apple confond encore Gb et Go

Par Pierre Dandumont

Un truc qui m’énerve quand ça vient de gens (ou de sociétés) qui travaillent dans l’informatique, c’est la confusion entre Go, GB et Gb. Et même Apple, dans son OS, fait parfois l’erreur.

Pour résumer : un b (minuscule) est un bit, soit la valeur de base en informatique (1 ou 0). Un B (majuscule) est un byte, c’est-à-dire un groupement de bits. Un byte vaut généralement 8 bits (depuis un moment), même s’il existe quelques (vieilles) machines ou ce n’est pas le cas. Un octet (o) est la traduction française du byte. L’octet fait 8 bits et vaut 1 byte, parce qu’au moment de franciser le mot, les ordinateurs utilisaient tous a priori une valeur de 8 bits.

Pour résumer : 1 Go = 1 GB = 8 Gb. Je vous passe la partie sur les Gio, Gib et GiB, vous devez juste savoir que dans le système international, 1 kb (k minuscule) vaut 1 000 b (et pas 1 024). macOS (depuis Snow Leopard) compte et affiche correctement, contrairement à Windows.

Pour ajouter à la confusion, on utilise généralement le byte ou l’octet pour le stockage (donc un SSD de 512 GB ou Go par exemple) mais le bit pour mesurer les débits. Dans le cas d’un SSD, on a donc une interface à 6 Gb/s (SATA) par exemple. Même chose, je vous passe les détails sur la conversion Gb vers Go dans ce cas-là, mais dans certains cas il ne suffit pas de diviser par 8. Dans le cas du SATA, 6 Gb/s deviennent 600 Mo/s.

Apple et les valeurs

Dans le cas d’Apple, les informations système affichent assez régulièrement des valeurs fausses. Pendant longtemps, c’était le cas dans les informations sur le Thunderbolt (la norme fonctionne à 10, 20 ou 40 Gb/s, certains OS affichent 10, 20 ou 40 Go/s), et c’est toujours le cas pour Mojave dans un cas précis. Si vous allez vérifier le débit d’un périphérique USB 3.1 « Gen. 2 », macOS Mojave annonce Jusqu’à 10 Go/s et pas Jusqu’à 10 Gb/s. C’est corrigé dans macOS Catalina de ce que j’ai vu, d’ailleurs, et pour les autres valeurs de l’USB (12, 480, 5, etc.), il affiche bien des Mb et des Gb/s.

Sous Mojave : WRONG


Dans les fichiers, il y a bien l’erreur


En 2014, l’erreur existait pour le Thunderbolt

Update To Catalina? Here’s How To Manually Export Your Music.app As XML

Par Dan White
Manual Music XML export in macOS Catalina

Yes, here’s another article in the thread of many about the release of macOS Catalina. We decided instead of only revising the previous article, more people might see this manual fix for the loss-of-connection between DJ software and the iTunes replacement, Music. Avid DJ music library management expert MixMasterG (the guy behind the many of […]

The post Update To Catalina? Here’s How To Manually Export Your Music.app As XML appeared first on DJ TechTools.

Read this before updating your DJ computer to Catalina! Wait For Serato/Traktor/Rekordbox Updates.

Par Dan White
Don't update to Catalina yet.

If you’re an early adopter, a DJ, and use a Mac, take note: iTunes is officially done in macOS Catalina, out today. The software is replaced with a music-only app, called simply Music (we’ll call it Music.app occasionally for clarity). One of the biggest issues is that this breaks a lot of DJ apps’ integrations […]

The post Read this before updating your DJ computer to Catalina! Wait For Serato/Traktor/Rekordbox Updates. appeared first on DJ TechTools.

Traktor Team Shares Update: Legacy Controllers on Traktor DJ 2, Catalina support for TP3, New hardware

Par Dan White
An update from the Traktor team in 2019

If you’re a Traktor DJ, or have been recently, it can be hard to read some of the more dire-sounding news recently from the Native Instruments HQ. But today, a message was posted by Friedemann Becker- one of the leads of the Traktor team – sharing more details around what’s underway. Keep reading for the […]

The post Traktor Team Shares Update: Legacy Controllers on Traktor DJ 2, Catalina support for TP3, New hardware appeared first on DJ TechTools.

Organizing Your Resolume Clips With Smart Folders (macOS)

Par Ryan Dejaegher

One of the biggest challenges for VJs is organizing their VJ loops. Which files are encoded properly? How long are these clips? What’s the resolution? Unlike DJs, VJs don’t really have any software like iTunes that’s designed for organizing their media. This usually leaves VJs to organize their content using boring old folders, lame. Today […]

The post Organizing Your Resolume Clips With Smart Folders (macOS) appeared first on Zero To VJ.

❌