[...]
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.
[...]
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.
[...]
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.
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.
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).
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.
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).
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.
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).
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.
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.
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 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.
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.
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.
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 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.
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.
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
compte bien reprendre la compilation dans des prochains mois.
Cordialement et à bientôt,
Stéphane.
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 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.
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.
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
compte bien reprendre la compilation dans des prochains mois.
Cordialement et à bientôt,
Stéphane.
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 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.
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.
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
compte bien reprendre la compilation dans des prochains mois.
Cordialement et à bientôt,
Stéphane.
voilà, le mot: priorité.
c'est quoi la priorité aujourd'hui qui justifie qu'on passe du temps à
compiler le kernel?
voilà, le mot: priorité.
c'est quoi la priorité aujourd'hui qui justifie qu'on passe du temps à
compiler le kernel?
voilà, le mot: priorité.
c'est quoi la priorité aujourd'hui qui justifie qu'on passe du temps à
compiler le kernel?
> 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.
> 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é.
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.
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 ....
> 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.
> 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é.
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.
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 ....
> 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.
> 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é.
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.
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 ....
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.
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.
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.
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.
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.
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.
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.
>
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.
>
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.
>