Tout le monde ou presque connaît Fedora Core, la test 2 est sortie :
http://www.redhat.com/archives/fedora-announce-list/2004-September/(...)
Par contre, certains ne connaissent pas encore VectorLinux, et ça, c'est pas bien. Je la recommande particulièrement pour les petites configs, comme c'est une question que je rencontre régulièrement sur les forums. La 4.3 étant sortie hier soir, c'est l'occasion pour la (re-)tester.
L'annonce de la sortie : http://www.vectorlinux.com/article.php?sid=18(...)
Journal VectorLinux 4.3 && Fedora Core 3 Test 2
20
sept.
2004
# Des torrents pour Fedora
Posté par marialamie . Évalué à 4.
# Ce sont des distributions
Posté par Djax . Évalué à 3.
VectorLinux 4.3 est aussi une distribution GNU/Linux petite et rapide.
J'ai cru que VectorLinux était un programme genre dessin vectoriel (qui aurait été adapté aux petites config, contrairement à d'autres logiciels gourmants d'imagerie) qui aurait été compris dans FC3.
[^] # Re: Ce sont des distributions
Posté par lezardbreton . Évalué à 2.
[^] # Re: Ce sont des distributions
Posté par Psychofox (Mastodon) . Évalué à 3.
[^] # Re: Ce sont des distributions
Posté par lezardbreton . Évalué à 3.
# FC3 test 2
Posté par 007 . Évalué à 6.
Voilà une petite présentation de FC3 :
$ cat /etc/udev/rules.d/20.rules
BUS="ide", KERNEL="hd*", PROGRAM="/bin/ide_id /sys/bus/ide/devices/%b/block/dev", RESULT="Y28G0SEE", NAME="%k", SYMLINK="BIG_A%n"
BUS="ide", KERNEL="hd*", RESULT="Y21860DE", NAME="%k", SYMLINK="BIG_B%n"
BUS="ide", KERNEL="hd*", RESULT="V21NYZTA", NAME="%k", SYMLINK="SMALL_A%n"
BUS="ide", KERNEL="hd*", RESULT="V21NZ0MA", NAME="%k", SYMLINK="SMALL_B%n"
En fonction du n° de série du disque ide, il me crée un lien symbolique "BIG_*" ou "SMALL_*".
Voilà ce que j'obtiens :
$ cd /dev ; ll BIG_* SMALL_*
lrwxr-xr-x 1 root root 3 sep 20 17:31 BIG_A -> hda
lrwxr-xr-x 1 root root 4 sep 20 17:31 BIG_A1 -> hda1
lrwxr-xr-x 1 root root 4 sep 20 17:31 BIG_A2 -> hda2
lrwxr-xr-x 1 root root 4 sep 20 17:31 BIG_A3 -> hda3
lrwxr-xr-x 1 root root 3 sep 20 17:31 BIG_B -> hdc
lrwxr-xr-x 1 root root 4 sep 20 17:31 BIG_B1 -> hdc1
lrwxr-xr-x 1 root root 4 sep 20 17:31 BIG_B2 -> hdc2
lrwxr-xr-x 1 root root 4 sep 20 17:31 BIG_B3 -> hdc3
lrwxr-xr-x 1 root root 3 sep 20 17:31 SMALL_A -> hde
lrwxr-xr-x 1 root root 4 sep 20 17:31 SMALL_A1 -> hde1
lrwxr-xr-x 1 root root 4 sep 20 17:31 SMALL_A2 -> hde2
lrwxr-xr-x 1 root root 3 sep 20 17:31 SMALL_B -> hdg
lrwxr-xr-x 1 root root 4 sep 20 17:31 SMALL_B1 -> hdg1
lrwxr-xr-x 1 root root 4 sep 20 17:31 SMALL_B2 -> hdg2
Mieux, si je vire la partition /dev/hdg2, le node hdg2 et le lien symbolique SMALL_B2 disparait. Et si je crée une nouvelle partition, tout est créé comme prévu. Ainsi, je peux déplacer mes disques ou utiliser ou non "ide=reverse", les liens symbolique pointent toujours sur le même disque (physique) et je ne touche plus à mon /etc/fstab. C'est mieux que devlabel (par exemple les partitions swap sont gérées) et d'ailleurs devlabel a été supprimé.
C'est vraiment bien consu et maintenant sysfs prend tout son sens (avec HAL aussi).
Notons que ça change complètement le fonctionnement "classique" de Linux. Les modules ne sont plus chargés à la volé, à la demande. Il y a détection du matériel avec kmodule (de kudzu). kmodule n'est pas très "brutal". Il ne charge pas tous les modules pour voir si un périphérique existe ou non. Il lit les informations sur les bus (PCI, etc) et charge les modules que s'il y a un périphérique. Si un périphérique est ajouté à chaud, le module nécessaire est ajouté de suite et non au moment de l'utilisation du périphérique.
Ça ne doit pas marcher avec de vieux périphérique, mais il faut bien vivre avec son temps.
Comme d'habitude, le chargement d'un module peut-être inhibé avec /etc/modprobe.conf.
Globalement, ça ralentit significativement le temps de boot.
Bien que la décision de passer "réellement" à udev soit récente par le projet Fedora (post "test 1") on a maintenant une intégration complète d'udev (dans initrd, /dev est un tmpfs, suppression du paquet dev- (et ses 18 000 fichiers spéciaux), etc). C'est tout neuf et pas totalement au point. Mais maintenant l'intégration d'udev est en phase de mise à point et non de développement.
Udev n'a pas une "remplaçant de devfs" puisqu'il n'y a jamais eu de devfs sous RH/Fedora :-)
Une copie d'écran vaut mieux qu'un long discours :
http://freedesktop.org/~david/hal-0.2/spec/hal-fdi-example1.png(...)
Ces informations sont facilement accessibles aux applis. Actuellement c'est utilisé par nautilus, gnome-volume-manageur et fstab-sync. C'est un début.
HAL répercute aussi les évèments aux applis (ajout/suppression d'un périphérique, changement d'état). Donc magicdev a été supprimé. HAL est une aide pour les applis pour bien utiliser/détecter le hardware et non une surcouche au noyau lors de l'utilisateur du hardware (c'est subtile, il faut voir la doc pour comprendre).
- voluntary-preemption
- 4g4g
- exec-shield
Plus remarquablement, il y a ext3-online-resize. Ça fait depuis un moment qu'il y est là mais il ne semble pas encore totalement fiabilisé (corruption de FS il y a peu de temps).
kernel-source n'est plus fourni ! Pour utiliser les sources Linux, il faut faire comme avec les autres paquets. C-à-d utiliser le src.rpm (rpmbuild -bp).
C'est une distribution très synchronisée avec les développements en cours et dans l'esprit Fedora (aller de l'avant et ne pas s'encombrer de problème de compatiblité etc). C'est criant pour udev/hal/gnome. Ça reste une beta ! En gros, elle sucks autant que la FC2T2. Donc on peut avoir confiance pour la version finale :-)
NB : FC3 sera la base de RHEL 4. D'ailleurs certains dev RHEL bossent déjà sur FC3. Ça donne une idée des prochaines distributions professionnelles.
NB2 : Oui, le bug avec les partitions Windows a été corrigé (enfin...).
[^] # Re: FC3 test 2
Posté par 007 . Évalué à 1.
Il semble que ppc (32 et 64 bits, jusqu'au p5) sera supporté dans peu de temps.
[^] # Re: FC3 test 2
Posté par ckyl . Évalué à 2.
Bref le ppc c'est bon pour les wariors avec fedora pour les autres va falloir attendre un peu. De plus il n'y a pas de depot apt a ma connaissance donc on est obliger de se taper cette grosse bouze de yum (oui oui 65 secondes pour generer les dependences a chaque fois !).
[^] # Re: FC3 test 2
Posté par 007 . É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.
[^] # Re: FC3 test 2
Posté par Guillaume Knispel . Évalué à 3.
[^] # Re: FC3 test 2
Posté par 007 . É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 lezardbreton . Évalué à 2.
[^] # Re: FC3 test 2
Posté par 007 . É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é :-(
# FC1 n'est plus supporté par Red Hat
Posté par 007 . Évalué à 1.
http://www.redhat.com/archives/fedora-announce-list/2004-September/(...)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.