Bonjour =E0 tous les utilisateurs et d=E9veloppeurs de Debian :
Le jeudi 23 octobre 2014 =E0 12:25, Fran=E7ois Boisson <user.anti-
spam@maison.homelinux.net> a =E9crit :
> Le Thu, 23 Oct 2014 10:10:33 +0200
>=20
> maderios <maderios@gmail.com> a =E9crit:
> > C'est simple, le noyau fourni par la distribution est compil=E9 pour
> > convenir =E0 tous les utilisateurs/configurations possibles et
> > imaginables. Ceci implique qu'une multitude de trucs
> > optionnels/inutiles sont charg=E9s en dur, avec pour cons=E9quence un
> > alourdissement du syst=E8me. Il suffit de visualiser la conf du noyau
> > officiel pour se rendre compte de son embonpoint. Un noyau personnalis=
=E9
> > et adapt=E9 rend le syst=E8me plus r=E9actif, c'est tout du moins ce qu=
e j'ai
> > constat=E9.
Je suis globalement d'accord avec Maderios concernant l'int=E9r=EAt d'utili=
ser un=20
noyau Linux adapt=E9 - =E0 la configuration mat=E9rielle de son ordinateur.=
=2E. et =E0=20
l'utilisation qu'on compte faire de son syst=E8me GNU/Linux - par rapport =
=E0 un=20
noyau g=E9n=E9rique fourni par Debian (ou par toute autre distribution).
Je me suis d=E9j=E0 exprim=E9 (tr=E8s) longuement sur ce sujet il y a plus =
d'un an sur=20
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=E9activit=E9=
=20
qu'aurait g=E9n=E9r=E9 un noyau personnalis=E9 mais, bon, cela doit certain=
ement=20
d=E9pendre de l'ordinateur.
En tout cas, je n'attends pas avoir de gros =E9carts et, de toute fa=E7on, =
la=20
r=E9activit=E9 d'un syst=E8me GNU/Linux dans son ensemble va bien au-del=E0=
du seul=20
noyau (personnalis=E9 ou non) m=EAme si cela reste un param=E8tre important.
> Certes mais en ce qui conerne le bnoyau tu passes de 3M =E0 600-700K =E0 =
tout
> casser soit un gain de 2,3M =E0 comparer avec les 512M =E0 8G des machines
> actuelles (la situation n'=E9tait pas la m=EAme avec des machines 8M fin =
des
> ann=E9es 90). Le code non utile est non utilis=E9e et ne sert =E0 rien m=
ais ne
> ralentit rien (pas vu de diff=E9rence sauf au chargement ce dont je me
> moque).
Il arrive parfois que certains consid=E8rent qu'il n'y a pas de petites=20
=E9conomies au niveau de l'occupation m=E9moire - m=EAme avec une m=E9moire=
centrale=20
de 8 Go.
Notons aussi que, =E0 la fin des ann=E9es 1990, les noyaux Linux (m=EAme g=
=E9n=E9riques)=20
faisaient plut=F4t 600 =E0 700 ko que 3 Mo. D'ailleurs, quand je suis rentr=
=E9 dans=20
la marmite du GNU/Linux il y a bient=F4t 15 ans, je me souviens qu'on pouva=
it=20
mettre un noyau version 2.2 (accompagn=E9 des fichiers System.map et initrd=
=2Eimg)=20
dans une simple disquette de 1440 ko. C'est ainsi qu'on pouvait proc=E9der =
=E0=20
l'installation d'un syst=E8me GNU/Linux =E0 partir d'une disquette.
Je me souviens aussi que les ordinateurs (qu'on commercialisait toujours =
=E0=20
cette =E9poque) contenaient plut=F4t 32 =E0 128 Mo de m=E9moire centrale ma=
is peu=20
importe.
A vrai dire et pour moi, le probl=E8me est au niveau de sa configuration :=
=20
d=E9marrez-la (=E0 partir de la commande "make menuconfig " ou "make xconfi=
g") et=20
vous vous trouvez =E0 g=E9rer approximativement - je ne me suis pas "amus=
=E9" =E0=20
compter une =E0 une - 3000 options (pilotes et fonctionnalit=E9s).
Au cours des ann=E9es 2000 =E0 2008, je proc=E9dais r=E9guli=E8rement =E0 l=
a configuration=20
(et =E0 la compilation) du noyau Linux mais, outre que depuis j'ai chang=E9=
=20
d'ordinateur (et m=EAme d'architecture en passant de IA-32 =E0 AMD64), je n=
e=20
retrouve plus mes fichiers config-* que j'ai d=FB ranger dans des je ne sai=
s=20
quelles unit=E9s de m=E9moire de masse (CD-ROM, disquettes ZIP, disques dur=
s=20
externes,...) que je me suis servies pour l'archivage.
Cependant, dans son num=E9ro 167 de janvier 2014, la revue "GNU/Linux Magaz=
ine=20
=46rance" avait produit un long article sur la compilation du noyau (et sur=
=20
l'utilisation de DKMS) et, =E0 la lecture de cet article et apr=E8s quelque=
s=20
r=E9flexions, j'ai eu quelques id=E9es qui peuvent faciliter - peut-=EAtre =
et, au=20
moins, en partie - la configuration du noyau.
Pour l'instant, sur mon syst=E8me GNU/Linux, j'ai d'autres priorit=E9s mais=
je=20
compte bien reprendre la compilation dans des prochains mois.
Cordialement et =E0 bient=F4t,
St=E9phane.
--
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
Le Sun, 26 Oct 2014 11:40:16 +0100 maderios 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 En cas de soucis, contactez EN ANGLAIS Archive: https://lists.debian.org/
On 10/26/2014 06:51 PM, Francois Boisson wrote:
Le Sun, 26 Oct 2014 11:40:16 +0100
maderios <maderios@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-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: https://lists.debian.org/544E060C.1060100@gmail.com
Le Sun, 26 Oct 2014 11:40:16 +0100 maderios 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 En cas de soucis, contactez EN ANGLAIS Archive: https://lists.debian.org/
BERTRAND Joël
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 En cas de soucis, contactez EN ANGLAIS Archive: https://lists.debian.org/
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-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: https://lists.debian.org/544E06B7.5010904@systella.fr
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 En cas de soucis, contactez EN ANGLAIS Archive: https://lists.debian.org/
BERTRAND Joël
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 En cas de soucis, contactez EN ANGLAIS Archive: https://lists.debian.org/
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-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: https://lists.debian.org/544E0755.2000605@systella.fr
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 En cas de soucis, contactez EN ANGLAIS Archive: https://lists.debian.org/
BERTRAND Joël
maderios a écrit :
On 10/26/2014 06:51 PM, Francois Boisson wrote:
Le Sun, 26 Oct 2014 11:40:16 +0100 maderios 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 En cas de soucis, contactez EN ANGLAIS Archive: https://lists.debian.org/
maderios a écrit :
On 10/26/2014 06:51 PM, Francois Boisson wrote:
Le Sun, 26 Oct 2014 11:40:16 +0100
maderios <maderios@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-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: https://lists.debian.org/544E0A1A.6080404@systella.fr
Le Sun, 26 Oct 2014 11:40:16 +0100 maderios 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 En cas de soucis, contactez EN ANGLAIS Archive: https://lists.debian.org/
BERTRAND Joël
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 En cas de soucis, contactez EN ANGLAIS Archive: https://lists.debian.org/
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-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: https://lists.debian.org/544E09D7.6030607@systella.fr
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 En cas de soucis, contactez EN ANGLAIS Archive: https://lists.debian.org/
Frédéric MASSOT
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 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 :
il y a les modifications upstream puis les modfications Debian.
-- ============================================= | FRÉDÉRIC MASSOT | | http://www.juliana-multimedia.com | | mailto: | | +33.(0)2.97.54.77.94 +33.(0)6.67.19.95.69 | ==========================Þbian=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 En cas de soucis, contactez EN ANGLAIS Archive: https://lists.debian.org/
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 <maderios@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 :
il y a les modifications upstream puis les modfications Debian.
--
============================================= | FRÉDÉRIC MASSOT |
| http://www.juliana-multimedia.com |
| mailto:frederic@juliana-multimedia.com |
| +33.(0)2.97.54.77.94 +33.(0)6.67.19.95.69 |
==========================Þbian=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-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: https://lists.debian.org/544E95BC.20809@juliana-multimedia.com
Le Sun, 26 Oct 2014 11:40:16 +0100 maderios 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 :
il y a les modifications upstream puis les modfications Debian.
-- ============================================= | FRÉDÉRIC MASSOT | | http://www.juliana-multimedia.com | | mailto: | | +33.(0)2.97.54.77.94 +33.(0)6.67.19.95.69 | ==========================Þbian=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 En cas de soucis, contactez EN ANGLAIS Archive: https://lists.debian.org/
maderios
On 10/27/2014 07:58 PM, Frédéric MASSOT wrote:
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 :
il y a les modifications upstream puis les modfications Debian.
Merci. On peut tout de même dire que cette façon de présenter tout en vrac (c'est d'ailleurs général chez Debian) engendre de la confusion. Je pense vraiment que Debian n'a pas envie de communiquer, sauf avec les initiés. Tant pis pour les utilisateurs... -- 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/
On 10/27/2014 07:58 PM, Frédéric MASSOT wrote:
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 :
il y a les modifications upstream puis les modfications Debian.
Merci. On peut tout de même dire que cette façon de présenter tout en
vrac (c'est d'ailleurs général chez Debian) engendre de la confusion.
Je pense vraiment que Debian n'a pas envie de communiquer, sauf avec les
initiés. Tant pis pour les utilisateurs...
--
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-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: https://lists.debian.org/544E9D3E.5070103@gmail.com
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 :
il y a les modifications upstream puis les modfications Debian.
Merci. On peut tout de même dire que cette façon de présenter tout en vrac (c'est d'ailleurs général chez Debian) engendre de la confusion. Je pense vraiment que Debian n'a pas envie de communiquer, sauf avec les initiés. Tant pis pour les utilisateurs... -- 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/
Les patches que Debian appliquent sur le kernel peuvent être facilement t rouvé dans le linux_3.16.5-1.debian.tar.xz (sous les dossiers debian/patc hes) http://ftp.de.debian.org/debian/pool/main/l/linux/linux_3.16.5-1.debian.tar .xz
Je trouve cela assez clair et cela ne prête pas a confusion.
Librement, Valentin OVD
Date: Mon, 27 Oct 2014 20:30:06 +0100 From: To: Subject: Noyau personnalisé
On 10/27/2014 07:58 PM, Frédéric MASSOT wrote:
>> 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. > Merci. On peut tout de même dire que cette façon de présenter tout en vrac (c'est d'ailleurs général chez Debian) engendre de la confusion. Je pense vraiment que Debian n'a pas envie de communiquer, sauf avec le s initiés. Tant pis pour les utilisateurs... -- 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/
<html> <head> <style><!-- .hmmessage P { margin:0px; padding:0px } body.hmmessage { font-size: 12pt; font-family:Calibri } --></style></head> <body class='hmmessage'><div dir='ltr'>Les patches que Debian appliquen t sur le kernel peuvent être facilement trouvé dans le linux_3.1 6.5-1.debian.tar.xz (sous les dossiers debian/patches)<br><a href="http:/ /ftp.de.debian.org/debian/pool/main/l/linux/linux_3.16.5-1.debian.tar.xz" t arget="_blank">http://ftp.de.debian.org/debian/pool/main/l/linux/linux_3. 16.5-1.debian.tar.xz</a><br><br>Je trouve cela assez clair et cela ne prê te pas a confusion.<br><br>Librement,<br>Valentin OVD <br><br><br>> Date: Mon, 27 Oct 2014 20:30:06 +0100<br>> From: < br>> To: <br>> Subject: Noyau personnalisé<br>> <br>> On 10/27/2014 07:58 PM, Frédéric MASSOT wrote:<br>> <br>> >> Par ailleurs, j'essaie de mettre la main sur la description des<br>> >> patches que D ebian applique aux noyaux originaux de kernel.org.<br>> >> Q uelqu'un connaît il un lien? Merci d'avance.<br>> ><br>> & gt; Tu peux regarder sur la page du paquet de chaque noyau, exemple :<b r>> ><br>> > https://packages.debian.org/jessie/linux-i mage-3.16-3-686-pae<br>> ><br>> > Il y a un lien vers l e changelog :<br>> ><br>> > http://metadata.ftp-master. debian.org/changelogs//main/l/linux/linux_3.16.5-1_changelog<br>> > ;<br>> ><br>> > il y a les modifications upstream pui s les modfications Debian.<br>> ><br>> Merci. On peut tout d e même dire que cette façon de présenter tout en <br>> vrac (c'e st d'ailleurs général chez Debian) engendre de la confusion.<br>> Je pense vraiment que Debian n'a pas envie de communiquer, sauf avec les <br>> initiés. Tant pis pour les utilisateurs...<br>> -- <br>&g t; Maderios<br>> <br>> <br>> -- <br>> Lisez la FAQ de la liste avant de poser une question :<br>> http://wiki.debian.org/fr /FrenchLists<br>> <br>> Pour vous DESABONNER, envoyez un messag e avec comme objet "unsubscribe"<br>> vers debian-user-french-REQUEST@ lists.debian.org<br>> En cas de soucis, contactez EN ANGLAIS listmas <br>> Archive: https://lists.debian.org/544E9D3E.5 <br>> <br> </div></body> </html> --_d4a8e728-d65c-4679-8624-f3db8714d046_--
-- 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/
Les patches que Debian appliquent sur le kernel peuvent être facilement t rouvé dans le linux_3.16.5-1.debian.tar.xz (sous les dossiers debian/patc hes)
http://ftp.de.debian.org/debian/pool/main/l/linux/linux_3.16.5-1.debian.tar .xz
Je trouve cela assez clair et cela ne prête pas a confusion.
Librement,
Valentin OVD
Date: Mon, 27 Oct 2014 20:30:06 +0100
From: maderios@gmail.com
To: debian-user-french@lists.debian.org
Subject: Noyau personnalisé
On 10/27/2014 07:58 PM, Frédéric MASSOT wrote:
>> 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.
>
Merci. On peut tout de même dire que cette façon de présenter tout en
vrac (c'est d'ailleurs général chez Debian) engendre de la confusion.
Je pense vraiment que Debian n'a pas envie de communiquer, sauf avec le s
initiés. Tant pis pour les utilisateurs...
--
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-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: https://lists.debian.org/544E9D3E.5070103@gmail.com
<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></style></head>
<body class='hmmessage'><div dir='ltr'>Les patches que Debian appliquen t sur le kernel peuvent être facilement trouvé dans le linux_3.1 6.5-1.debian.tar.xz (sous les dossiers debian/patches)<br><a href="http:/ /ftp.de.debian.org/debian/pool/main/l/linux/linux_3.16.5-1.debian.tar.xz" t arget="_blank">http://ftp.de.debian.org/debian/pool/main/l/linux/linux_3. 16.5-1.debian.tar.xz</a><br><br>Je trouve cela assez clair et cela ne prê te pas a confusion.<br><br>Librement,<br>Valentin OVD <br><br><br>> Date: Mon, 27 Oct 2014 20:30:06 +0100<br>> From: maderios@gmail.com< br>> To: debian-user-french@lists.debian.org<br>> Subject: Noyau personnalisé<br>> <br>> On 10/27/2014 07:58 PM, Frédéric MASSOT wrote:<br>> <br>> >> Par ailleurs, j'essaie de mettre la main sur la description des<br>> >> patches que D ebian applique aux noyaux originaux de kernel.org.<br>> >> Q uelqu'un connaît il un lien? Merci d'avance.<br>> ><br>> & gt; Tu peux regarder sur la page du paquet de chaque noyau, exemple :<b r>> ><br>> > https://packages.debian.org/jessie/linux-i mage-3.16-3-686-pae<br>> ><br>> > Il y a un lien vers l e changelog :<br>> ><br>> > http://metadata.ftp-master. debian.org/changelogs//main/l/linux/linux_3.16.5-1_changelog<br>> > ;<br>> ><br>> > il y a les modifications upstream pui s les modfications Debian.<br>> ><br>> Merci. On peut tout d e même dire que cette façon de présenter tout en <br>> vrac (c'e st d'ailleurs général chez Debian) engendre de la confusion.<br>> Je pense vraiment que Debian n'a pas envie de communiquer, sauf avec les <br>> initiés. Tant pis pour les utilisateurs...<br>> -- <br>&g t; Maderios<br>> <br>> <br>> -- <br>> Lisez la FAQ de la liste avant de poser une question :<br>> http://wiki.debian.org/fr /FrenchLists<br>> <br>> Pour vous DESABONNER, envoyez un messag e avec comme objet "unsubscribe"<br>> vers debian-user-french-REQUEST@ lists.debian.org<br>> En cas de soucis, contactez EN ANGLAIS listmas ter@lists.debian.org<br>> Archive: https://lists.debian.org/544E9D3E.5 070103@gmail.com<br>> <br> </div></body>
</html>
--_d4a8e728-d65c-4679-8624-f3db8714d046_--
--
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/DUB119-W29D75F8A77141F56074B75869E0@phx.gbl
Les patches que Debian appliquent sur le kernel peuvent être facilement t rouvé dans le linux_3.16.5-1.debian.tar.xz (sous les dossiers debian/patc hes) http://ftp.de.debian.org/debian/pool/main/l/linux/linux_3.16.5-1.debian.tar .xz
Je trouve cela assez clair et cela ne prête pas a confusion.
Librement, Valentin OVD
Date: Mon, 27 Oct 2014 20:30:06 +0100 From: To: Subject: Noyau personnalisé
On 10/27/2014 07:58 PM, Frédéric MASSOT wrote:
>> 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. > Merci. On peut tout de même dire que cette façon de présenter tout en vrac (c'est d'ailleurs général chez Debian) engendre de la confusion. Je pense vraiment que Debian n'a pas envie de communiquer, sauf avec le s initiés. Tant pis pour les utilisateurs... -- 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/
<html> <head> <style><!-- .hmmessage P { margin:0px; padding:0px } body.hmmessage { font-size: 12pt; font-family:Calibri } --></style></head> <body class='hmmessage'><div dir='ltr'>Les patches que Debian appliquen t sur le kernel peuvent être facilement trouvé dans le linux_3.1 6.5-1.debian.tar.xz (sous les dossiers debian/patches)<br><a href="http:/ /ftp.de.debian.org/debian/pool/main/l/linux/linux_3.16.5-1.debian.tar.xz" t arget="_blank">http://ftp.de.debian.org/debian/pool/main/l/linux/linux_3. 16.5-1.debian.tar.xz</a><br><br>Je trouve cela assez clair et cela ne prê te pas a confusion.<br><br>Librement,<br>Valentin OVD <br><br><br>> Date: Mon, 27 Oct 2014 20:30:06 +0100<br>> From: < br>> To: <br>> Subject: Noyau personnalisé<br>> <br>> On 10/27/2014 07:58 PM, Frédéric MASSOT wrote:<br>> <br>> >> Par ailleurs, j'essaie de mettre la main sur la description des<br>> >> patches que D ebian applique aux noyaux originaux de kernel.org.<br>> >> Q uelqu'un connaît il un lien? Merci d'avance.<br>> ><br>> & gt; Tu peux regarder sur la page du paquet de chaque noyau, exemple :<b r>> ><br>> > https://packages.debian.org/jessie/linux-i mage-3.16-3-686-pae<br>> ><br>> > Il y a un lien vers l e changelog :<br>> ><br>> > http://metadata.ftp-master. debian.org/changelogs//main/l/linux/linux_3.16.5-1_changelog<br>> > ;<br>> ><br>> > il y a les modifications upstream pui s les modfications Debian.<br>> ><br>> Merci. On peut tout d e même dire que cette façon de présenter tout en <br>> vrac (c'e st d'ailleurs général chez Debian) engendre de la confusion.<br>> Je pense vraiment que Debian n'a pas envie de communiquer, sauf avec les <br>> initiés. Tant pis pour les utilisateurs...<br>> -- <br>&g t; Maderios<br>> <br>> <br>> -- <br>> Lisez la FAQ de la liste avant de poser une question :<br>> http://wiki.debian.org/fr /FrenchLists<br>> <br>> Pour vous DESABONNER, envoyez un messag e avec comme objet "unsubscribe"<br>> vers debian-user-french-REQUEST@ lists.debian.org<br>> En cas de soucis, contactez EN ANGLAIS listmas <br>> Archive: https://lists.debian.org/544E9D3E.5 <br>> <br> </div></body> </html> --_d4a8e728-d65c-4679-8624-f3db8714d046_--
-- 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/
François Boisson
> 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. > Merci. On peut tout de même dire que cette façon de présenter tout en vrac (c'est d'ailleurs général chez Debian) engendre de la confusion. Je pense vraiment que Debian n'a pas envie de communiquer, sauf avec les initiés. Tant pis pour les utilisateurs...
Ce document est le changelog du noyau, Debian ne rajoute ces modifications qu'à la fin. Je pense que les patches debian se trouvent dans les sources des paquets du noyau (pas le linux-source, mais les paquets de deb-src). Par exemple, tu prends le fichier linux_3.2.63-2.debian.tar.xz Tu le déplies et va dans deboan/patches Tu lis bugfix/x86/net-wireless-ipw2200-Fix-WARN_ON-occurring-in-wiphy_.patch et tu as les commentaires précis
«The problem was found by Larry Finger: http://marc.info/?l=linux-wireless&m3702401700614&w=2
The problem is identical to the one for ipw2200 which is already fixed: http://marc.info/?l=linux-wireless&m3457257407196&w=2 [description du problème, etc]»
Tu as également les rajouts (par exemple features/x86/x86-Add-amilo-rfkill-driver-for-some-Fujitsu-Siemens.patch ou encore bien sûr et surtout :features/all/aufs3/ qui rajoute aufs (qui n'est pas dans le noyau de kernel.org).
Bref, je trouve ça très détaillé et ordonné. Le changelog n'est là que pour faire une recherche par mot clef pour savoir si une modification a été fait ou un bug précis corrigé, par pour expliquer les modifs.
François Bpisson
-- 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/
> 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.
>
Merci. On peut tout de même dire que cette façon de présenter tout en
vrac (c'est d'ailleurs général chez Debian) engendre de la confusion.
Je pense vraiment que Debian n'a pas envie de communiquer, sauf avec les
initiés. Tant pis pour les utilisateurs...
Ce document est le changelog du noyau, Debian ne rajoute ces modifications
qu'à la fin. Je pense que les patches debian se trouvent dans les sources des
paquets du noyau (pas le linux-source, mais les paquets de deb-src). Par
exemple, tu prends le fichier
linux_3.2.63-2.debian.tar.xz
Tu le déplies et va dans deboan/patches
Tu lis bugfix/x86/net-wireless-ipw2200-Fix-WARN_ON-occurring-in-wiphy_.patch
et tu as les commentaires précis
«The problem was found by Larry Finger:
http://marc.info/?l=linux-wireless&m3702401700614&w=2
The problem is identical to the one for ipw2200 which is already fixed:
http://marc.info/?l=linux-wireless&m3457257407196&w=2
[description du problème, etc]»
Tu as également les rajouts (par exemple
features/x86/x86-Add-amilo-rfkill-driver-for-some-Fujitsu-Siemens.patch
ou encore bien sûr et surtout :features/all/aufs3/ qui rajoute aufs (qui n'est
pas dans le noyau de kernel.org).
Bref, je trouve ça très détaillé et ordonné. Le changelog n'est là que pour
faire une recherche par mot clef pour savoir si une modification a été fait ou
un bug précis corrigé, par pour expliquer les modifs.
François Bpisson
--
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/20141027224430.6a9af87ff0a1db8f2a92f1f7@maison.homelinux.net
> 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. > Merci. On peut tout de même dire que cette façon de présenter tout en vrac (c'est d'ailleurs général chez Debian) engendre de la confusion. Je pense vraiment que Debian n'a pas envie de communiquer, sauf avec les initiés. Tant pis pour les utilisateurs...
Ce document est le changelog du noyau, Debian ne rajoute ces modifications qu'à la fin. Je pense que les patches debian se trouvent dans les sources des paquets du noyau (pas le linux-source, mais les paquets de deb-src). Par exemple, tu prends le fichier linux_3.2.63-2.debian.tar.xz Tu le déplies et va dans deboan/patches Tu lis bugfix/x86/net-wireless-ipw2200-Fix-WARN_ON-occurring-in-wiphy_.patch et tu as les commentaires précis
«The problem was found by Larry Finger: http://marc.info/?l=linux-wireless&m3702401700614&w=2
The problem is identical to the one for ipw2200 which is already fixed: http://marc.info/?l=linux-wireless&m3457257407196&w=2 [description du problème, etc]»
Tu as également les rajouts (par exemple features/x86/x86-Add-amilo-rfkill-driver-for-some-Fujitsu-Siemens.patch ou encore bien sûr et surtout :features/all/aufs3/ qui rajoute aufs (qui n'est pas dans le noyau de kernel.org).
Bref, je trouve ça très détaillé et ordonné. Le changelog n'est là que pour faire une recherche par mot clef pour savoir si une modification a été fait ou un bug précis corrigé, par pour expliquer les modifs.
François Bpisson
-- 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/
Ouais, lâutilisateur, il doit savoir chercher sur le web ou
RTFM. Quelle plaie !
--
Sylvain Sauvage
--
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/10331785.b6IAUDjGMH@earendil
