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
(656 avis produit)
Produits 456 456
Actu 143 143
Articles 10 10
Tutoriels Tutos 41 41
Avis 656 656
Petites annonces Annonces 74 74
Forums 5 196 5,2k

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

  • 474 réponses
  • 57 participants
  • 24 375 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
191
Incroyable j'ai lu tous le fils (190 posts).
Quelques remarques générales:
  • Il est difficile de faire des logiciels portables d'une plate forme à l'autre à cause du langage utilisé et de la chaîne de compilation. Objective-C n'est pas portable contrairement à ce que l'on pourrait croire. L'implémentation d'Apple est très différente de l'implémentation originale GNU-Step (pour ceux qui connaissent) car ils ont ajoutée des modifications massives aux langages (Objective-C n'est pas standardisé contrairement au C). Pour avoir fait une étude de faisabilité (sur un logiciel de gestion donc rien à voir avec la musique), la seul implémentation portable qui fonctionnait sur les systèmes Window, Linux, BSD, MacOS-X étaient soit en utilisant directement le langage C avec les bibliothèques standards (Gtk/Sqlite ...) ou le langage Vala. Et dans ce cas il fallait utiliser le gestionnaire de paquet libre Homebrew sous Mac et l'environnement MSYS2 sous Windows. Dans le cas du langage C, il fallait faire tous les Makefiles à la main avec certaines directives en début du script pour détecter le système d'exploitation. Le nouveau langage d'Apple (swift) est encore pire pour la compatibilité (c'est bien beau d'avoir un compilateur libre mais sans bibliothèque multi-plate forme autour ça ne sert à rien). Il reste bien sûr le langage Java, mais il est désactivé par défaut sous Mac à cause de nombreux problèmes de sécurité.
  • L'obsolescence des logiciels est très importants (voir d'ailleurs les propositions des lois en ce sens). Et effectivement on risque d'obliger les utilisateurs à racheter des licences car leurs anciennes versions de logiciels ne sont plus prise en charge dans la nouvelle plate-forme.
  • Certains utilisateurs de Mac affirment que le portage d'une architecture vers l'autre se feraient en quelques jours seulement. Ce n'est pas aussi simple que cela, surtout pour des logiciels de musique qui touchent de près la configuration matériel. Une personne parlait des normes little indian et big indian par exemple. Ça peut-être un sacré problème à résoudre même s'il me semble justement que l'architecture arm prend en charge les deux normes. Mais il y a des tas d'autres problèmes matériels qui vont s'imposer.
  • Ensuite on utilise pas un logiciel de musique de la même manière sur un ordinateur portable que sur un iphone. Donc je ne crois pas que cela favorisera un portage d'application d'un type d'appareil vers l'autre.
  • Certaines personnes parlent d'icloud. Ok mais les logiciels de MAO ne sont pas des applications client/serveur (contraintes matériels, performance audio, temps réel ...). Ils sont installés en dur sur l'appareil. On peut s'en servir pour importer des plugins ou d'autres choses mais par exemple on ne pourra pas avoir un logiciel comme Logic Pro fonctionnant sur l'icloud.

Ce sont toutes ces raisons, entre autres, qui font que depuis plusieurs années je n'utilise que du hardware (j'ai un Tascam DP-24 pour enregistrer). Alors j'utilise bien quelques logiciels libres (Rosegarden, LMMS) mais uniquement pour faire de la musique retro sur des petits jeux de plate forme.
Perso, je suis sous Linux depuis plus de 20 ans, la base de MacOS-X est libre (Micro noyaux Mach+couche BSD) mais beaucoup d'implémentations sont propriétaires (interface graphique Cocoa, beaucoup de commandes qui s'éloignent du standard unix) et pour avoir été confronté à ce système en tant que programmeur, cette politique mélangeant libre/propriétaire me gène. Et surtout justement, elle empêche le programmeur de créer facilement des logiciels portables et l'enferment dans l'eco-sustème propre à Apple.
192
Il y a un truc que je ne pige pas, les softs GNU sont en général portés sur toutes les plateformes. C'est de part leurs conceptions de départ, la façon dont ils sont codés, le langage de programmation... Il y a quelques temps j'ai téléchargé la version mac du midicontrolcenter d'arturia, pour voir. Il y a deux dossiers:
MIDI Control Center-1.11.1-Darwin-resources.pkg
MIDI Control Center-1.11.1-Darwin-templates.pkg
Darwin, c'est bien l'OS unix like https://en.wikipedia.org/wiki/Darwin_%28operating_system%29
Qu'est ce qui empêche de compiler pour un linux, la volonté?

[ Dernière édition du message le 27/06/2020 à 12:56:17 ]

193
Citation de magasin :


Oui, je suppose que:

[*]La fibre ou plutôt la 5g va se généraliser ainsi que le télétravail et l’école en ligne (avec des "discriminations" qui doivent être mesurées). Le cloud computing va sûrement coûter moins cher, en tout cas, on opposera: ferme de rendu plus coût des logiciels vs cloud computing avec licences incluses, services supplémentaires et scalabilités. Le moins cher remportera la palme.[newline]


Le cout le moins eleve est la machine, le plus eleve l'humain. Le cloud sur un prod que je ne citerais pas, le cout en rendu par semaine etaient pas loins de celui d'une berline de luxe.

Machine learning est le terme adequat.
IA. Il n'y a pas d'inteligence artificielle. Uniquement des data qu'on lui donne a moudre.

[ Dernière édition du message le 27/06/2020 à 13:02:08 ]

194
C'est fou comme ça part dans tous les sens mais toujours de plus en plus loin du sujet. Il faudrait juste essayer de se documenter auprès de vraies sources.
Sur les perfs d'une architecture ARM avec des serveurs (non Apple donc, mais très exigeants) : https://www.anandtech.com/show/15578/cloud-clash-amazon-graviton2-arm-against-intel-and-amd/10
Plus proche de nos préoccupations, les réflexions du dev d'Audio Damage à propos de ce tournant : https://www.patreon.com/posts/definitely-whole-38639438 Le point n°3 est très intéressant pour nous, puisqu'il prédit que les early adopters n'auront qu'une très faible partie des softs et notamment des plugins fonctionnant sur ARM. On sera certainement dans une phase un peu vierge où un studio ou un artiste ne pourra pas s'appuyer sur un Mac ARM pour fonctionner. Le point n°4 est aussi intéressant du point de vue des devs et concerne le prix des softs, plutôt bas sur iOS et qui pourrait baisser sur MacOS.
Sur le thread consacré au sujet sur GS, un développeur expérimenté affirme que le portage se fera automatiquement, à l'exception de petits fragments, soulignant que de boîtes comme Fabfilter développent déjà leurs produits conjointement pour iOS et Mac.
Pour le code (j'ai beaucoup de lacunes en la matière), Apple a développé Swift, qui est d'après ce que j'ai compris un langage "facile" et relativement universel : https://fr.wikipedia.org/wiki/Swift_(langage_d%27Apple)

[ Dernière édition du message le 27/06/2020 à 15:55:37 ]

195
bref, la transition va être bordélique. les studios et ingé sons sous macs ne vont pas changer de matos tout de suite en terme d'info, c'est sûr.

l'enjeu du codage est de taille, et c'est le temps qui est primordial. Les boites qui réussiront à rendre leurs softs compatibles vite seront gagnantes, mais ça va coûter cher (personnel à payer), il faudra du monde.

et ça va encore augmenter la bataille mac pc, cette histoire.........

Soundcloud

facebook 

Nouvelle chaine you tube!

Twitch autour du son et du home studio

 

 

 

196
"Ça va coûter cher" : pas sûr, en tout cas sur une petite structure comme la majorité des devs de plugins, il n'y a pas grand monde. Comme le dit le mec de Damage Audio, lui va se mettre à plein temps sur la transition, son collègue sera sur le reste. Sans doute que pour les projets plus ambitieux comme les STAN, il y aura beaucoup plus de travail. D'un autre côté, c'est leur métier, ils vivent de ce type d'évolution et de la concurrence qui se crée à ces moments-clés (ce sera un argument publicitaire). Pour nous, utilisateurs, cela augure effectivement d'une zone grise plus ou moins longue, comme on la connaît à chaque évolution majeure du système. Catalina a pris un an à peu près (j'exagère ?) pour que tout le monde soit au diapason. Là ce sera peut-être plus long.

[ Dernière édition du message le 27/06/2020 à 16:04:52 ]

197
Citation :
Qu'est ce qui empêche de compiler pour un linux, la volonté?

Les bibliothèques propriétaires de MacOS-X comme cocoa pour l'interface graphique. Tant que ces bibliothèques sont propriétaires on ne pourra pas faire de portage.
Citation :
Sur les perfs d'une architecture ARM avec des serveurs

Ton premier lien parle de structure ARM développés par Amazon. Amazon a une grande expérience des serveurs et de l'ARM en général (serveur, liseuse Kindle ...). Et effectivement je n'ai aucun doute sur le fait que les architectures ARM pourront rivaliser avec des intel ou amd sur le long terme (que ce soit en serveur ou pour d'autres besoins).
Ton deuxième lien est intéressant aussi. Il précise que les logiciels comme LogicPro et GarageBand par exemples seront supportés immédiatement. Mais c'est normal, ce sont des logiciels développés par Apple, à mon avis cela doit faire plusieurs mois qu'ils travaillent sur ce portage. Et à mon avis Apple va se débrouiller pour que leurs logiciels soient optimisés sur leur nouvelle architecture.
Pour des logiciels tiers, provenant d'autres éditeurs qu'Apple on verra concrètement ce qui se passe au moment voulu.
Citation :
Apple a développé Swift, qui est d'après ce que j'ai compris un langage "facile" et relativement universel

Swift est effectivement un langage facile à apprendre et son code source est ouvert (donc universel). Mais ce que je disais dans le post précédent c'est qu'un logiciel sans bibliothèque tiers ne sert à rien. Par exemple, il faut utiliser des bibliothèques graphiques pour faire un logiciel, or sur MacOS-X il y a cocoa (qui est propriétaire et fermé) mais sous les autres systèmes il n'y a pour l'instant aucun widget graphique fonctionnant convenablement avec Swift. Donc Swift tout seul ne sert pas à grand chose.
198
Je pense que la transition sera beaucoup plus longue que 2 ans.
Oui : la transition va être relativement rapide pour les Macs destinés au non-professionnels : les iApps, le suites bureautiques, ect... sont déjà quasiment toutes ready. Il y aura des manques mais qui seront résorbés au fur et une mesure . Donc on peut penser que pour les utilisateurs qui n'ont pas besoin d'avoir un version MacARM performante d'une appli spécifiques, ça va aller très vite. Et c'est pour ça que des MacARM basiques seront en vente dès 2021.
Par contre, la transition sera beaucoup plus lente pour toutes les applis métiers ou "spécifiques" . Le gros morceau , ce sera la suite Adobe mais ya pas mal de logiciels spécifiques -notamment en MAO - qui vont demander du temps.

Si Apple se permet de sortir de nouveaux Mac avec des CPU intel, c'est justement pour que cette clientèle-là puisse continuer à bosser.

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 à 16:17:47 ]

199
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.
200
@owuzan : cela dépasse mes compétences, mais cet article donne des clés pour comprendre ce qui se trame au niveau de Cocoa https://shapeof.com/archives/2020/6/educated_guesses_about_a_mac_transition_to_arm.html
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.