Les apps mobiles Blued et Finka sont maintenant absentes de l'AppStore d'Apple en Chine...
Grindr y avait déjà été censuré.
Ces trois apps sont destinées aux public homosexuel et bisexuel.

La Chine a choisi de les faire interdire de l'AppStore d'Apple et du PlayStore de Google, les deux multinationales ont choisi de respecter la loi et de bannir ces deux apps.
Mais silencieusement, sans réagir, sans communication, comme si c'était normal.

L'homosexualité n'est pas illégale en Chine, contrairement à de trop nombreux autres pays qui partagent une religion commune et une loi commune.
Mais petit à petit la Chine interdit ceci ou cela, comme la "Shangai Pride" suspendue en 2020.

Ces deux multinationales, Apple et Google, font assembler (assemblage final) leurs smartphone respectifs en Chine pour de nombreux marchés.
La Chine est aussi destinée à devenir leur premier marché, comme c'est déjà le cas pour l'automobile.

Je me souviens de Tim Cook donnant des leçons de chose à un Président des États-Unis pourtant ouvertement pour le mariage gay.
Le même allant porter la bonne parole dans des pays où ses propres mœurs étaient criminalisé, et là ne l'ouvrant absolument pas. Les Droits de l'Homme? Après le business, un peu de sérieux!
Toujours le même donnant à la Chine les clés pour surveiller tout ce qui est stocké dans iCloud, qu'on peut maintenant appeler Xi Cloud...

Je vous avouerais que je suis choqué et énervé, j'avais même préparé un autre texte (trop brutal, trop engagé), car entre ce que Apple et Tim Cook disent et font, il y a une abysse, incroyable!

Selon le Financial Times, les dirigeants d'Apple ont considérablement accéléré leur recherche d'un successeur pour Tim Cook. Le but serait de le remplacer dès 2026.
Cette volonté de le remplacer au plus tôt ne serait pas liée à des contre-performances à venir ce qui est une bonne nouvelle. On ne connaît en revanche pas la raison profonde, aucune piste n'étant évoquée.

Nous ne vous cachons pas nous réjouir de voir du sang neuf à la tête d'Apple et ne serions pas surpris que le fiasco d'Apple Intelligence ne soit la raison profonde de cette volonté de confier les rênes de la société à quelqu'un d'autre.

Selon Mac Gurman, Apple se désintéresse de la gamme Mac Pro.
Ces machines qui n'ont pas été renouvelées depuis 2023 et toujours dotées de processeur M2 seraient considérées comme inutiles par la société qui préfère miser dans le futur sur le Mac Studio qui deviendrait le haut de gamme professionnel que ce soit en puissance de CPU qu'en dotation RAM.

Il y a quelques années nous aurions fustigé cette position. Aujourd'hui, avoir un Mac Pro n'a plus de réel intérêt surtout quand deux ans plus tard un MacBook Pro en a pratiquement la même puissance brute pour un prix bien moindre.
C'est d'ailleurs un des effets de biais des puces Apple Silicon et de leur évolution. Elles tendent à pousser l'achat de machines milieu de gamme quitte à les renouveler plus fréquemment plutôt que de prendre une machine bien plus coûteuse et ultra puissante qui n'aura un intérêt que dans des domaines très pointus et qui sera surclassée deux ans plus tard par une machine coûtant e tiers de son prix.

Rendering VT-100 émulant l'affichage DOS

J'écris des moteurs d'échecs, ou d'autres comme pour le Reversi/Othello, depuis plusieurs décennies.
Je suis en train de travailler sur un moteur sorti fin 1994 pour le Minitel, écrit en C-Ansi, Borland C 3.1 pour DOS à l'époque et gcc maintenant pour Posix dans un terminal VT-100, 32 bits pour Pentium [1] à l'époque et 64 bits pour x86 et ARM aujourd'hui.
Du vieux code monothread, c'est à noter.

Et pour m'amuser, sur mon Mac mini M4, je ne fais non pas tourner une version compilée pour ARM mais celle compilée pour x86 64 bits. Le même exact code, grâce à Rosetta 2.
Ce code x86 sort de gcc, avec l'option -O3 : optimisé mais en limitant les risques.

Je viens de m'apercevoir que si en moyenne un cœur Performance du M4 est 3,3 fois plus rapide que chaque cœur de mon MBP 15" 2017, ce qui devrait amener ce code x86 monothread à tourner moins de 3 fois plus vite sous ARM via Rosetta 2 (85% d'efficacité mesurée en 2020), il tourne en fait 4 fois plus vite maintenant en 2025!

Je soupçonne que Rosetta 2 s'est vu amélioré et pourrait utiliser les 16 registres généraux en plus de l'architecture ARM 64 bits pour optimiser le code x86 quand il le transcrit pour nos Mac Apple Silicon.
Ce code simple (non-vectoriel, non fpu) tourne 30% plus vite qu'il le devrait !

Une limitation du Amd64 (ou x86 64 bit, ou x86-64) créé par AMD, c'est que son architecture ne contient que 16 registres généraux (entiers et pointeurs), contre 32 pour ARM 64bits (AArch64).

Ça permet évidemment à nos Mac ARM d'émuler facilement les 16 registres du x86, mais en laisse beaucoup inutilisés, et je pense que Rosetta 2 en profite pour limiter les relectures après écriture dans la pile (les écritures étant probablement conservées).

Une autre optimisation peut être d'éliminer les copies de registres inutiles, puisque en ARM 64 bits les opérations ont souvent 3 opérandes (2 sources et 1 destination), contre 2 en x86 64 bits (1 source, 1 destination).
Par exemple a=b+c en x86 64 bits consiste à "copier" (créer un alias) b dans a puis à lui ajouter c (2 opérations), quand en ARM 64 bits, on ajoute b et c dans a en une seule opération.

L'aliasing de registres (ex-copie) est "gratuite" en x86 maintenant, mais nécessite de décoder une instruction de plus, donc plus de charge coté décodeur (front end) qui est déjà un problème en x86 avec des instructions de longueur variable et le travail pour créer les micro-instructions et macro-instructions depuis les Core™ 2.

Je vais vous revenir avec une comparaison avec du code ARM natif (même compilo mêmes options). Mais ce résultat est très surprenant, Apple fait un travail incroyable sur Rosetta 2 !

Réalisation ChatGPT 5.1, prompt pourri et déjaunissement par Philippe

Acte 1 : Le cloud privé Apple pour Siri avec des IA Google

Apple voudrait utiliser des IA Google pour Siri, dont des versions modifiées de Google Gemini voire Google Gemma.
Tout cela dans son "cloud privé", ce qui ne veut pas dire grand-chose.

Apple n'a pas encore les datacenter pour leurs propres IA cloud, et si des rumeurs indiquaient que de futurs M5 pourraient être des "compute module" pour cela, on est probablement à 1 ou 2 ans de leur implémentation à l'échelle de leur clientèle d'utilisateurs !

Mais où donc pourrait être alors hébergé le "cloud privé" d'Apple pour Siri?!?

Acte 2 : Google annonce son cloud privé sécurisé par TEE

La situation s'éclaire avec Google annonçant un "cloud privé sécurisé", dans ce cas des pool de serveurs au sein de ses propres datacenter, loués ou achetés par les clients l'utilisant pour faire tourner des IA, dont celles de Google: Gemini et/ou Gemma.

Le "cloud privé" d'Apple pour Siri pourrait bien n'être que des serveurs "privés sécurisés" chez Google.
La sécurité reposant sur plusieurs couches, dont la couche matérielle TEE.
Cette couche TEE devant théoriquement empêcher tout accès physique aux données présentes dans ces serveurs d'IA. C'est une protection contre l'accès physique aux données.

Google prétend que son "cloud privé sécurisé" serait aussi sécurisé que l'exécution locale.
Ça rassure, la sécurité est incroyable grâce aux TEE ! Ou pas?

Acte 3 : L'insécurité de TEE est prouvée

Et voilà que des chercheurs se sont intéressés au sujet, et ont littéralement démoli la couche de sécurité TEE, que les données soient stockées en DDR4 (déjà fait avant) ou en DDR5.
Et cela sur les 3 architectures CPU/SoC majeures. Toutes.

Les TEE de nVidia, AMD et Intel sont tous cassés. Le papier de recherche est ici (PDF).

Pas de protection d'accès physique, donc aucun "cloud privé", Google étant en mesure d'accéder aux données de ces serveurs d'IA dans son datacenter. Ou des agences Américaines.
À la merci de qui les exigera. Ou simplement pour récupérer nos échanges et nos vies...

Pour ceux qui veulent en savoir plus, c'est l'usage de chiffrements "déterministes" par réusage de clés qui est le problème, créant des possibilités d'attaques de type Replay.
On ne fait jamais ça, on ne doit jamais faire ça. C'est plus rapide, mais non... Jamais !

Même pas besoin que la NSA, comme d'hab, pourrisse la génération de clés pseudo-aléatoires en poussant des générateurs pas du tout aléatoires. AMD a mis 6 ans avant de reconnaître sa faute.
Un grand pas en avant qui simplifie tellement le travail des Agences Américaines !

Conclusion

Le "cloud privé sécurisé" dont Apple et Google se targuent n'est en rien sécurisé ou privé: je pense qu'ils foncent dans le mur, comme tout ceux qui croient à leurs promesses.

Il est à noter qu'il y a d'autres failles dans le modèle de "cloud privé sécurisé" de Google, puisque reposant sur des acteurs "indépendants", mais pas indépendants des Lois et Agences Américaines.
Même pas besoin d'accès physique ! Même pas besoin de failles de TEE ! Les lois US !

Mon avis est que si c'est dans le cloud, ça n'est ni sécurisé ni privé, c'est publique...
L'exception étant de contrôler le chiffrement et le déchiffrement localement, soi-même.
Et pour les IA, c'est localement avec LM Studio par exemple (et beaucoup de RAM).

[MàJ] Apple a corrigé la page pour ce qui n'était visiblement qu'une erreur. Il s'agit probablement d'un stagiaire à qui l'on a confié une tâche au dessus de ses compétences sans supervision. On le pardonnera à cette jeune société qui se lance.

Comme le rapporte Macrumors, Apple a modifié la page des produits compatibles avec Apple Intelligence.

Auparavant, tous les Mac ARM étaient compatibles. Dorénavant ceux dotés d'une puce M1 ne le sont plus, le processeur M2 étant le minimum.
Chose étrange, les iPad avec un M1 restent compatibles.

On pourra dire qu'Apple veut une expérience optimale pour ses utilisateurs.
Mon expérience me fait penser qu'il s'agit d'une limitation artificielle visant à pousser au renouvellement alors que le M1 est encore très largement assez puissant pour 99% des usages de particuliers. Je me doutais qu'on finirait à en arriver à cela. Pour Apple, Apple Intelligence est un nouveau moyen de programmer l'obsolescence de produits.