Reprise du message précédent :

 
Bizarre,
 
Quand je regarde sur le site d'intel pour ton CPU (du moins celui de la fiche 01) ça précise bien que le jeux d'instruction est 32b et non 64b : https://www.intel.fr/content/www/fr [...] tions.html

My bad, c'est pas le n270 mais le n450.
Après avoir fait lshw en root:

C'est donc cette Ferrari: https://icecat.biz/fr-ca/p/samsung/ [...] 93704.html

Bonne année le topic.
J'ai une VM Debian à jour qui me sert pour diverses tâches et sur laquelle j'ai rajouté récemment un site python fait avec Django et qui tourne avec gunicorn
Depuis ce rajout, la VM de temps en temps se met à consommer de la RAM en permanence jusqu'à atteindre 80~90% de la RAM allouée à la VM. A ce moment ça redescend comme par magie aux niveaux habituels...
Dans le cron.hourly je viens de rajouter des dumps de la commande top et de la commande ps pour identifier le consommateur fautif, mais cela ne s'est pas encore reproduit depuis la mise en place du cron.... vous voyez d'autres pistes pour identifier la cause ? (même si je soupçonne fortement gunicorn).

En guise de conclusion à 2024, Debian a publié une « micronews » annonçant la première préversion alpha de l’installeur de la prochaine version 13 « Trixie », avec un lien menant à un message de la liste de diffusion, qui confirme (sans grande surprise) l’abandon de la fourniture d’installeurs pour les architectures armel et i386).
 

Perso, ça ne changera rien à mes install  

Certes, non, mais ceux qui continuaient à utiliser un EeePC ou apparenté comme machine nomade ou d’appoint quand leur ordi principal n’est pas disponible n’auront plus Debian (ou ses dérivées maintenant une version 32 bits, comme Q4OS, AntiX ou MX Linux) comme solution d’OS à jour pour de telles configs. Faudra aller voir du côté de Void ou Mageia, ou peut-être Gentoo et Slackware si on a l’âme assez barbue pour ça, pour l’instant.

Gentoo avec le temps de compilation sur un eepc pas sûr qu'il reste du temps pour l'utiliser

Faut s’en tenir aux paquets binaires qui sont précompilés, oui. Ou laisser la compilation se faire en arrière-plan (mais quand on voit que sur du Ryzen de 2018, Chromium met dans les 3h30 à se compiler à lui seul, je pense que sur un Atom de 2010, on dépasse certainement la semaine en continu, oui… ).

Je me souviens d'une époque ou sur mon x31 (Intel PIII) il me fallait plus de 7h pour compiler OpenOffice...  
 
Je suis toujours autant nostalgique de cette machine ^^"

Perso je trouve complètement absurde de continuer à utiliser ce genre de machines mais chacun son truc. On trouve des machines x64 fonctionnelles et gratuites en déchetterie, pourquoi continuer à utiliser des trucs 32 bits...

Personnellement, je suis plutôt d’accord, vu que je ne connais présentement que mon père comme utilisateur (occasionnel mais régulier) de tels bidules. Après, faut voir à quoi ça peut servir, toute autre considération mise à part : pour de la bureautique pure (on se limite strictement à LibreOffice Writer ou Calc) et si on vire tout ce qui nécessite une connexion réseau (pas de navigation Web), par exemple, ça fait encore l’affaire car c’est vraiment le seul usage où les performances ne sont pas vraiment un problème.
 

Je crois pas que « les gens » (ceux qu’on appelait jadis « lusers » ou « Michu », ici) sachent ni même se préoccupent une seule seconde de savoir ce que signifient les termes « 32 » et « 64 bits ». Donc, s’ils se fichent de ce détail, la réponse sera celle de la question « pourquoi continuer à utiliser ces trucs dépassés ? » : « parce que ça marche et que ça me suffit pour ce que je veux en faire » (authentique).

Et comme tout, vient un moment où faut passer à autre chose. La tv CRT couleur qui marchait bien mais permettait pas de brancher de l'HDMI ni de recevoir la TNT, la radio qui passe au DVB, les OS avec des navigateurs plus supportés car unsafe et maintenant le matos trop vieux et trop rare pour justifier de gaspiller des ressources deja pas si enormes dans le monde OSS.

C'est la vie c'est comme ca. Et en effet pour ces personnes, passer à une solution viable peut se faire gratuitement ou à très peu de frais. Et sinon juste rester avec le software dans sa version.

Suite à une mise à jour ce matin de plasma, au reboot, je me retrouve avec un gros manque d'icônes, 80% manquantes avec n'importe quel tĥême d'icônes breeze.
 
J'ai essayé ceci, sans effet:

 
Vu sur le forum manjaro q'un utilisateur avait installé qt6-sgv-plugins, puis après redémarrage du service plasmashell, les icônes sont réapparues:

Commande trouvée ici: https://bugs.kde.org/show_bug.cgi?id=481402

Je viens de découvrir qu'on ne peut plus faire plus de 4 partitions sur un disque? Il me dit de créer une partition étendue.  
Ca existait ça y a 4 ou 5 ans? A une époque j'avais 11 ou 12 partitions avec 3 OS différents et je me souviens pas d'avoir fait des partitions primaires, secondaires ou étendues...
Encore un problème en + pour installer un OS en +.  
 
 
 

T'as oublié, parce que ça n''a rien de nouveau
Ou alors avant t'étais en GPT, et là t'es en MBR.

En sid ou testing?

en MBR il n'a jamais été possible de créer plus de 4 partitions principales.
en GPT ce n'est pas le cas

 
J'ai deux autres HDD vierges qui attendent plusieurs OS linux, j'vais tenter d'être en GPT, mais je crois avoir lu qu'il peut y avoir un problème pour le boot.  

 
OK, je savais pas.

A moins d'avoir du matos préhistorique, ça ne devrait pas poser problème.

testing/unstable. La même version des paquets est dans les 2 repo.

C’est avec SecureBoot (qui requiert un disque système en GPT) que le problème peut se poser. Mais ça fait déjà un moment que les principales distributions sont maintenant compatibles avec SB, donc tu peux tenter et, si ça va pas, tu pourras toujours désactiver ce mécanisme dans l’UEFI.

 
Je suis plutôt d'accord  sur la fin du 32 bits, ça ne me choque pas.
 
De plus il ne faut pas oublier que debian 12 est supportée en EOL jusqu'au 30/06/2028 et en EOL ELTS jusqu'au 30/06/2033.  
 
Le 32 bits n'est donc pas fini

mais c'est juste l'installeur 64 bits qui ne sera plus fourni (auquel cas il resterait possible d'upgrader depuis debian 12), ou également les kernels 32 bits qui ne seront plus fournis par apt (auquel cas pas vraiment de solution après debian 12) ?

C'est ennuyant dans certains environnements, genre industriel/médical/... où tu as des machines qui peuvent avoir une durée de vie de plusieurs décennies.
Ca me dérange pas de faire des mises à jour "pour la beauté du geste", mais si il faut compiler le noyau, l'userland, et gérer - seul - les éventuelles régressions ...

 
J'ai réussi à faire marcher MX linux en GPT sur un autre disque, c'est bon. En fin de compte je n'installerai pas mx linux derrière debian mate, mx linux 23 est lent.
 
Je vais essayer d'installer Porteus, bien que c'est vraiment pas facile car j'ai une erreur comme ici: https://forum.porteus.org/viewtopic.php?t=9744
 
 
J'ai une question à vous poser: Si j'installe une version 32 bit d'un OS sur un processeur 64 d'ordi miserable, est ce que la distribution marchera et sera plus rapide qu'une version 64? (j'imagine qu'elle doit être plus légère)
 
edit: mais est ce que chrome marcherait sur une distrib en 32 bit...

Les noyaux ne sont plus compilés en 32 bits depuis le 6 octobre, et il n’existe pas de version i386 pour les paquets de Debian Testing. Ça répond à ta question ?
 

MX a un autre problème : on ne peut pas la mettre à niveau vers une nouvelle version. Il faut refaire une installation de zéro.
 

Non. Tu ne gagnerais rien et ce serait même le contraire pour les performances, dans l’absolu. Pour reprendre une comparaison avec le numéro de septembre 1995 de feu SVM : manger une soupe à la petite cuillère prend plus de temps qu’avec une grande… Sans parler du fait qu’en 32 bits, le total de mémoire adressable (la RAM système et celle de la CG, ainsi que celle d’autres périphériques) est de 4 Gio seulement (2³² octets), et c’est la RAM système qui se voit amputée de celle requise par les autres périphériques si tu dépasses ce plafond (une CG avec 1 Gio réduira la RAM système utilisable à seulement 3 Gio).
 
Quant à Chrome… Sur des vieilleries pareilles, faut peut-être oublier les navigateurs Web, surtout ceux basés sur Blink, tellement ce sont des « éléphantes enceintes » en termes de performances.

 
D'un côté, les machines industrielles/médicales ne sont en général jamais mises à jour

Et les hopitaux se prennent regulierement des ransomwares...

Ah oui mais bon, c'était 1000 € la mise à jour par notre fournisseur donc bon hein on n'a pas le budget

Alors, ça tombe très bien que vous parliez de ça, parce que Next (ex-INpact) vient de publier un article sur le dernier rapport de la Cour des Comptes traitant justement du cas de la sécurité informatique dans les hôpitaux. Spoiler : elle est vraiment pas bonne, mais pas bonne du tout…
 
Morceaux choisis (le gras, c’est de moi) :
 

Mais c’est vrai que 1 k€ pour maintenir ses systèmes à jour, c’est trop cher… Vaut mieux en perdre 10 à 20 000 fois plus en cas d’attaque et rester en mode dégradé pendant un an et demi.
 
(Je dis pas ça contre toi, Darx : je sais que tu étais ironique)

 
Merci pour l'explication.  

 
 
c'est amusant, mon PC au CHU est de 2017 (et marche très bien, physiquement je vois pas pourquoi il faudrait le changer, mais il n'est pas compatible windows 11... ).
 
le problème c'est que c'est pas 1000€ et on a fini. C'est ça + coùt d'installation/formation x nombres de postes et à recommencer régulièrement. Quand ton budget est déjà massivement en déficit en raison des politiques publiques, il faut faire des choix et la machine qui fonctionne encore ben elle attendra vs le médicament/dispositif/travaux dans les locaux/etc.
 

Après faudrait peut-être aussi voir quelles machines ont (quel) accès internet etc. Car y'a pas que les pertes en cas d'attaque, dans le domaine médical y'a aussi des données hypersensibles...
 
Enfin bref...

Pour le coup (et le coût), c’est pas moi qu’il va falloir convaincre, mais la Cour des Comptes. Certes, ce sont des professionnels du « yakafokon », mais c’est quand même à eux que tu dois plaider ta cause.

Suis en testing au bureau, apt upgrade et full upgrade ce matin et RIP les drivers nvidia des repository ça vautre le kernel au boot
 
Idem si je vire le tout et que je passe sur "nouveau". Seul moyen de récupérer mon mode graphique c'est d'installer les drivers nvidia récupéré sur leur site.

J’ai lu récemment (un mois de ça) que le canal Testing était le plus casse-gueule des trois, et qu’il était plus sûr d’être soit sur Stable, soit sur Sid (oui…) ; parce que contrairement aux deux autres, Testing n’a pas forcément tous les paquets. C’est ce qui a dû t’arriver.

 
Je n'ai jamais eu de soucis jusqu'à maintenant pour le moment ça tourne avec le driver récupéré chez nvidia, je vais attendre un moment pour voir ce que ça donne.
Le curieux de l'affaire, c'est le driver nouveau qui plante aussi

Ça m'est déjà arrivé le coup du driver NVIDIA qui saute à la mise à jour parce que pas dispo dans testing à un instant T. Depuis je regarde ce qu'apt compte faire lors d'un upgrade (et j'ai dégagé NVIDIA)

Debian 12.9 pour le 11 Janvier.