Jump to content

Sethenès

Members
  • Posts

    2,807
  • Joined

  • Last visited

Everything posted by Sethenès

  1. Du nouveau ... Apple s'est tournée vers l'instance d'appel (9ème circuit) et a obtenu le gel de l'injonction décidée par la juge Rogers jusqu'à ce que la procédure en appel soit terminée. Source : https://www.zdnet.fr/actualites/apple-vs-epic-un-sursis-pour-la-modification-des-regles-de-l-app-store-39933863.htm Je me posais justement la question de la durée exacte donné par la cour à Apple et The Verge me semble plus précis, je cite "The stay, issued Wednesday afternoon, does not reverse the earlier ruling but puts enforcement on hold until the appeals court can fully hear the case, a process that will likely take months. “Apple has demonstrated, at minimum, that its appeal raises serious questions on the merits of the district court’s determination,” the ruling reads. “Therefore, we grant Apple’s motion to stay part (i) of paragraph (1) of the permanent injunction. The stay will remain in effect until the mandate issues in this appeal.” Ce n'est pas clair, c'est soit jusqu'à la fin des auditions (fully hear), je pourrais donc imaginer que le juge d'appel statue en deux temps. Soit jusqu'au prononcé du jugement d'appel car j'ai difficile à comprendre la portée juridique de l'expression "until the mandate issues". Source : https://www.theverge.com/2021/12/8/22814147/epic-apple-app-store-injunction-paused Le document de jugement ne fait que deux pages et ne contient même qu'une seule page "de fond". Je pense que la cour d'appel a plutôt pris une mesure "défensive" qui pourrait se résumer à "si on suspend, on ne fait rien de mal et on se donne le temps de juger sur le fond à l'aise.". Source : https://s3.documentcloud.org/documents/21150555/order.pdf
  2. Je ne l'ai jamais fait sur aucun RAID 5 et donc a fortiori pas sur le Syno non plus, à vérifier. Maintenant, en principe, si DSM te laisse faire la manip ... mais "re"vérifier.
  3. Excellente idée. D'autant plus que tu peux toujours revenir sur cette décision si le besoin s'en faisait sentir. De plus, depuis DSM 7, le switch est effectivement automatique en cas de détection d'un pépin par l'OS, ce qui minimise le temps de dégradation du RAID que Pehache évoquait. J'ai été surpris de constater que jusqu'à la version 6, cette procédure restait à charge de l'utilisateur quand bien même y a-t-il un disque spare. P.S. ; je suis toujours en 6.2 ...
  4. Les achats ont été phasés. D'abord le NAS et une extension avec 28 disques et ensuite dans un second temps, un extension supplémentaire avec 14 disques. C'était des investissements budgétés.
  5. Pour le premier point, effectivement le RAID est en plus dégradé pendant le phase de reconstruction. Le deuxième point est techniquement impossible parce que ce que tu fais, c'est de "sizer" les arrays RAID en fonction des besoins initiaux. Et puis au cours du temps, tu rajoutes progressivement des disques aux RAIDs qui sont presque full. C'est d'ailleurs l'énorme avantage du RAID 4 puisque les deux disques de parités sont fixes (ce sont les deux premiers) et que lors d'un ajout d'un nouveau disque au RAID, celui est préparé et ne contient que des 0 ... ce qui laisse la parité inchangée. C'est vrai aussi sur un RAID 5, mais là, comme les parités sont distribuées, il faut malgré tout les redistribuer et donc déplacer au moins 1/N blocs de parité (ou N = nombre de disques du RAID). Sans compter que justement, les disques spares sont attribués au RAID qui a un disque défectueux et qu'eux sont ben ... là où ils sont. Dans le cas du NetApp, la taille maximum du RAID est de 14 disques (qui d'ailleurs n'a rien à voir avec la taille des armoires qui font aussi 14 disques) puisque tu peux panacher et ajouter des disques supplémentaires provenant soit de l'unité de base (14 disques) soit d'une extension.
  6. Je suis ennuyé, mais pour moi, c'est clairement une très mauvaise idée. Effectivement le wiki français suggère de mélanger des disques de même modèles et de bains différents mais je préfère l'argumentation du wiki anglais qui n'évoque pas du tout l'idée d'un lot défectueux mais plutôt celle d'une durée de vie et aussi d'une vie similaire. Par exemple, un jour la clim de notre petit centre est tombée et la t° est montée à un tel point qu'on ne pouvait pas entre dans la pièce. Littéralement. On a ouvert les deux portes pour faire courant d'air, on a stoppé tout ce qu'on pouvait mais il est évident que tout à pris un "coup" (UPS, CPU, Disques, ...). En raison de ces deux faits cumulés (même durée de vie et même "vie"), les statistiques réelles montrent que la probabilité que 2 disques lâchent dans la même heure est 4x plus importante que le modèle théorique (loi exponentielle) ne le prédirait. C'est 4x plus mais ... 4 fois pas grand chose, ça reste pas grand chose. Source : Lien . Précisons encore qu'aucun des deux wikis n'évoque l'idée de disque de modèle (a fortiori de constructeur) différent. Ensuite, on peut raisonner comme en math en extrapolant aux limites le raisonnement. Au taf, on avait un NAS en RAID 4 (avec 2 disques de parités par array RAID), ce qui fait que si 3 disques lâchent, c'est la cata. Donc au maximum on aurait pu avoir 2 disques de chaque type. Sur un NAS de 42 disques, il est évident que de trouver 21 paires de disques "comparables "mais de fournisseurs différents c'est impossible. Par contre, ce qui est vrai, c'est que si les disques font initialement partie de la même commande, ici on a ajouter l'armure d'extension (pour passer de 28 à 42) après quelques années, donc les disques sortaient en principe d'un autre bain. Malgré tout, encore une fois disposer de disques de 21 bains différents est tout simplement impossible à réaliser dans la pratique. Nous n'avions "évidemment" pas un seul RAID sur les 42 disques (on devait en avoir 4 ou 5 arrays contenant entre 5 disques et 14) Plus fondamentalement, c'est (selon moi) promouvoir l'idée que le RAID est une solution qui augmente le "data integrity" (qui augmente l'intégrité des données) alors qu'au niveau professionnel, le RAID est surtout un outil de "data availibility" (qui augmente la disponibilité des données). Car il y a ici aussi une confusion. Le RAID, c'est du RAID 0, du RAID 1, 4, 5, 6, 10 et combien d'autres combinaisons plus complexes. Ici, ce que est toujours implicitement sous-entendus, c'est qu'on parle du RAID 5. Je me place bien dans cette utilisation particulière du RAID. Quand je parle de disponibilité, je peux prendre l'exemple des machines Unix que j'administrais il y a 20 ans sans RAID et sans hotswap. Sur une telle machine, un crash d'un disque aurait occasionné des indisponibilités partielles ou totales de 48 h (livraison du disque en J+1, arrêt et restore de la machine dans la nuit de J+1 à J+2). Alors qu'avec un RAID, il n'y a aucune interruption. Sur le fameux NAS à 42 disques, j'ai eu 2 défaillances qui se sont produites de nuit. Mais le système a automatiquement détecté le problème, pris l'un des disques spares (de réserve) et à commencer le reconstruction. Le lendemain, un technicien est venu avec le nouveau "disque" et à simplement remplacé (sans interruption, grâce au hotswap) le "disque" défectueux par un nouveau qui a simplement rejoint la liste des spares. Evidemment, l'OS de nombreuses machines est installé sur un RAID 1 (mirroring). Ceci dit, en plus de 20 ans, je n'ai jamais mais jamais eu le cas où il a été possible / nécessaire de faire usage de cette sécurité. A titre indicatif, si je ne dis pas de bêtise, c'est ce qu'il se passe dans les Syno. Il y a un volume caché au début de chaque disque qui est "utilisé" par le Syno et ce petit volume contient tout le système et tous les paramètres qui sont donc présents autant de fois que vous avez de disques. Même sur un disque "RAID 5" il y a ce petit volume caché en RAID 1 en début de disque.
  7. De très bonnes nouvelles ! On croise ce qu'il y a moyen de croiser
  8. Honnêtement, je ne sais pas que te conseiller. De base, je resterais sur des Ironwolf mais juste parce que c'est la même marque que celle que tu as actuellement et que j'imagine que le temps de réveil sera le plus proche de tes disques actuels. Et effectivement, je partais de l'idée de remplacer le disque suspect et pas toute la grappe. J'ajoute que j'ai déjà du aussi mélanger des disques légèrement différents. J'ai remplacé un WD RED de 3TB par un 5 et un autre par un 6 TB, même si c'est avec ces disques là que j'ai eu le plus de prob (le 5 a lâché). J'ai aussi remplacé des disques 3 TB Red par des 3TB acheté 3 ans plus tard. Et quand on sait comment WD a agit ... là aussi, j'ai du remplacé un plus récent (qui avait un max de LOAD_CYCLE_COUNT) par un autre. Mais bon, quand on voit comment WD a "joué" avec ses gammes ... je suis sûr que c'est la source de mes 2 problèmes de disque avec eux sur un total de 18 disques RED. Et ça, j'ai quand même du mal à l'accepter même si je fermé les yeux et croisé les doigts quand j'ai acheté les derniers RED Plus (je n'ai pas de disques 7200 rpm).
  9. Question difficile. D'abord quel est le "vrai" risque ? En fait, c'est qu'il y ait une trop grande différence (typiquement au démarrage, au réveil, ...) entre les temps de disponibilités des différents disques. Dans ce cas, le système peut suspecter un problème et lancer d'autorité un check de parité (consistency check). Ce test implique la lecture de tous les secteurs de données, le calcul de la parité et la comparaison avec la parité inscrite sur le secteur de parité. Autrement dit, le processus passe tous les disques en revue du premier au dernier bit. Cela entraine un peu d'usure supplémentaire des disques ainsi qu'un ralentissement pendant toute la durée du processus. Evidemment, si cela se produit de manière récurrente (ce ne sera pas plusieurs fois par jour, mais peut-être quelques fois par trimestre ou par mois), la probabilité d'un "vrai" couac est augmentée. Ici le problème, c'est que même si tu prends des Ironwolf, après 6 ans (ton NAS date de 2015, c'est ça ?), ce risque d'avoir une différence sensible dans la durée de démarrage me parait exister. Enfin, la translation des disques d'un NAS à l'autre est toujours un peu tricky ... donc vérifie bien que tes backups sont à jour. Et j'imagine que ...
  10. Pour ma part, j'agis sur plusieurs leviers. Tout d'abord, quand j'attends une livraison, j'installe une petite WebCam directement pointée sur l'entrée de ma rue (qui est à sens unique). Cette WebCam, je l'utilise comme une simple caméra et en fait je connecte le MBA sur le site web de la webcam et je regarde donc d'un œil ce qu'il se passe dans ma rue. Jusque là, je pense que c'est légal. Par contre, cette WebCam me sert habituellement à être chose et en fait elle enregistre H24/7j/7 et ça, ce n'est permis que si on la déclare à l'administration (mais vu que c'est 1h / 15 j ... ben je fais sans). Un jour (avant que j'opte pour ce système), j'ai eu un souci avec une société qui m'a livré 2 colis distincts à 2 j d'intervalle. Le premier jour, j'ai peut-être dormi trop tard mais le second j'étais sur mes gardes car j'avais trouvé l'avis de passage du 1er colis et comme j'avais passé la journée à attendre ... Je ne sais plus pourquoi mais je vais regarder à la fenêtre et je vois le livreur sortir de sa voiture et directement posté l'avis de passage sans sonner. Je prends alors une pièce de monnaie et je fait tinter la fenêtre. Evidemment, il va chercher mon colis et me dit : "il y a 2 jours j'ai sonné" (c'est possible ...). Mais bon mtn, j'ai la WebCam (parfois je reviens en arrière pour voir si je n'ai pas loupé le passage lors d'une afk). En principe, ils passent, ils doivent laisser un avis de passage. Ici, pour moi, "le" client du livreur, ce n'est pas moi mais c'est (dans ce cas) Apple. C'est peut-être une idée d'ouvrir un ticket chez eux et de leur signaler le problème. Enfin, avec certaines sociétés (dont entre autre "la" fameuse société française de matériel informatique en 4 lettres), je vais plus loin et je filme le déballage complet en commençant par le colis que je filme sous toutes les coutures pour prouver qu'il n'a pas été ouvert. Si je fais cela, c'est parce que j'ai eu la désagréable surprise de tomber à deux reprises sur un emballage qui a déjà été ouvert. Alors il s'agissait à chaque fois de "petites" choses (un câble SATA pour l'une des deux fois) mais c'est le principe que je ne supporte pas. Il y a le coin des affaires et j'attends que si je paie le prix plein, je reçoive un produit neuf. Je ne sais pas SI je le ferai mais SI cela devait concerné une grosse pièce ou une pièce à usure, il est possible que j'uploade le déballage sur Youtube ! Une chose est sûre, si c'est un disque dur, je ferai tout pour retrouver les éventuelles données effacées ... et là ... ils vont m'entendre !
  11. Parmi les jeux "éducatifs" de l'époque, il y en a un qui me vient tout de suite en tête, c'est l'histoire d'un personnage dont la tête est un boule de billard marqué d'un 8 Pour la plupart de mes connaissances un peu plus jeunes, ce sont ceux qui ont eu la chance d'avoir un parent intéressé, qui ont pu très tôt toucher à un ordi. Pour ma part, j'ai eu la chance que "mon" parent suive le conseil de mon prof de math de 1ère et m'offre un Commodore-64. Ici on était en '85 mais j'avais déjà pu me faire un peu la main sur des TRS-80 (Tandy) et des VIC-20 (ancêtre du C-64) en 3ème ('83) et même un CBM Pet mais sur des stands de démonstration. Ici une photo en bonne compagnie (Commodore PET - Apple ][ - TRS-80) https://en.wikipedia.org/wiki/Commodore_PET#/media/File:Trinity77.jpg
  12. Si vous voulez jouer à qui à la plus grosse ... moi c'est bon ... J'ai mis mes paluches pour la première fois sur un Mac vers 20 ans (un Mac sans HD et avec un seul floppy ... donc on jouait au disc-jokey entre le floppy de l'OS, celui du Soft et celui des datas). Pour la petite histoire en '90/'91, j'ai rédigé mon TFE (mémoire de master) sur un Mac SE (je pense, en tout cas il avait un HD). Pour info, j'étais le premier et le seul à rédiger mon mémoire moi-même. Tous les autres l'ont rédigés (ou le rédigeaient les années précédentes) sur papier et ensuite le manuscrit était donné à taper (contre rétribution) soit à une secrétaire qui se constituait un petit pactole avant les vacances, soit à un doctorant qui rentabilisait le Mac qu'il s'était acheté. Comme soft, je crois que j'utilisais MacWrite, un traitement de texte Wysiwig (What you see is what you get) alors qu'à l'époque, les traitement de texte PC permettaient certes de faire de la mise en page et appliquer des styles mais au mieux via un preview permettait d'estimer ce qui sortirait de l'imprimante. Par la suite, mon premier taf rémunéré a été de faire de la programmation HyperCard sur LC II.
  13. Je sais ... Mais bon, tu connais mon avis : tu hésites, alors il ne faut pas acheter.
  14. Je ne sais pas si je te l'ai dit, mais j'ai acheté le DS1821+ il y a quelques mois. A 899 pour le 1621+, c'est une belle offre. Dans le 1821+, j'ai activé le Raid 6 et j'ai en plus un disque Spare, donc d'utile je n'ai que 5 disques (8 - 2 pour les parités - 1 pour le spare). Si tu ne veux pas de spare ni de raid 6 (qui ralenti le fonctionnement) tu auras aussi 5 disques utiles (6 - 1 pour la parité). Une chose à savoir c'est qu'ils sont équipés d'un CPU AMD mais j'en suis très content. De plus, de mémoire mais je vérifierai, j'ai l'impression qu'il utilise bcp moins de mémoire que les Intel. Donc, avec 4GB, je pense que c'est jouable. Pour la carte réseau, je suis vraiment ennuyé car j'ai lu à un endroit qu'elle chauffait. Donc je ne me suis pas embêté et j'ai pris le modèle à 2x10 Gb/s. Mais bon, c'est "encore" 100 euros de plus et ... évidemment ... je n'utilise qu'un seul des deux ports 10 Gb/s. Tu peux peut-être prendre le risque d'acheter la 1x10, ne pas trainer pour la monter dans le NAS et profiter du délai de retour si tu as l'impression qu'il y a un problème. Enfin, le cache SSD, à moins que le DSM 7 ait vraiment tout changé mais pour l'avoir testé sur mon autre NAS, je n'ai pas été "ébloui". En plus si tu n'as qu'un seul SSD tu ne peux faire que du cache en lecture et il faut 2 SSDs pour pouvoir faire du cache en écriture (les SSD sont configurés en mirroring pour minimiser le risque de perte d'info).
  15. Dans ce cas tu ne dis rien. Tu dis que ta machine était sur tes genoux. Qu'il y a eu une odeur de brûlé et que c'était très chaud à cet endroit là. Et tu précises l'heure. Tu ne parles pas de l'USB-C et s'il te demande s'il y avait de connecté tu dis que non. Et là, il pourra aller voir dans le journal si un périphérique y était connecté ou pas ! Et si il est sceptique (je t'avoue que je le serai aussi ...) tu peux lui dire qu'il peut aller vérifier dans le journal qu'il y aura bien une trace de la connexion / déconnexion d'un périphérique sur ce port.
  16. J'ajoute qu'en principe si je ne dis pas de bêtise, ce serait à eux de prouver ton tort (c'est la principe de la garantie) ou en tout cas de prouver le problème sur l'autre appareil et qu'il est la cause du problème sur le leur. Mais bon ...
  17. Attention quand même comme tu présentes le dossier car ils pourraient arguer que c'est du à ce qui était connecté au port USB-C à ce moment-là. Evidemment si rien n'y était connecté ... ce serait l'idéal.
  18. J'ai beau retourner cette question dans tous les sens, je pense qu'Apple a commis une erreur, je dirais même une faute. Tout d'abord, si j'ai entamé la discussion, c'est parce que pas mal de réactions lues ici ou ailleurs, opposaient Apple et Epic, comme s'il fallait absolument un gagnant et un perdant. Là, Apple était donné comme grande gagnante, ailleurs les titres mentionnait une déconvenue pour Apple. Ma vision au contraire était celle deux, voir même trois perdants mais aussi de deux gagnants "collatéraux". Si les gagnants collatéraux du premier jugement sont clairement les développeurs et les clients, Apple et Epic en sortent tous les deux perdants à mes yeux et les institutions ne s'en sortent pas grandies non plus. Et ce second jugement ne fait que confirmer, à mes yeux, qu'Apple est bel et bien une perdante dans ce premier round. Pire, selon moi, il a donné tant à Epic qu'à la juge une nouvelle opportunité de développer leurs arguments. Je vais me risquer à une prospective, j'imagine que le prochain "coup" d'Apple dans cette espèce de partie d'échec sera (si ils interjettent appel) de demander un report de la mesure qui doit je le rappelle, être mise en œuvre pour le 9 décembre prochain. Mais à ce jeu là, ils sont aujourd'hui plus éloigné de cet objectif qu'ils ne l'étaient avant ce second jugement. Je ne sais évidemment pas si cette opportunité existe ni les lois et les jurisprudences des cours aux EU mais je me base juste sur le bon sens. Le timing général peut (et selon moi doit) quand même être scruté. Si à ma connaissance, Epic a fait immédiatement part de sa décision de faire appel (bien que je ne sais pas si le pourvoi est déjà déposé), Apple semble avoir pris son temps et initier le "mini-appel" devant la juge de première instance pratiquement un mois après le jugement. Ici, la juge tranche alors qu'il ne reste plus que 30 jours, mais aucun juge n'est comptable du temps que la partie met à lui soumettre ses arguments et ses demandes. Si Apple se tourne le 6 décembre vers l'instance d'appel, le jugement initial datera lui de pratiquement 3 mois ... Alors évidemment, j'écrivais que ce qui s'était est pour moi une erreur, voire même une faute. Encore faut-il une instance capable de sanctionner Apple. Ce n'est pas le rôle de la justice. Par contre et cela restera de toute manière invérifiable mais la mise à l'écart de Jony Ive (dé)montre pour moi que les hauts dirigeants d'Apple sont peut-être moins indéboulonnable que certains ne l'imaginent. Le conseil d'administration ou l'assemblée des actionnaires pourrait se montrer critique et demander des comptes. Signalons que le C.A. comporte quand même des administrateurs et des directeurs (actuels ou passés) de sociétés aussi connues que Boeing, Johnson et Johnson, ... ou de moins connues mais tout aussi importantes comme BlackRock un géant du secteur bancaire. Toutes ces personnes ont "évidemment" une expérience de la justice. Note : j'ai vu la news concernant Jony Ive avant de poster mais je maintiens mon point de vue.
  19. Certains d'entre vous le savent peut-être mais il y a du neuf dans ce dossier. Je vais répondre en deux posts, dans le premier, je vais tenter d'être le plus neutre possible et ensuite je pense que j'exprimerai mon ressenti dans un second. Comme d'habitude, les sources seront citées en fin de post. Ce mardi 9 novembre (plutôt le 10 pour nous), la juge de première instance, Mme Gonzalez Rogers a rendu son jugement concernant les deux demandes qu'Apple avait déposées. Pour rappel, la juge avait donné un délai de 90 jours à Apple pour modifier les règles de validation des applications soumises en vue d'une publication sur l'Apple Store et avait étendu cette obligation à l'ensemble du territoire américain. Apple dans la première des deux demandes qu'elle fait à la juge demande de sursoir à ce délai mais sans proposer de durée. Elle demande simplement à la juge de supprimer toute idée de délai. La juge se base dans son rendu sur une jurisprudence en 4 points et (dé)montre que la situation d'Apple (ou en tout cas, qu'Apple ne parvient à lui prouver) qu'elle rentre dans une des 4 possibilités de cette jurisprudence. Il est à noter que la juge motive ses prises de position par d'autres citations de jurisprudence (des affaires déjà jugées). En conséquence de quoi, la juge rejette la demande d'Apple. Elle note, dans le rendu de 4 pages qu'Apple a fait une demande de délai sans préciser cette durée. La juge l'écrit, je cite : "Rather, at best, it only suggests that more time is needed to comply. Apple, though, did not request additional time to comply. It wants an open-ended stay with no requirement that it make any effort to comply.". Traduction très libre : "Au mieux, il est suggéré qu'il faut plus de temps pour se mettre en ordre. Apple cependant ne demande pas de temps additionnel pour se mettre en conformité mais veut une solution sans délai de fin et sans aucune contrainte pour qu'Apple soit obligé de faire le moindre effort pour se mettre en ordre.". C'est (à la traduction très libre près) écrit noir sur blanc dans le rendu. La seconde demande concernait un report "technique" de 10 jours de manière à faire appel de la décision devant le 9ème circuit d'appel est également rejetée. Cette fois, la juge note que son rendu a lieu le 9 novembre, ce qui laisse encore 30 jours à Apple pour faire appel. Ce rejet est (évidemment) également motivé par plusieurs cas de jurisprudence. Elle ajoute qu'un délai de 10 jours se télescoperait avec le début de la trève de Noël, je cite : "Granting this extension would extend the deadline to the end of December just before the December holidays which itself is inconvenient.". En résumé, les deux demandes d'Apple sont rejetées. Je fais trois observations : - Contrairement à ce que je pensais, Epic a bel et bien eu voie au chapitre et ses avocats ont pu s'exprimer sur ces deux demandes d'Apple. - Force est de constater que contrairement à ce que je pensais (et ce qui est habituellement relayé par les sites d'informations que je consulte), c'est qu'en fait, Apple n'a (à la date du 9 novembre en tout cas) toujours pas fait appel de la décision de début septembre. Dans la mesure où ils demandent 10 jours de plus ... on peut difficilement être plus clair - Ce jugement s'ajoute au premier, notamment dans l'idée d'un procès en appel. Les nombreuses références à des cas déjà jugés sont autant d'obstacles qu'Apple devra négocier en appel. Les sources : - Source primaire, le jugement en anglais : https://s3.documentcloud.org/documents/21101223/epic-v-apple-judge-denies-apples-request-for-stay.pdf - Source secondaire, l'article de "The Verge" : https://www.theverge.com/2021/11/9/22773082/epic-apple-fortnite-lawsuit-ruling-injunction-stay-app-store-anti-steering-rules
  20. Si je vois bien, le modèle que tu as est équipé d'un Geforce 750M. Si je prends comme seule valeur de performance graphiques, les TFlops, cette carte est à 0,7 TFlops en FP32. Source: https://www.techpowerup.com/gpu-specs/geforce-gt-750m.c2224 La M1 de base tourne à 2,6 TFlops, soit déjà près de 4x les perfs de ta carte actuelle. Le M1 Pro, c'est le double soit 7,5x et le M1 Mac c'est encore le double soit près de 15x ta carte actuelle. As-tu vraiment besoin d'un tel up ?
  21. De toute manière avec la décision d'Apple de ne pas implanter de puce TPM 2.0 sur ces cartes-mères, le débat est clos. Windows 11 ne pourra "jamais" s'installer "nativement" sur un Mac. A moins que : 1/ Microsoft renonce définitivement à l'usage de cette technologie. Ce qui est peu probable. Rappelons que dès 2016, Redmond a averti tous les fabricants de cette future obligation. 2/ Apple ouvre sa puce T2 ... 3/ Apple implémente dans ses CPU les fonctionnalités qui existent désormais dans les processeurs récents Intel et AMD. Bref ... Alors je sais qu'aujourd'hui, c'est possible puisque Microsoft a donné un "délai de grâce" mais ils l'ont bien précisé, ce n'est que provisoire. Ce provisoire va durer disons ... 2 à 3 ans mais après ce sera définitif.
  22. Je pense que tous les intervenants vont te répondre la même chose. Le problème principal de ta config vient du fait que tu as un disque dur et pas un SSD. Depuis plusieurs générations d'OSX, le SSD est "quasi" devenu obligatoire.
  23. Je n'en disconviens pas mais la raison invoquée pour le non portage de folding@home sur les puces M1 est (à ce qu'on m'a dit, je n'ai pas vérifié) l'absence de cette technologie ou d'une concurrente.
  24. D'abord, augmentation "fantastique" ... il faut quand même raison garder. Au moment de la sortie, les perfs monocoeur de la plupart des Intel peinaient à s'approcher de 1600 au score de geekbench et le M1 a franchi la barre des 1700 pour s'établir vers 1750. Aujourd'hui les nouveaux processeurs d'Intel ont dépassé la barre des 1800 (pour les gros modèles déjà sortis). De même en terme de puissance GPU, le M1 Max avoisine les 10 TFlops en FP32, ce qui est vraiment très bien mais une 3080, c'est 20 TFlops et encore avec de meilleure perf en FP16 car il semble que l'Apple M1 ne "scale" les perfs quand on passe en FP16. De plus, Apple a renoncé aux instructions AVX d'Intel qui offrent d'intéressantes opportunités. Puisque tu as programmé en assembleur, le principe d'AVX est d'avoir un mot très très long (ex : 256 bits) structurés par exemple en 16 mots de 16 bits et en "une" instruction assembleur tu peux (par exemple) agir sur les 16 mots en même temps (ex : shl, décalage vers la gauche) ou encore opérer des opération bit à bit entre 2 "mots" de 256 bits. Par exemple, le calcul distribué de "repliage" des protéines n'est pas porté sur M1 pour cette absence. Pour le reste, oui, clairement aujourd'hui les développeurs utilisent des frameworks de plus en plus éloignés du matériel et donc de moins en moins optimisés. Mais cela permet de développer des applications multiplateformes très facilement. Mais ces applis sont des gouffres à mémoire et à temps CPU. Je serais très curieux de savoir lorsque qu'on code une division d'entier dans un tel programme, cb de vérification de non division par zéro sont effectuées en cascade. Je pars en gros de l'idée que chaque couche rajoute un test. Je ne dois avoir tout à fait raison, mais pas tout à fait tort non plus. Ceci dit, le surcroit de performance est parfois utile. Si on dispose de correction orthographique en temps réel, c'est bien grâce à ces progrès.
  25. C'est le vrai test. Il y a quand même une chose à dire, c'est qu'avant la sortie officielle du Mac M1, des Mac Mini "de tests" ont été fournis aux développeurs. Je ne connais la date exacte mais c'était avant les vacances de 2020, soit il y 15 bons mois au moins. Si aujourd'hui les apps ne sont toujours pas portées nativement sur M1, cela pose quand même question. D'autant plus qu'à moins d'une app qui interagit presque avec le matériel (et je ne parle pas du micro, ...) mais vraiment du HW graphique par exemple, le portage est en principe relativement simple. Il suffit de recompiler puisqu'on reste sous OSX. Porter une appli Intel de Windows à Mac est un travail important, mais ici, il ne s'agit "que" de recompiler. Je vous laisse tirer les conclusions qui s'imposent et c'est bien pour cela que je parlais du "vrai" test.
×
×
  • Create New...