Non, c'est seulement toi qui à voulu montrer que tu avais la plus
grosse, alors que le sujet initial était l'installation d'*UN* systèm e.
Si pour toi mettre en uvre tout le bordel que tu cites pour installer
*UN* unique système est une avancée technologique, effectivement, je
préfère rester avec mes techniques de mange disque.
Sauf que le terme 'Administrative install' ne se traduit pas pas 'Images
administratives'. C'est d'ailleurs pour cela que je t'avais donné un
lien qui aurait du t'aider à comprendre que tu utilisais les termes du
bon DSI de base qui veut se faire mousser.
Non, c'est seulement toi qui à voulu montrer que tu avais la plus
grosse, alors que le sujet initial était l'installation d'*UN* systèm e.
Si pour toi mettre en uvre tout le bordel que tu cites pour installer
*UN* unique système est une avancée technologique, effectivement, je
préfère rester avec mes techniques de mange disque.
Sauf que le terme 'Administrative install' ne se traduit pas pas 'Images
administratives'. C'est d'ailleurs pour cela que je t'avais donné un
lien qui aurait du t'aider à comprendre que tu utilisais les termes du
bon DSI de base qui veut se faire mousser.
Non, c'est seulement toi qui à voulu montrer que tu avais la plus
grosse, alors que le sujet initial était l'installation d'*UN* systèm e.
Si pour toi mettre en uvre tout le bordel que tu cites pour installer
*UN* unique système est une avancée technologique, effectivement, je
préfère rester avec mes techniques de mange disque.
Sauf que le terme 'Administrative install' ne se traduit pas pas 'Images
administratives'. C'est d'ailleurs pour cela que je t'avais donné un
lien qui aurait du t'aider à comprendre que tu utilisais les termes du
bon DSI de base qui veut se faire mousser.
Je n'installe ni dépanne de windows.
> note que meme là il y a quelques années
> qu'on prefere restorer des dump de fs a des images pour d'excelllentes
> raisons
Excellentes raisons que tu n'expliqueras pas, bien sûr.
Ben puisque tu es si malin, pourquoi ne fais tu pas l'essai en mettant
en module les drivers IDE / SATA / SCSI pour voir si ton linux boote
toujours aussi bien !
Vu le niveau de ton argumentaire, et le fait que tu ne sois même pas
fichu de comprendre que nombre de drivers sont compilés en DUR
Je n'installe ni dépanne de windows.
> note que meme là il y a quelques années
> qu'on prefere restorer des dump de fs a des images pour d'excelllentes
> raisons
Excellentes raisons que tu n'expliqueras pas, bien sûr.
Ben puisque tu es si malin, pourquoi ne fais tu pas l'essai en mettant
en module les drivers IDE / SATA / SCSI pour voir si ton linux boote
toujours aussi bien !
Vu le niveau de ton argumentaire, et le fait que tu ne sois même pas
fichu de comprendre que nombre de drivers sont compilés en DUR
Je n'installe ni dépanne de windows.
> note que meme là il y a quelques années
> qu'on prefere restorer des dump de fs a des images pour d'excelllentes
> raisons
Excellentes raisons que tu n'expliqueras pas, bien sûr.
Ben puisque tu es si malin, pourquoi ne fais tu pas l'essai en mettant
en module les drivers IDE / SATA / SCSI pour voir si ton linux boote
toujours aussi bien !
Vu le niveau de ton argumentaire, et le fait que tu ne sois même pas
fichu de comprendre que nombre de drivers sont compilés en DUR
On 7 mar, 21:36, NiKo wrote:Non, c'est seulement toi qui à voulu montrer que tu avais la plus
grosse, alors que le sujet initial était l'installation d'*UN* système.
si seulement tu avais lu, j'ai justement voulu montrer qu'avoir la
plus
petite (durée d'install) n'etait certainement pas un argument :)Si pour toi mettre en œuvre tout le bordel que tu cites pour installer
*UN* unique système est une avancée technologique, effectivement, je
préfère rester avec mes techniques de mange disque.
la difference en terme de temps d'installation pour un unique systeme
que ce soit un windows on un linux est de l'ordre de 10 minutes, pour
une installation qui sera effectivement unique a long terme,
contrairement
aux partie de mange disques que tu aimes temps reproduire :)
Sauf que le terme 'Administrative install' ne se traduit pas pas 'Images
administratives'. C'est d'ailleurs pour cela que je t'avais donné un
lien qui aurait du t'aider à comprendre que tu utilisais les termes du
bon DSI de base qui veut se faire mousser.
tu restes bloqué dans ton auto trip, d'autres parleraient de monomanie
anale, ca nous change :)
On 7 mar, 21:36, NiKo <N...@nomail.svp> wrote:
Non, c'est seulement toi qui à voulu montrer que tu avais la plus
grosse, alors que le sujet initial était l'installation d'*UN* système.
si seulement tu avais lu, j'ai justement voulu montrer qu'avoir la
plus
petite (durée d'install) n'etait certainement pas un argument :)
Si pour toi mettre en œuvre tout le bordel que tu cites pour installer
*UN* unique système est une avancée technologique, effectivement, je
préfère rester avec mes techniques de mange disque.
la difference en terme de temps d'installation pour un unique systeme
que ce soit un windows on un linux est de l'ordre de 10 minutes, pour
une installation qui sera effectivement unique a long terme,
contrairement
aux partie de mange disques que tu aimes temps reproduire :)
Sauf que le terme 'Administrative install' ne se traduit pas pas 'Images
administratives'. C'est d'ailleurs pour cela que je t'avais donné un
lien qui aurait du t'aider à comprendre que tu utilisais les termes du
bon DSI de base qui veut se faire mousser.
tu restes bloqué dans ton auto trip, d'autres parleraient de monomanie
anale, ca nous change :)
On 7 mar, 21:36, NiKo wrote:Non, c'est seulement toi qui à voulu montrer que tu avais la plus
grosse, alors que le sujet initial était l'installation d'*UN* système.
si seulement tu avais lu, j'ai justement voulu montrer qu'avoir la
plus
petite (durée d'install) n'etait certainement pas un argument :)Si pour toi mettre en œuvre tout le bordel que tu cites pour installer
*UN* unique système est une avancée technologique, effectivement, je
préfère rester avec mes techniques de mange disque.
la difference en terme de temps d'installation pour un unique systeme
que ce soit un windows on un linux est de l'ordre de 10 minutes, pour
une installation qui sera effectivement unique a long terme,
contrairement
aux partie de mange disques que tu aimes temps reproduire :)
Sauf que le terme 'Administrative install' ne se traduit pas pas 'Images
administratives'. C'est d'ailleurs pour cela que je t'avais donné un
lien qui aurait du t'aider à comprendre que tu utilisais les termes du
bon DSI de base qui veut se faire mousser.
tu restes bloqué dans ton auto trip, d'autres parleraient de monomanie
anale, ca nous change :)
On 7 mar, 21:48, NiKo wrote:Je n'installe ni dépanne de windows.
ni quoi que ce soit d'autre manifestement :)note que meme là il y a quelques années
qu'on prefere restorer des dump de fs a des images pour d'excelllentes
raisons
Excellentes raisons que tu n'expliqueras pas, bien sûr.
Bien sur, que tu ne puisses défendre tes images vis a vis de dump
partiels, avec les avantages que tout ceux compétents suceptibles
de lire connaissent enlèverait toute saveur a cette discussion, et je
ne suis pas là pour éduquer un crétin :)Ben puisque tu es si malin, pourquoi ne fais tu pas l'essai en mettant
en module les drivers IDE / SATA / SCSI pour voir si ton linux boote
toujours aussi bien !
si 3 drivers en dur fonctionne tu en conclurais que n'importe quelle
association est valable... essais plutot avec une bonne collection
de NIC qu'on rigole, tu n'as clairement jamais testé :)
Vu le niveau de ton argumentaire, et le fait que tu ne sois même pas
fichu de comprendre que nombre de drivers sont compilés en DUR
toi non plus tu n'explique pas pourquoi, passe, tu aurais affirmer
"un nombre minimum" cela aurait au moins donner du sens
te permettant d'être crédible. Mais tu tiens tellement a donner
je comprend pas contre l'interet qu'il y a a ne pas l'avoir en dur
comme voir le kernel queblo dans l'initialisation d'un des dit module
lorsqu'on le change de platforme.
dans le ridicule qu'il vaut mieux en foutre un bon gros paquet
histoire d'obtenir l'effet inverse a celui habituellement recherché
dans ce genre de manip, c'est tres fort :) udev a beau etre une
infame merde en pseudo HAL, meme ca tu n'en veux pas :)
On 7 mar, 21:48, NiKo <N...@nomail.svp> wrote:
Je n'installe ni dépanne de windows.
ni quoi que ce soit d'autre manifestement :)
note que meme là il y a quelques années
qu'on prefere restorer des dump de fs a des images pour d'excelllentes
raisons
Excellentes raisons que tu n'expliqueras pas, bien sûr.
Bien sur, que tu ne puisses défendre tes images vis a vis de dump
partiels, avec les avantages que tout ceux compétents suceptibles
de lire connaissent enlèverait toute saveur a cette discussion, et je
ne suis pas là pour éduquer un crétin :)
Ben puisque tu es si malin, pourquoi ne fais tu pas l'essai en mettant
en module les drivers IDE / SATA / SCSI pour voir si ton linux boote
toujours aussi bien !
si 3 drivers en dur fonctionne tu en conclurais que n'importe quelle
association est valable... essais plutot avec une bonne collection
de NIC qu'on rigole, tu n'as clairement jamais testé :)
Vu le niveau de ton argumentaire, et le fait que tu ne sois même pas
fichu de comprendre que nombre de drivers sont compilés en DUR
toi non plus tu n'explique pas pourquoi, passe, tu aurais affirmer
"un nombre minimum" cela aurait au moins donner du sens
te permettant d'être crédible. Mais tu tiens tellement a donner
je comprend pas contre l'interet qu'il y a a ne pas l'avoir en dur
comme voir le kernel queblo dans l'initialisation d'un des dit module
lorsqu'on le change de platforme.
dans le ridicule qu'il vaut mieux en foutre un bon gros paquet
histoire d'obtenir l'effet inverse a celui habituellement recherché
dans ce genre de manip, c'est tres fort :) udev a beau etre une
infame merde en pseudo HAL, meme ca tu n'en veux pas :)
On 7 mar, 21:48, NiKo wrote:Je n'installe ni dépanne de windows.
ni quoi que ce soit d'autre manifestement :)note que meme là il y a quelques années
qu'on prefere restorer des dump de fs a des images pour d'excelllentes
raisons
Excellentes raisons que tu n'expliqueras pas, bien sûr.
Bien sur, que tu ne puisses défendre tes images vis a vis de dump
partiels, avec les avantages que tout ceux compétents suceptibles
de lire connaissent enlèverait toute saveur a cette discussion, et je
ne suis pas là pour éduquer un crétin :)Ben puisque tu es si malin, pourquoi ne fais tu pas l'essai en mettant
en module les drivers IDE / SATA / SCSI pour voir si ton linux boote
toujours aussi bien !
si 3 drivers en dur fonctionne tu en conclurais que n'importe quelle
association est valable... essais plutot avec une bonne collection
de NIC qu'on rigole, tu n'as clairement jamais testé :)
Vu le niveau de ton argumentaire, et le fait que tu ne sois même pas
fichu de comprendre que nombre de drivers sont compilés en DUR
toi non plus tu n'explique pas pourquoi, passe, tu aurais affirmer
"un nombre minimum" cela aurait au moins donner du sens
te permettant d'être crédible. Mais tu tiens tellement a donner
je comprend pas contre l'interet qu'il y a a ne pas l'avoir en dur
comme voir le kernel queblo dans l'initialisation d'un des dit module
lorsqu'on le change de platforme.
dans le ridicule qu'il vaut mieux en foutre un bon gros paquet
histoire d'obtenir l'effet inverse a celui habituellement recherché
dans ce genre de manip, c'est tres fort :) udev a beau etre une
infame merde en pseudo HAL, meme ca tu n'en veux pas :)
> dans le ridicule qu'il vaut mieux en foutre un bon gros paquet
> histoire d'obtenir l'effet inverse a celui habituellement recherché
> dans ce genre de manip, c'est tres fort :) udev a beau etre une
> infame merde en pseudo HAL, meme ca tu n'en veux pas :)
Que viens tu parler de HAL et de udev ? Quel est le rapport avec des
drivers intégrés dans le noyau ?
Tu te sens con, alors tu tentes une diversion ?
Voila, je te prouve par A+B que tu n'y connais rien, je te prouve par
A+B qu'il y a un intérrêt à mettre des drivers en DUR dans le NOYAU ,
alors comme tu te sens con de te faire moucher par un 'crétin' que tu
croyais 'éduquer', tu tentes une diversion.
PS : Tu devrais regarder la config de ton noyau Linux (Ah ben non, suis
con, avec un 'UserAgent' comme le tien, tu ne connais que le
cliquodrome), et tu pourrais te rendre compte qu'il y a nombre de
cartes, dont nombre de cartes, dont nombre de cartes RESEAU
qui sont compilées en DUR.
Je l'avoue, la compréhension de texte avec toi est un sport. Je vais
finir par t'appeler 'Ptilou'.
Donc, je te démontre
Comment tu fais pour accéder à un matériel nécessaire pour déma rrer l'OS
(Typiquement un accès au disque dur où un accès réseau pour un sy stème
diskless) si ton noyau n'a pas le driver pour ce matériel.
Ptilou, sort de ce corps.
> dans le ridicule qu'il vaut mieux en foutre un bon gros paquet
> histoire d'obtenir l'effet inverse a celui habituellement recherché
> dans ce genre de manip, c'est tres fort :) udev a beau etre une
> infame merde en pseudo HAL, meme ca tu n'en veux pas :)
Que viens tu parler de HAL et de udev ? Quel est le rapport avec des
drivers intégrés dans le noyau ?
Tu te sens con, alors tu tentes une diversion ?
Voila, je te prouve par A+B que tu n'y connais rien, je te prouve par
A+B qu'il y a un intérrêt à mettre des drivers en DUR dans le NOYAU ,
alors comme tu te sens con de te faire moucher par un 'crétin' que tu
croyais 'éduquer', tu tentes une diversion.
PS : Tu devrais regarder la config de ton noyau Linux (Ah ben non, suis
con, avec un 'UserAgent' comme le tien, tu ne connais que le
cliquodrome), et tu pourrais te rendre compte qu'il y a nombre de
cartes, dont nombre de cartes, dont nombre de cartes RESEAU
qui sont compilées en DUR.
Je l'avoue, la compréhension de texte avec toi est un sport. Je vais
finir par t'appeler 'Ptilou'.
Donc, je te démontre
Comment tu fais pour accéder à un matériel nécessaire pour déma rrer l'OS
(Typiquement un accès au disque dur où un accès réseau pour un sy stème
diskless) si ton noyau n'a pas le driver pour ce matériel.
Ptilou, sort de ce corps.
> dans le ridicule qu'il vaut mieux en foutre un bon gros paquet
> histoire d'obtenir l'effet inverse a celui habituellement recherché
> dans ce genre de manip, c'est tres fort :) udev a beau etre une
> infame merde en pseudo HAL, meme ca tu n'en veux pas :)
Que viens tu parler de HAL et de udev ? Quel est le rapport avec des
drivers intégrés dans le noyau ?
Tu te sens con, alors tu tentes une diversion ?
Voila, je te prouve par A+B que tu n'y connais rien, je te prouve par
A+B qu'il y a un intérrêt à mettre des drivers en DUR dans le NOYAU ,
alors comme tu te sens con de te faire moucher par un 'crétin' que tu
croyais 'éduquer', tu tentes une diversion.
PS : Tu devrais regarder la config de ton noyau Linux (Ah ben non, suis
con, avec un 'UserAgent' comme le tien, tu ne connais que le
cliquodrome), et tu pourrais te rendre compte qu'il y a nombre de
cartes, dont nombre de cartes, dont nombre de cartes RESEAU
qui sont compilées en DUR.
Je l'avoue, la compréhension de texte avec toi est un sport. Je vais
finir par t'appeler 'Ptilou'.
Donc, je te démontre
Comment tu fais pour accéder à un matériel nécessaire pour déma rrer l'OS
(Typiquement un accès au disque dur où un accès réseau pour un sy stème
diskless) si ton noyau n'a pas le driver pour ce matériel.
Ptilou, sort de ce corps.
On 7 mar, 22:53, NiKo wrote:dans le ridicule qu'il vaut mieux en foutre un bon gros paquet
histoire d'obtenir l'effet inverse a celui habituellement recherché
dans ce genre de manip, c'est tres fort :) udev a beau etre une
infame merde en pseudo HAL, meme ca tu n'en veux pas :)
Que viens tu parler de HAL et de udev ? Quel est le rapport avec des
drivers intégrés dans le noyau ?
la fonction d'udev pour le kernel linux est entre autre de remplacer
un
HAL historiquement mort ET de répondre a hotplug pour assurer le
chargement des drivers en question dans le noyau ce qui permet
(entre autres) de ne pas les avoirs en dur tout en les chargeant sans
intervention manuelle, le tout permettant également/accesoirement
de contourner les conflits de drivers qui deviennent bloquant lorsque
ceux-ci sont en dur.Tu te sens con, alors tu tentes une diversion ?
aucun besoin, comme déjà dis il me semble suffisamment
évident que lorsque tu parles de linux, comme de deploiement
vs images vs dump tu parles de choses auxquelles tu ne comprends
rien, tout au moins pas plus qu'un pousse bouton qui s'excite
la nouille devant un shell :)
Voila, je te prouve par A+B que tu n'y connais rien, je te prouve par
A+B qu'il y a un intérrêt à mettre des drivers en DUR dans le NOYAU,
alors comme tu te sens con de te faire moucher par un 'crétin' que tu
croyais 'éduquer', tu tentes une diversion.
mes propos portait sur le fait de rajouter des drivers en dur,
par ce qu'un kernel sans aucun driver ne permet évidemment
pas d'exploiter grand chose si ce n'est ton cerveau, il n'est
pas besoin de faire diversion dans une telle situation.
ceci dit si mets propos sont dignes d'un ptilou tes démonstrations
sont dignes d'un luc2 :)
PS : Tu devrais regarder la config de ton noyau Linux (Ah ben non, suis
con, avec un 'UserAgent' comme le tien, tu ne connais que le
cliquodrome), et tu pourrais te rendre compte qu'il y a nombre de
cartes, dont nombre de cartes, dont nombre de cartes RESEAU
qui sont compilées en DUR.
aucune, je compile non seulement mes kernel mes aussi
l'integralité de mes nunux a grand coup de makefiles
& script maison. je suis de cettte catégorie que certains
"windosien" qualifie (a tord, ce qui rejoins le propos initial
de mon intervention) de "linuxien". sans pour autant négliger
de cracher sur les crétin de ces deux categories.
Je l'avoue, la compréhension de texte avec toi est un sport. Je vais
finir par t'appeler 'Ptilou'.
ptilou a bon dos, aussi incompréhensible que puisse être
ses interventions, elles ne peuvent justifier que tu ne comprennes
le francais :)
Donc, je te démontre
luc2 powa par contre... :)Comment tu fais pour accéder à un matériel nécessaire pour démarrer l'OS
(Typiquement un accès au disque dur où un accès réseau pour un système
diskless) si ton noyau n'a pas le driver pour ce matériel.
cite donc le passage ou j'ai dis qu'il n'en fallait aucun... mais y'en
a pas,
le crétin n'eduque pas, le crétin brode :)
Ptilou, sort de ce corps.
luc2 reste dans celui-ci, qu'on continue a s'amuser:)
On 7 mar, 22:53, NiKo <N...@nomail.svp> wrote:
dans le ridicule qu'il vaut mieux en foutre un bon gros paquet
histoire d'obtenir l'effet inverse a celui habituellement recherché
dans ce genre de manip, c'est tres fort :) udev a beau etre une
infame merde en pseudo HAL, meme ca tu n'en veux pas :)
Que viens tu parler de HAL et de udev ? Quel est le rapport avec des
drivers intégrés dans le noyau ?
la fonction d'udev pour le kernel linux est entre autre de remplacer
un
HAL historiquement mort ET de répondre a hotplug pour assurer le
chargement des drivers en question dans le noyau ce qui permet
(entre autres) de ne pas les avoirs en dur tout en les chargeant sans
intervention manuelle, le tout permettant également/accesoirement
de contourner les conflits de drivers qui deviennent bloquant lorsque
ceux-ci sont en dur.
Tu te sens con, alors tu tentes une diversion ?
aucun besoin, comme déjà dis il me semble suffisamment
évident que lorsque tu parles de linux, comme de deploiement
vs images vs dump tu parles de choses auxquelles tu ne comprends
rien, tout au moins pas plus qu'un pousse bouton qui s'excite
la nouille devant un shell :)
Voila, je te prouve par A+B que tu n'y connais rien, je te prouve par
A+B qu'il y a un intérrêt à mettre des drivers en DUR dans le NOYAU,
alors comme tu te sens con de te faire moucher par un 'crétin' que tu
croyais 'éduquer', tu tentes une diversion.
mes propos portait sur le fait de rajouter des drivers en dur,
par ce qu'un kernel sans aucun driver ne permet évidemment
pas d'exploiter grand chose si ce n'est ton cerveau, il n'est
pas besoin de faire diversion dans une telle situation.
ceci dit si mets propos sont dignes d'un ptilou tes démonstrations
sont dignes d'un luc2 :)
PS : Tu devrais regarder la config de ton noyau Linux (Ah ben non, suis
con, avec un 'UserAgent' comme le tien, tu ne connais que le
cliquodrome), et tu pourrais te rendre compte qu'il y a nombre de
cartes, dont nombre de cartes, dont nombre de cartes RESEAU
qui sont compilées en DUR.
aucune, je compile non seulement mes kernel mes aussi
l'integralité de mes nunux a grand coup de makefiles
& script maison. je suis de cettte catégorie que certains
"windosien" qualifie (a tord, ce qui rejoins le propos initial
de mon intervention) de "linuxien". sans pour autant négliger
de cracher sur les crétin de ces deux categories.
Je l'avoue, la compréhension de texte avec toi est un sport. Je vais
finir par t'appeler 'Ptilou'.
ptilou a bon dos, aussi incompréhensible que puisse être
ses interventions, elles ne peuvent justifier que tu ne comprennes
le francais :)
Donc, je te démontre
luc2 powa par contre... :)
Comment tu fais pour accéder à un matériel nécessaire pour démarrer l'OS
(Typiquement un accès au disque dur où un accès réseau pour un système
diskless) si ton noyau n'a pas le driver pour ce matériel.
cite donc le passage ou j'ai dis qu'il n'en fallait aucun... mais y'en
a pas,
le crétin n'eduque pas, le crétin brode :)
Ptilou, sort de ce corps.
luc2 reste dans celui-ci, qu'on continue a s'amuser:)
On 7 mar, 22:53, NiKo wrote:dans le ridicule qu'il vaut mieux en foutre un bon gros paquet
histoire d'obtenir l'effet inverse a celui habituellement recherché
dans ce genre de manip, c'est tres fort :) udev a beau etre une
infame merde en pseudo HAL, meme ca tu n'en veux pas :)
Que viens tu parler de HAL et de udev ? Quel est le rapport avec des
drivers intégrés dans le noyau ?
la fonction d'udev pour le kernel linux est entre autre de remplacer
un
HAL historiquement mort ET de répondre a hotplug pour assurer le
chargement des drivers en question dans le noyau ce qui permet
(entre autres) de ne pas les avoirs en dur tout en les chargeant sans
intervention manuelle, le tout permettant également/accesoirement
de contourner les conflits de drivers qui deviennent bloquant lorsque
ceux-ci sont en dur.Tu te sens con, alors tu tentes une diversion ?
aucun besoin, comme déjà dis il me semble suffisamment
évident que lorsque tu parles de linux, comme de deploiement
vs images vs dump tu parles de choses auxquelles tu ne comprends
rien, tout au moins pas plus qu'un pousse bouton qui s'excite
la nouille devant un shell :)
Voila, je te prouve par A+B que tu n'y connais rien, je te prouve par
A+B qu'il y a un intérrêt à mettre des drivers en DUR dans le NOYAU,
alors comme tu te sens con de te faire moucher par un 'crétin' que tu
croyais 'éduquer', tu tentes une diversion.
mes propos portait sur le fait de rajouter des drivers en dur,
par ce qu'un kernel sans aucun driver ne permet évidemment
pas d'exploiter grand chose si ce n'est ton cerveau, il n'est
pas besoin de faire diversion dans une telle situation.
ceci dit si mets propos sont dignes d'un ptilou tes démonstrations
sont dignes d'un luc2 :)
PS : Tu devrais regarder la config de ton noyau Linux (Ah ben non, suis
con, avec un 'UserAgent' comme le tien, tu ne connais que le
cliquodrome), et tu pourrais te rendre compte qu'il y a nombre de
cartes, dont nombre de cartes, dont nombre de cartes RESEAU
qui sont compilées en DUR.
aucune, je compile non seulement mes kernel mes aussi
l'integralité de mes nunux a grand coup de makefiles
& script maison. je suis de cettte catégorie que certains
"windosien" qualifie (a tord, ce qui rejoins le propos initial
de mon intervention) de "linuxien". sans pour autant négliger
de cracher sur les crétin de ces deux categories.
Je l'avoue, la compréhension de texte avec toi est un sport. Je vais
finir par t'appeler 'Ptilou'.
ptilou a bon dos, aussi incompréhensible que puisse être
ses interventions, elles ne peuvent justifier que tu ne comprennes
le francais :)
Donc, je te démontre
luc2 powa par contre... :)Comment tu fais pour accéder à un matériel nécessaire pour démarrer l'OS
(Typiquement un accès au disque dur où un accès réseau pour un système
diskless) si ton noyau n'a pas le driver pour ce matériel.
cite donc le passage ou j'ai dis qu'il n'en fallait aucun... mais y'en
a pas,
le crétin n'eduque pas, le crétin brode :)
Ptilou, sort de ce corps.
luc2 reste dans celui-ci, qu'on continue a s'amuser:)
l'important est que ce soit
phonétiquement correcte...
l'important est que ce soit
phonétiquement correcte...
l'important est que ce soit
phonétiquement correcte...
Ben non ! Ça marche pas comme ça, mais je vais pas me perdre à
t'expliquer. Pourtant, le simple nom de 'uDEV' devrait t'aider à
comprendre ce qu'il fait.
Ben non ! Ça marche pas comme ça, mais je vais pas me perdre à
t'expliquer. Pourtant, le simple nom de 'uDEV' devrait t'aider à
comprendre ce qu'il fait.
Ben non ! Ça marche pas comme ça, mais je vais pas me perdre à
t'expliquer. Pourtant, le simple nom de 'uDEV' devrait t'aider à
comprendre ce qu'il fait.
On 8 mar, 06:21, NiKo wrote:Ben non ! Ça marche pas comme ça, mais je vais pas me perdre à
t'expliquer. Pourtant, le simple nom de 'uDEV' devrait t'aider à
comprendre ce qu'il fait.
J'imagine que tu prétendrais le limiter a la création des device
file, ce qui démontre bien que tu ne connais effectivement rien
a ton kernel. De même que si tu en avais un minimum d'expérience
tu éviterais également de prendre pour exemples de drivers
classiquement en dur ceux (deux d'entre eux au moins) dont
certaines fonctionnalités ne peuvent être intégrées au kernel
lorsqu'ils sont en modules; ou encore tu ne t'interrogerais pas
sur comment charger des modules sans avoir accès a un support
physique lorsque le kernel et un initrd chargé du nécessaires
peuvent être placé en ram par le bootloader.
bien sur il te faudra un peu plus qu'un 'apropos udev' pour
faire ta/tes démonstrations qui sur ce coup se limite un peu a
"même pas vrai", luc2 faisait mieux, j'suis déçu :)
le reste étant du même acabit, inutile d'en rajouter.
On 8 mar, 06:21, NiKo <N...@nomail.svp> wrote:
Ben non ! Ça marche pas comme ça, mais je vais pas me perdre à
t'expliquer. Pourtant, le simple nom de 'uDEV' devrait t'aider à
comprendre ce qu'il fait.
J'imagine que tu prétendrais le limiter a la création des device
file, ce qui démontre bien que tu ne connais effectivement rien
a ton kernel. De même que si tu en avais un minimum d'expérience
tu éviterais également de prendre pour exemples de drivers
classiquement en dur ceux (deux d'entre eux au moins) dont
certaines fonctionnalités ne peuvent être intégrées au kernel
lorsqu'ils sont en modules; ou encore tu ne t'interrogerais pas
sur comment charger des modules sans avoir accès a un support
physique lorsque le kernel et un initrd chargé du nécessaires
peuvent être placé en ram par le bootloader.
bien sur il te faudra un peu plus qu'un 'apropos udev' pour
faire ta/tes démonstrations qui sur ce coup se limite un peu a
"même pas vrai", luc2 faisait mieux, j'suis déçu :)
le reste étant du même acabit, inutile d'en rajouter.
On 8 mar, 06:21, NiKo wrote:Ben non ! Ça marche pas comme ça, mais je vais pas me perdre à
t'expliquer. Pourtant, le simple nom de 'uDEV' devrait t'aider à
comprendre ce qu'il fait.
J'imagine que tu prétendrais le limiter a la création des device
file, ce qui démontre bien que tu ne connais effectivement rien
a ton kernel. De même que si tu en avais un minimum d'expérience
tu éviterais également de prendre pour exemples de drivers
classiquement en dur ceux (deux d'entre eux au moins) dont
certaines fonctionnalités ne peuvent être intégrées au kernel
lorsqu'ils sont en modules; ou encore tu ne t'interrogerais pas
sur comment charger des modules sans avoir accès a un support
physique lorsque le kernel et un initrd chargé du nécessaires
peuvent être placé en ram par le bootloader.
bien sur il te faudra un peu plus qu'un 'apropos udev' pour
faire ta/tes démonstrations qui sur ce coup se limite un peu a
"même pas vrai", luc2 faisait mieux, j'suis déçu :)
le reste étant du même acabit, inutile d'en rajouter.
