bonjour,
je souhaiterai faire une copie de mon dd de 80go sur un autre
disque de la meme taille.
ils sont partionner exactement de la meme facon.
j ai "formater" mon disque B
dd if=/dev/zero of=/dev/ad2 count=2
et j ai essaye de copier la disque A vers le B
dd if=/dev/ad1 of=/dev/ad2
dd: /dev/ad1: Input/output error
209914+0 records in
209914+0 records out
107475968 bytes transferred in 65.549117 secs (1639625
bytes/sec)
dd if=/dev/ad1 of=/dev/null
dd: /dev/ad1: Input/output error
209914+0 records in
209914+0 records out
107475968 bytes transferred in 34.388560 secs (3125341
bytes/sec)
c est la premiere fois que j ai un message de ce type...
je me demande donc si il est trop tard pour faire un backup de
disque.
Sauf, que pour des questions de licence, sur les BSD, tar est en fait pax, à qui manque pas mal d'options de tar (-W pour la vérification, entre autres, comme si les bandes étaient devenues fiables d'un coup)
Sous FreeBSD 4.10, "tar" s'annonce comme étant un "GNU tar 1.13.25". Sous FreebSD-5.3(-BETA4), "tar" est un lien sur "bsdtar" (qui n'est pas "pax") et il y a un "gtar" à côté, qui est le "tar" GNU. Je subodore que s'il y a des questions de licence, c'est juste pour avoir un système _d'installation_ entièrement BSD ; un FreeBSD installé est de toutes façons truffé de produits GNU (par exemple, les pages de man sont produites avec groff, qui est GNU ; le compilateur C est gcc, tout aussi GNU ; etc...).
tar a pour avantage qu'on peut prendre une image d'un filesystem "live" -modulo les sockets ingorés et les fichiers de log qui risquent d'être tronqués.
dump impose en pratique un passage en single-user, ce qui pour la sauvegadre nocturne d'un serveur en prod, est difficilement faisable.
Personnellement, je fais des dumps quotidiens de filesystems "live" depuis trois ans et ça marche bien. Je suppose que si ça posait un problème grave, "dump" râlerait. Évidemment, si on fait des modifications lourdes du filesystem à ce moment-là, je pense qu'on doit pouvoir faire échapper des fichiers au "dump". C'est pour ça que je fais mes backups à 4h du matin. Ces problèmes ne se posent pas quand on fait une opération lourde comme celle évoquée (duplication d'un disque) parce qu'on est alors, fonctionnellement, en mode single-user.
Sous FreeBSD-5.x (et UFS2), on fait un snapshot du filesystem et ça roule.
--Thomas Pornin
According to Xavier <xavier@groumpf.org>:
Sauf, que pour des questions de licence, sur les BSD, tar est en fait
pax, à qui manque pas mal d'options de tar (-W pour la vérification,
entre autres, comme si les bandes étaient devenues fiables d'un coup)
Sous FreeBSD 4.10, "tar" s'annonce comme étant un "GNU tar 1.13.25".
Sous FreebSD-5.3(-BETA4), "tar" est un lien sur "bsdtar" (qui n'est pas
"pax") et il y a un "gtar" à côté, qui est le "tar" GNU. Je subodore que
s'il y a des questions de licence, c'est juste pour avoir un système
_d'installation_ entièrement BSD ; un FreeBSD installé est de toutes
façons truffé de produits GNU (par exemple, les pages de man sont
produites avec groff, qui est GNU ; le compilateur C est gcc, tout aussi
GNU ; etc...).
tar a pour avantage qu'on peut prendre une image d'un filesystem "live"
-modulo les sockets ingorés et les fichiers de log qui risquent d'être
tronqués.
dump impose en pratique un passage en single-user, ce qui pour la
sauvegadre nocturne d'un serveur en prod, est difficilement faisable.
Personnellement, je fais des dumps quotidiens de filesystems "live"
depuis trois ans et ça marche bien. Je suppose que si ça posait
un problème grave, "dump" râlerait. Évidemment, si on fait des
modifications lourdes du filesystem à ce moment-là, je pense qu'on doit
pouvoir faire échapper des fichiers au "dump". C'est pour ça que je fais
mes backups à 4h du matin. Ces problèmes ne se posent pas quand on fait
une opération lourde comme celle évoquée (duplication d'un disque) parce
qu'on est alors, fonctionnellement, en mode single-user.
Sous FreeBSD-5.x (et UFS2), on fait un snapshot du filesystem et ça
roule.
Sauf, que pour des questions de licence, sur les BSD, tar est en fait pax, à qui manque pas mal d'options de tar (-W pour la vérification, entre autres, comme si les bandes étaient devenues fiables d'un coup)
Sous FreeBSD 4.10, "tar" s'annonce comme étant un "GNU tar 1.13.25". Sous FreebSD-5.3(-BETA4), "tar" est un lien sur "bsdtar" (qui n'est pas "pax") et il y a un "gtar" à côté, qui est le "tar" GNU. Je subodore que s'il y a des questions de licence, c'est juste pour avoir un système _d'installation_ entièrement BSD ; un FreeBSD installé est de toutes façons truffé de produits GNU (par exemple, les pages de man sont produites avec groff, qui est GNU ; le compilateur C est gcc, tout aussi GNU ; etc...).
tar a pour avantage qu'on peut prendre une image d'un filesystem "live" -modulo les sockets ingorés et les fichiers de log qui risquent d'être tronqués.
dump impose en pratique un passage en single-user, ce qui pour la sauvegadre nocturne d'un serveur en prod, est difficilement faisable.
Personnellement, je fais des dumps quotidiens de filesystems "live" depuis trois ans et ça marche bien. Je suppose que si ça posait un problème grave, "dump" râlerait. Évidemment, si on fait des modifications lourdes du filesystem à ce moment-là, je pense qu'on doit pouvoir faire échapper des fichiers au "dump". C'est pour ça que je fais mes backups à 4h du matin. Ces problèmes ne se posent pas quand on fait une opération lourde comme celle évoquée (duplication d'un disque) parce qu'on est alors, fonctionnellement, en mode single-user.
Sous FreeBSD-5.x (et UFS2), on fait un snapshot du filesystem et ça roule.
--Thomas Pornin
Jacques Caron
On 12 Sep 2004 01:16:32 -0700, Nico wrote:
merci bcp.
Le voici le voilà. Evidemment, penser à changer les devices dans les deux "open" vers le début sous peine de catastrophe. Le programme essaie de lire des gros blocs (pour aller plus vite), mais en cas de souci sur le gros bloc, il lit alors le gros bloc par petits bouts pour en récupérer le plus possible.
Tout ça sans garantie et à tes risques et périls, bien entendu. Bon courage!
int main(int argc,char **argv) { int i,n,in,out; unsigned char buf[1024*1024]; off_t off; time_t t,l; FILE *f;
t = time(0); in = open("/dev/rad1",O_RDONLY); out = open("/dev/rad3",O_WRONLY); f = fopen("errs","a"); off = 0; while (1) { l = time(0)-t; if (!l) l = 1; printf("Reading at offset %lld [large] %d secs %d MB/sn",off,l,off/(1024*1024)/l); lseek(in,off,SEEK_SET); n = read(in,buf,sizeof(buf)); if (n==-1) { for (i=0; i<2048;i++) { printf("Reading at offset %lld [small]n",off); lseek(in,off,SEEK_SET); n = read(in,buf,512); if (n == 0) break; if (n == -1) { fprintf(f,"Error at offset %lld block %lldn",off,off/512); fflush(f); off += 512; continue; } lseek(out,off,SEEK_SET); write(out,buf,512); off += 512; continue; } if (n==0) break; continue; } if (n==0) break; lseek(out,off,SEEK_SET); write(out,buf,n); off += n; } fclose(f);
return 0; } -- Interactive Media Factory Création, développement et hébergement de services interactifs: SMS, SMS+, Audiotel... http://www.imfeurope.com/
On 12 Sep 2004 01:16:32 -0700, Nico <n.cormier@gmail.com> wrote:
merci bcp.
Le voici le voilà. Evidemment, penser à changer les devices dans les deux
"open" vers le début sous peine de catastrophe. Le programme essaie de
lire des gros blocs (pour aller plus vite), mais en cas de souci sur le
gros bloc, il lit alors le gros bloc par petits bouts pour en récupérer le
plus possible.
Tout ça sans garantie et à tes risques et périls, bien entendu. Bon
courage!
int main(int argc,char **argv)
{
int i,n,in,out;
unsigned char buf[1024*1024];
off_t off;
time_t t,l;
FILE *f;
t = time(0);
in = open("/dev/rad1",O_RDONLY);
out = open("/dev/rad3",O_WRONLY);
f = fopen("errs","a");
off = 0;
while (1)
{
l = time(0)-t;
if (!l)
l = 1;
printf("Reading at offset %lld [large] %d secs %d
MB/sn",off,l,off/(1024*1024)/l);
lseek(in,off,SEEK_SET);
n = read(in,buf,sizeof(buf));
if (n==-1)
{
for (i=0; i<2048;i++)
{
printf("Reading at offset %lld [small]n",off);
lseek(in,off,SEEK_SET);
n = read(in,buf,512);
if (n == 0)
break;
if (n == -1)
{
fprintf(f,"Error at offset %lld block
%lldn",off,off/512);
fflush(f);
off += 512;
continue;
}
lseek(out,off,SEEK_SET);
write(out,buf,512);
off += 512;
continue;
}
if (n==0)
break;
continue;
}
if (n==0)
break;
lseek(out,off,SEEK_SET);
write(out,buf,n);
off += n;
}
fclose(f);
return 0;
}
--
Interactive Media Factory
Création, développement et hébergement
de services interactifs: SMS, SMS+, Audiotel...
http://www.imfeurope.com/
Le voici le voilà. Evidemment, penser à changer les devices dans les deux "open" vers le début sous peine de catastrophe. Le programme essaie de lire des gros blocs (pour aller plus vite), mais en cas de souci sur le gros bloc, il lit alors le gros bloc par petits bouts pour en récupérer le plus possible.
Tout ça sans garantie et à tes risques et périls, bien entendu. Bon courage!
int main(int argc,char **argv) { int i,n,in,out; unsigned char buf[1024*1024]; off_t off; time_t t,l; FILE *f;
t = time(0); in = open("/dev/rad1",O_RDONLY); out = open("/dev/rad3",O_WRONLY); f = fopen("errs","a"); off = 0; while (1) { l = time(0)-t; if (!l) l = 1; printf("Reading at offset %lld [large] %d secs %d MB/sn",off,l,off/(1024*1024)/l); lseek(in,off,SEEK_SET); n = read(in,buf,sizeof(buf)); if (n==-1) { for (i=0; i<2048;i++) { printf("Reading at offset %lld [small]n",off); lseek(in,off,SEEK_SET); n = read(in,buf,512); if (n == 0) break; if (n == -1) { fprintf(f,"Error at offset %lld block %lldn",off,off/512); fflush(f); off += 512; continue; } lseek(out,off,SEEK_SET); write(out,buf,512); off += 512; continue; } if (n==0) break; continue; } if (n==0) break; lseek(out,off,SEEK_SET); write(out,buf,n); off += n; } fclose(f);
return 0; } -- Interactive Media Factory Création, développement et hébergement de services interactifs: SMS, SMS+, Audiotel... http://www.imfeurope.com/
espie
In article <ci3ijv$1tse$, Thomas Pornin wrote:
According to Xavier :
Sauf, que pour des questions de licence, sur les BSD, tar est en fait pax, à qui manque pas mal d'options de tar (-W pour la vérification, entre autres, comme si les bandes étaient devenues fiables d'un coup)
Sous FreeBSD 4.10, "tar" s'annonce comme étant un "GNU tar 1.13.25". Sous FreebSD-5.3(-BETA4), "tar" est un lien sur "bsdtar" (qui n'est pas "pax") et il y a un "gtar" à côté, qui est le "tar" GNU. Je subodore que s'il y a des questions de licence, c'est juste pour avoir un système _d'installation_ entièrement BSD ; un FreeBSD installé est de toutes façons truffé de produits GNU (par exemple, les pages de man sont produites avec groff, qui est GNU ; le compilateur C est gcc, tout aussi GNU ; etc...).
Il me semble que maintenant, les sources d'un troff originel sont disponibles avec une licence admissible pour un projet BSD. A terme, on va sans doute se debarrasser de groff, ce qui n'est pas un mal, vu le dialecte de C++ dans lequel ce dernier est ecrit.
D'ailleurs, sauf erreur de ma part, l'auteur de groff est depuis devenu raisonnable, puisque la libexpat, par exemple, est distribuee sous une licence de type MIT.
In article <ci3ijv$1tse$1@biggoron.nerim.net>,
Thomas Pornin <pornin@nerim.net> wrote:
According to Xavier <xavier@groumpf.org>:
Sauf, que pour des questions de licence, sur les BSD, tar est en fait
pax, à qui manque pas mal d'options de tar (-W pour la vérification,
entre autres, comme si les bandes étaient devenues fiables d'un coup)
Sous FreeBSD 4.10, "tar" s'annonce comme étant un "GNU tar 1.13.25".
Sous FreebSD-5.3(-BETA4), "tar" est un lien sur "bsdtar" (qui n'est pas
"pax") et il y a un "gtar" à côté, qui est le "tar" GNU. Je subodore que
s'il y a des questions de licence, c'est juste pour avoir un système
_d'installation_ entièrement BSD ; un FreeBSD installé est de toutes
façons truffé de produits GNU (par exemple, les pages de man sont
produites avec groff, qui est GNU ; le compilateur C est gcc, tout aussi
GNU ; etc...).
Il me semble que maintenant, les sources d'un troff originel sont disponibles
avec une licence admissible pour un projet BSD. A terme, on va sans doute
se debarrasser de groff, ce qui n'est pas un mal, vu le dialecte de C++
dans lequel ce dernier est ecrit.
D'ailleurs, sauf erreur de ma part, l'auteur de groff est depuis devenu
raisonnable, puisque la libexpat, par exemple, est distribuee sous une
licence de type MIT.
Sauf, que pour des questions de licence, sur les BSD, tar est en fait pax, à qui manque pas mal d'options de tar (-W pour la vérification, entre autres, comme si les bandes étaient devenues fiables d'un coup)
Sous FreeBSD 4.10, "tar" s'annonce comme étant un "GNU tar 1.13.25". Sous FreebSD-5.3(-BETA4), "tar" est un lien sur "bsdtar" (qui n'est pas "pax") et il y a un "gtar" à côté, qui est le "tar" GNU. Je subodore que s'il y a des questions de licence, c'est juste pour avoir un système _d'installation_ entièrement BSD ; un FreeBSD installé est de toutes façons truffé de produits GNU (par exemple, les pages de man sont produites avec groff, qui est GNU ; le compilateur C est gcc, tout aussi GNU ; etc...).
Il me semble que maintenant, les sources d'un troff originel sont disponibles avec une licence admissible pour un projet BSD. A terme, on va sans doute se debarrasser de groff, ce qui n'est pas un mal, vu le dialecte de C++ dans lequel ce dernier est ecrit.
D'ailleurs, sauf erreur de ma part, l'auteur de groff est depuis devenu raisonnable, puisque la libexpat, par exemple, est distribuee sous une licence de type MIT.
pornin
According to Marc Espie :
Il me semble que maintenant, les sources d'un troff originel sont disponibles avec une licence admissible pour un projet BSD. A terme, on va sans doute se debarrasser de groff, ce qui n'est pas un mal, vu le dialecte de C++ dans lequel ce dernier est ecrit.
Ça va être plus difficile pour gcc et les binutils...
--Thomas Pornin
According to Marc Espie <espie@nerim.net>:
Il me semble que maintenant, les sources d'un troff originel sont
disponibles avec une licence admissible pour un projet BSD. A terme,
on va sans doute se debarrasser de groff, ce qui n'est pas un mal, vu
le dialecte de C++ dans lequel ce dernier est ecrit.
Ça va être plus difficile pour gcc et les binutils...
Il me semble que maintenant, les sources d'un troff originel sont disponibles avec une licence admissible pour un projet BSD. A terme, on va sans doute se debarrasser de groff, ce qui n'est pas un mal, vu le dialecte de C++ dans lequel ce dernier est ecrit.
Ça va être plus difficile pour gcc et les binutils...
--Thomas Pornin
Miod Vallat
Ça va être plus difficile pour gcc et les binutils...
Grumble-bubble.
Ça va être plus difficile pour gcc et les binutils...
Ça va être plus difficile pour gcc et les binutils...
Grumble-bubble.
espie
In article <ci491r$2ap2$, Thomas Pornin wrote:
According to Marc Espie :
Il me semble que maintenant, les sources d'un troff originel sont disponibles avec une licence admissible pour un projet BSD. A terme, on va sans doute se debarrasser de groff, ce qui n'est pas un mal, vu le dialecte de C++ dans lequel ce dernier est ecrit.
Ça va être plus difficile pour gcc et les binutils...
helas, trois fois helas, oui.
In article <ci491r$2ap2$1@biggoron.nerim.net>,
Thomas Pornin <pornin@nerim.net> wrote:
According to Marc Espie <espie@nerim.net>:
Il me semble que maintenant, les sources d'un troff originel sont
disponibles avec une licence admissible pour un projet BSD. A terme,
on va sans doute se debarrasser de groff, ce qui n'est pas un mal, vu
le dialecte de C++ dans lequel ce dernier est ecrit.
Ça va être plus difficile pour gcc et les binutils...
Il me semble que maintenant, les sources d'un troff originel sont disponibles avec une licence admissible pour un projet BSD. A terme, on va sans doute se debarrasser de groff, ce qui n'est pas un mal, vu le dialecte de C++ dans lequel ce dernier est ecrit.
Ça va être plus difficile pour gcc et les binutils...
helas, trois fois helas, oui.
Eric Masson
"Thomas" == Thomas Pornin writes:
Thomas> Ça va être plus difficile pour gcc et les binutils...
Tendra (Ten15 ou TenDRA) ne pourrait vraiment pas devenir une alternative valable ?
Eric Masson
-- JCB: "premiers-pas" c'est une enseigne [] pour les gens un peu paumés LW: Sans compter qu'un groupe spécifique pour les questions des FAQ permet de réaliser un robot qui maile 'RTFM' à chaque intervant. -+- Laurent in guide du Linuxien pervers - "Soyons pratiques !" -+-
"Thomas" == Thomas Pornin <pornin@nerim.net> writes:
Thomas> Ça va être plus difficile pour gcc et les binutils...
Tendra (Ten15 ou TenDRA) ne pourrait vraiment pas devenir une
alternative valable ?
Eric Masson
--
JCB: "premiers-pas" c'est une enseigne [] pour les gens un peu paumés
LW: Sans compter qu'un groupe spécifique pour les questions des FAQ
permet de réaliser un robot qui maile 'RTFM' à chaque intervant.
-+- Laurent in guide du Linuxien pervers - "Soyons pratiques !" -+-
Thomas> Ça va être plus difficile pour gcc et les binutils...
Tendra (Ten15 ou TenDRA) ne pourrait vraiment pas devenir une alternative valable ?
Eric Masson
-- JCB: "premiers-pas" c'est une enseigne [] pour les gens un peu paumés LW: Sans compter qu'un groupe spécifique pour les questions des FAQ permet de réaliser un robot qui maile 'RTFM' à chaque intervant. -+- Laurent in guide du Linuxien pervers - "Soyons pratiques !" -+-
espie
In article , Eric Masson wrote:
"Thomas" == Thomas Pornin writes:
Thomas> Ça va être plus difficile pour gcc et les binutils...
Tendra (Ten15 ou TenDRA) ne pourrait vraiment pas devenir une alternative valable ?
Eric Masson
Pour l'instant, c'est loin d'etre encore ca... Le travail de titan, bien sur, c'est d'avoir un support raisonnable pour tous les processeurs qu'on est susceptible de vouloir.
Notons que gcc facilite un peu la tache: en declarant comme obsolete plein de config qui n'ont plus de mainteneurs, ou en produisant du code notoirement buggue sur certaines vieilles architectures, il simplifie peu a peu le passage a Tendra.
In article <86hdq2utl8.fsf@srvbsdnanssv.interne.kisoft-services.com>,
Eric Masson <emss@free.fr> wrote:
"Thomas" == Thomas Pornin <pornin@nerim.net> writes:
Thomas> Ça va être plus difficile pour gcc et les binutils...
Tendra (Ten15 ou TenDRA) ne pourrait vraiment pas devenir une
alternative valable ?
Eric Masson
Pour l'instant, c'est loin d'etre encore ca...
Le travail de titan, bien sur, c'est d'avoir un support raisonnable
pour tous les processeurs qu'on est susceptible de vouloir.
Notons que gcc facilite un peu la tache: en declarant comme obsolete
plein de config qui n'ont plus de mainteneurs, ou en produisant du
code notoirement buggue sur certaines vieilles architectures, il
simplifie peu a peu le passage a Tendra.
Thomas> Ça va être plus difficile pour gcc et les binutils...
Tendra (Ten15 ou TenDRA) ne pourrait vraiment pas devenir une alternative valable ?
Eric Masson
Pour l'instant, c'est loin d'etre encore ca... Le travail de titan, bien sur, c'est d'avoir un support raisonnable pour tous les processeurs qu'on est susceptible de vouloir.
Notons que gcc facilite un peu la tache: en declarant comme obsolete plein de config qui n'ont plus de mainteneurs, ou en produisant du code notoirement buggue sur certaines vieilles architectures, il simplifie peu a peu le passage a Tendra.
Miod Vallat
Tendra (Ten15 ou TenDRA) ne pourrait vraiment pas devenir une alternative valable ?
Pour répondre une fois de plus à ce qui devient une FAQ :
«oui, mais».
Je veux dire par là que, oui, TenDRA est prometteur, mais : - il ne supporte pas assez de plate-formes pour le moment, en tous cas pour NetBSD et OpenBSD ; - il y a déjà un fork entre TenDRA et Ten15 et on aimerait bien savoir où chacun va, histoire de ne pas s'intéresser trop à celui des deux projets qui va dans le mur.
En plus, le premier point ouvre un cercle vicieux car les personnes qui pourraient aider à ajouter le support des processeurs manquant ne s'intéresseront pas beaucoup à TenDRA tant qu'il ne supportera plus de processeurs...
Tendra (Ten15 ou TenDRA) ne pourrait vraiment pas devenir une
alternative valable ?
Pour répondre une fois de plus à ce qui devient une FAQ :
«oui, mais».
Je veux dire par là que, oui, TenDRA est prometteur, mais :
- il ne supporte pas assez de plate-formes pour le moment, en tous cas
pour NetBSD et OpenBSD ;
- il y a déjà un fork entre TenDRA et Ten15 et on aimerait bien savoir
où chacun va, histoire de ne pas s'intéresser trop à celui des deux
projets qui va dans le mur.
En plus, le premier point ouvre un cercle vicieux car les personnes qui
pourraient aider à ajouter le support des processeurs manquant ne
s'intéresseront pas beaucoup à TenDRA tant qu'il ne supportera plus de
processeurs...
Tendra (Ten15 ou TenDRA) ne pourrait vraiment pas devenir une alternative valable ?
Pour répondre une fois de plus à ce qui devient une FAQ :
«oui, mais».
Je veux dire par là que, oui, TenDRA est prometteur, mais : - il ne supporte pas assez de plate-formes pour le moment, en tous cas pour NetBSD et OpenBSD ; - il y a déjà un fork entre TenDRA et Ten15 et on aimerait bien savoir où chacun va, histoire de ne pas s'intéresser trop à celui des deux projets qui va dans le mur.
En plus, le premier point ouvre un cercle vicieux car les personnes qui pourraient aider à ajouter le support des processeurs manquant ne s'intéresseront pas beaucoup à TenDRA tant qu'il ne supportera plus de processeurs...
Eric Masson
"Miod" == Miod Vallat writes:
Miod> En plus, le premier point ouvre un cercle vicieux car les Miod> personnes qui pourraient aider à ajouter le support des Miod> processeurs manquant ne s'intéresseront pas beaucoup à TenDRA Miod> tant qu'il ne supportera plus de processeurs...
Un peu le problème de la poule et de l'oeuf.
Concernant le fork Ten15/TenDRA, j'ai eu beau lire le post l'annonçant, je n'ai pas bien compris le pourquoi de la chose, mais bon...
Eric Masson
-- Linux, c'est simple : ça s'adresse à une machine qui est parfois un peu maraboutée mais qui d'habitude n'a pas d'états d'âme. Sur Usenet y'a plein d'humains et de primates, et ça devient vraiment gore par moment. -+- TP in : Guide du linuxien pervers - "Le linuxien a-t-il une âme ?" -+-
"Miod" == Miod Vallat <miod@online.fr> writes:
Miod> En plus, le premier point ouvre un cercle vicieux car les
Miod> personnes qui pourraient aider à ajouter le support des
Miod> processeurs manquant ne s'intéresseront pas beaucoup à TenDRA
Miod> tant qu'il ne supportera plus de processeurs...
Un peu le problème de la poule et de l'oeuf.
Concernant le fork Ten15/TenDRA, j'ai eu beau lire le post l'annonçant,
je n'ai pas bien compris le pourquoi de la chose, mais bon...
Eric Masson
--
Linux, c'est simple : ça s'adresse à une machine qui est parfois un peu
maraboutée mais qui d'habitude n'a pas d'états d'âme. Sur Usenet y'a
plein d'humains et de primates, et ça devient vraiment gore par moment.
-+- TP in : Guide du linuxien pervers - "Le linuxien a-t-il une âme ?" -+-
Miod> En plus, le premier point ouvre un cercle vicieux car les Miod> personnes qui pourraient aider à ajouter le support des Miod> processeurs manquant ne s'intéresseront pas beaucoup à TenDRA Miod> tant qu'il ne supportera plus de processeurs...
Un peu le problème de la poule et de l'oeuf.
Concernant le fork Ten15/TenDRA, j'ai eu beau lire le post l'annonçant, je n'ai pas bien compris le pourquoi de la chose, mais bon...
Eric Masson
-- Linux, c'est simple : ça s'adresse à une machine qui est parfois un peu maraboutée mais qui d'habitude n'a pas d'états d'âme. Sur Usenet y'a plein d'humains et de primates, et ça devient vraiment gore par moment. -+- TP in : Guide du linuxien pervers - "Le linuxien a-t-il une âme ?" -+-
