> Sur tes isos il y a des paquets binaires et pour générer ces paquets, il faut un makefile ou assimilé (parce qu'on ne fait pas ça à la main).
Comme sur i386. Dingue.
Oui il y a des scripts de build. Mais il y a mieux. Les isos déjà compilées et installables en x68-64. Linux n'est pas au stade ou il faut se taper des scripts de build pour bootstraper vers un système AMD64 contrairement à ce que sous-entend la news.
> À noter que de nombreuses distributions (gentoo, Slackware, Suse, sebian, Mandrake, Redhat, TurboLinux, Fedora) fournissent déjà des build scripts prêts pour l'AMD64.
Pour Mandrake, Gentoo, SuSE, Red Hat, Fedora, ce ne sont pas des scripts de build mais des distributions complètes qui s'installent, s'utilisent comme n'importe quelle distribution.
Pour les autres distributions, j'en sais rien. Et sebian que je ne connais pas.
Pour le reste, j'ai entendu parlé de quelques problèmes qui doivent être corrigés.
Avec la dernière FC3T3 je peux graver sans être root et sans suid pour cdrecord (graveur IDE).
> avec une Fedora 2
Il y aura _peut-être_ une mise à jour pour FC2 après la sortie de FC3.
> Tu aurais une "solide" raison pour justifier le manque d'intérêt de la communauté pour OCaml?
Non. Et d'ailleur je ne connais pas OCaml.
Je ne dis pas que OCaml est de la "bouse" car il est peu utilisé. Tu as peut-être raison lorsque tu dis que OCaml est injustement impopulaire et les différents arguments que tu avances sur du _vécu_ sont pertinents et intéressants.
Je dis simplement que "2. Affirmer que si c'était bien (...) c'est d'une connerie et d'une étroitesse d'esprit affolante" n'est pas la marque d'une personne "large" d'esprit :-)
> je pense que c'est plus un "rejet" de la part de la communauté qu'un réel vice de conception dans le langage ou dans l'API.
Mais "voilà"...
Le problème du chois d'un langage (ou autre) est qu'il est fortement basé sur des considérations qu'on ne peut ramener à sa "conception" ou son API. Il y a tout un tas de contraintes qui influence énormément.
Au premier abord, le C est nul et se fait explosé par le C++. Dans la pratique, le C reste génial et pas pour des raisons de conceptions évidentes. Le C++ aussi est génial :-) Et OCaml sûrement aussi :-)
Quoi ? Oui, python aussi :-)
w.x.y.z : le z est pour les distributeurs, etc...
Linus c'est fait remonté les bretelles pour le 2.6.8.1 (qui a été qualifié de "fiasco" pour le nom) et il a "promis" de ne plus recommencer pour une release officielle.
D'ailleur le patch du 2.6.9 est basé sur un 2.6.8 et non sur un 2.6.8.1. Ceux qui ont un 2.6.8.1 doivent faire un "downgrade" avant d'appliquer le patch.
> Avec l'ancien mode de développement du noyau
On aurait un 2.6.9 à la place de 2.6.8.1. J'avais EXTRAVERSION n'avait été utilisé pour une release officiel sauf pour le 2.6.8.1.
> Bon bien sûr y'a les gentooïstes qui font leurs ports vite fait
J'ai testé une Gentoo assez longuement et cette distribution m'a "bluffée" par sa qualité globale compte tenu de ses objectifs (dont je ne suis pas fou mais c'est une autre histoire).
Le noyau par défaut (stable, c-à-d USE="x86") est un 2.4.
Le noyau en développement (USE="~x86") est un 2.6 et a les patchs de sécurité/fix "qui vont bien".
Il faut bien tester les nouveaux noyaux. Que ce soit en parti fait pas les "gentooïstes" ne me dérange en rien.
Tiens, il y a Linux 2.6.9 dans Rawhide (Fedora). Chiao, je m'en vais tester tout ça.
> 2. Connais pas mais si c'était mieux, ça se saurait.
Ça reste généralement vrai même si peut-être ici ce n'est pas le cas.
Ce qui me gène dans ton argument c'est qui ne s'appuie que sur l'incompétence des autres et les autres ne sont rien moins que les développeurs du logiciel libre qui dans la grande majorité des cas savent adopter de nouvelles solutions et sont relativement insensible aux propos marketing. Java n'est pas un succès délirant dans le logiciel libre. Python est très utilisé, ruby se fait une "place au soleil", etc.
> 2. Affirmer que si c'était bien, ça se saurait et que de toute façon,
C++, qt, gtk ou n'importe quoi d'autre, c'est fondamentalement mieux,
c'est d'une connerie et d'une étroitesse d'esprit affolante.
Il doit bien y avoir de solides raisons autre que la "paresse" pour que les gens développent gtk+, gnome, KDE, ... alors qu'il y a déjà OpenStep. Nier ce fait, c'est aussi faire preuve "d'une étroitesse d'esprit affolante".
Je veux bien admettre que tu es particuliairement heureux avec Linux 2.6 vanilla en production (comme certainement beaucoup de personnes), mais là ce sont des mainteneurs du noyau qui disent qu'il y a changement.
Ils ont tords aussi car ils n'ont pas ton niveau d'"expertise" ?
C'est le rédacteur de lwn qui affabule ?
> Depuis bien avant le "nouveau" modèle de développement qui n'est que l'officialisation de ce qui se passait déjà avant.
C'est ce qui est dit dans les url données. Mais il faut faire attention avec toi car tu as sûrement un "avant" et un "avant". C'est le nouveau modèle pour Linux >= 2.6 . L'url donnée ne dit pas que c'est le nouveau modèle pour Linux >= 2.6.9 .
Pour ton info, Linux 2.4 était la précédente branche stable. Donc avant, par rapport à 2.6, ce n'était pas comme maintenant.
Oui, il a raison, :
- "pas au sens ça va m'exploser à la figure à chaque branchement de périphérique USB."
Effectivement, ça ne va pas exploser à la figure à chaque branchement de périphérique USB. C'est aussi bien qu'un 2.5.
Questions :
C'est bien qu'une machine en production ait les sécurités fix bien après les autres ?
C'est bien qu'une mise à jours (peut-être avec sécurité fix) soit incompatible avec la version production ?
Si pour toi ça aussi ça te parait adapté pour la production...., je ferme ma gueule. J'ai des exigences qui n'ont manifestement plus cours.
> Il faut lire stable au sens stabilité des interfaces
Non.
Au sens ou la stabilité/sécurité n'est pas la priorité. C'est pris en compte, mais ce n'est pas la priorité. Si tel ou tel driver sucks ou s'il y a un trou de sécurité : tant pis. Tu peux attendre plusieurs semaines avant d'avoir un noyau vanilla avec un fix de sécurité (c'est déjà arrivé plusieurs fois !).
...
The traditional stabilization mechanism, where almost no patches are accepted for long periods of time, does not strike him as a good idea.
...
These patches include API changes, incidentally. Stable internal kernel APIs have never been guaranteed, but the developers have usually tried to not make big changes during a stable kernel series. That looks to change now.
Ça me parait claire. Si t'as un serveur en production et met à jour vers Linux 2.6.n+1, ça peut ne pas marcher entre autre à cause d'incompatibilité. Mais évidemment que le noyau vanilla marchera sur la plus part des configurations. Sinon comme ils font les développeurs pour bosser :-)
Selon lwn :
- a lot of NTFS updates
- block I/O barrier support ( http://lwn.net/Articles/103183/(...) )
- patch allowing unprivileged process to lock small amounts of memory in RAM
http://lwn.net/Articles/96587/(...)
Rik van Riel and Arjan van de Ven have put together a new patch which allows normal users to lock memory into physical RAM without root privilege. The RLIMIT_MEMLOCK resource limit puts an upper bound on how much memory can be locked, and its default value is zero. By raising this limit, system administrators can enable users to lock a single page (useful for cryptographic applications which do not want to see passphrases and clear text swapped to disk) or larger amounts (for CD writing tasks, for example).
Andrew pointed out that, during the 2.6 process, he and Linus have been merging patches at a rate of about 10MB/month. There is, he says, no reason to believe that things will not continue that way. The traditional stabilization mechanism, where almost no patches are accepted for long periods of time, does not strike him as a good idea. Instead, Andrew would like to see a 2.6 tree which continues to change and evolve, and let the distributors do the final stabilization work. In his vision of the future, the kernel.org kernel will be the most featureful and fastest kernel out there, but it will not necessarily be the most stable.
Pour le son, utilise alsamixer.
alsamixer est moche (y tout) mais il propose presque toutes les options. Et surtout, tu trouveras peut-être une voie qui est désactivée et qui empêche d'entendre.
Depuis un terminal :
$ man alsamixer (c'est pour la documentation)
$ alsamixer
Lorsque tu arrêteras la bécane, la configuration de la carte son sera sauvegardée.
> donc j'imagine que la diff avec la test 1 n'est pas si importante que cela, si ?
Il n'y a pas d'enorme différence. Xorg 6.8.0 a été ajouté alors que FC3 était prévu avec 6.7.0. Il y a par contre l'emploi "intensif" d'udev. Ce n'était pas prévu à l'origine (/dev devait toujours avoir ses milliers de fichiers) mais le mainteneur d'udev a su convaincre Red Hat. Ça a demandé un nombre de modifications assez important et parfois tout était cassé :-(
Bref, comme d'habitude. Par contre pour le lien, il n'y aura qu'un lien (BIG_A) et sur hdb car c'est le second disque détecté (en gros, udev fait "ln -s -f"). Si tu permutes hda avec hdb, le lien pointe toujours sur hdb (l'autre disque physique).
Si les disques sont "hotplugs", c'est le dernier "qui a priorité". Le nom noyau (%k (hda, hdb, etc)) et la paire numéro majeur/mineur est toujours unique. Le lien symbolique n'est qu'un racourci.
C'est pour celà qu'il faut toujours conserver 'NAME="%k"' et ne renommer qu'avec les liens symboliques.
[^] # Re: Build scripts?
Posté par 007 . En réponse à la dépêche AMD64 vs Intel32 : 30% d'écart !. Évalué à 4.
[^] # Re: Build scripts?
Posté par 007 . En réponse à la dépêche AMD64 vs Intel32 : 30% d'écart !. Évalué à 3.
Comme sur i386. Dingue.
Oui il y a des scripts de build. Mais il y a mieux. Les isos déjà compilées et installables en x68-64. Linux n'est pas au stade ou il faut se taper des scripts de build pour bootstraper vers un système AMD64 contrairement à ce que sous-entend la news.
# scripts de build ?
Posté par 007 . En réponse à la dépêche AMD64 vs Intel32 : 30% d'écart !. Évalué à 3.
Pour Mandrake, Gentoo, SuSE, Red Hat, Fedora, ce ne sont pas des scripts de build mais des distributions complètes qui s'installent, s'utilisent comme n'importe quelle distribution.
Pour les autres distributions, j'en sais rien. Et sebian que je ne connais pas.
[^] # Re: investissement
Posté par 007 . En réponse au message probleme de montage de particion. Évalué à 2.
> mais ok, promis je fait plus gaffe a l'ortographe dans mes prochins posts.
fait => ferai
a => à
ortographe => orthographe
prochins => prochains
Ce n'est pas grave ici. Mais fais attention. Ça pourrait tu nuire _gravement_ !
[^] # Re: Graveur SCSI
Posté par 007 . En réponse à la dépêche Sortie du noyau Linux 2.6.9. Évalué à 2.
Normal :
http://lwn.net/Articles/98379/(...)
Pour le reste, j'ai entendu parlé de quelques problèmes qui doivent être corrigés.
Avec la dernière FC3T3 je peux graver sans être root et sans suid pour cdrecord (graveur IDE).
> avec une Fedora 2
Il y aura _peut-être_ une mise à jour pour FC2 après la sortie de FC3.
# Re:
Posté par 007 . En réponse au message Clustering. Évalué à 3.
Pourquoi Raid 1 et pas Raid 0 ?
> J'ai survolé la question et j'ai vu que 2 paquetages ont existé sous RH
Normalement il existe toujours...
Essaies un "up2date --show-available"
La doc est là :
http://www.redhat.com/docs/manuals/enterprise/RHEL-3-Manual/cluster(...)
Red Hat propose aussi GFS (ce n'est pas livré avec RHEL 3 AS en standard contrairement à "Cluster Suite") :
http://www.redhat.com/docs/manuals/csgfs/admin-guide/(...)
[^] # Re: Hors sujet mais pas tant que ça
Posté par 007 . En réponse à la dépêche 10 ans d'OpenStep. Évalué à 0.
Non. Et d'ailleur je ne connais pas OCaml.
Je ne dis pas que OCaml est de la "bouse" car il est peu utilisé. Tu as peut-être raison lorsque tu dis que OCaml est injustement impopulaire et les différents arguments que tu avances sur du _vécu_ sont pertinents et intéressants.
Je dis simplement que "2. Affirmer que si c'était bien (...) c'est d'une connerie et d'une étroitesse d'esprit affolante" n'est pas la marque d'une personne "large" d'esprit :-)
> je pense que c'est plus un "rejet" de la part de la communauté qu'un réel vice de conception dans le langage ou dans l'API.
Mais "voilà"...
Le problème du chois d'un langage (ou autre) est qu'il est fortement basé sur des considérations qu'on ne peut ramener à sa "conception" ou son API. Il y a tout un tas de contraintes qui influence énormément.
Au premier abord, le C est nul et se fait explosé par le C++. Dans la pratique, le C reste génial et pas pour des raisons de conceptions évidentes. Le C++ aussi est génial :-) Et OCaml sûrement aussi :-)
Quoi ? Oui, python aussi :-)
Je crois que ça suffit maintenant.
[^] # Re: Quelques corrections assez importantes
Posté par 007 . En réponse à la dépêche Sortie du noyau Linux 2.6.9. Évalué à 1.
Ooops, c'est KEYWORDS="x86". Ou un truc comme ça, je n'ai plus de Gentoo pour vérifier.
[^] # Re: Quelques corrections assez importantes
Posté par 007 . En réponse à la dépêche Sortie du noyau Linux 2.6.9. Évalué à 1.
Linus c'est fait remonté les bretelles pour le 2.6.8.1 (qui a été qualifié de "fiasco" pour le nom) et il a "promis" de ne plus recommencer pour une release officielle.
D'ailleur le patch du 2.6.9 est basé sur un 2.6.8 et non sur un 2.6.8.1. Ceux qui ont un 2.6.8.1 doivent faire un "downgrade" avant d'appliquer le patch.
> Avec l'ancien mode de développement du noyau
On aurait un 2.6.9 à la place de 2.6.8.1. J'avais EXTRAVERSION n'avait été utilisé pour une release officiel sauf pour le 2.6.8.1.
[^] # Re: Quelques corrections assez importantes
Posté par 007 . En réponse à la dépêche Sortie du noyau Linux 2.6.9. Évalué à 2.
J'ai testé une Gentoo assez longuement et cette distribution m'a "bluffée" par sa qualité globale compte tenu de ses objectifs (dont je ne suis pas fou mais c'est une autre histoire).
Le noyau par défaut (stable, c-à-d USE="x86") est un 2.4.
Le noyau en développement (USE="~x86") est un 2.6 et a les patchs de sécurité/fix "qui vont bien".
Il faut bien tester les nouveaux noyaux. Que ce soit en parti fait pas les "gentooïstes" ne me dérange en rien.
Tiens, il y a Linux 2.6.9 dans Rawhide (Fedora). Chiao, je m'en vais tester tout ça.
[^] # Re: Hors sujet mais pas tant que ça
Posté par 007 . En réponse à la dépêche 10 ans d'OpenStep. Évalué à -2.
Ça reste généralement vrai même si peut-être ici ce n'est pas le cas.
Ce qui me gène dans ton argument c'est qui ne s'appuie que sur l'incompétence des autres et les autres ne sont rien moins que les développeurs du logiciel libre qui dans la grande majorité des cas savent adopter de nouvelles solutions et sont relativement insensible aux propos marketing. Java n'est pas un succès délirant dans le logiciel libre. Python est très utilisé, ruby se fait une "place au soleil", etc.
> 2. Affirmer que si c'était bien, ça se saurait et que de toute façon,
C++, qt, gtk ou n'importe quoi d'autre, c'est fondamentalement mieux,
c'est d'une connerie et d'une étroitesse d'esprit affolante.
Il doit bien y avoir de solides raisons autre que la "paresse" pour que les gens développent gtk+, gnome, KDE, ... alors qu'il y a déjà OpenStep. Nier ce fait, c'est aussi faire preuve "d'une étroitesse d'esprit affolante".
[^] # Re: Quelques corrections assez importantes
Posté par 007 . En réponse à la dépêche Sortie du noyau Linux 2.6.9. Évalué à 1.
Ils ont tords aussi car ils n'ont pas ton niveau d'"expertise" ?
C'est le rédacteur de lwn qui affabule ?
Fais moi une explication de texte.
[^] # Re: Quelques corrections assez importantes
Posté par 007 . En réponse à la dépêche Sortie du noyau Linux 2.6.9. Évalué à -1.
> des choses sérieuses
La production n'est pas une "chose sérieuse" ?
> Depuis bien avant le "nouveau" modèle de développement qui n'est que l'officialisation de ce qui se passait déjà avant.
C'est ce qui est dit dans les url données. Mais il faut faire attention avec toi car tu as sûrement un "avant" et un "avant". C'est le nouveau modèle pour Linux >= 2.6 . L'url donnée ne dit pas que c'est le nouveau modèle pour Linux >= 2.6.9 .
Pour ton info, Linux 2.4 était la précédente branche stable. Donc avant, par rapport à 2.6, ce n'était pas comme maintenant.
[^] # Re: Quelques corrections assez importantes
Posté par 007 . En réponse à la dépêche Sortie du noyau Linux 2.6.9. Évalué à 1.
Oui, il a raison, :
- "pas au sens ça va m'exploser à la figure à chaque branchement de périphérique USB."
Effectivement, ça ne va pas exploser à la figure à chaque branchement de périphérique USB. C'est aussi bien qu'un 2.5.
Questions :
C'est bien qu'une machine en production ait les sécurités fix bien après les autres ?
C'est bien qu'une mise à jours (peut-être avec sécurité fix) soit incompatible avec la version production ?
Si pour toi ça aussi ça te parait adapté pour la production...., je ferme ma gueule. J'ai des exigences qui n'ont manifestement plus cours.
[^] # Re: Quelques corrections assez importantes
Posté par 007 . En réponse à la dépêche Sortie du noyau Linux 2.6.9. Évalué à 1.
Non.
Au sens ou la stabilité/sécurité n'est pas la priorité. C'est pris en compte, mais ce n'est pas la priorité. Si tel ou tel driver sucks ou s'il y a un trou de sécurité : tant pis. Tu peux attendre plusieurs semaines avant d'avoir un noyau vanilla avec un fix de sécurité (c'est déjà arrivé plusieurs fois !).
Relis bien :
http://lwn.net/Articles/94386/(...)
...
The traditional stabilization mechanism, where almost no patches are accepted for long periods of time, does not strike him as a good idea.
...
These patches include API changes, incidentally. Stable internal kernel APIs have never been guaranteed, but the developers have usually tried to not make big changes during a stable kernel series. That looks to change now.
Ça me parait claire. Si t'as un serveur en production et met à jour vers Linux 2.6.n+1, ça peut ne pas marcher entre autre à cause d'incompatibilité. Mais évidemment que le noyau vanilla marchera sur la plus part des configurations. Sinon comme ils font les développeurs pour bosser :-)
# Il n'y a pas que Alsa :-)
Posté par 007 . En réponse à la dépêche Sortie du noyau Linux 2.6.9. Évalué à 8.
- a lot of NTFS updates
- block I/O barrier support ( http://lwn.net/Articles/103183/(...) )
- patch allowing unprivileged process to lock small amounts of memory in RAM
http://lwn.net/Articles/96587/(...)
Rik van Riel and Arjan van de Ven have put together a new patch which allows normal users to lock memory into physical RAM without root privilege. The RLIMIT_MEMLOCK resource limit puts an upper bound on how much memory can be locked, and its default value is zero. By raising this limit, system administrators can enable users to lock a single page (useful for cryptographic applications which do not want to see passphrases and clear text swapped to disk) or larger amounts (for CD writing tasks, for example).
- new USB storage driver
- cluster-wide file locking infrastructure
- completely out-of-line spinlocks ( http://lwn.net/Articles/97537/(...) )
- AMD dual-core support
- support for the POSIX waitid() system call
- KProbes ( http://www-124.ibm.com/linux/projects/kprobes/(...) )
- USB "on the go" support
- the "flex mmap" user-space memory layout
- m32r architecture support ( http://www.linux-m32r.org/(...) )
- a bunch of latency-reduction work (Ingo Molnar)
- Nouvelle adressage mémoire : http://lwn.net/Articles/91829/(...)
- new I/O memory access mechanism ( http://lwn.net/Articles/102232/(...) )
- and lots of fixes :-)
Après le Kernel coding style, il y a maintenant le "Linux kernel management style" :
http://lwn.net/Articles/105375/(...)
Merci à lwn.
[^] # Re: Quelques corrections assez importantes
Posté par 007 . En réponse à la dépêche Sortie du noyau Linux 2.6.9. Évalué à 5.
Le Linux vanilla n'est plus un noyau pour la production. Ou uniquement pour les personnes abonnées à la lkml et qui comprennent ce qui s'y dit.
C'est lié au nouveau modèle de développement défini durant le dernier sommet noyau :
http://lwn.net/Articles/94386/(...)
Andrew pointed out that, during the 2.6 process, he and Linus have been merging patches at a rate of about 10MB/month. There is, he says, no reason to believe that things will not continue that way. The traditional stabilization mechanism, where almost no patches are accepted for long periods of time, does not strike him as a good idea. Instead, Andrew would like to see a 2.6 tree which continues to change and evolve, and let the distributors do the final stabilization work. In his vision of the future, the kernel.org kernel will be the most featureful and fastest kernel out there, but it will not necessarily be the most stable.
Un autre article qui parle de la même chose :
http://lwn.net/Articles/95312/(...)
À lire attentivement avant de protester.
[^] # Re: le rythme diminue
Posté par 007 . En réponse au journal 2.6.9. Évalué à -3.
Installes un 2.4 si c'est t'as priorité.
Jamais un .9 est sorti avec une telle distance du .0 .
[^] # Re: Mieux avant ?
Posté par 007 . En réponse au journal 2.6.9. Évalué à 4.
Il est sorti hier à 18h.
http://www.ussg.iu.edu/hypermail/linux/kernel/0410.2/0578.html(...)
[^] # Re: FC3 test 2
Posté par 007 . En réponse au journal VectorLinux 4.3 && Fedora Core 3 Test 2. Évalué à -1.
Tu veux dire qu'il y en a 5 % de paquet de moins que i386 ?
> pas mal de bug
Oui, ce n'est pas un yellow dog et ce n'est pas l'objectif.
> cette grosse bouze de yum
Ben il y a longtemps que tu n'as pas testé yum...
Il n'y a pas de dépôt apt, comme il n'y a pas de dépôt apt pour les autres architectures.
# Le son
Posté par 007 . En réponse au message déja des problémes.... Évalué à 1.
alsamixer est moche (y tout) mais il propose presque toutes les options. Et surtout, tu trouveras peut-être une voie qui est désactivée et qui empêche d'entendre.
Depuis un terminal :
$ man alsamixer (c'est pour la documentation)
$ alsamixer
Lorsque tu arrêteras la bécane, la configuration de la carte son sera sauvegardée.
# FC1 n'est plus supporté par Red Hat
Posté par 007 . En réponse au journal VectorLinux 4.3 && Fedora Core 3 Test 2. Évalué à 1.
http://www.redhat.com/archives/fedora-announce-list/2004-September/(...)
[^] # Re: FC3 test 2
Posté par 007 . En réponse au journal VectorLinux 4.3 && Fedora Core 3 Test 2. Évalué à 2.
Je parlais de l'annonce RedHat. Pas de la tienne.
Red Hat aurait pu faire un petit effort.
À ce propos : http://www.bytebot.net/talks/FC3-t2rawhide-whatsnew.pdf(...)
> donc j'imagine que la diff avec la test 1 n'est pas si importante que cela, si ?
Il n'y a pas d'enorme différence. Xorg 6.8.0 a été ajouté alors que FC3 était prévu avec 6.7.0. Il y a par contre l'emploi "intensif" d'udev. Ce n'était pas prévu à l'origine (/dev devait toujours avoir ses milliers de fichiers) mais le mainteneur d'udev a su convaincre Red Hat. Ça a demandé un nombre de modifications assez important et parfois tout était cassé :-(
[^] # Re: FC3 test 2
Posté par 007 . En réponse au journal VectorLinux 4.3 && Fedora Core 3 Test 2. Évalué à 1.
Udev crée :
$ ll /dev/hda /dev/hdb
brw-rw---- 1 root disk 3, 0 fév 23 2004 /dev/hda
brw-rw---- 1 root disk 3, 64 fév 23 2004 /dev/hdb
Bref, comme d'habitude. Par contre pour le lien, il n'y aura qu'un lien (BIG_A) et sur hdb car c'est le second disque détecté (en gros, udev fait "ln -s -f"). Si tu permutes hda avec hdb, le lien pointe toujours sur hdb (l'autre disque physique).
Si les disques sont "hotplugs", c'est le dernier "qui a priorité". Le nom noyau (%k (hda, hdb, etc)) et la paire numéro majeur/mineur est toujours unique. Le lien symbolique n'est qu'un racourci.
C'est pour celà qu'il faut toujours conserver 'NAME="%k"' et ne renommer qu'avec les liens symboliques.
[^] # Re: FC3 test 2
Posté par 007 . En réponse au journal VectorLinux 4.3 && Fedora Core 3 Test 2. Évalué à 1.
Il semble que ppc (32 et 64 bits, jusqu'au p5) sera supporté dans peu de temps.