[HS] Noyau personnalisé contre noyau générique

Le
Stéphane GARGOLY
Bonjour à tous les utilisateurs et développeurs de Debian :

Le jeudi 23 octobre 2014 à 12:25, François Boisson <user.anti-
spam@maison.homelinux.net> a écrit :
> Le Thu, 23 Oct 2014 10:10:33 +0200
>
> maderios <maderios@gmail.com> a écrit:
> > C'est simple, le noyau fourni par la distribution est compilé pour
> > convenir à tous les utilisateurs/configurations possibles et
> > imaginables. Ceci implique qu'une multitude de trucs
> > optionnels/inutiles sont chargés en dur, avec pour conséquence un
> > alourdissement du système. Il suffit de visualiser la conf du noyau
> > officiel pour se rendre compte de son embonpoint. Un noyau personnalis=
é
> > et adapté rend le système plus réactif, c'est tout du moins ce qu=
e j'ai
> > constaté.

Je suis globalement d'accord avec Maderios concernant l'intérêt d'utili=
ser un
noyau Linux adapté - à la configuration matérielle de son ordinateur.=
.. et à
l'utilisation qu'on compte faire de son système GNU/Linux - par rapport =
à un
noyau générique fourni par Debian (ou par toute autre distribution).

Je me suis déjà exprimé (très) longuement sur ce sujet il y a plus =
d'un an sur
cette liste :
https://lists.debian.org/debian-user-french/2013/08/msg00234.html

Je suis - juste - un peu plus prudent concernant le gain de réactivité=

qu'aurait généré un noyau personnalisé mais, bon, cela doit certain=
ement
dépendre de l'ordinateur.

En tout cas, je n'attends pas avoir de gros écarts et, de toute façon, =
la
réactivité d'un système GNU/Linux dans son ensemble va bien au-delà=
du seul
noyau (personnalisé ou non) même si cela reste un paramètre important.

> Certes mais en ce qui conerne le bnoyau tu passes de 3M à 600-700K à =
tout
> casser soit un gain de 2,3M à comparer avec les 512M à 8G des machines
> actuelles (la situation n'était pas la même avec des machines 8M fin =
des
> années 90). Le code non utile est non utilisée et ne sert à rien m=
ais ne
> ralentit rien (pas vu de différence sauf au chargement ce dont je me
> moque).

Il arrive parfois que certains considèrent qu'il n'y a pas de petites
économies au niveau de l'occupation mémoire - même avec une mémoire=
centrale
de 8 Go.

Notons aussi que, à la fin des années 1990, les noyaux Linux (même g=
énériques)
faisaient plutôt 600 à 700 ko que 3 Mo. D'ailleurs, quand je suis rentr=
é dans
la marmite du GNU/Linux il y a bientôt 15 ans, je me souviens qu'on pouva=
it
mettre un noyau version 2.2 (accompagné des fichiers System.map et initrd=
.img)
dans une simple disquette de 1440 ko. C'est ainsi qu'on pouvait procéder =
à
l'installation d'un système GNU/Linux à partir d'une disquette.

Je me souviens aussi que les ordinateurs (qu'on commercialisait toujours =
à
cette époque) contenaient plutôt 32 à 128 Mo de mémoire centrale ma=
is peu
importe.

A vrai dire et pour moi, le problème est au niveau de sa configuration :=

démarrez-la (à partir de la commande "make menuconfig " ou "make xconfi=
g") et
vous vous trouvez à gérer approximativement - je ne me suis pas "amus=
é" à
compter une à une - 3000 options (pilotes et fonctionnalités).

Au cours des années 2000 à 2008, je procédais régulièrement à l=
a configuration
(et à la compilation) du noyau Linux mais, outre que depuis j'ai changé=

d'ordinateur (et même d'architecture en passant de IA-32 à AMD64), je n=
e
retrouve plus mes fichiers config-* que j'ai dû ranger dans des je ne sai=
s
quelles unités de mémoire de masse (CD-ROM, disquettes ZIP, disques dur=
s
externes,) que je me suis servies pour l'archivage.

Cependant, dans son numéro 167 de janvier 2014, la revue "GNU/Linux Magaz=
ine
France" avait produit un long article sur la compilation du noyau (et sur=

l'utilisation de DKMS) et, à la lecture de cet article et après quelque=
s
réflexions, j'ai eu quelques idées qui peuvent faciliter - peut-être =
et, au
moins, en partie - la configuration du noyau.

Pour l'instant, sur mon système GNU/Linux, j'ai d'autres priorités mais=
je
compte bien reprendre la compilation dans des prochains mois.

Cordialement et à bientôt,

Stéphane.

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: https://lists.debian.org/201410240840.32241.stephane.gargoly@gmail.com
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses Page 1 / 3
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
daniel huhardeaux
Le #26317164
Bonjour

Le 24/10/2014 10:40, Stéphane GARGOLY a écrit :
[...]
Notons aussi que, à la fin des années 1990, les noyaux Linux (même génériques)
faisaient plutôt 600 à 700 ko que 3 Mo. D'ailleurs, quand je suis rentré dans
la marmite du GNU/Linux il y a bientôt 15 ans, je me souviens qu'on pouvait
mettre un noyau version 2.2 (accompagné des fichiers System.map et initrd.img)
dans une simple disquette de 1440 ko. C'est ainsi qu'on pouvait procéder à
l'installation d'un système GNU/Linux à partir d'une disquette.



Pourquoi on pouvait? C'est toujours le cas

http://www.fli4l.de/fr/fli4l/fli4l-cest-quoi/

--
Daniel

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/
maderios
Le #26317251
On 10/24/2014 10:40 AM, Stéphane GARGOLY wrote:

Je suis - juste - un peu plus prudent concernant le gain de réactivité
qu'aurait généré un noyau personnalisé mais, bon, cela doit certainement
dépendre de l'ordinateur.



Je constate vraiment de meilleures performances, sinon je ne me serais
pas enquiquiné à compiler des centaines de noyaux depuis 15 ans...

A vrai dire et pour moi, le problème est au niveau de sa configuration :
démarrez-la (à partir de la commande "make menuconfig " ou "make xconfig") et
vous vous trouvez à gérer approximativement - je ne me suis pas "amusé" à
compter une à une - 3000 options (pilotes et fonctionnalités).



- Compréhension de l'anglais obligatoire
- les doc en ligne sur le sujet sont pour moi imbuvables ou/et trop
succinctes et ont tendance à compliquer ce qui est simple (vrai pour
Debian/Linux en général)
- installer kernel-package + initramfs-tools et récupérer les dernières
sources du dernier noyau ici (je n'aime pas les sources Debian)
https://www.kernel.org/
- Pour démarrer la 1° compilation et se simplifier la vie, copier la
conf du noyau générique Debian, par ex le 3.16
- lancer make menuconfig
- Dégraisser la conf de tout ce qui est susceptible d'être inutile ou
d'être paramétré en fonction du matériel et des besoins, ne pas avoir la
main lourde... On apprend ainsi des tas de choses et on finit par
repérer au fil du temps ce qui est utile ou non. Plutôt se fier à "if
unsure, say Y".
- lancer la compilation
make-kpkg --jobs 9 kernel_image --initrd ( '--jobs 9' pour une cpu 8
threads, à ajuster n threads +1 en fonction de la cpu, cf page man )
- Récupérer sa dernière conf perso lors des changements de versions en
sachant qu'il y a souvent des modif à faire.
--
Maderios


--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/
BERTRAND Joël
Le #26317255
maderios a écrit :
On 10/24/2014 10:40 AM, Stéphane GARGOLY wrote:

Je suis - juste - un peu plus prudent concernant le gain de réactivité
qu'aurait généré un noyau personnalisé mais, bon, cela doit certainement
dépendre de l'ordinateur.



Je constate vraiment de meilleures performances, sinon je ne me serais
pas enquiquiné à compiler des centaines de noyaux depuis 15 ans...



J'aimerais bien avoir des chiffres pour savoir de quoi on parle. Autant
sur des sparc64 ou alpha, c'est intéressant, autant je demande
franchement à voir sur du x86. C'est intéressant sur l'alpha parce que
le noyau de base est compilé pour un ev4 qui n'a pas les extensions BWX,
donc qui se coltine un adressage bâtard pour accéder à un octet. Donc,
dès qu'on utilise un truc supérieur à l'ev56 inclus, il est intéressant
de recompiler son noyau.

Pour un x86, l'architecture du processeur ne change pas assez pour
avoir une significative différence de performance en recompilant son
noyau avec un -mtune ou un -march (même en virant le code qui n'est pas
utile à sa configuration particulière).

A vrai dire et pour moi, le problème est au niveau de sa configuration :
démarrez-la (à partir de la commande "make menuconfig " ou "make
xconfig") et
vous vous trouvez à gérer approximativement - je ne me suis pas "amusé" à
compter une à une - 3000 options (pilotes et fonctionnalités).



- Compréhension de l'anglais obligatoire
- les doc en ligne sur le sujet sont pour moi imbuvables ou/et trop
succinctes et ont tendance à compliquer ce qui est simple (vrai pour
Debian/Linux en général)
- installer kernel-package + initramfs-tools et récupérer les dernières
sources du dernier noyau ici (je n'aime pas les sources Debian)
https://www.kernel.org/
- Pour démarrer la 1° compilation et se simplifier la vie, copier la
conf du noyau générique Debian, par ex le 3.16
- lancer make menuconfig
- Dégraisser la conf de tout ce qui est susceptible d'être inutile ou
d'être paramétré en fonction du matériel et des besoins, ne pas avoir la
main lourde... On apprend ainsi des tas de choses et on finit par
repérer au fil du temps ce qui est utile ou non. Plutôt se fier à "if
unsure, say Y".
- lancer la compilation
make-kpkg --jobs 9 kernel_image --initrd ( '--jobs 9' pour une cpu 8
threads, à ajuster n threads +1 en fonction de la cpu, cf page man )
- Récupérer sa dernière conf perso lors des changements de versions en
sachant qu'il y a souvent des modif à faire.



Tu aimes vivre dangereusement. Le noyau vanilla est considéré
aujourd'hui comme un noyau de développement, charge aux distributions de
le stabiliser. Par ailleurs, certains pans du noyau ne sont correctement
compilés que par une version bien précise de gcc.

JKB

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/
maderios
Le #26317279
On 10/24/2014 03:06 PM, BERTRAND Joël wrote:
maderios a écrit :
On 10/24/2014 10:40 AM, Stéphane GARGOLY wrote:

Je suis - juste - un peu plus prudent concernant le gain de réactivité
qu'aurait généré un noyau personnalisé mais, bon, cela doit certainement
dépendre de l'ordinateur.



Je constate vraiment de meilleures performances, sinon je ne me serais
pas enquiquiné à compiler des centaines de noyaux depuis 15 ans...



J'aimerais bien avoir des chiffres pour savoir de quoi on parle.
Autant sur des sparc64 ou alpha, c'est intéressant, autant je demande
franchement à voir sur du x86. C'est intéressant sur l'alpha parce que
le noyau de base est compilé pour un ev4 qui n'a pas les extensions BWX,
donc qui se coltine un adressage bâtard pour accéder à un octet. Donc,
dès qu'on utilise un truc supérieur à l'ev56 inclus, il est intéressant
de recompiler son noyau.

Pour un x86, l'architecture du processeur ne change pas assez pour
avoir une significative différence de performance en recompilant son
noyau avec un -mtune ou un -march (même en virant le code qui n'est pas
utile à sa configuration particulière).


Tu aimes vivre dangereusement. Le noyau vanilla est considéré
aujourd'hui comme un noyau de développement, charge aux distributions de
le stabiliser. Par ailleurs, certains pans du noyau ne sont correctement
compilés que par une version bien précise de gcc.


Quel danger? Les maj de sécurité sur kernel.org sont immédiates... J'ai
rencontré moins de problèmes (ex pour l'audio et la carte graphique)
avec les sources du noyau originales qu'avec les sources Debian.
Question gcc, j'utilise la 4.9 (Sid)
Pour élargir le sujet, certains paquets Debian ne sont pas au top,
négligés ou inexistants (ex E17 utilisable depuis longtemps) et je
préfère compiler les sources originales. J'ai du virer ce matin le
récent paquet debian Terminology pour cause de comportement étrange,
donc retour à mon paquet compilé perso qui marche à merveille. Idem pour
le paquet deb Mnogosearch qui logue à n'en plus finir et qui était
obsolète ... Transmageddon, qui ne procurait plus Xvid sauf la vieille
version 0.20 compilée perso. Ouf, Transmageddon 1.4 vient de sortir et
il réintègre Xvid. A compiler sinon il faut attendre en restant sur
l'ancienne version. Tout ceci pour dire qu'il est avantageux de
compiler certains programmes tout en gardant une base debian fiable.
Cela permet de s'affranchir des délais de maj, de vivre dans une
relative indépendance par rapport à certains choix de Debian, et de
gagner du temps et de la fiabilité, malgré les apparences.

--
Maderios


--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/
admini
Le #26317352
Il arrive parfois que certains considèrent qu'il n'y a pas de petites
économies au niveau de l'occupation mémoire - même avec une mémoire centrale
de 8 Go.



mes serveurs ont des mémoires de 24 à 96Go, dans le monde de la
production, l'économie de 3Mo est ridicule compte tenu du cout de la
recompilation: tu multiplie le temps que j'y passe par mon salaire, on a
dejà de quoi se payer une barrette de 8Go (c'est parce que je suis payé
au lance pierre)


Notons aussi que, à la fin des années 1990, les noyaux Linux (même génériques)
faisaient plutôt 600 à 700 ko que 3 Mo. D'ailleurs, quand je suis rentré dans
la marmite du GNU/Linux il y a bientôt 15 ans, je me souviens qu'on pouvait
mettre un noyau version 2.2 (accompagné des fichiers System.map et initrd.img)
dans une simple disquette de 1440 ko. C'est ainsi qu'on pouvait procéder à
l'installation d'un système GNU/Linux à partir d'une disquette.



on peut toujours.

Je me souviens aussi que les ordinateurs (qu'on commercialisait toujours à
cette époque) contenaient plutôt 32 à 128 Mo de mémoire centrale mais peu
importe.




Mon premier PC en avait 4 ... j'ai du économiser 500FF, pour avoir les 4
autres Mo. c'était un SX25 qui marchait à 8 Bits !!! j'avais encore le
bouton turbo et meme pas de radiateur sur le CPU. là oui, la compilation
est obligatoire, si non c'est un tiers du smic qui à y passait.


A vrai dire et pour moi, le problème est au niveau de sa configuration :
démarrez-la (à partir de la commande "make menuconfig " ou "make xconfig") et
vous vous trouvez à gérer approximativement - je ne me suis pas "amusé" à
compter une à une - 3000 options (pilotes et fonctionnalités).

Au cours des années 2000 à 2008, je procédais régulièrement à la configuration
(et à la compilation) du noyau Linux mais, outre que depuis j'ai changé
d'ordinateur (et même d'architecture en passant de IA-32 à AMD64), je ne
retrouve plus mes fichiers config-* que j'ai dû ranger dans des je ne sais
quelles unités de mémoire de masse (CD-ROM, disquettes ZIP, disques durs
externes,...) que je me suis servies pour l'archivage.

Cependant, dans son numéro 167 de janvier 2014, la revue "GNU/Linux Magazine
France" avait produit un long article sur la compilation du noyau (et sur
l'utilisation de DKMS) et, à la lecture de cet article et après quelques
réflexions, j'ai eu quelques idées qui peuvent faciliter - peut-être et, au
moins, en partie - la configuration du noyau.

Pour l'instant, sur mon système GNU/Linux, j'ai d'autres priorités



voilà, le mot: priorité.

c'est quoi la priorité aujourd'hui qui justifie qu'on passe du temps à
compiler le kernel?



gain de mémoire, mais uniquement dans le cadre de l'embarqué. sur un
serveur à 96Go de RAM je ne vois vraiment pas l'interet à compiler le
kernel pour gagner les 3Mo. dans les machines comme ca, je mets 0 swap!

gain de performance, mais hors virtualisation. et tout dépend de ce
qu'on fait. si on travaille dans un environnement lourdement chargé en
IO, la recompile peut etre utile, mais une fois de plus, vu le temps
qu'on y passe, optimiser le stockage, sizer correctement les trames
réseaux ou les cellules transmises dans les fibres me parait plus
efficace. il y a tellement d'autres parametres qui rentrent en jeu dans
le gain de la perfe, que la recompile est vraiment la cerise sur le
gateau quand on plus rien d'autre à faire. MAIS, faut-il encore avoir le
temps de la refaire chaque fois qu'on met à jour le kernel ! et le temps
c'est l'argent. dans une entreprise, ca compte.


gain de sécurité: là, c'est un autre débat. une machine très exposée en
DMZ subissant 10000 connexions uniques à la minutes?? oui, il faut peut
etre la recompile, non pour la perfe, mais pour durcir le kernel en
monolitique. et de toute façon, dans les grosses boites qui ont de gros
sites ayant ce genre de fréquentation web, ils ont souvent des grappes
de nginx clonés à l'identique par lot de 10. la compilation est faite
une fois sur le template sur un blade center. donc, ils ont les moyens
de se payer le luxe d'un kernel recompilé aux petits ognons.


conclusion: aujourd'hui, la recompile pour moi, a un champs assez limité
en environnement de production. en effet, les machines sont crées et
détruites toutes les heures, la recompile c'est vraiment dans les cas
très particuliers dans l'industrie où l'embarqué est présent. appliance
de firewall basés sur linux, PC pilotant un ROBOT de chaine de montage,
caisse enregistreuses dans les supermarchés .....



ou un geek céliba chez papa maman ....






mais je
compte bien reprendre la compilation dans des prochains mois.

Cordialement et à bientôt,

Stéphane.




--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/
maderios
Le #26317399
On 10/25/2014 12:07 AM, admini wrote:

voilà, le mot: priorité.

c'est quoi la priorité aujourd'hui qui justifie qu'on passe du temps à
compiler le kernel?



La priorité pour moi, c'est ne pas être dépendant de gens qui décident
tout pour nous.
Pour casser une idée reçue: une compilation kernel demande peu de temps,
4 mn sur ma machine, le temps de faire autre chose sur la même machine.
Quant à la configuration, une fois qu'on l'a faite au départ on la
garde, avec très peu de modif au fil des versions.

--
Maderios


--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/
Stéphane GARGOLY
Le #26317486
Bonjour à tous les utilisateurs et développeurs de Debian :

Le vendredi 24 octobre 2014 à 22:07, admini
> Notons aussi que, à la fin des années 1990, les noyaux Linux (même
> génériques) faisaient plutôt 600 à 700 ko que 3 Mo. D'ailleurs, quand je
> suis rentré dans la marmite du GNU/Linux il y a bientôt 15 ans, je me
> souviens qu'on pouvait mettre un noyau version 2.2 (accompagné des
> fichiers System.map et initrd.img) dans une simple disquette de 1440 ko.
> C'est ainsi qu'on pouvait procéder à l'installation d'un système
> GNU/Linux à partir d'une disquette.

on peut toujours.



[Je répond aussi à Daniel H. concernant ce point]

Je pense moi aussi que c'est encore possible aujourd'hui. Cependant, un
"petit" noyau (version 2.6.x ou 3.y) doit avoir probablement des sévère s
restrictions au niveau des pilotes et/ou fonctionnalités que les noyaux d its
"génériques" distribués par les plus importantes (ou les plus notoire s)
distributions.

> Cependant, dans son numéro 167 de janvier 2014, la revue "GNU/Linux
> Magazine France" avait produit un long article sur la compilation du
> noyau (et sur l'utilisation de DKMS) et, à la lecture de cet article et
> après quelques réflexions, j'ai eu quelques idées qui peuvent fac iliter
> - peut-être et, au moins, en partie - la configuration du noyau.
>
> Pour l'instant, sur mon système GNU/Linux, j'ai d'autres priorités

voilà, le mot: priorité.



A vrai dire, j'aurais dû dire : "je n'ai pas trop envie pour l'instant".

gain de sécurité: là, c'est un autre débat. une machine très ex posée en
DMZ subissant 10000 connexions uniques à la minutes?? oui, il faut peut
etre la recompile, non pour la perfe, mais pour durcir le kernel en
monolitique. et de toute façon, dans les grosses boites qui ont de gros
sites ayant ce genre de fréquentation web, ils ont souvent des grappes
de nginx clonés à l'identique par lot de 10. la compilation est faite
une fois sur le template sur un blade center. donc, ils ont les moyens
de se payer le luxe d'un kernel recompilé aux petits ognons.



Je me doutais bien que autant pour un ordinateur personnel ou familial (che z
un particulier) ou pour poste de travail (dans une entreprise ou une
administration), il peut être intéressant d'avoir un noyau modulaire, a utant
pour un serveur, il est préférable d'utiliser un noyau purement monolit hique.

conclusion: aujourd'hui, la recompile pour moi, a un champs assez limité
en environnement de production. en effet, les machines sont crées et
détruites toutes les heures, la recompile c'est vraiment dans les cas
très particuliers dans l'industrie où l'embarqué est présent. app liance
de firewall basés sur linux, PC pilotant un ROBOT de chaine de montage,
caisse enregistreuses dans les supermarchés .....

ou un geek céliba chez papa maman ....



Effectivement, le geek que je suis (voir note a) n'a pas à subir de contr aintes
ou de pressions qu'un administrateur système ou réseau peut être conf ronté
dans le monde professionnel.

Note a : Je suis effectivement encore célibataire mais il y a bien longte mps -
20 ans au moins - que je ne suis plus "chez papa maman"... ;-)

Cordialement et à bientôt,

Stéphane.

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/
admini
Le #26317638
Le 25/10/2014 10:41, maderios a écrit :
On 10/25/2014 12:07 AM, admini wrote:

voilà, le mot: priorité.

c'est quoi la priorité aujourd'hui qui justifie qu'on passe du temps à
compiler le kernel?



La priorité pour moi, c'est ne pas être dépendant de gens qui décident
tout pour nous.



sur le principe, je suis bien d'accord. malheureusement, tout le monde
n'est pas chef d'entreprise. et meme lorsqu'on l'est, on est quand meme
sous "l'autorité" des actionnaires et des clients.

Pour casser une idée reçue: une compilation kernel demande peu de temps,
4 mn sur ma machine, le temps de faire autre chose sur la même machine.



ben, en production, le temps, c'est tout ce qu'on n'a pas. 4 minutes
fois le nombre de machines fois le nombre de clients ayant des besoins
plus divers les uns que les autres, ca devient très vite ingérable. ben
oui, chaque besoin justifie une compile différente non? et les besoins
d'un client évolue dans le temps. de toute façon, je ne connais aucune
boite hébergeur de SAS ou autres machin du genre qui recompile le
kernel. en cas de problèmes, chaque truc fait maison constitue une piste
supplémentaire d'enquête. et pour le faire il faut donc, embaucher un
type assez pointu, dont le salaire sera évidemment plus élevé qu'un
simple admin de base.

bienvenue dans la production.

Quant à la configuration, une fois qu'on l'a faite au départ on la
garde, avec très peu de modif au fil des versions.




il ne faut pas oublier non plus les machines qui évoluent aussi. cela
dit, dans le cadre de R&D, de test, ou perso, on fait ce qu'on veut.

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/
maderios
Le #26317653
On 10/26/2014 10:48 AM, admini wrote:
Le 25/10/2014 10:41, maderios a écrit :
On 10/25/2014 12:07 AM, admini wrote:

voilà, le mot: priorité.

c'est quoi la priorité aujourd'hui qui justifie qu'on passe du temps à
compiler le kernel?



La priorité pour moi, c'est ne pas être dépendant de gens qui décident
tout pour nous.



sur le principe, je suis bien d'accord. malheureusement, tout le monde
n'est pas chef d'entreprise. et meme lorsqu'on l'est, on est quand meme
sous "l'autorité" des actionnaires et des clients.


J'ai choisi GNU/Linux en 1999 pour être indépendant des lobbies industriels.
Puis j'ai choisi Debian pour accroître cette indépendance: distribution
stable, bidouillable à l'infini, nombre minimum de dépendances paquets,
éthique.

Pour casser une idée reçue: une compilation kernel demande peu de temps,
4 mn sur ma machine, le temps de faire autre chose sur la même machine.



ben, en production, le temps, c'est tout ce qu'on n'a pas. 4 minutes
fois le nombre de machines fois le nombre de clients ayant des besoins
plus divers les uns que les autres, ca devient très vite ingérable. ben
oui, chaque besoin justifie une compile différente non? et les besoins
d'un client évolue dans le temps. de toute façon, je ne connais aucune
boite hébergeur de SAS ou autres machin du genre qui recompile le
kernel. en cas de problèmes, chaque truc fait maison constitue une piste
supplémentaire d'enquête. et pour le faire il faut donc, embaucher un
type assez pointu, dont le salaire sera évidemment plus élevé qu'un
simple admin de base.



Tu mentionnes ici une utilisation serveur ou/et parcs de machines, ce
n'est pas ce dont je parle. Il est bien évident que dans ce contexte,
les noyaux précompilés sont la seule solution.

bienvenue dans la production.


Debian sert à bien autre chose que faire tourner des serveurs....
Tu aurais du préciser "production serveur" car il existe bien d'autres
productions.

--
Maderios


--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/
Francois Boisson
Le #26317785
Le Sun, 26 Oct 2014 11:40:16 +0100
maderios
Tu mentionnes ici une utilisation serveur ou/et parcs de machines, ce
n'est pas ce dont je parle. Il est bien évident que dans ce contexte,
les noyaux précompilés sont la seule solution.
>



Pas vraiment, sur un parc de machines, la compilation d'un noyau utilisé pour
toutes les machines est rentable. Il ne faut pas exagérer, ce qui pose souci,
c'est la configuration du noyau (qui pour être bien faite peut prendre du
temps) et le fait qu'une erreur peut avoir des conséquences importantes. La
compilation elle même, qu'elle prenne une bonne demi heure (cas pour moi sur
une machine 4 fois 3200 bogomips) ou quatre minutes n'a pas d'importance, on
fait autre chose pendant ce temps.

François Boisson

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/
Publicité
Poster une réponse
Anonyme