Jump to content

Sethenès

Members
  • Posts

    2978
  • Joined

  • Last visited

Everything posted by Sethenès

  1. Effectivement, c'est élevé. Le "score" le plus élevé que j'ai est sur le NAS qui a 11 ans et c'est seulement 32. Sur le NAS le plus récent (3,5 ans), le score est de 1 pour le 1er disque et de 0 pour tous les autres.
  2. Attention Pehache, ici y a pas de blème car tu n'as pas désactivé la fonction d'hibernation. Si tu avais eu ces chiffres avec l'hibernation désactivée, là, ça aurait été un problème.
  3. Ce que je tu suggères, c'est de faire un tableau et d'y noter la valeur SMART (193) de tous tes disques. Refais la mesure dans 30 jours et compare l'évolution des disques entre eux.
  4. QU'entends-tu par "pas très vieux" ? 3 semaines, 3 mois, 3 ans ?
  5. C'est raisonable comme résultat. Tu aurais pu avoir des 10000 voire des 50000 et ça aurait été problématique. Et pour les SSDs, la principe est différent.
  6. J'ai trouvé les commandes en ligne. D'abord tu entres dans un shell la commande fdisk -l -l pour list; ce qui va te retourner quelque chose comme ceci : fdisk: cannot open /dev/sda: Permission denied fdisk: cannot open /dev/sdc: Permission denied fdisk: cannot open /dev/sdd: Permission denied fdisk: cannot open /dev/md0: Permission denied fdisk: cannot open /dev/md1: Permission denied fdisk: cannot open /dev/zram0: Permission denied fdisk: cannot open /dev/zram1: Permission denied fdisk: cannot open /dev/md4: Permission denied fdisk: cannot open /dev/md2: Permission denied fdisk: cannot open /dev/md5: Permission denied fdisk: cannot open /dev/mapper/vg1-syno_vg_reserved_area: Permission denied fdisk: cannot open /dev/mapper/vg1-volume_1: Permission denied fdisk: cannot open /dev/mapper/vg1-volume_2: Permission denied fdisk: cannot open /dev/mapper/vg3-syno_vg_reserved_area: Permission denied fdisk: cannot open /dev/mapper/vg3-volume_5: Permission denied fdisk: cannot open /dev/mapper/vg3-volume_6: Permission denied fdisk: cannot open /dev/mapper/vg3-volume_7: Permission denied fdisk: cannot open /dev/mapper/vg4-syno_vg_reserved_area: Permission denied fdisk: cannot open /dev/mapper/vg4-volume_8: Permission denied fdisk: cannot open /dev/synoboot: Permission denied Les disques sont les entées avec /dev/sda, /dev/sdb et ainsi de suite. Tu en choisis un (par exemple /dev/sda) et tu lances la commande : sudo smartctl -a -d sat /dev/sda Là tu reçois un paquet d'information et ce qui nous intéresse, c'est la ligne commençant par 193 : 12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 126 192 Power-Off_Retract_Count 0x0032 200 200 000 Old_age Always - 32 193 Load_Cycle_Count 0x0032 200 200 000 Old_age Always - 111 194 Temperature_Celsius 0x0022 121 110 000 Old_age Always - 29 Et dans la dernière colonne pour l'attribut 193, tu peux voir, j'ai 111.
  7. Je tombe (presque) de ma chaise ... Synology a enlevé cette option dans la 7.2 ... apparement car les utilisateurs interprêtaient "mal" les données et retournaient trop de disque à Synology ... Source : https://community.synology.com/enu/forum/1/post/163050
  8. Je suis toujours en 6.2, mais c'est très simple. Voici ce que cela donne chez moi :
  9. Pour avoir une idée quel est ton Load_Cycle_Count sur un de tes disques ?
  10. Pour moi, le risque majeur en panachant les disques est qu'au moment du réveil, certains tardent et que le système considère que c'est une potentiel signe de problème sur le disque. Dans ce cas, la conséquence, c'est que le système démarre un parity check, ce qui revient à lire tous les disques pour vérifier qu'il n'y a pas de problème de parité. Les disques que je choisis sont fait pour ne jamais hiberner (d'ailleurs, j'ai décoché l'option HDD hibernation) et après 3,5 années d'utilisation mon Load_Cycle_Count est à 10 (SMART). Je crois que tu as choisi dans une autre gamme de disque, ce qui implique beaucoup plus de "réveils".
  11. Cherche peut-être du côté de ceci en lançant "convert screen without vesa mount" sur google.
  12. Je comprends, c'est pour ça que j'ai linké l'article principal où ils évoquaient la Dremel ...
  13. Apparemment il faudrait un kit tel que celui-ci : https://www.thebookyard.com/product.php?cPath=34_166_524&products_id=17700 Attention aux 190 Livres s'ajoutent certainement des frais de douane (BrExit toussa). Et ce ne sera pas 10 euros. Source initiale : https://forums.macrumors.com/threads/imac-5k-vesa-conversion.2337430/
  14. Je n'ai pas tout compris, mais ce n'est pas grave. En ergonomie on dit souvent que l'idéal est que le haut de l'écran soit à la hauteur des yeux. J'insiste, c'est bien le haut de l'écran à la même hauteur que les yeux. A ma connaissance, il y a deux raisons : soulager les cervicales et favoriser le clignement des yeux (ce qui induit une bonne hydratation de l'oeil). Autrement dit, si tu as déjà des soucis aux yeux qui piquent, chatouillent, ... fait attention - ou - si tu as des douleurs au cou, dans le haut du dos, ... Autrement si tu veux "encore" monter plus haut, ça peut se révéler problématique. Pour le bras, je pense qu'il n'y a pas de secrets. Il faudra mettre un certain prix. Par contre, ce que tu suggères, ce sont les vidéos YT de possesseurs (pas de testeurs) et de te baser sur ce que tu vois chez eux à l'usage. Chez moi, j'ai trois bras mais 2 sont sur des petits écrans 4/3 ... autrement dit, ils ne pèsent rien. Le 3ème était compris avec mon "fameux" écran "carré". Il est de très bonne qualité.
  15. Pour moi, le gros problème des iPads Pro est qu'ils voient leur date de fin de support identique aux autres appareils équipés de la même génération de puces. C'est bien la preuve, dans la tête d'Apple, que ce ne sont pas "vraiment" des machines différentes des autres (sous-entendu, de leur génération).
  16. Pour la question 2, j'ai trouvé pigz : "A parallel implementation of gzip for modern multi-processor, multi-core machines". Par contre, je ne sais pas ce que ça vaut. Pour la question 3, c'est subtil. Tout d'abord, il existe (ou existait) une version CUDA pour OSX mais CUDA nécessite la possession d'un GPU Nvidia puisque c'est propriétaire. Il existe bien OpenCL (attention pas OpenGL) qui permet de faire l'équivalent, mais autant CUDA dispose de nombreuses bibliothèques de fonction, autant (à ma connaissance) c'est plus limité du côté d'OpenCL. Enfin, si Apple est à l'origine d'OpenCL (dont une version vient de sortir cette année encore), METAL est censé combiné OpenCL et OpenGL. Mais je ne sais pas quel est la situation actuelle, ni le futur envisagé que ce soit du côté de chez Apple ou pour les autres partenaires de la norme.
  17. Ce qui est aussi un gros plus, c'est que l'ancien NAS peut servir de backup. En tout cas, le temps que les disques tiennent. Et même par la suite, tu peux y installer des disques les moins chers possible et continuer le backup. Et ça, même si les 2 NAS ne sont pas du tout sur le même OS, des mécanismes comme le backup de Synology, ou mieux, de Snapshots vont continuer à fonctionne. Par contre, il y a un gros "mais", c'est que chez Synology, tout fonctionne par "shared folders" (répértoire partagé ?). Donc si tu n'en crées qu'un seul, tu seras coincer dès que la capacité du répértoire dépassera celle de l'ancien NAS.
  18. Ce n'est pas logique. Il faudrait analyser avec les outils fournis par Apple.
  19. Je ne suis pas trop fan des extensions, hors vraies solutions rackable qui garantissent que le câble ne sera jamais déconnecté. Dans tous les cas, je déconseillerais de créer un Raid qui ne soit pas entièrement hébergé sur le même composant. Autrement dit, une extension -> son propre Raid, pas d'extension du Raid existant depuis le NAS vers l'extension.
  20. "Ailleurs", quelqu'un a mentionné le Raspery Pi qui apparemment n'aurait de problèmes de compatibilité. A l'ocassion, j'investiguerai.
  21. Tu fais bien de relever, mais c'est quand même très particulier comme usage. Je sais qu'il ne faut pas réécrire l'histoire non plus. Au moment de passer au 64 bits, Intel a tenté la rupture avec les Itaniums. C'était aussi l'occasion de repartir d'une page blanche. Et c'est là qu'AMD les a court-circuité en étendant les instructions x86-32 (bits) aux x86-64, qui sont utilisées aujourd'hui (c'est un comble) par tous les processeurs ... Intel (et AMD bien sûr). Les choses sont toujours plus subtiles, mais ici, c'est une réflexion que je voulais initier. Et en même temps, expliquer pourquoi je suis si réticent vis-à-vis de l'approche ARM qui va se généraliser, je pense.
  22. Ce que suggères est une approche concurrente à Rosetta 4. J'utilise d'ailleurs la même astuce entre Windows 7 et Windows 10 car j'ai écrit énormement de programme en VB6 (tout simplement car on m'avait offert la licence) et malgré pas mal d'essais je n'ai jamais réussi à installer le programme VB6 sur Windows 10. Alors que les programmes compilés, eux, fonctionnent parfaitement sur Windows 10 (à conditions de "régistrer" certains composants, mais ça c'est peanuts).
  23. J'aimerais attirer votre attention sur un point qui à mon avis échappe à de nombreuses personnes. Ces 30 dernières années, le monde informatique a bénéficié d'une forme de protection. De plus cette durée est telle que je pense que tous tiennent cela pour acquis. Or, je ne suis pas sûr que ce soit le cas. Je m'explique. Le x86 offre une garantie de compatibilité ascendante et descendante. Dis comme ça, c'est bien. Mais concrètement qu'est-ce que cela signifie ? Je vais prendre un exemple avec un software que j'ai acheté et qui pilote une CNC (les imprimantes 3D sont des CNC). Ce soft a maintenant 5 ans et je l'ai installé sur un vieux PC acheté en 2008. Ce soft est compatible Windows 7, 10 et 11. Autrement dit, j'ai la garantie que si dans 5 ans, j'achète un PC, je pourrais toujours installer ce software, même si la société n'assure plus le suivi, qu'elle a fait faillite, ... Vous vous rendez compte de l'énorme avantage que cette situation apporte ? Le même soft (avant on aurait parlé de binaire) peut indifférement tourner sur un PC de 2008 et sur un PC de 2028. "La" question à laquelle je n'ai pas de réponse est de savoir ce qu'il en est du côté des puces ARM. Sont-elles compatibles de manière ascendante et descendante ? Comme ce n'est jamais mis en avant ... j'ai un doute (mais qui ne présume de rien). Ici, avant de continuer, je dois préciser certains éléments. Le PC de 2008 était livré avec Vista ainsi que les drivers pour revenir à XP si nécessaire. Heureusement, j'ai pu installé Windows 7 et c'est grâce à cela que j'ai pu installer le soft car je pense qu'il n'était compatible Windows XP ou Vista. Vous le voyez, il faut une double compatibilié. D'une part, le processeur doit être compatible et d'autre l'OS doit permettre de faire tourner le programme. D'ailleurs pour utiliser ce même programme sur Windows 10 ou 11, l'OS fourni une couche de compatibilité car le soft initial est compilé en 32 bits. Mais grâce à "Wow64" (Wow = Windows on Windows, à comprendre Windows 32 on Windows 64) il est possible de faire tourner une application 32 bits sur un OS 64 bits. Ici, il faut bien comprendre que Wow64 est totalement à l'opposé de Rosetta 3. Rosetta 3 pallie non pas le problème d'OS mais bien le problème de processeur. C'est au fond une passerelle qui permet d'exécuter 2 softs macOS (même OS) sur 2 HW différent (x86 "on" ARM). Alors ceux qui me répondraient que c'est le problème d'Intel. Oui et non. D'abord si Rosetta 3 prend en charge tous les x86 sur lesquels on peut installer une version de macOS qui contient Rosetta 3, c'est justement parce que les x86 sont compatibles entre eux. Imaginez si Apple avait du développer une version Rosetta 3 pour les PC de moins de 3 ans, de moins de 5 ans, ... Je suis certain que le support des x86 "un peu trop vieux" aurait été absent. D'ailleurs tant qu'à parler de Rosetta 3, ça doit démanger Apple d'en arrêter le support et sait bien ce qu'il se passer ce jour là. Ceux qui auront besoin d'un soft qui n'est nativement supporté sur ARM ... garderont la dernière version de macOS qui supportera Rosetta 3. Exactement comme il en fut avec Rosetta ... je n'invente rien ! Plus fondamentalement, si les génération de puces ARM ne sont pas compatibles entre elles ... je suppose que vous voyez où je veux en venir ? Oui, il sera nécessaire à Apple d'offrir un Rosetta 4 qui permettra (par exemple) de faire tourner les binaires compatibles M1, M2, M3, M4 sur des architectures M5, M6, ...
  24. Mettons que pour une fois, j'y ai vu une attaque anti-UE et que ce n'était pas le cas. Cela faisait évidemment un certain temps que je voulais aborder ce thème, de préférence sur le forum car les news "passent" trop vite, et j'ai saisi l'occasion. Quant au référendum sur le Frexit, je ne me réjouirais pas trop vite. Cameron a utilisé le référendum pour se tirer d'un mauvais pas. Et je ne serais pas surpris qu'en cas de réelles difficultés, la même approche soit un jour utilisée par un politique français (par exemple, un nouveau/nouvellle président(e)).
×
×
  • Create New...