Se connecter
Se connecter
Mot de passe oublié ?
ou
Créer un compte
ou
Se connecter avec Facebook
Notifications
< Retour vers Apple
Agrandir
Apple
Apple
(655 avis produit)
Produits 457 457
Actu 143 143
Articles 10 10
Tutoriels Tutos 41 41
Avis 655 655
Petites annonces Annonces 71 71
Forums 5 197 5,2k

réactions à la news Apple va équiper ses Mac de processeurs ARM

  • 474 réponses
  • 57 participants
  • 24 332 vues
  • 51 followers
Sujet de la discussion Apple va équiper ses Mac de processeurs ARM
apple-52.jpg
La Keynote WWDC20 organisée par Apple hier a confirmé la rumeur qui courait depuis plusieurs jours concernant la fin du partenariat avec Intel.


Lire la news




Ce thread a été créé automatiquement suite à la publication d'une news pour ce produit. N'hésitez pas à poster vos commentaires ici !
Afficher le sujet de la discussion
201
Et le même dev a l'air enthousiaste et très confiant dans la portabilité des apps : https://shapeof.com/archives/2020/6/more_mac_and_wwdc_2020_thoughts.html
Evidemment, l'idéal serait qu'un codeur français ou francophone qui a l'expérience de ces langages nous fasse un topo rapide :clin:
202
Franchement, pour avoir fait les deux, c'est souvent plus simple de porter un produit sur une nouvelle architecture que sur un nouveau système d'exploitation.

Si un changement d'architecture casse tout et que ça demande des mois de modifications pour que ça marche, c'est que le programme a été mal pensé à la base. Une bonne partie des logiciels du monde libre se compilent sur une dizaine d'architectures sans problème avec juste quelques macros.

Le passage de x86_64 à ARM est un non-problème comparé par exemple à la suppression d'OpenGL. Je pense en particulier à un code de calcul sur lequel j'avais bossé et dont le module de visualisation des résultats est en OpenGL. Actuellement le logiciel fonctionne n'importe où (càd sur n'importe quel système unix dont MacOS, linux, IBM AIX... et sur Windows). Si il y a pas moyen d'utiliser OpenGL sur mac, il y aura plus de version mac, c'est aussi simple que ça. En revanche compiler sur raspberry pi (donc de l'ARM), un mec l'a fait en quelques jours.
203
Citation de tguyfr :
Si j'ai bien tout compris, ils devraient s'appuyer sur Cocoa en attendant que Swift prenne, car c'est un langage très jeune, en profitant de la transition pour virer OpenCL/GL.

MacOS prévois sur le long terme de se passer d'Objective-C au profit de swift.
De remplacer Cocoa par SwiftUI.
Et de se passer d'OpenGL au profit de Metal, un gestionnaire 3D se basant directement sur le framebuffer mais totalement fermé (OpenGL est libre).
Le lien que vous avez passé explique très bien la politique d'Apple. Créer des technologies de remplacement mais totalement fermé (donc non multi plate forme).

Citation de Shreddator :
Franchement, pour avoir fait les deux, c'est souvent plus simple de porter un produit sur une nouvelle architecture que sur un nouveau système d'exploitation.

En général je suis d'accord avec vous. Mais si votre application utilise des primitives de bas niveaux ça peut-être très problématique.

Citation :
Une bonne partie des logiciels du monde libre se compilent sur une dizaine d'architectures sans problème avec juste quelques macros.

C'est vrai aujourd'hui, mais pour les premières versions de Linux et BSD ce n'était pas du tout le cas. Il faut voir qu'il y a des années de développement et d'expérience afin d'obtenir un système suffisamment modulaire qui permet de compiler indifféremment sur des architectures différentes. Comme Apple a déjà de l'expérence sur ARM (avec IOS) il se pourrait que cela soit transparent. Mais je demande à voir. Si on regarde le Hurd par exemple, cela fait 30 ans qu'il existe et qu'il ne compile que sur x_86 (bon après il y a la puissance de feu d'Apple derrière, ce n'est pas comparable par rapport à une petite équipe de bénévole mais le parallèle est intéressant car les deux systèmes utilisent le même micro-noyau).

Citation :
Si il y a pas moyen d'utiliser OpenGL sur mac, il y aura plus de version mac, c'est aussi simple que ça

Ça c'est un vrai problème et c'est même le problème majeur des nouvelles versions de Mac. Jusqu'à présent le système respectait à peu près les standard unix et les grands standards de développement (commande shell d'administrateur standard, bibliothèque de dev standard comme OpenGL etc ...). Aujourd'hui ça devient de plus en plus compliqué de faire des logiciels multi-plate forme à cause de l'éloignement de ces standards et de la mise en oeuvre de technologie propriétaire ne fonctionnant que sous Mac. Vous ne pouvez même plus utiliser des commandes systèmes unix de base sous MacOS, vous ne pouvez plus utiliser le cron (ils l'ont remplacé par un truc imbuvable beaucoup moins puissant et moins performant).
Bref, il faudra faire avec les technologies Apple et si vous n'êtes pas content, vous partez vers un autre système.
204
@Shreddator apparemment l'abandon d'OpenCL/GL était une spéculation pré-WWDC, si j'ai tout compris ils vont le maintenir.
@owuzan : Swift comme Cocoa semble construit sur Objective-C. Ce langage tourne sur tous les supports Apple évidemment, mais aussi sur Ubuntu et d'autres distributions de Linux (même si moins officiellement). Ce n'est pas un projet fermé Apple, mais plutôt un projet fortement soutenu par Apple, mais aussi IMB et Google (et d'autres). Ce n'est donc pas un langage fermé mais bien de l'open source. Comme je l'écrivais ci-dessus, on est dans un modèle économique de transition, entre capitalisme et collaboration communautaire.
205
OpenGL est déjà partiellement abandonné et déconseillé. L'abandon définitif n'est qu'une question de temps.

@tguyfr, avant de parler, essaie de compiler une application Objective-C/Cocoa sous Linux/Windows... Cocoa n'est pas libre. Il y a bien une implémentation partielle, non pas de Cocoa mais de son ancêtre (NextStep/OpenStep), GnuStep. Mais on est loin d'une compatibilité à 100%. Apple ayant fait évoluer cette techno depuis le retour de SJ et OSX. Les seuls moments où Apple fait du libre, c'est quand il repompe des logiciels qui ne sont pas de lui (WebKit venant de KHTML, Darwin venant en partie de BSD, CUPS, etc).

Ce qui a été souligné et que j'ai mal exprimé au départ, c'est bien le fait qu'Apple enferme ses clients ET les développeurs. Les petits n'auront pas les moyens ni le temps de refaire une application identique mac/pc car ils devront presque TOUT réécrire. En gros c'est comme faire deux applications au lieu d'une et quelques modifications.
Toutes les technologies proprio d'Apple sont bien faites dans le but de cannibaliser les marché.
Peut être qu'un jour la loi anti-trust américaine interdira à Apple de continuer, comme ils l'avaient fait pour AT&T par exemple (et pour moins que ça).
Huawei s'est bien fait planter par Trump à cause d'un concept similaire à la puce T2.
206
La facilité de portage entre différentes archi n'est pas du tout évidente selon le programme. Plus le programme est optimisé pour de bonnes performances (ce qui est le cas de beaucoup d'applis audio et traitement d'images) plus il est lié à une architecture, notamment car les instructions SIMD ne sont pas du tout équivalentes d'une archi à l'autre.
Dire que c'est facile c'est vrai pour la majorité des applis lambda, mais faux dans le domaine de l'audio.
207
Citation de tguyfr :
Ou alors Apple vraiment bien fait les choses pour que les gros aient bénéficié de formations de pointe afin que les portages soient, sinon immédiats, du moins très rapides. D'ailleurs je ne suis pas utilisateur du Cloud d'Adobe par exemple, mais comment est-ce que ça fonctionne ? Les softs restent dans le nuage et finalement le terminal importe peu, ou il y a une partie du soft installé sur la machine et l'autre qui reste sur serveur ? Parce que finalement, ce sera peut-être plus rapide qu'on ne le pense avec ce modèle de service.

Non, le cloud Adobe, c'est juste une sorte de centre de contrôle et de partage
Sinon, c'est bien une vingtaine de Giga d'applications tout à fait classiques qui sont résidantes et totalement indépendantes du cloud ( à part pour la protection anti piratage qui est facilement contournable )

UAD API Vision Console Emulation  : mon avis

Vous avez demandé la Lune ?  Le DAW d'Universal Audio

La précision suisse  moniteurs PSI A21M

Studer A5 :  mon avis

UAD Ampex ATR-102 : mon avis

[ Dernière édition du message le 27/06/2020 à 19:09:44 ]

208
Spoiler - Cliquer ici pour lire la suite

@bda65 back again and again :bravo: Je ne risque pas de compiler quoi que ce soit, ce n’est pas mon domaine. Personne n’a dit que Cocoa était une techno ouverte, ce qui n’est pas le cas de Swift. A terme, je pense qu’Apple vise le succès de ce langage (et l’abandon de Cocoa ?). Ils ont dû intégrer la leçon d’un environnement trop fermé et doivent tenter d’ouvrir la boîte, au contraire de ce que tu suggères. La loi antitrust que tu évoques ne concernera pas un bout de code, ce dont le gouvernement fédéral se fout totalement, mais une position dominante sur les marchés financiers qui pourrait conduire au démantèlement de l’entreprise quand elle sera jugée trop grosse. Apple doit être très attentive à son statut pour ne pas effrayer la justice. D’un autre côté, les GAFAM sont un moteur de la puissance américaine, et démanteler l’une amènerait à toucher aux autres... Enfin pour la T2 Huawei il ne t’a pas échappé que ce n’était pas une entreprise américaine, mais chinoise, et qu’il y a comme un conflit larvé entre les deux, avec au centre justement Huawei et des questions de sécurité des réseaux 5G. Rien à voir avec Apple donc.
209
@tguyfr: Encore une fois, tu dérives. Cocoa n'est pas un langage mais plus de l'ordre d'une bibliothèque fournissant une API (contenant des fonctions comme "créer_une_fenêtre", "ajouter_un_menu", etc). Swift est un langage ouvert, mais pas SwiftUI (qui remplace Cocoa). Donc ce que tu as dis dans ton précédent message ne colle pas. Le fait qu'un langage soit libre ne suffit pas. Les bibliothèques ne le sont pas donc on est bien sur une techno fermée. AT&T était aussi un "moteur de la puissance américaine"...
Pour Huawei, c'est bien le même genre de techno que T2. Donc pourquoi l'interdire à un Chinois mais pas à Apple? Tu refuses que l'on compare quoi que ce soit avec Apple. Si c'est Apple c'est bien sinon c'est mal. Ça n'avait rien à voir avec la sécurité, ça c'était juste la comm de Trump "il y a un mouchard dedans". Comme pour Apple, la T2 n'a aucun lien réel avec la sécurité. Sauf peut être à protéger les finances d'Apple.
210
@bda65 non TU dérives et je te réponds. Je ne parlais pas de SwiftUI, ne déforme pas mes propos. On peut aussi comprendre qu’une entreprise privée soit vouée à faire du profit et verrouille ses produits en partie. Ce que tu suggères est absurde en fait (ils sont très méchants parce qu’ils ne fournissent pas le code source de leurs produits). Et Adobe ? MS ? Google ? etc. Ce sont des technologies ouvertes ? Ton argument n’a aucun sens.
De même que ton propos sur Huawei montre que tu vis dans une bulle. Ouvre le journal et renseigne-toi sur les relations stratégiques entre les deux pays :facepalm: Je ne refuse que l’on compare rien, je ne sais pas d’où tu sors ça. Ce sont précisément les comparaisons qui nous permette de comprendre le monde tel qu’il est, pas tel qu’on le voudrait.
Si tu veux revenir au sujet, tu peux toujours chercher des liens, de la doc et des témoignages sur le passage du Mac à l’ARM, c’est le titre du sujet.