Apple rappelle que High Sierra sera le dernier macOS pleinement compatible avec les apps 32 bits
Apple prévient ce soir que macOS High Sierra sera la dernière version de son système d'exploitation à exploiter « sans compromis » les applications 32 bits. Les futures moutures de macOS sont susceptibles de ne plus les prendre en charge, ou alors mal.
C'est pourquoi le constructeur recommande aux développeurs de distribuer leurs applications en 64 bits afin qu'elles puissent fonctionner sans encombres avec les futures versions du système. Ce rappel n'est pas une surprise : fin juin, Apple annonçait déjà la même chose (lire : High Sierra, dernière version de macOS à accepter les apps 32 bits « sans compromis »).
Par ailleurs, à partir de janvier 2018, les nouvelles applications soumises au Mac App Store devront être en 64 bits. Les mises à jour de logiciels distribués par la boutique d'Apple devront elles être fournies en 64 bits à partir de juin 2018.
Donc High Sierra sera mon dernier OS Apple pour l'instant… (CS6 oblige)
@Madalvée
Pareil
Si, vous utilisez Photoshop, il est compatible 64 bits depuis, au moins CS5 dans mes souvenir.
Pour les autre je ne sais pas par contre.
Sinon, vous pouvez essayer la suite de logiciel Affinity ils sont une bonne alternative a Adobe Photoshop, Illustator et InDesign. (pour ce dernier il faudras quand même attendre courant 2018)
@Madalvée :
CS6 existe en version 64 bits également =)
Et ben c’est tant mieux.
Les noobs, du balais.
Tant mieux il est temps ! Les dev ont eu le temps de se mettre à la page notamment adobe !
C'est marrant, quand ils ont sorti High Sierra, Apple a cassé la compatibilité avec la suite Final Cut Studio (pas la version X...) sous prétexte qu'elle était en 32 bits. Alors qu'elle aurait très bien pu continuer à fonctionner sous cet OS mal né...
Ce serait bien qu'Apple, au lieu de decreter la chose comme un dictateur explique un peu la raison de cette exclusion qui semble des plus arbitraires...
Parce que mine de rien, une application 32bits ça tourne tres bien sur un MacOS 64bits et un processeur 64bits.. preuve en est... que c'est le cas actuellement.
Sinon, obsolescence programmées?
@C1rc3@0rc
Mais c’est compliqué de livrer les mêmes librairies en 32 et en 64
De maintenir l’environnement 32 bits
Si tu forces en 64 c’est plus simple pour Apple
Hop compilation de tout en 64 et basta....
@saoullabit
Avec tout le fric que ce fait Apple ? Elle a les moyens si elle le veut... maintenir des librairies 32 bits c'est possible... même si le système est 64 bits... Les OS open sources y arrivent sans difficulté. l'architecture Intel est mixte. Elle intègre Les primitives 32 bits dans des processeurs 64 bits. Apres il faut arrêter de prendre les gens pour des idiots... oui cela est une forme de marche forcée. Apres il n'est pas suspect que certains y voient une forme d'obsolescence programmée.
Mais bon si déjà Apple ne se donne pas les moyens de faire un contrôle qualité de ses OS et laisse passer des bugs gros comme des éléphants, on comprend qu'avec cette logique elle ait aussi la flemme de maintenir le 32 bits... Sa priorité est sa capitalisation boursière visiblement.
@saoullabit
Rappelles nous quel est le dernier Mac qui tournait avec un processeurs 32 bits?
Pourquoi Apple impose donc aujourd'hui l'abandon du 32bits alors que ça fait au moins 10 ans que tous les Mac sont en 64bits (et meme un peu avant puisque le PowerPC G5 etait en 64 bits)
@C1rc3@0rc
Non.
À une si large échelle, des contraintes sont nécessaires, sinon personne ne bouge jamais. En l’occurrence, Apple utilise sa position de force pour pousser le mouvement, et elle a raison.
@Shralldam
"et elle a raison."
Je ne suis pas certain de ça.
Apple travaille pour proposer d’excellents outils à ses clients ou pour pousser l’industrie au détriment de ses clients ?
La seconde option à l’évidence.
Il y a des façons moins radicales, moins détrimentales pour les clients, je pense.
Adieu QuickTime.
Adieu Carbon.
Et adieu à toutes les applications qui reposaient sur ces deux API.
Au fait, le lecteur DVD est toujours 32 bits dans High Sierra. oO
@Moonwalker
Apple a dû oublié cette app...
Psk c'est sûr, qui utilises des DVD ?
C'est tellement plus simple de partager/vendre des films super lourds via iCloud... (ironie)
Non mais sérieusement, Lecteur DVD est bien l'app que j'utilise le moins sur mon Mac. Mais j'en ai quand même besoin de temps en temps quand on me donne/vend un DVD pour le regarder. Ça me ferait donc chier qu'elle disparaisse :/
@mat 169, Si cela peut te rassurer un peu tu as pas mal de lecteurs tiers du style VLC pour ne pas le nommer qui marchent au moins aussi bien que le vieux lecteur DVD à l’abandon d’Apple‼️ ?
De toute façon, ça fait bien longtemps que c'est tout l'éco-système macOS avec les machines pour le faire tourner qui est à l'abandon.
Il n'y en a plus que pour les iBidules, bcp plus rentables et cible kikolool bcp moins exigeante que ces gens ayant besoin de la suite CS6.
@R1x_Fr1x
Parce que du côté du mac tout est déjà fait (avec le succès que l'on connaît ) tandis que du côté d'ios tout est à faire.
En terme de croissance (entreprise, actions, etc) le mac a fait son chemin.
Vous avez vu la blague du Gorafi cette semaine ?
" Obsolescence programmée: Apple parvient à réduire la durée de vie d’un iPhone de 3 ans à 8 mois."
Ils sont toujours plein de sagesse ceux-là.
@gela
Oui un vrai média sérieux et indépendant
Ça change
?
Je trouve ça bien perso. Ça fait certainement plus de 10 ans que tous les processeurs sont 64 bits et je me suis toujours demandé pourquoi encore aujourd’hui il y a tant de programmes encodés en 32 bits. C’est bien on aura un nouveau système avec des programmes eux aussi a jour. Ça permettra de faire le tri. Après il faut pas qu’Apple en profite pour virer certains utilitaires pratiques comme le lecteur CD
@Glop0606
"il y a tant de programmes encodés en 32 bits."
Parce que pour la majorité des programmes, qui donc n’utilisent pas plus de 2 ou 3 GB de RAM, adopter le 64 bit ralenti le fonctionnement et consomme plus de mémoire pour 0 bénéfice.
Pour Apple par contre, ça implique de maintenir toutes les API et librairies aux deux modes. C’est complexe et coûteux, les bugs sont différents parfois, ça nécessite le double de testing... pour une toute petite boite comme Apple c’est un coût difficile à justifier. Elle est assez grosse mon ironie ?
Ouai, bon, vu ce que fait Apple en ce moment, c’est peut-être une bonne chose. Et puis c’est une évolution logique, peut-être qu’un jour on aura des procs simplifiés ne supportant plus que 64 bits et basta.
@fte
Tu racontes n'importe quoi.
Faut arrêter une bonne fois pour toute avec la légende urbaine de la mémoire ram.
Oui un système 64Bits gère plus de Ram. Non ce n'est pas son unique intérêt.
Toutes les apps que j'ai eu qui sont passées au 64Bits tournent mieux sur la même machine.
La raison est bien simple, elle tient à la précision des calculs en 64Bits, entre les float et double notamment.
@LeGrosJeanLou
"La raison est bien simple, elle tient à la précision des calculs en 64Bits, entre les float et double notamment."
Et c’est moi qui raconte n’importe quoi. Il vaut mieux entendre ça que d’être sourd.
https://support.microsoft.com/en-us/help/15056/windows-7-32-64-bit-faq
Est-ce qu’il est fait mention de calculs ? De flottants ? Non. Pourquoi ? Parce que ça a autant a voir avec la choucroute que de la framboise râpée.
Une application 64-bit utilise des pointeurs (adresses mémoire) de 64 bits. Ce qui lui permet d’adresser plus de 4 GB de mémoire. C’est tout. Mais ce qui double la taille des pointeurs, donc leur encombrement, donc la quantité de mémoire nécessaires pour toutes les structures contenant des pointeurs, donc l’encombrement en cache et la bande passante mémoire - processeur, donc impacte négativement la performance globale. Bénéfice ? Adresser plus de 4 GB de mémoire, je l’ai dit plus haut. C’est tout. Un application qui n’utilise pas autant de mémoire perd et ne gagne rien.
Les applications de 1990 qui utilisaient des flottants 80 bits étaient des applications 80-bit sur des systèmes 80-bit à ton avis ? Que dire des PowerPC 32 bits mais dotés d’AltiVec 128 bits ?! Applications 128-bit et système 128-bit ?
Purée ces newbs qui essaie d’en remonter aux pros, c’est d’un comique.
@fte
Un Double est stocké sur 64Bits coco... c'est la base.
Donc un Double passe par une seule instruction en 64Bits, mais 2 en 32Bits. Donc l'exécution est plus rapide.
Maintenant tu peux continuer de faire le malin si tu veux, ça change rien au fait que t'y connais que dalle en informatique.
https://doc.ubuntu-fr.org/comparatif_32bits_et_64bits
@LeGrosJeanLou
Crois ce que tu veux, je n’en ai strictement rien à faire. Tu peux même croire en la numérologie ou n’importe quelle fadaise de ton choix, pour ce que ça m’importe.
@fte
Et puis c'est marrant de faire appel à des puces équipées de coprocesseurs arithmétiques pour m'expliquer qu'on a pas attendu le 64Bits pour faire du calcul de précision...
On pourrait aussi parler des cartes graphiques qui tournent en 512Bits, parce que si le seul intérêt du 64Bits c'est l'augmentation de la mémoire adressable, à quoi ça peut bien servir de pouvoir adresser 2^512 octets ?
@LeGrosJeanLou
"à quoi ça peut bien servir de pouvoir adresser 2^512 octets ?"
À rien.
C’est pour ça qu’aucun hardware ni aucun logiciel sur Terre ne le fait.
Enfin pour comprendre ça bien sûr il faut comprendre ce qu’"adresser" veut dire, bien entendu.
@fte
"À rien."
On est bien d'accord...
Du coup tu veux bien expliquer l'intérêt du 512Bits sur une CG ? Tu vas me répondre "à rien" encore, ou bien tu vas enfin confronter tes contradictions à la réalité ?
@LeGrosJeanLou
Bien entendu que ça sert à quelque chose gros malin.
Mais c’est sans rapport aucun avec cette question de processus 32-bit ou 64-bit. Seulement ça tu le ne comprend pas, parce que dans ta compréhension limitée un bit est un bit et l’usage on s’en balance.
Tu n’as pas non plus l’air de comprendre la différence entre la mémoire virtuelle et l’espace d’adressage, et les channels mémoire et largeurs de bus.
Tu sais quoi ? Tu es libre. Je ne vais pas essayer de nier ta liberté d’avoir tord. C’est ton choix apparemment, donc grand bien te fasse. On ne peut pas faire boire un âne triple bâté qui n’a pas soif.
@fte
"Tu n’as pas non plus l’air de comprendre la différence entre la mémoire virtuelle et l’espace d’adressage, et les channels mémoire et largeurs de bus."
C'est toi qui te focalise bêtement sur l'espace d'adressage des puces 64Bits...
On a jamais eu besoin du 64Bits pour avoir plus de 4Go de RAM... Intel proposait d'ailleurs un proco 32Bits dont l'espace d'adressage était étendu à 36Bits (soit 64Go de RAM max).
Alors arrête deux minutes ta fixette sur l'espace d'adressage et penches toi sur les autres différences qui existent entre les architectures 32Bits et 64Bits.
Tu comprendras alors peut-être pourquoi le 64Bits est plus performant que le 32Bits sur certains types de calculs, au lieu de les nier en bloc (comme un âne ?)
@LeGrosJeanLou
?♂️
Cette conversation est inutile. Bon dimanche.
@fte
Tant que tu resteras campé sur tes positions en effet...
Relis ton premier commentaire et tu comprendras peut-être comment on en est arrivé là.
Parce que dès qu'on parle de 64Bits, y a toujours un Gus comme toi pour expliquer que le 64Bits permet de gérer plus de RAM et rien d'autre. Ce qui est faux à plus d'un titre, cf les puces Intel qui géraient déjà 64Go de RAM en 32Bits ou la nécessité d'avoir plus de 32Bits par paquet pour le calcul de précision (et la nécessité de créer un coprocesseur arithmétique pour ce type de calcul).
Alors maintenant, à savoir si toutes les apps gagneraient à passer au 64Bits il est évident que non. Mais l'équation globale ne se résume pas à ça. Et on peut sans mal imaginer qu'une puce libérée des archaïsmes des précédentes architectures serait plus efficace que les bricolages actuels.
Comme le rappelle @harisson ça fait 15ans qu'on a cette conversation, et 15ans qu'on entend que le 64Bits ne sert à rien d'autre que de gérer plus de mémoire... Alors forcément ça commence à lasser.
@fte
"A common misconception is that 64-bit architectures are no better than 32-bit architectures unless the computer has more than 4 GiB of random-access memory.[33] This is not entirely true:
- Some operating systems and certain hardware configurations limit the physical memory space to 3 GiB on IA-32 systems, due to much of the 3–4 GiB region being reserved for hardware addressing; see 3 GB barrier; 64-bit architectures can address far more than 4 GiB. However, IA-32 processors from the Pentium Pro onward allow a 36-bit physical memory address space, using Physical Address Extension (PAE), which gives a 64 GiB physical address range, of which up to 62 GiB may be used by main memory; operating systems that support PAE may not be limited to 4 GiB of physical memory, even on IA-32 processors. However, drivers and other kernel mode software, more so older versions, may be incompatible with PAE; this has been cited as the reason for 32-bit versions of Microsoft Windows being limited to 4 GiB of physical RAM[34] (although the validity of this explanation has been disputed[35]).
- Some operating systems reserve portions of process address space for OS use, effectively reducing the total address space available for mapping memory for user programs. For instance, 32-bit Windows reserves 1 or 2 GiB (depending on the settings) of the total address space for the kernel, which leaves only 3 or 2 GiB (respectively) of the address space available for user mode. This limit is much higher on 64-bit operating systems.
- Memory-mapped files are becoming more difficult to implement in 32-bit architectures as files of over 4 GiB become more common; such large files cannot be memory-mapped easily to 32-bit architectures, as only part of the file can be mapped into the address space at a time, and to access such a file by memory mapping, the parts mapped must be swapped into and out of the address space as needed. This is a problem, as memory mapping, if properly implemented by the OS, is one of the most efficient disk-to-memory methods.
- Some 64-bit programs, such as encoders, decoders and encryption software, can benefit greatly from 64-bit registers,[citation needed] while the performance of other programs, such as 3D graphics-oriented ones, remains unaffected when switching from a 32-bit to a 64-bit environment.[citation needed]
- Some 64-bit architectures, such as x86-64, support more general-purpose registers than their 32-bit counterparts (although this is not due specifically to the word length). This leads to a significant speed increase for tight loops since the processor does not have to fetch data from the cache or main memory if the data can fit in the available registers.
@fte
« Crois ce que tu veux, je n’en ai strictement rien à faire. Tu peux même croire en la numérologie ou n’importe quelle fadaise de ton choix, pour ce que ça m’importe. »
Le problème n’est pas de croire ou pas.
Le problème est que ce qu’il dit est vrai
Attention de pas être le newbie arrosé.....
@fifounet
"Le problème est que ce qu’il dit est vrai "
Certes. Mais pas sur le bon sujet.
Presque.
Enfin, le coup des processus 64-bit et des double 64-bit, c'est pas tout à fait "vrai". Par exemple.
Ça va être trop cool, du jour au Lendemain des tonnes de petits utilitaires qui marchent très bien et qui sont indispensables ne vont plus pouvoir se lancer...
C'est fou comme pour enlever des trucs ils sont forts, rapides et réactifs.
Par contre pour debuguer un minimum y a plus personne !
Derniere version à faire tourner "sans compromis" les applications 32bit.
Doit-on comprendre que le prochain MacOS pourrait quand même les faire tourner mais "avec" des compromis???
Sinon que vient faire cette précision "sans compromis"???
"Apple rappelle que High Sierra sera le dernier macOS "
On commençait à s'en douter.
Ça craint, j'ai 87 applications qui sont en 32 bits. Parmi elles il y en a dont je me sers régulièrement. Pour savoir quelles sont vos en applis en 32 bits, allez dans "À propos de votre Mac">Rapport système>Logiciels>Applications, mettez la fenêtre en plein écran, cliquez sur la colonne 64 bits(Intel) et vous aurez toutes les applis 32 bits regroupées ensemble.
Depuis le temps que cet abandon du 32 bits est dans les tuyaux et qu'Apple a prévenu les développeurs, on ne peut vraiment pas dire qu'Apple, pour ce sujet précis, a eu un comportement dictatorial vis à vis de ces derniers ou des usagers.
Entre les différentes mises à jour système ou des logiciels encore activement développés, les solutions trouvées pour les logiciels abandonnés, il ne me reste finalement que peu de softs ou possédant encore quelques process 32 bits sous High Sierra, au-delà du Lecteur DVD d'Apple :
- XLD, mais le développeur a toujours dit que ce serait simple pour lui de passer en 64 bits, mais qu'il préférait une plus large compatibilité de machine. Bref pas trop d'inquiétudes à avoir.
- Finderpop, et là je n'ai plus trop d'espoir avec le prochain système. Et pas de remplaçant, même édulcoré, en tête.
- Synology Cloud Station, étonnamment. Mais on peut espérer qu'une grosse boite comme çà n'aura pas trop de difficultés a basculer en 64 bits quand il le faudra.
- Pulse secure, là aussi, très étonnant, et même constat que pour Synology.
- Des process Dropbox, encore en 32 bits, mais pas d'inquiétudes là aussi.
Aucun argument pour le faire si ce n'est encore réduire les moyens alloués à macOS dont ils vont bien réussir à avoir la peau au profit d'un iOS tordu et torturé afin de s'adapter à un usage avec un clavier et une souris.
Est-ce que iWeb est en 64 bits?
hahahahahahaha
C'est toujours amusant de voir les déchirements 32 bits vs 64 bits presque 15 ans après l'introduction de l'Athlon64 ^_^
@harisson
On pourrait supposer après tant de temps que la question serait à peu près cernée, mais non. Il y en a encore pour amalgamer le modèle programmeur, les registres et ALCUs, la largeur de bus et je ne sais trop quoi d’autre.
Le plus marrant c’est qu’ils te démontrent qu’ils ont raison en te sortant n’importe quoi du moment qu’il y a 64 dedans. Heureusement qu’il n’y a pas 64 nains de Blanche-Neige...
Je me souviens des mêmes prises de tête sur fcsm il y a 15 ans. C’était déjà très nul.
@fte
"Il y en a encore pour amalgamer le modèle programmeur, les registres et ALCUs, la largeur de bus et je ne sais trop quoi d’autre."
S'il y en a bien un ici pour faire des amalgames c'est toi, en réduisant l'architecture 64Bits à son espace d'adressage... Alors que la taille du paquet qui passe de 4 à 8 octets est de loin l'amélioration la plus significative de cette architecture.
Tu seras d'ailleurs certainement étonné d'apprendre que la majorité des puces 64 Bits actuelles n'adressent même pas les 2^64 octets de mémoire.
Tu devrais lire l'article que je t'ai mis en lien au sujet des différences de performances entre un système 32 et 64Bits. Tu verras qu'avec des exemples concrets c'est beaucoup plus clair. Et c'est autre chose qu'un forum de Q&A...
@fte
J'ai hâte de voir les prochaines prises de têtes entre bits vs qubits (pourvu que je sois encore vivant quand ça démarrera ^_^).
@harisson
Pas besoin d’attendre pour se régaler de belles prises de tête, juste considère le vaste topic de l’IA. Déjà, ce qu’on appelle communément de l’IA n’a en réalité rien à voir avec de l’IA, les bases de connaissances, moteurs d’inférence, deep learning et autres systèmes "neuronaux" (qui ne le sont que par lointaine analogie)...
Le truc de base qui manque généralement, c’est le vocabulaire. Les gens ne savent pas ce que ces appellations recouvrent. On arrive ainsi à des amalgames de notions sous une même bannière, et c’est ensuite la croix et la bannière de corriger le tir avec des termes correctement utilisés et définis. Le premier document que je donne à mes étudiants est systématiquement un glossaire avec tout le vocabulaire du cours. C’est essentiel d’avoir un langage commun pour avoir une conversation éclairée. La culture Google n’aide guère, on y trouve autant d’excellents contenus que de garbage bourré d’amalgames. Même la littérature professionnelle n’y échappe pas, au point que parfois des définitions et termes sont revus pour correspondre à la croyance populaire.
Pages