Discussion :

[LittleWhite]

Comme d'hab. Ce ne sont que quelques exemples mais personne ne voit de problème.

Je peux comprendre votre avis (enfin, je pense le comprendre). Toutefois, dans tous les logiciels, ou même dans toutes les conception, il y a un moment où des choix doivent être pris. Ces choix sont pris, soit pas la communauté (de manière ouverte), soit de manière fermé (cas plus courant au sein des sociétés). Mais, il y a toujours un moment, où il y a un choix de fait, pouvant être portés par plusieurs intérêts (commerciaux, sécuritaires, politique...) et cela, que ce soit pour les logiciels, les jouets, les consoles, les voitures...
Là, où je pense que Linux ou plus précisément, l'écosystème du monde du logiciel libre a un avantage, c'est que tout est configurable, modifiable. Je pense, que sous Windows, ont subit les choix (par exemple, l'apparition d'une nouvelle barre des tâches... ou je ne sais pas encore quels changements vont arriver avec Windows 11), alors que du côté de Linux, vous avez le choix, que ce soit dans le fonctionnement interne ou ne serait-ce que l'aspect graphique de votre environnement de travail.
Et au final, pas besoin de tout (re)configurer, à un moment, il se pourrait que vous trouverez une distribution à votre goût. Mais, de mon avis, vous avez aussi le choix de préféré Windows (ou même MacOS) et pour moi, aucun mal à cela. Nos choix sont personnels et tant que l'on s'y retrouve, s'y plaît, tout est bon.

Bref, ce que je voulais dire, c'est que l'aspect des coredumps (et autres choix de configuration) est un choix pris (que ce soit pour Windows ou pour Linux). Que vous pouvez revenir en arrière de ce choix mais aussi, que dans un sens, vous pouvez aussi penser que les gens qui ont pris ce choix, l'ont pris pour de bonnes raisons (des raisons qui correspondent à vos idées).

[Kannagi]

mais j'ai bon espoir un jour de revoir des smartphones x86 avec de l'intel et/ou de l'amd, surtout avec la nouvelle architecture en approche: Alder Lake qui est très prometteuse

Cela m'étonnerai , par contre curieux de voir des personnes qui veulent encore du x86 ,pour ma part j'espere que le x86 mourra ,on paie une dette technique énorme sur ce type de processeur en terme de temps de R&D , mais aussi sur les prix (bon ils compensent par rapport aux unité vendu) , et surtout que le x86 commence a voir certaine limite technique , dans le décodage notamment , alors que le M1 peut en bouffer 8 par cycles ( chose improbable sur x86 ).

[foetus]

Bref, ce que je voulais dire, c'est que l'aspect des coredumps (et autres choix de configuration) est un choix pris (que ce soit pour Windows ou pour Linux). Que vous pouvez revenir en arrière de ce choix mais aussi, que dans un sens, vous pouvez aussi penser que les gens qui ont pris ce choix, l'ont pris pour de bonnes raisons (des raisons qui correspondent à vos idées).

Lors de mes premières armes avec Linux, j’avais mis dans la config fvwm un xterm normal et un «*xterm -bg salmon -e su *». Du coup, un coup de souris et une saisie de mot de passe et j’avais une fenêtre root mise en évidence par la couleur. Ainsi, travailler au bon niveau de sécurité était assez facile.

Désolé de vous importuner avec *MES* problèmes de sécurité
Qui va installer 1 Debian sur 1 poste de travail pour avoir 1 bonne distribution "fixed realesed" ? Personne, parce qu'en étant 1 distribution serveur, beaucoup de choses sont désactivées par défaut pour raison de sécurité (le compte sudoers que j'ai pris l'exemple)
Debian et les autres, c'est 1 tannée sans nom à configurer tout en ligne de commande (par exemple, édition des fichiers avec vi ou nano)

Qui va installer 1 Ubuntu et ne va pas utiliser toutes les facilités de cette distribution (magasin, mise à jour, 2-3 dépôts sécurisées, ....) ?
Personne, parce que pour 1 poste de travail c'est cool, elle ressemble à Windows : tu cliques, tu cliques.

je suis presque nostalgique de ma Mandrake de 1999-2000 qui permettait de se connecter en tant que *root* mais la couleur principale était le rouge partout.
1 coup de temps en temps pour 1 grosse session de configuration de son poste de travail, et ensuite on supprime l'accès.

[floyer]

Je ne comprends pas où tu veux en venir avec les comptes «*sudoers*» désactivés (les comptes sudoers ne sont pas désactivés, seul le compte root a des accès limités pour éviter qu’un administrateur se logue root pour faire de la bureautique : on élargi la surface d’attaque bêtement). Mais, c’est juste un paramétrage (https://fedoraproject.org/wiki/Enabl...play_Manager)… mais tout cela pour éviter de devoir taper «*su*» ou «*sudo su*» avant d’avoir un shell root, je peine à comprendre.

[calvaire]

Cela m'étonnerai , par contre curieux de voir des personnes qui veulent encore du x86 ,pour ma part j'espere que le x86 mourra ,on paie une dette technique énorme sur ce type de processeur en terme de temps de R&D , mais aussi sur les prix (bon ils compensent par rapport aux unité vendu) , et surtout que le x86 commence a voir certaine limite technique , dans le décodage notamment , alors que le M1 peut en bouffer 8 par cycles ( chose improbable sur x86 ).

bah le x86 c'est la seul architecture "ouverte", je veux dire il y'a une standardisation de l’amorçage sur système (bios/uefi) et des drivers de boot ce qui permet d'installer n'importe quel OS.

en ARM chacun fait ce qu'il veut, dans les systèmes privée (surtout le monde d'android) on se retrouve assez vite sans maj et sans pilote utilisable, meme chez apple le support ne sera que de 8ans grand max (ce qui est peu pour un pc, sachant que mon pc portable date de 2006 sous manjaro et tourne très bien)
et l’architecture arm est peu rétrocompatible.


Non, le jeu d'instructions x86 n'est certainement pas déprécié. Il est plus populaire que jamais.
Intel ne code pas matériellement les instructions x86 dans ces processeurs. Il utilise un ensemble de micro-instructions de type RISC en interne est qu'elles peuvent être traitées plus efficacement.
Ainsi, un processeur x86 fonctionne en ayant un décodeur assez lourd dans le front-end, qui accepte les instructions x86 et les convertit en un format interne optimisé, que le back-end peut traiter.

Il ne s'agit pas d'un format stable. Intel peut le modifier d'un modèle de CPU à l'autre pour l'adapter au mieux à l'architecture spécifique. Cela leur permet de maximiser l'efficacité, et cet avantage serait perdu s'ils devaient se contenter d'un format d'instruction fixe et stable pour un usage interne comme pour un usage externe.
Il n'y a tout simplement rien à gagner à supporter directement le jeu d'instruction. Avec les processeurs complexes et énormes d'aujourd'hui, le décodeur est une partie relativement petite du processeur. Le fait de devoir décoder les instructions x86 rend la chose plus complexe, mais le reste de l'unité centrale n'est pas affecté, donc globalement, il n'y a pas grand-chose à gagner, en particulier parce que le frontal x86 devrait toujours être présent, afin d'exécuter le code "hérité". Vous n'économiserez donc même pas les transistors actuellement utilisés sur le frontal x86.
Intel pourrait parfaitement ajouter des accélérateurs ou l'encodage et de le décodage de certains codec mais ca prends du temps... en 2021 seul mediatek propose d'encoder matériellement du av1 par exemple.

Au final, seul les proc arm peu performant et basse conso sont intéressant et n'ont pas d'équivalent x86. Des qu'on monte en puissance (les soc pour smartphone hdg d'arm ou les puces arm server) on atteint voir dépasse la conso des x86 intel/amd pour des perfs équivalente... et le prix j'en parle même pas (spoiler c'est plus cher)

[floyer]

Le x86 ne définit pas la procédure d’amorçage (on peut avoir le BIOS, UEFI, U-boot…), et il existe une architecture (SBSA) qui spécifie le fonctionnement d’un système complet et permet de charger une distribution ARM qui n’est pas conçue pour un modèle précis de serveur ARM (ex : Ubuntu). Bref. Soit tu compare 2 CPU (x86 et ARM), soit deux architectures système (PC/UEFI et SBSA), mais pas PC/UEFI et ARM par exemple.

La disponibilité de logiciels pour ARM64 dépend plus de la politique commerciale des éditeurs que de l’ouverture de la plateforme.

Par ailleurs, j’ai été bluffé par les performances de la puce M1 en émulation x86 sur du code non accéléré (interpréteur Python). Cela promet pour du code tournant nativement en ARM.

[Kannagi]

bah le x86 c'est la seul architecture "ouverte", je veux dire il y'a une standardisation de l’amorçage sur système (bios/uefi) et des drivers de boot ce qui permet d'installer n'importe quel OS.

en ARM chacun fait ce qu'il veut, dans les systèmes privée (surtout le monde d'android) on se retrouve assez vite sans maj et sans pilote utilisable, meme chez apple le support ne sera que de 8ans grand max (ce qui est peu pour un pc, sachant que mon pc portable date de 2006 sous manjaro et tourne très bien)
et l’architecture arm est peu rétrocompatible.

Comme dit précédamment , c'est pas une comparaison , là tu compare deux type d'ordinateurs (le PC et les autres) , qui n'ont rien à voir avec l'architecture d'un CPU.

Non, le jeu d'instructions x86 n'est certainement pas déprécié. Il est plus populaire que jamais.
Intel ne code pas matériellement les instructions x86 dans ces processeurs. Il utilise un ensemble de micro-instructions de type RISC en interne est qu'elles peuvent être traitées plus efficacement.
Ainsi, un processeur x86 fonctionne en ayant un décodeur assez lourd dans le front-end, qui accepte les instructions x86 et les convertit en un format interne optimisé, que le back-end peut traiter.

Il ne s'agit pas d'un format stable. Intel peut le modifier d'un modèle de CPU à l'autre pour l'adapter au mieux à l'architecture spécifique. Cela leur permet de maximiser l'efficacité, et cet avantage serait perdu s'ils devaient se contenter d'un format d'instruction fixe et stable pour un usage interne comme pour un usage externe.
Il n'y a tout simplement rien à gagner à supporter directement le jeu d'instruction. Avec les processeurs complexes et énormes d'aujourd'hui, le décodeur est une partie relativement petite du processeur. Le fait de devoir décoder les instructions x86 rend la chose plus complexe, mais le reste de l'unité centrale n'est pas affecté, donc globalement, il n'y a pas grand-chose à gagner, en particulier parce que le frontal x86 devrait toujours être présent, afin d'exécuter le code "hérité". Vous n'économiserez donc même pas les transistors actuellement utilisés sur le frontal x86.
Intel pourrait parfaitement ajouter des accélérateurs ou l'encodage et de le décodage de certains codec mais ca prends du temps... en 2021 seul mediatek propose d'encoder matériellement du av1 par exemple.

Alors oui je sais que Intel et AMD font du CISC -> RISC en interne et ça depuis plus de 20 ans. (je suis un peu dans le monde de la micro architecture donc :p )

Mais le décodage est lourd quand même et oui , et il prend bien plus de circuit que de l'ARM (et il est plus long aussi).
et comme les opcodes du x86 sont variables , ils doivent tester toutes les combinaisons possible (et ça en prend du transistor ) , ce qui limite le nombre de décodage du x86 à 4 (ou 6) , alors que tu peux en faire facilement 8 sur un ARM

La rétrocompatibilité l'oblige a rajouté des circuits obsolète (entre autre le FPU qui date du i386) , quasi aucun logiciel l’utilise , tous utilise le SSE (depuis le x64) , donc tu as des instructions inutile et qui te prend un peu de place , et tu on a plein dans le genre.

Tu as donc le CISC -> RISC en interne et donc des étape supplémentaire ,et du microcode supplémentaire que tu n'as pas sur ARM !

Le nombre de registre restreint , oblige de taper bien plus souvent sur le cache L1 qui provoque bien plus de chauffe que d'avoir plus de registre.

Du coup le x86 a bien plus de désavantage que d'avantage et c'est aussi tout ces truc qu'il fait qu'un ARM cause moins de consommation (y'a bien plus d'étape sur un x86).

Il n'y a tout simplement rien à gagner à supporter directement le jeu d'instruction.

Ah ah ,oh que oui , tu as beaucoup d’intérêt de gérer directement le jeu d'instruction pour ARM , ça évite des étapes en moins , hors processeurs RISC , si tu veux gérer un jeu d'instruction pour les haute perf , alors cela rend la programmation de ces machines bien plus complexe (CF Itanium /CELL) , mais en échange, tu gagne énormément de transistor sur le die (le CELL , je crois c'est 300 MT pour 9 cores , alors que avec le même nombre de transistor que si tu faisais un intel core Duo :p )

[lecosmotien]

J'ai basculé de windows sur Linux Mint et je suis passé de l'enfer (windows 11) au paradis.

Sous windows j'avais l'impression que ma machine ne m'appartenait moins qu'elle appartenait à microsoft.

Sous Mint j'ai trouvé une ergonomie "windows like" mais beaucoup plus simple et pratique :
- le bureau, le menu démarré - la barre de tâche sont très simple et efficace (pas les lourdeurs des dernières version de windows)
- la logithèque - ça n'existe pas sous windows et cela permet d'installer des applications simplement. J'ai peu retrouver quasiment tous les programmes que j'avais sous windows et des remplaçants pour les autres
- le paramétrage est plus simple - sous windows à chaque version ils changent l'ergonomie (ils le font exprès ????)
- des périphériques que je ne pouvais plus utiliser sous windows sont parfaitement opérationnel sous linux.
- le démarrage très rapide - la réouverture de session à partir de la veille en 3s chrono (sous windows la tâche de fond de l'antivirus indéboulonnable pouvait bloquer mon accès à la machine pendant 1/2 heure)
- pas de mémoire qui sature dans le temps par perte de mémoire (ce qui oblige à rebooter régulièrement sous windows - la prochaine version de windows s’appellera windows-reboot)
- portage facile de mes programmes c et perl.
- unix est nativement un système de développement, Linux en hérite de plus belle.

bref que du bonheur.

[calvaire]

J'ai peu retrouver quasiment tous les programmes que j'avais sous windows et des remplaçants pour les autres

ou utiliser wine qui marche assez bien !


Quand on est habitué a utiliser certains logiciels c'est chiant de trouver des alternatives et de se reformer. clairement je ne pourrais pas me passer de sony vegas ou de photoshop.

si vous utiliser un raspberry, vous pouvez installer box86 et wine pour y faire tourner des jeux et programmes windows, pour des programmes pas très gourmand ça marche très bien.

[LittleWhite]

Certes Wine marche bien (bien mieux qu'il y a quinze ans, lors de mon premier essai ), mais je considère que Wine n'est pas si simple que cela pour un néophyte sous Linux.

[chrtophe]

Et c'est pas la solution miracle. Ca marche pas forcément pour tout.
Pour Photoshop par exemple, je sais pas ce que ça vaut au niveau perfs.

[calvaire]

Et c'est pas la solution miracle. Ca marche pas forcément pour tout.
Pour Photoshop par exemple, je sais pas ce que ça vaut au niveau perfs.

j'ai pas de problème de perf avec photoshop ou sony vegas sous linux (je précise que j'ai un ryzen 3700X et une gtx 980, pas une conf pourrie avec un atom)

mais wine ne fait pas perdre en performance par rapport à une exécution native sous windows (enfin la perte est très négligeable de 1-5% grand max sauf exception), parfois d’ailleurs c'est plus performant sous wine (de quelques % la aussi rien de bien significatif)

par contre oui si vous utiliser wine sous une couche d'émulation (le cas de box86 sous raspberry) oui c'est la cata. Mais c'est la même chose avec windows arm, les apps x86 sont très très lente.
J’espère que les émulateurs vont s'améliorer dans le temps et que les processeurs arm vont monter en puissance.


Apres avec mon sd835 j'arrive a faire tourner windows98 et des jeux sous mon smartphone, j'imagine qu'avec un soc puissant et moderne (apple M1 et les futur sd gen8 et dimensity 9000) y'a moyen de faire tourner des programmes moderne de manière fluide.
Le cpu est de moins en moins utilisé dans les programmes gourmand, le rendu et souvent déporté sur le gpu, donc cela signifie quasi aucune perte de perf même en émulation. des jeux x86 3d gourmand en gpu et Photoshop x86 tourne très bien sur un apple M1.
Maintenant oui un soft de dao/cao qui bouffe a mort du cpu ce sera la cata