[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [HS] GAFAM est devenu GAFA



Marc Chantreux a écrit :
> on va encore rencontrer nombre d'experience démoralisantes mais je crois
> vraiment qu'on se rapproche du moment ou l'exponentielle décolle. ça a
> fait ca sur le marché du serveur aussi: alors que tout le monde nous
> riait encore fin des années 90, l'adoption a été fulgurante (je trouve)
> courant 2000.

	Ça, franchement, je ne suis pas sûr que ce soit réellement une bonne chose.

	Je m'explique :
1/ j'ai fait partie des premiers en France à installer du Linux. Mon
premier noyau en production fut, de mémoire, un 1.0.9, ce qui ne nous
rajeunit pas. Enfin, ne me rajeunit pas ;
2/ j'ai participé au développement du noyau sparc jusqu'au 2.4 inclus,
j'ai donc suivi les guéguerres intestines (en particulier l'histoire
fumeuse du serveur http dans le noyau pour éclater IIS, un grand moment
et celle non moins importante des la VM entre les 2.4.0 et 2.4.19 qui a
changé trois fois avec plein d'effets de bord rigolos comme des crashes
NMI sur les sparc) ;
3/ je suis aussi les guéguerres actuelles et, franchement, Linux en
général et debian en particulier filent un très mauvais coton. La
philosophie actuelle est très loin du KISS. On a vu arriver resolvconf
(déjà une aberration impossible à configurer correctement simplement),
network-manager (qui est capable de foutre un bronx pas possible sur un
serveur), un truc comme systemd (qui fonctionne dans 98% des cas
correctement, il faut juste ne pas être dans les 2% restants) qui sont
capable de mettre par terre un serveur en tuant des threads noyau et qui
est incapable de les relancer (j'ai un souvenir ému avec nfsd), des
daemons qui sont tout donc rien proprement et qui gèrent tout, la
numérotation des interfaces réseau en fonction du bus PCI et du nom du
pilote (alors qu'il était possible d'affecter simplement les numéros des
interfaces avec quelques règles), numérotation qui peut changer d'une
version du noyau à la suivante si les bus ne s'énumèrent pas dans le
même ordre (vécu, l'un de mes serveurs possèdes cinq cartes réseau Intel
de même référence) je suis donc revenu à l'ancien système à grands coups
de règles udev) ! Le problème, c'est que ce genre de "fonctionnalité"
peuvent mettre un serveur par terre avec un firewall aux fraises. Il est
vrai que l'immense majorité des utilisateurs n'a qu'une carte réseau à
sa disposition donc n'est pas impacté.

	Un Linux (debian au hasard) il y a quelques années, c'était du solide,
on pouvait l'oublier dans un coin. On redémarrait les machines à
distance sans croiser les doigts. Aujourd'hui, c'est devenu impossible.
On n'est jamais sûr lorsqu'il y a un systemd qui est mis à jour que la
machine fonctionnera de la même façon après redémarrage (ou que,
simplement, le réseau remontera normalement), d'autant qu'il est
impossible de redémarrer un ancien noyau vu l'interdépendance de la
grouille. Donc en dehors d'avoir un KVM sur IP, point de salut !

	Dans la version testing de debian, on a eu récemment un noyau qui
faisait gueuler les disques durs Toshiba. Exemple :

  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  84 51 01 d7 69 70 04  Error: ICRC, ABRT at LBA = 0x047069d7 = 74475991

  Commands leading to the command that caused the error were:
  CR FR SC SN CL CH DH DC   Powered_Up_Time  Command/Feature_Name
  -- -- -- -- -- -- -- --  ----------------  --------------------
  60 08 e0 d0 69 70 40 00      00:01:45.931  READ FPDMA QUEUED
  60 08 d8 e0 69 70 40 00      00:01:45.931  READ FPDMA QUEUED
  60 08 d0 20 6a 70 40 00      00:01:45.931  READ FPDMA QUEUED
  60 08 c8 d0 6a 70 40 00      00:01:45.931  READ FPDMA QUEUED
  60 08 c0 08 6b 70 40 00      00:01:45.931  READ FPDMA QUEUED

	Fausses alertes (tous les disques Toshiba de la machine remontaient les
mêmes alertes au même moment !...). On a eu l'un des noyaux 4.19 qui
crachait sur des erreurs mémoire fantaisistes, bref, tout ça n'est plus
vraiment sec ni sérieux. Je ne parle même pas de la gestion calamiteuse
des stations diskless, je deviendrai mauvaise langue.

	Sur les disques Seagate, les données smart sont de temps en temps
aberrantes. Il faut le savoir, c'est tout.

	Linux en général et Debian en particulier se "windowise" de plus en
plus en devenant Michu-compliant sur le poste de travail. C'est très
bien. Mais il n'y a plus de version solide et éprouvée en face. Ça date
des nouvelles règles de développement du noyau 2.6. Par version solide
et éprouvée, j'entends un système qui a un fonctionnement parfaitement
reproductible, même après un apt upgrade (je ne parle pas de changement
de version majeure) et qui se configure normalement avec une palanquée
de fichiers textes sur une console texte.

	Aujourd'hui, il me reste des postes de travail sous Linux (je ne veux
pas me faire des noeuds au cerveau en virant les linuxismes des codes
sources), il me reste un serveur de mail/alfresco qui a dû être installé
en potatoe et qui subit régulièrement des dist-upgrade et des chagements
de disques. Installé en i386 sur un Pentium 166 même pas MMX, il est
aujourd'hui en amd64 sur un i7. Toutes les autres machines sont passées
en xBSD. C'est nettement plus reposant lorsqu'on a autre chose à faire
de ses journées que de l'administration à temps plein.

	Bien cordialement,

	JKB


Reply to: