Re: [HS] Noyau personnalisé contre noyau générique
On 10/26/2014 06:51 PM, Francois Boisson wrote: Le Sun, 26 Oct 2014 11:40:16 +0100 maderios mader...@gmail.com a écrit: 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. La compilation d'un noyau optimisé pour un certain matériel et destiné à un parc de machines est certainement rentable si l'on veut y consacrer un peu de temps au départ. Par ailleurs, j'essaie de mettre la main sur la description des patches que Debian applique aux noyaux originaux de kernel.org. Quelqu'un connaît il un lien? Merci d'avance. -- 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 debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: https://lists.debian.org/544e060c.1060...@gmail.com
Re: [HS] Noyau personnalisé contre noyau générique
maderios a écrit : 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) Je parle de la stabilité du noyau. J'ai eu assez de problèmes sur architectures non x86 pour ne plus jouer à cela. Parce que le noyau sparc64 qui compile et fonctionne parfaitement avec un gcc 4.5 et qui merdoie allègrement avec force deadlocks lorsqu'il est compilé avec gcc 4.8, j'ai donné. Linus lui-même a indiqué sur les listes de diffusion du noyau que le 2.6 de kernel.org était _le_ noyau de développement et qu'il n'y aurait plus de branche de développement. 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. Ce n'est pas exactement la même chose. Le noyau est ce qui fait la stabilité du système. 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 debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: https://lists.debian.org/544e06b7.5010...@systella.fr
Re: [HS] Noyau personnalisé contre noyau générique
admini a écrit : 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 . Il y a bien une autre raison. Debian refuse sur alpha de faire une distribution ev4 et une autre ev56 ou plus, comme il n'y a jamais eu de distribution sparc_v7 et une autre sparc_v8+. Or dans les deux cas, recompiler son noyau (et son userland) avec les bonnes options permet un sacré gain en performances. Mais dans l'immense majorité des cas, hors embarqué, c'est un luxe totalement inutile. Sur arm, c'est aussi intéressant, mais là, pour le coup, différentes branches sont proposées. 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 debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: https://lists.debian.org/544e0755.2000...@systella.fr
Re: [HS] Noyau personnalisé contre noyau générique
maderios a écrit : 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. C'est justement ce qui va tuer Linux. Aujourd'hui, les grandes industries du logiciels tirent chacunes de leur côté avec pour certainres des moyejns qui dépassent allègrement ceux qu'elles mettent dans leurs OS maison (parce qu'elles n'aiment pas la licence BSD et c'est tant mieux). Résultat des courses, le noyau est devenu un immense foutoir avec des abi et des api qui changent plus vite que leur ombre. Là, tout de suite, il faut que je rétroporte un pilote du noyau 3.10 vers le 3.0. C'est mission impossible. Le corollaire est assez simple : il y a quelque temps, tu pouvais t'affranchir des lobbies industriels comme tu dis et maintenir un système à jour. Aujourd'hui, ce n'est plus le cas. Le développement du noyau fait que tu es contraint d'utiliser telle ou telle version du noyau quitte à ce qu'il soit plus percé qu'une passoire. Il est vrai que ça ne concerne pas le x86, mais dans l'embarqué, c'est une réalité à laquelle je suis tous les jours confronté. Typiquement, le dernier noyau que j'arrive à peu près à faire booter sur une carte avec un Freescale iMX-6 est un 3.0 (et encore, j'ai 5 threads noyau qui restent dans l'état D avec une charge de 5). Et ce noyau est un noyau Freescale (plein de patches Freescale) suivi de patches de l'intégrateur. Bref, de plus en plus de monde regarde ailleurs ce qu'il se fait parce que, dans l'embarqué qui doit avoir une durée de vie importante avec un minimum de sécurité, entre les blobs binaires, les firmwares foireux et les bouts de code pas secs, il devient difficile de faire quelque chose avec Linux. 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 debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: https://lists.debian.org/544e09d7.6030...@systella.fr
Re: [HS] Noyau personnalisé contre noyau générique
maderios a écrit : On 10/26/2014 06:51 PM, Francois Boisson wrote: Le Sun, 26 Oct 2014 11:40:16 +0100 maderios mader...@gmail.com a écrit: 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. La compilation d'un noyau optimisé pour un certain matériel et destiné à un parc de machines est certainement rentable si l'on veut y consacrer un peu de temps au départ. Par ailleurs, j'essaie de mettre la main sur la description des patches que Debian applique aux noyaux originaux de kernel.org. Quelqu'un connaît il un lien? Merci d'avance. apt-get source devrait t'aider un peu. 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 debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: https://lists.debian.org/544e0a1a.6080...@systella.fr
Re: [HS] Noyau personnalisé contre noyau générique
Le 27/10/2014 09:45, maderios a écrit : On 10/26/2014 06:51 PM, Francois Boisson wrote: Le Sun, 26 Oct 2014 11:40:16 +0100 maderios mader...@gmail.com a écrit: 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. La compilation d'un noyau optimisé pour un certain matériel et destiné à un parc de machines est certainement rentable si l'on veut y consacrer un peu de temps au départ. Par ailleurs, j'essaie de mettre la main sur la description des patches que Debian applique aux noyaux originaux de kernel.org. Quelqu'un connaît il un lien? Merci d'avance. Tu peux regarder sur la page du paquet de chaque noyau, exemple : https://packages.debian.org/jessie/linux-image-3.16-3-686-pae Il y a un lien vers le changelog : http://metadata.ftp-master.debian.org/changelogs//main/l/linux/linux_3.16.5-1_changelog il y a les modifications upstream puis les modfications Debian. -- == | FRÉDÉRIC MASSOT | | http://www.juliana-multimedia.com | | mailto:frede...@juliana-multimedia.com | | +33.(0)2.97.54.77.94 +33.(0)6.67.19.95.69 | ===Debian=GNU/Linux=== -- 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-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: https://lists.debian.org/544e95bc.20...@juliana-multimedia.com
Re: [HS] Noyau personnalisé contre noyau générique
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 RD, 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 debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: https://lists.debian.org/544cc35f.20...@freeatome.com
Re: [HS] Noyau personnalisé contre noyau générique
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 debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: https://lists.debian.org/544ccf90.6060...@gmail.com
Fwd: Re: [HS] Noyau personnalisé contre noyau générique
moi perso j'ai mes serveurs chez ovh du coup j'utilise leurs kernel recompiler pour leurs machines par leurs techniciens et plus à jour que ceux de debian du coup je n'ai pas ce problème en plus je gère essentiellement des serveurs de jeux vidéos en prod et ovh me propose des kernels avec ipV6 compilé à 1000Hz adapté à la machine j'ai juste à les installé et update-grub et c'est partis pour les serveurs auxiliaires teamspeak mumble web mail etc j'utilise leur kernel ipV6+GreSec et depuis 2004 j'ai pas de problèmes voila un retour d'experience juste comme sa en passant Le 26/10/2014 11:40, maderios a écrit : 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. --- L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast. http://www.avast.com
Re: [HS] Noyau personnalisé contre noyau générique
Le Sun, 26 Oct 2014 11:40:16 +0100 maderios mader...@gmail.com a écrit: 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 debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: https://lists.debian.org/20141026185109.5c74a721005dbce352e30...@maison.homelinux.net
Re: [HS] Noyau personnalisé contre noyau générique
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 debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: https://lists.debian.org/544b6245.2030...@gmail.com
Re: [HS] Noyau personnalisé contre noyau générique
Bonjour à tous les utilisateurs et développeurs de Debian : Le vendredi 24 octobre 2014 à 22:07, admini adm...@freeatome.com 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. 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ères restrictions au niveau des pilotes et/ou fonctionnalités que les noyaux dits génériques distribués par les plus importantes (ou les plus notoires) 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 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é. 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 exposée en DMZ subissant 1 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 (chez un particulier) ou pour poste de travail (dans une entreprise ou une administration), il peut être intéressant d'avoir un noyau modulaire, autant pour un serveur, il est préférable d'utiliser un noyau purement monolithique. 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 Effectivement, le geek que je suis (voir note a) n'a pas à subir de contraintes ou de pressions qu'un administrateur système ou réseau peut être confronté dans le monde professionnel. Note a : Je suis effectivement encore célibataire mais il y a bien longtemps - 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 debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: https://lists.debian.org/201410251315.29781.stephane.garg...@gmail.com
[HS] Noyau personnalisé contre noyau générique
Bonjour à tous les utilisateurs et développeurs de Debian : Le jeudi 23 octobre 2014 à 12:25, François Boisson user.anti- s...@maison.homelinux.net a écrit : Le Thu, 23 Oct 2014 10:10:33 +0200 maderios mader...@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 que j'ai constaté. Je suis globalement d'accord avec Maderios concernant l'intérêt d'utiliser 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 certainement 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 mais 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 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 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-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: https://lists.debian.org/201410240840.32241.stephane.garg...@gmail.com
Re: [HS] Noyau personnalisé contre noyau générique
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 debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: https://lists.debian.org/544a128a.5040...@tootai.net
Re: [HS] Noyau personnalisé contre noyau générique
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 debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: https://lists.debian.org/544a499f.3030...@gmail.com
Re: [HS] Noyau personnalisé contre noyau générique
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 debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: https://lists.debian.org/544a4ed0.2010...@systella.fr
Re: [HS] Noyau personnalisé contre noyau générique
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 debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: https://lists.debian.org/544a6d36.20...@gmail.com
Re: [HS] Noyau personnalisé contre noyau générique
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 1 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 debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive:
