Journal Slackware est désormais passée à la modernité

Posté par FreeB5D le 29 mai 2011 à 01:07. Licence CC By‑SA.

Étiquettes :

mai

2011

Aujourd'hui, en regardant le ChangeLog de Slackware, j'ai remarqué quelque chose de bien surprenant, inhabituel et carrément pas Slackwarien dans un de ses entrées. Après que le passage à GCC 3 de Slackware pour la version 9.0 ait enterré sa compatibilité avec les 386, voilà-t-y pas que Pat a encore frappé et cassé la compatibilité au niveau du processeur: le noyau par défaut de la version 32 bits sera désormais compilé pour le Pentium III ! Slackware-current est ainsi subitement passée du côté de la modernité, mais rassurons-nous: pour ceux qui ont encore des ordinosaures pré-PIII, ils pourront toujours démarrer le noyau huge.s, et seront encore tranquilles pendant une bonne dizaine d'années.

Source: http://www.slackware.com/changelog/current.php?cpu=i386

# He ben

Posté par rewind (Mastodon) le 29 mai 2011 à 18:05. Évalué à 7.

Moi qui croyais que Debian avait les choix les plus conservateurs parmi les distrib Linux, je vois que je me trompais lourdement...
- [^] # Re: He ben
  
  Posté par FreeB5D le 29 mai 2011 à 22:49. Évalué à 7.
  
  Pour Slackware, ça dépend. Au niveau des pilotes, depuis le passage définitif au noyau 2.6, le noyau et X.org sont assez à jour au moment de la sortie d'une nouvelle version. Pas comme Debian qui a sorti la Squeeze basée sur le noyau 2.6.32 moins de 3 mois avant Slackware 13.37, basée sur le noyau 2.6.37. Par contre au niveau des applications, c'est très différent. On trouve encore dans la version 32 bits des bibliothèques C++ aussi anciennes que libstdc++.so.3, et d'une façon générale il y a souvent des décisions qui sont prises parce que sinon «ça casse le logiciel propriétaire XYZ». Et sinon, dans Slackware, il n'y a toujours pas PAM et PulseAudio, mais à mon avis on pourra attendre encore longtemps avant de les voir et tant mieux.
# Pourquoi le PIII ?

Posté par DLFP est mort le 29 mai 2011 à 18:17. Évalué à 2.

Le passage du 386 vers 686 aurait été logique, mais pourquoi le PIII, alors que c'est juste un PII un peu évolué ?

DLFP >> PCInpact > Numerama >> LinuxFr.org
- [^] # Re: Pourquoi le PIII ?
  
  Posté par claudex le 29 mai 2011 à 18:26. Évalué à 2.
  
  Ils ont peut-être monter progressivement jusqu'à ce que quelqu'un râle. Du coup, ils ont pu fixer une limite en fonction de ce que les gens utilisent vraiment.
  
  « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
  - [^] # Re: Pourquoi le PIII ?
    
    Posté par DLFP est mort le 29 mai 2011 à 18:52. Évalué à 2.
    
    Oui mais bon la différence entre PII et PIII c'est la présence d'instructions SSE. Enfin peut-être que c'est optimisé pour PIII sans forcément exclure les précédents ?
    
    DLFP >> PCInpact > Numerama >> LinuxFr.org
    - [^] # Re: Pourquoi le PIII ?
      
      Posté par FreeB5D le 29 mai 2011 à 22:39. Évalué à 2.
      
      C'est CONFIG_MPIII=y dans la configuration du noyau. Donc a priori c'est avec rupture de compatibilité.
  - [^] # Re: Pourquoi le PIII ?
    
    Posté par FreeB5D le 29 mai 2011 à 22:37. Évalué à 3.
    
    D'après le ChangeLog, le changement a été fait en une seule fois, lors du passage du noyau 2.6.37 au noyau 2.6.38.
- [^] # Re: Pourquoi le PIII ?
  
  Posté par Patrick Lamaizière (site web personnel) le 29 mai 2011 à 21:46. Évalué à 6.
  
  Le passage du 386 vers 686 aurait été logique, mais pourquoi le PIII, alors que c'est juste un PII un peu évolué ?
  
  Il y a des processeurs assez récents qui sont des 586 (comme l'AMD Geode LX)
  
  les pixels au peuple !
  - [^] # Re: Pourquoi le PIII ?
    
    Posté par DLFP est mort le 29 mai 2011 à 21:48. Évalué à 2.
    
    Ah, je ne savais pas, surprenant. J'ai vérifié chez Via mais pas chez AMD.
    
    DLFP >> PCInpact > Numerama >> LinuxFr.org
- [^] # Re: Pourquoi le PIII ?
  
  Posté par FreeB5D le 29 mai 2011 à 22:35. Évalué à 4.
  Depuis la version 12.0 (2007), et jusqu'à maintenant, Slackware avait déjà le noyau par défaut (hugesmp.s) compilé pour 686 et le noyau huge.s compilé pour 486. À ma connaissance, il n'y a jamais eu de noyau 2.4 SMP dans Slackware. D'ailleurs, le fait que hugesmp.s soit pour 686 est clairement annoncé dans l'écran d'accueil ISOLINUX:
```
If you need to pass extra parameters to the kernel, enter them at the prompt
below after the name of the kernel to boot (huge.s etc).  NOTE: If your machine
is not at least a Pentium-Pro, you *must* boot and install with the huge.s
kernel, not the hugesmp.s kernel!  For older machines, use "huge.s" at the
boot prompt.
```
# Impacte ?

Posté par steph1978 le 30 mai 2011 à 12:08. Évalué à 4.

Bonjour,

Je ne suis pas hyper calé en compilation de noyau. Déjà fait mais de là à connaître les optimisations par architectures, non.
Donc je me posais la question : quel est l'impacte du choix d'un processeur cible (dans la même famille j'entends) ?
Je vois le set d'instructions utilisables ? les fréquences des bus ? la taille des caches peut être ?
Je suppose qu'il y a une compatibilité descendante dans les modèles de processeurs d'une même famille.

Merci de vos lumières.
- [^] # Re: Impacte ?
  
  Posté par FreeB5D le 30 mai 2011 à 21:02. Évalué à 4.
  Dans le fichier arch/x86/Makefile_32.cpu, dont je cite le début:
```
# CPU tuning section - shared with UML.
# Must change only cflags-y (or [yn]), not CFLAGS! That makes a difference for UML.

#-mtune exists since gcc 3.4
HAS_MTUNE       := $(call cc-option-yn, -mtune=i386)
ifeq ($(HAS_MTUNE),y)
tune            = $(call cc-option,-mtune=$(1),$(2))
else
tune            = $(call cc-option,-mcpu=$(1),$(2))
endif

align := $(cc-option-align)
cflags-$(CONFIG_M386)           += -march=i386
cflags-$(CONFIG_M486)           += -march=i486
```
  le processeur choisi dans CONFIG_MXYZ détermine le drapeau -march passé à gcc.
  Le manuel de gcc détaille le comportement de -march et -mtune: -mtune fait uniquement des optimisations compatibles avec le -march choisi, mais -march fait toutes les optimisations pour ce type de processeur et peut générer des codes opérations spécifiques. Par exemple, Slackware compile les logiciels en mode utilisateur (sauf peut-être Firefox, mais on sait bien que le vrai navigateur favori de Slackware est SeaMonkey) avec les options
```
-O2 -march=i486 -mtune=i686
```
  ce qui génère des programmes optimisés pour 686 en n'utilisant que des codes opérations compatibles avec le 486.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.