J'ai aussi cherché le "penchant" de Pascal Lamy sur les brevets logiciels. J'ai rien trouvé de "tranchant". Actuellement je ne sais pas s'il est pour ou contre. Je sais qu'il est pour les brevets "classiques" (qui n'ont rien à voir avec les brevets logiciels tels que proposées). De plus, par rapport aux propos de France Inter, il parle d'un brevet Européen. Il ne parle pas de voter pour le brevet. Il demande un brevet reconnu à l'échelle européenne et non pays par pays comme actuellement. C'est "administratif".
> J´ai l'impression qu´il y a un hiatus entre les idées libérales de 007 et celles appliquées en pratique par les gens censés le représenter.
Moi j'aime bien Pascal Lamy.
Les gens aiment taper dessus car il a une bonne tête pour cet emploi et c'est tout.
C'est lui qui pousse l'élargissement de l'Europe. Il a demander à l'Europe de ne plus subventionner l'agriculture européenne (pour les exportations) pour ne pas tuer l'agriculture des payés pauvres. Les états européens ne veulent pas...
Il est pour le nouveau traité européen qui donne plus d'importance au parlement (qui nous représente).
etc...
Certe, vous pouvez toujours lui taper dessus, mais faut regarder un peu les faits.
Si vous ne le trouvé pas de gauche, installé Sarkozi comme commissaire au commerce pour voir la différence. Le "petit nicolas" est un conservateur libéral, qui n'est pas convaincu par le nouveau traité européen, est contre l'entré de la Turquie en Europe, ne pense qu'à diminuer les impôts et les couvertures sociales (j'ai jamais entendu ça de la par de Lamy), etc...
Il y a les gens de gauche (dont Pascal Lamy) et les gens de droite (dont Sarkozy, Alain Madelin, etc). Ce n'est pas la même chose.
Peut-être que vous trouvez Pascal Lamy pas assez de gauche. C'est un avis respectable.
Malheureusement, le parlement européen est principalement à droite et la faute en est principalement à ceux qui votent. Pascal Lamy, même s'il est de gauche, doit faire avec.
> Messieurs les allergiques au fonctionnement (atypique ?) de Debian, passez votre chemin...
Mouaif.
On peut dire ça pour tout et toute critique devient impossible au nom du "politiquement correct". Et moi le "politiquement correct" me casse les couilles.
L'éditeur de lwn (fort respecté) a fait un article sur Ubuntu et parle de Debian qu'il utilise depuis longtemps : http://lwn.net/Articles/107324/(...)
Debian has a lot of appeal. It is an excruciatingly free distribution characterized by a widely recognized technical excellence. It offers a variety of packages which is second to none and a package management system which is unequaled elsewhere. But Debian scares away a number of potential users. Its "stable" release is painfully out of date most of the time, the "unstable" release is rather too bleeding-edge for many users (while still being slow to pick up new releases at times), and the middle-of-the-road "testing" release seems to offer the worst of both "stable" and "unstable." The process of creating a new stable release looks chaotic, with no timeline for an actual release in sight. The community seems to spend rather too much time arguing about the free status of firmware and documentation and packaging up obscure tools and too little time simply creating a current distribution with a broader appeal. Debian is a great institution, but it worries a number of people.
Avec le temps, entre autre car Debian ne supporte pas amd64, l'éditeur de lwn est maintenant plustot porté sur Fedora (souvent sur les mailings).
J'oubliais, les discussions sur Fedora sont publics. Il y a des mailings et irc. Tu y trouveras plein de développeurs Red Hat. Red Hat a même fait un "rappel à l'ordre" durant le test de FC2 en rappellant aux employés qui bossent sur Fedora de ne pas utiliser les canaux privés de Red Hat (RHEL notament) pour parler de Fedora.
Et dernièrement j'ai vu un employé Red Hat dire que reiserfs rox et que c'est son FS préféré :-)
Néanmoins, Fedora est dirigé par Red Hat. Ce n'est pas un projet aussi communautaire que Debian.
> il serait bon que Debian adopte un cycle de release bien plus rapide sans nuire à la stabilité.
Pour un serveur simple (lamp), la stabilité est facile à atteindre. Il y a des tonnes de serveurs sous Mandrake/Fedora/gentoo/etc qui marchent parfaitement. Il ne faut pas 2 ans de maturation pour avoir quelque chose de fiable. Heureusement.
Il faut aussi dissocier stabilité et fiabilité. Pour un serveur en production qui marche, on veut de la stabilité. Par exemple, on ne veut pas passer de php3 à php4 du jour au lendemain car le distributeur ne supporte plus php3.
Pour un nouveau serveur, on veut la dernière technologie (car c'est mieux :-)) _et_ fiable.
Par exemple RHEL ou SuSE Enterprise sont stables (long support) _et_ fiables (t'en trouveras toujours pour gueuler...).
La difficulté est de définir une bonne période de sortie de nouvelle release. Si la fréquence est élevée alors que le support est long, il faut maintenir plusieurs branches en même temps et ça coûte cher (argent ou temps développeur). Si la fréquence est faible, il y a moins de boulot mais t'as souvent de vieux logiciels (comprendre pas performants, pas en mesure de répondre à un besoin, etc).
Red Hat et SuSE ont trouvé un bon compromis. Debian rame encore alors que c'est un vieu problème.
Au-delà de la période de sortie (qui peut être un simple choix), il y a la qualité, les fonctionnalités et le niveau de mise à jours d'une nouvelle distribution.
RHEL 4 va sûrement sortir en même temps que Sarge. La comparaison sera intéressante puisque les _produits_ ont les même objectifs (pour un usage serveur) et sont du logiciel libre. J'ai peur que Sarge fasse "has been" à côté d'une RHEL
OK, je sais, RHEL est cher et Debian gratuit. RHEL s'appuie sur le soutient "massif" d'employés qui doivent travailler dans une direction clairement précisée.
Il n'empêche que ça montre que Debian peut faire clairement mieux et que se réfugier systématiquement derrière la "stabilité" n'est pas suffisant pour justifier d'avoir des vieux logiciels.
Et oui, RHEL et SuSE Enterprise sont multi plateforme (moins que Debian) et oui toutes les plateformes sont disponibles en même temps.
Et non, RHEL et SuSE Enterprise ne tournent pas sur Arm ou m68k.
Sachant que Debian veut toujours fournir en même temps 11 architectures et des paquets par milliers (dont les deux tières sont d'un usage confidentiel), j'ai peur que Debian reste le "pire choix" pour du hardware commun. Par contre, c'est le meilleur choix pour du hardware "exotique".
> > Pour finir, Mandrake 10.1, Suse 9.2 et Debian utilisent /etc/init.d/hotplug au boot!
Pas Mandrake 10.1 !!!!!!!!!!!!!!!!!!!!!!!!
Je n'ai pas vu ça pour Mandrake 10.1 rc1.
Ce n'est pas activé par le paquet hotplug (il y a /etc/rc.d/init.d/hotplug):
$ rpm -q --scripts -p hotplug-2004_04_01-8mdk.i586.rpm
preinstall scriptlet (using /bin/sh):
if [ ! -L /usr/lib/hotplug ]; then
echo "Moving /usr/lib/hotplug to /lib/hotplug"
mkdir -p /lib/hotplug/
mv /usr/lib/hotplug/* /lib/hotplug/
rmdir /usr/lib/hotplug
cd /usr/lib/
ln -s ../../lib/hotplug hotplug
fi
postinstall scriptlet (using /bin/sh):
/usr/sbin/update-usb.usermap || :
Je ne vois pas de "chkconfig --add" ou "add-service".
Et pour SuSE 9.2, manifestement je ferais mieux de regarder moi même....
> Donc en clair, toutes les distrib utilisent modules.usbmap sauf RedHat...
PPsssssssssssssssssssss.
Cette obsession de la conspiration Red Hat... Red Hat pourri le libre, Red Hat le microsoft du libre, etc...
T'as prelink sur ta bécane ?
C'est Red Hat qui l'a fait.
T'as ext3 sur ta bécane ?
C'est Red Hat qui bosse le plus sur ext3 (c'est pas le seul)
T'as gamin (remplaçant de fam) ?
C'est Red Hat.
T'as nptl ?
C'est Red Hat.
T'as gcc ?
Red Hat fait 20 % minimum du boulot sur gcc.
T'as la libc ? oui forcément.
C'est Red Hat qui fait 40 % du boulot.
Nautilus ?
Le mainteneur est Red Hat.
Gtk+ ?
Le mainteneur est Red Hat.
Nash utilisé par Mandrake, c'est Red Hat.
Dbus ?
Red Hat en a fait une bonne partie.
PAM ?
Red Hat y a beaucoup bossé aussi.
Xorg ?
Red Hat a poussé pour son émergeance. Introduit au milieu du beta cycle de FC2.
etc...
Si Red Hat n'utilise pas /lib/modules/.../modules.usbmap, c'est leur affaire. Ça les regarde. On peut dire qu'ils ont tords. Mais les "sauf Red Hat..." et autre "RedHat/Fedora est maintenant une distribution à part, non standard et donc à éviter" sont au mieux tout simplement cons.
Red Hat n'a pas à être aux ordres de Debian ou attendre de Debian un accord pour faire quelque chose ! C'est claire ?
btw, Red Hat utilise modules.usbmap. modules.usbmap est généré par depmod avec les infos dans les modules.
> Pourrait tu nous eclairer sur ce qu'il se passe sous fedora alors?
Bonne question. J'ai donné une tendance de fond. Il semble (ce n'est pas facile à deviner car il y a une évolution rapide) que hotplug (userland) ne sera là "que" pour communiquer certains evènements noyau. Le chargement de module supplémentaire se fait/fera automatiquement. Chargement à la demande "classique" sera fait dans la grande majorité des cas. Udev soulève quelque problème et peut-être qu'a côté de ioctl("/dev/...") il y aura aussi ioctl((major, mineur)). C'est à hal (par exemple) avec les informations dans "/sys" et/ou "/proc" de monter la clée usb (le module sera automatiquement chargé à ce moment). Le nouveau module-init-tools a aussi un rôle central tout comme "/sys".
"/etc/dev.d" (utilisé par udev _après_ l'installation du modules et _après_ la création des fichiers spéciaux) sera utilisé pour configurer le matériel (restaurer le son, charger un firmware, par exemple).
Ceci dit, pour usb, je n'en sais pas beaucoup car je n'ai pas usb.
Pour FC3, tout (ou presque) est absolument standard de ce côté (sinon regarde les patchs dans les paquets). Dans un premier temps, Fedora ne voulait pas de udev dans FC3 (on l'a tous remarqué, il y a quelques problèmes pour le chargement à la demande). Le mainteneur de udev est venu défendre l'intérêt de udev sur la mailing Fedora. Un employé Red Hat a aussi défendu udev avec l'argument "massu" qu'il était facile de gérer 2000 disque dur avec (cas des gros serveurs). Finalement udev a trouvé son chemin sur le tard. Red Hat a _beaucoup_ bossé sur hal (en upstream) durant la phase de test de FC3.
Amuses toi à installer une FC3T1 puis une FC3 finale (toute proche) pour voir l'énorme différence et l'énorme boulot. FC3 finale aura les dernières version de udev (039) et hal (0.4.0). Sans travailler "main dans la main" avec les développeurs en upstream, ce n'est pas possible.
3. Do as much of the development work as possible directly in the upstream packages. This includes updates; our default policy will be to upgrade to new versions for security as well as for bugfix and new feature update releases of packages.
5. Be on the leading edge of open source technology, by adopting and helping develop new features and version upgrades.
Non-Objectives of Fedora Core:
3. Being a dumping ground for unmaintained or poorly designed software.
Non, ça été fait pour FC3 comme indiqué précédement (à cause de udev).
> Attention, la je rigole bien: "qui est le *coeur* d'hotplug", ah bon, /sbin/hotplug, un script de 6 lignes est le coeur de hotplug ?
D'accord, j'ai été rigolo.
Je disait au début : $ cat /proc/sys/kernel/hotplug
/sbin/hotplug
Pour parler de ce qui est appelé par le noyau.
Toi tu me montres un truc appelé en userland (/etc/rc.d/init.d/hotplug).
> Mandrake, Debian, Suse, ... : Utilisation *complete* du projet hotplug pour la détection à chaud et au boot du matériel.
Non. Mandrake fait comme Red Hat (depuis la 10.1).
Pour SuSE, je ne sait pas.
> A chaud, le kernel appelle le script /sbin/hotplug avec en argument le bus ou il a détecté un nouveau materiel, /sbin/hotplug appelle ensuite /etc/hotplug/bus.rc
$ ll /etc/hotplug/bus.rc
ls: /etc/hotplug/bus.rc: Aucun fichier ou répertoire de ce type
De plus, hotplug appelé depuis le noyau n'utilise jamais /etc/hotplug/*.rc (ici en tout cas).
Ici /sbin/hotplut appelle que les fichiers :
DIR="/etc/hotplug.d"
for I in "${DIR}/$1/"*.hotplug "${DIR}/"default/*.hotplug ; do
Puis default.hotplug appelle /etc/hotplug/AGENT.agent
Dans les fichiers /etc/hotplug/*.agent j'ai :
* /etc/hotplug/scsi.agent :
TYPE=$(cat $TYPE_ATTR)
case "$TYPE" in
# 2.5.51 style attributes; <scsi/scsi.h> TYPE_* constants
0) TYPE=disk ; MODULE=sd_mod ;;
# FIXME some tapes use 'osst' not 'st'
1) TYPE=tape ; MODULE=st ;;
2) TYPE=printer ;;
3) TYPE=processor ;;
4) TYPE=worm ; MODULE=sr_mod ;;
5) TYPE=cdrom ; MODULE=sr_mod ;;
6) TYPE=scanner ;;
7) TYPE=mod ; MODULE=sd_mod ;;
8) TYPE=changer ;;
9) TYPE=comm ;;
14) TYPE=enclosure ;;
esac
if [ "$MODULE" != "" ]; then
mesg "$TYPE at $DEVPATH"
modprobe $MODULE
else
Pas de détection matériel. Le noyau qui a lu le bus SCSI dit a hotplug qu'il y a un périphérique type printer, cdrom ou disk... Ce'est pas hotplug qui a "détecté" ça.
* /etc/hotplug/ieee1394.agent
# on 2.4 systems, modutils maintains MAP_CURRENT
if [ -r $MAP_CURRENT ]; then
load_drivers ieee1394 $MAP_CURRENT "$LABEL"
fi
pas de MAP_CURRENT sous Linux 2.6. C'est-à-dire avec module-init-tools. Mais Debian doit être avec modutils pour être compatible Linux 2.4 (comme je l'ai sous-entendu plus haut). Ça regarde Debian.
* /etc/hotplug/input.agent
if [ -r $MAP_CURRENT ]; then
load_drivers input $MAP_CURRENT "$LABEL"
fi
* /etc/hotplug/usb.agent :
# on 2.4 systems, modutils 2.4.2+ maintains MAP_CURRENT
# ... otherwise we can't rely on it (sigh)
case "$KERNEL" in
2.4.*|2.5.*|2.6.*)
if [ -r $MAP_CURRENT ]; then
load_drivers usb $MAP_CURRENT "$LABEL"
fi;;
*)
# cope with special driver module configurations
# (mostly HID devices, until we have an input.agent)
# not needed on 2.6 - they are loaded by hotplug
case "$KERNEL" in
2.6.* )
: nothing
;;
# some devices have user-mode drivers (no kernel module, but config)
# or specialized user-mode setup helpers
MODPROBE=:
for MAP in $MAP_USERMAP $HOTPLUG_DIR/usb/*.usermap
do
if [ -r $MAP ]; then
load_drivers usb $MAP "$LABEL"
$ ll /etc/hotplug/usb/*.usermap
ls: /etc/hotplug/usb/*.usermap: Aucun fichier ou répertoire de ce type
En gros sous Linux _2.6_, ça ne charge jamais de module. Sauf pour SCSI mais ce n'est pas de la détection matériel. C'est le noyau qui a fait la détection, puis le communique à hotplug pour configurer la matériel.
> Pour la détection au boot, c'est encore plus con, on appelle les scripts *.rc qui scannent chaque bus a la recherche du matos et ils chargent les modules de chaque matériel détecté(usb, pci, ...).
Sous Linux 2.4 et pour certain...
De plus, ce n'est pas du "hotplug" mais si le projet hotplug fournis les scripts.
> Redhat/Fedora: on fait bande a part, on prend ce qui nous interesse dans hotplug et on fait tout a notre sauce histoire d'etre bien incompatible avec le reste de la planete.
C'est du pure FUD. Renseigne toi 2 secondes. La méthode Debian, est la vieille méthode. De plus cette méthode "pue" car ça charge plein de modules pour rien.
Je regarde /proc/modules juste après le boot et j'ai 58 modules de chargé ! Je n'ai pas usb et pourtant il y a des modules usb de chargés, etc. Je comprend maintenant pourquoi on explique très tôt qu'il faut recompiler un noyau...
Ici j'ai 33 modules dont le réseau alors que j'avais pas le réseau sous debian (normal, je l'avais pas configuré). Dans ces 34, je retire sch_tbf, pppoatm, ppp_generic, atm, unicorn_pci_atm et dm_mod que je n'avais pas sous Debian et j'ai au final, 31 modules de trop sous Debian !
Tu trouves ça "moderne" ?
Fedora applique la nouvelle méthode. Hotplug sert à communiquer et configurer le matériel. Pas à le détecter. C'est le noyau qui doit détecter le matériel (sans charger les modules). C'est aux autres applis (donc hald qui va prendre une place de plus en plus importante) d'utiliser ces informations pour, pourquoi pas, charger un module.
Debian est _toujours_ en retard.
Ce que fait Debian, n'est pas la référence.
Mandrake a sa version stable et une branche de développement (cooker).
La branche de développement peut exploser "grave" à tout moment. Elle a seulement pour but de sortir une branche stable de temps à autre.
Mandrake s'impose des contraintes de temps.
Mandrake sort une release stable pour i386 en premier et fait le portage des autres archs après.
Mandrake se concentre sur son "noyau" (3 cd).
Debian sorte une nouvelle release "quand ils le sentent".
Dans Debian il y a : stable, testing, unstable, experimental, backport.
La branche testing est sensé être utilisable à tout moment.
Debian sort 11 archs en même temps.
Debian sort une distribution avec tout (10 cd).
> Si tu t'exprimais correctement aussi ... les gens te comprendraient.
J'ai été claire (il me semble).
La différence c'est que les autres disent qu'il est normal de compiler un noyau "classique" en 15 secondes et n'ont pas à le prouver.
Moi je dois prouver noir sur blanc que ce n'est pas possible alors que c'est évident.
> abstient toi de dénigrer gratuitement son travail.
Où tu vois ça ?
Je dis qu'il ne faut pas 15 secondes pour compiler un noyau linux classique.
Je suis sûr que TCC ne fait pas ça.
L'image initrd décompressée avec les sources linux à compiler fait 18Mo (compilateur compris) ! Linux en fait 10 fois plus.
Les sources dans l'image font : 399 742 (251 fichiers ".c")
Linux 2.6.9 (non, je ne vais pas downloader le 2.4.18 pour ça) : 6 463 002 (6841 fichiers ".c")
For your information, the patch 'linux-2.4.26-tcc.patch' gives the
necessary modifications to build a Linux kernel with TCCBOOT (NOTE: it
is not suffisant to build the kernel with its own Makefiles - I never
tried)
Voilà comment est compilé le noyau :
# This file contains the TinyCC command line arguments needed to
# produce the kernel.
Compilation speed for the Links Browser project. There are 76936 lines (including headers). 1632659 lines (57.9 MBytes) are compiled because the same headers are included in many files.
Notes que _tout_ tient dans le cache.
Ça doit beaucoup jouer sur le temps de chargement de gcc.
Le 4.8 Mo/s est en tenant compte de la _relecture_ des entêtes.
Soit (sans compter la relecture des headers) : 0.226 Mo/s (beau score) !
Pour Linux (en imaginant qu'on peut extrapoler car Linux est beaucoup plus complexe que links) à ce rythme, il faut 867 secondes (14 minutes et 27 secondes).
Je ne critique pas TCC, c'est peut-être un truc super. Mais il ne faut pas "n'importe quoi".
Pour un noyau "classique" comme c'est indiqué ?
Mon vmlinuz (compressé) "classique" (de la distribution) fait 1.4 Mo et j'ai 31 Mo de modules.
Mon vmlinuz au petit oignons fait 930 Ko et j'ai 2.5 Mo de modules. 15 secondes pour mon noyau customiser, je n'y crois pas 0,0002 quart de seconde.
> c'est qu'ils n'en ont pas ressenti le besoin. Ils sont donc satisfait
Certe, il parait que DOS est encore beaucoup utilisé pour la même raison.
> Ce qui ne semble pas être le cas des utilisateurs des autres distri vu qu'ils passent leur temps à essayer autres choses.
Et tu crois qu'ils n'ont pas essayé Debian ?
Pour toi il y a deux catégories :
- ceux qui utilisent Debian et qui sont contents.
- ceux qui testent tout _sauf_ Debian et qui ne sont pas contents.
[^] # Re: Brevet
Posté par 007 . En réponse au journal Psacal Lamy persiste et signe. Évalué à 1.
> http://www.europa.eu.int/chatlamy/trans_fr.pdf(...)
Document fin 1999 ...
> J´ai l'impression qu´il y a un hiatus entre les idées libérales de 007 et celles appliquées en pratique par les gens censés le représenter.
Moi j'aime bien Pascal Lamy.
Les gens aiment taper dessus car il a une bonne tête pour cet emploi et c'est tout.
C'est lui qui pousse l'élargissement de l'Europe. Il a demander à l'Europe de ne plus subventionner l'agriculture européenne (pour les exportations) pour ne pas tuer l'agriculture des payés pauvres. Les états européens ne veulent pas...
Il est pour le nouveau traité européen qui donne plus d'importance au parlement (qui nous représente).
etc...
Certe, vous pouvez toujours lui taper dessus, mais faut regarder un peu les faits.
Si vous ne le trouvé pas de gauche, installé Sarkozi comme commissaire au commerce pour voir la différence. Le "petit nicolas" est un conservateur libéral, qui n'est pas convaincu par le nouveau traité européen, est contre l'entré de la Turquie en Europe, ne pense qu'à diminuer les impôts et les couvertures sociales (j'ai jamais entendu ça de la par de Lamy), etc...
Il y a les gens de gauche (dont Pascal Lamy) et les gens de droite (dont Sarkozy, Alain Madelin, etc). Ce n'est pas la même chose.
Peut-être que vous trouvez Pascal Lamy pas assez de gauche. C'est un avis respectable.
Malheureusement, le parlement européen est principalement à droite et la faute en est principalement à ceux qui votent. Pascal Lamy, même s'il est de gauche, doit faire avec.
[^] # Re: Certains sont simplement heureux...
Posté par 007 . En réponse à la dépêche Sortie de la Debian Woody 3.0r3. Évalué à 1.
Mouaif.
On peut dire ça pour tout et toute critique devient impossible au nom du "politiquement correct". Et moi le "politiquement correct" me casse les couilles.
L'éditeur de lwn (fort respecté) a fait un article sur Ubuntu et parle de Debian qu'il utilise depuis longtemps :
http://lwn.net/Articles/107324/(...)
Debian has a lot of appeal. It is an excruciatingly free distribution characterized by a widely recognized technical excellence. It offers a variety of packages which is second to none and a package management system which is unequaled elsewhere. But Debian scares away a number of potential users. Its "stable" release is painfully out of date most of the time, the "unstable" release is rather too bleeding-edge for many users (while still being slow to pick up new releases at times), and the middle-of-the-road "testing" release seems to offer the worst of both "stable" and "unstable." The process of creating a new stable release looks chaotic, with no timeline for an actual release in sight. The community seems to spend rather too much time arguing about the free status of firmware and documentation and packaging up obscure tools and too little time simply creating a current distribution with a broader appeal. Debian is a great institution, but it worries a number of people.
Avec le temps, entre autre car Debian ne supporte pas amd64, l'éditeur de lwn est maintenant plustot porté sur Fedora (souvent sur les mailings).
[^] # Re: Drôle de surprise !
Posté par 007 . En réponse à la dépêche Sortie de la Debian Woody 3.0r3. Évalué à 1.
Et dernièrement j'ai vu un employé Red Hat dire que reiserfs rox et que c'est son FS préféré :-)
Néanmoins, Fedora est dirigé par Red Hat. Ce n'est pas un projet aussi communautaire que Debian.
[^] # Re: Migration Sourceforge
Posté par 007 . En réponse à la dépêche Sortie de la Debian Woody 3.0r3. Évalué à 1.
Pour un serveur simple (lamp), la stabilité est facile à atteindre. Il y a des tonnes de serveurs sous Mandrake/Fedora/gentoo/etc qui marchent parfaitement. Il ne faut pas 2 ans de maturation pour avoir quelque chose de fiable. Heureusement.
Il faut aussi dissocier stabilité et fiabilité. Pour un serveur en production qui marche, on veut de la stabilité. Par exemple, on ne veut pas passer de php3 à php4 du jour au lendemain car le distributeur ne supporte plus php3.
Pour un nouveau serveur, on veut la dernière technologie (car c'est mieux :-)) _et_ fiable.
Par exemple RHEL ou SuSE Enterprise sont stables (long support) _et_ fiables (t'en trouveras toujours pour gueuler...).
La difficulté est de définir une bonne période de sortie de nouvelle release. Si la fréquence est élevée alors que le support est long, il faut maintenir plusieurs branches en même temps et ça coûte cher (argent ou temps développeur). Si la fréquence est faible, il y a moins de boulot mais t'as souvent de vieux logiciels (comprendre pas performants, pas en mesure de répondre à un besoin, etc).
Red Hat et SuSE ont trouvé un bon compromis. Debian rame encore alors que c'est un vieu problème.
Au-delà de la période de sortie (qui peut être un simple choix), il y a la qualité, les fonctionnalités et le niveau de mise à jours d'une nouvelle distribution.
RHEL 4 va sûrement sortir en même temps que Sarge. La comparaison sera intéressante puisque les _produits_ ont les même objectifs (pour un usage serveur) et sont du logiciel libre. J'ai peur que Sarge fasse "has been" à côté d'une RHEL
OK, je sais, RHEL est cher et Debian gratuit. RHEL s'appuie sur le soutient "massif" d'employés qui doivent travailler dans une direction clairement précisée.
Il n'empêche que ça montre que Debian peut faire clairement mieux et que se réfugier systématiquement derrière la "stabilité" n'est pas suffisant pour justifier d'avoir des vieux logiciels.
Et oui, RHEL et SuSE Enterprise sont multi plateforme (moins que Debian) et oui toutes les plateformes sont disponibles en même temps.
Et non, RHEL et SuSE Enterprise ne tournent pas sur Arm ou m68k.
Sachant que Debian veut toujours fournir en même temps 11 architectures et des paquets par milliers (dont les deux tières sont d'un usage confidentiel), j'ai peur que Debian reste le "pire choix" pour du hardware commun. Par contre, c'est le meilleur choix pour du hardware "exotique".
[^] # Re: Drôle de surprise !
Posté par 007 . En réponse à la dépêche Sortie de la Debian Woody 3.0r3. Évalué à 1.
Pas Mandrake 10.1 !!!!!!!!!!!!!!!!!!!!!!!!
Je n'ai pas vu ça pour Mandrake 10.1 rc1.
Ce n'est pas activé par le paquet hotplug (il y a /etc/rc.d/init.d/hotplug):
$ rpm -q --scripts -p hotplug-2004_04_01-8mdk.i586.rpm
preinstall scriptlet (using /bin/sh):
if [ ! -L /usr/lib/hotplug ]; then
echo "Moving /usr/lib/hotplug to /lib/hotplug"
mkdir -p /lib/hotplug/
mv /usr/lib/hotplug/* /lib/hotplug/
rmdir /usr/lib/hotplug
cd /usr/lib/
ln -s ../../lib/hotplug hotplug
fi
postinstall scriptlet (using /bin/sh):
/usr/sbin/update-usb.usermap || :
Je ne vois pas de "chkconfig --add" ou "add-service".
Et pour SuSE 9.2, manifestement je ferais mieux de regarder moi même....
> Donc en clair, toutes les distrib utilisent modules.usbmap sauf RedHat...
PPsssssssssssssssssssss.
Cette obsession de la conspiration Red Hat... Red Hat pourri le libre, Red Hat le microsoft du libre, etc...
T'as prelink sur ta bécane ?
C'est Red Hat qui l'a fait.
T'as ext3 sur ta bécane ?
C'est Red Hat qui bosse le plus sur ext3 (c'est pas le seul)
T'as gamin (remplaçant de fam) ?
C'est Red Hat.
T'as nptl ?
C'est Red Hat.
T'as gcc ?
Red Hat fait 20 % minimum du boulot sur gcc.
T'as la libc ? oui forcément.
C'est Red Hat qui fait 40 % du boulot.
Nautilus ?
Le mainteneur est Red Hat.
Gtk+ ?
Le mainteneur est Red Hat.
Nash utilisé par Mandrake, c'est Red Hat.
Dbus ?
Red Hat en a fait une bonne partie.
PAM ?
Red Hat y a beaucoup bossé aussi.
Xorg ?
Red Hat a poussé pour son émergeance. Introduit au milieu du beta cycle de FC2.
etc...
Si Red Hat n'utilise pas /lib/modules/.../modules.usbmap, c'est leur affaire. Ça les regarde. On peut dire qu'ils ont tords. Mais les "sauf Red Hat..." et autre "RedHat/Fedora est maintenant une distribution à part, non standard et donc à éviter" sont au mieux tout simplement cons.
Red Hat n'a pas à être aux ordres de Debian ou attendre de Debian un accord pour faire quelque chose ! C'est claire ?
btw, Red Hat utilise modules.usbmap. modules.usbmap est généré par depmod avec les infos dans les modules.
> Pourrait tu nous eclairer sur ce qu'il se passe sous fedora alors?
Bonne question. J'ai donné une tendance de fond. Il semble (ce n'est pas facile à deviner car il y a une évolution rapide) que hotplug (userland) ne sera là "que" pour communiquer certains evènements noyau. Le chargement de module supplémentaire se fait/fera automatiquement. Chargement à la demande "classique" sera fait dans la grande majorité des cas. Udev soulève quelque problème et peut-être qu'a côté de ioctl("/dev/...") il y aura aussi ioctl((major, mineur)). C'est à hal (par exemple) avec les informations dans "/sys" et/ou "/proc" de monter la clée usb (le module sera automatiquement chargé à ce moment). Le nouveau module-init-tools a aussi un rôle central tout comme "/sys".
"/etc/dev.d" (utilisé par udev _après_ l'installation du modules et _après_ la création des fichiers spéciaux) sera utilisé pour configurer le matériel (restaurer le son, charger un firmware, par exemple).
Ceci dit, pour usb, je n'en sais pas beaucoup car je n'ai pas usb.
Pour FC3, tout (ou presque) est absolument standard de ce côté (sinon regarde les patchs dans les paquets). Dans un premier temps, Fedora ne voulait pas de udev dans FC3 (on l'a tous remarqué, il y a quelques problèmes pour le chargement à la demande). Le mainteneur de udev est venu défendre l'intérêt de udev sur la mailing Fedora. Un employé Red Hat a aussi défendu udev avec l'argument "massu" qu'il était facile de gérer 2000 disque dur avec (cas des gros serveurs). Finalement udev a trouvé son chemin sur le tard. Red Hat a _beaucoup_ bossé sur hal (en upstream) durant la phase de test de FC3.
Amuses toi à installer une FC3T1 puis une FC3 finale (toute proche) pour voir l'énorme différence et l'énorme boulot. FC3 finale aura les dernières version de udev (039) et hal (0.4.0). Sans travailler "main dans la main" avec les développeurs en upstream, ce n'est pas possible.
Pour finir : http://fedora.redhat.com/about/objectives.html(...)
3. Do as much of the development work as possible directly in the upstream packages. This includes updates; our default policy will be to upgrade to new versions for security as well as for bugfix and new feature update releases of packages.
5. Be on the leading edge of open source technology, by adopting and helping develop new features and version upgrades.
Non-Objectives of Fedora Core:
3. Being a dumping ground for unmaintained or poorly designed software.
Globalement c'est le cas.
[^] # Re: Drôle de surprise !
Posté par 007 . En réponse à la dépêche Sortie de la Debian Woody 3.0r3. Évalué à 1.
Tu ne serais pas en train de confondre avec kerneld ?
# Brevet
Posté par 007 . En réponse au journal Psacal Lamy persiste et signe. Évalué à 4.
Les brevets logiciels sont "abusifs", anti-concurrentiel, etc car ont peut breveter une idée.
Je ne crois pas que Pascal Lamy parle des brevets logiciels puisque "ça n'existent pas" (encore).
De plus Pascal Lamy est "social-libéral". Il est peu probable qu'il soit favorable aux brevets logiciels.
# kernelnewbies
Posté par 007 . En réponse au message Ecriture d'un module. Évalué à 1.
[^] # Re: Pour ceux...
Posté par 007 . En réponse à la dépêche Sortie de la Debian Woody 3.0r3. Évalué à 1.
Car beaucoup d'utilisateurs de Debian ne sont pas honnètes. Même unstable est stable quand tu les écoutes.
[^] # Re: Correction lien ? ou Correction drapeau?
Posté par 007 . En réponse à la dépêche Sortie de la Debian Woody 3.0r3. Évalué à 1.
[^] # Re: Drôle de surprise !
Posté par 007 . En réponse à la dépêche Sortie de la Debian Woody 3.0r3. Évalué à 2.
Non, ça été fait pour FC3 comme indiqué précédement (à cause de udev).
> Attention, la je rigole bien: "qui est le *coeur* d'hotplug", ah bon, /sbin/hotplug, un script de 6 lignes est le coeur de hotplug ?
D'accord, j'ai été rigolo.
Je disait au début :
$ cat /proc/sys/kernel/hotplug
/sbin/hotplug
Pour parler de ce qui est appelé par le noyau.
Toi tu me montres un truc appelé en userland (/etc/rc.d/init.d/hotplug).
> Mandrake, Debian, Suse, ... : Utilisation *complete* du projet hotplug pour la détection à chaud et au boot du matériel.
Non. Mandrake fait comme Red Hat (depuis la 10.1).
Pour SuSE, je ne sait pas.
> A chaud, le kernel appelle le script /sbin/hotplug avec en argument le bus ou il a détecté un nouveau materiel, /sbin/hotplug appelle ensuite /etc/hotplug/bus.rc
$ ll /etc/hotplug/bus.rc
ls: /etc/hotplug/bus.rc: Aucun fichier ou répertoire de ce type
De plus, hotplug appelé depuis le noyau n'utilise jamais /etc/hotplug/*.rc (ici en tout cas).
Ici /sbin/hotplut appelle que les fichiers :
DIR="/etc/hotplug.d"
for I in "${DIR}/$1/"*.hotplug "${DIR}/"default/*.hotplug ; do
J'ai :
$ find /etc/hotplug.d/ -iname "*.hotplug"
/etc/hotplug.d/default/05-wait_for_sysfs.hotplug
/etc/hotplug.d/default/10-udev.hotplug
/etc/hotplug.d/default/20-hal.hotplug
/etc/hotplug.d/default/default.hotplug
Puis default.hotplug appelle /etc/hotplug/AGENT.agent
Dans les fichiers /etc/hotplug/*.agent j'ai :
* /etc/hotplug/scsi.agent :
TYPE=$(cat $TYPE_ATTR)
case "$TYPE" in
# 2.5.51 style attributes; <scsi/scsi.h> TYPE_* constants
0) TYPE=disk ; MODULE=sd_mod ;;
# FIXME some tapes use 'osst' not 'st'
1) TYPE=tape ; MODULE=st ;;
2) TYPE=printer ;;
3) TYPE=processor ;;
4) TYPE=worm ; MODULE=sr_mod ;;
5) TYPE=cdrom ; MODULE=sr_mod ;;
6) TYPE=scanner ;;
7) TYPE=mod ; MODULE=sd_mod ;;
8) TYPE=changer ;;
9) TYPE=comm ;;
14) TYPE=enclosure ;;
esac
if [ "$MODULE" != "" ]; then
mesg "$TYPE at $DEVPATH"
modprobe $MODULE
else
Pas de détection matériel. Le noyau qui a lu le bus SCSI dit a hotplug qu'il y a un périphérique type printer, cdrom ou disk... Ce'est pas hotplug qui a "détecté" ça.
* /etc/hotplug/ieee1394.agent
# on 2.4 systems, modutils maintains MAP_CURRENT
if [ -r $MAP_CURRENT ]; then
load_drivers ieee1394 $MAP_CURRENT "$LABEL"
fi
pas de MAP_CURRENT sous Linux 2.6. C'est-à-dire avec module-init-tools. Mais Debian doit être avec modutils pour être compatible Linux 2.4 (comme je l'ai sous-entendu plus haut). Ça regarde Debian.
* /etc/hotplug/input.agent
if [ -r $MAP_CURRENT ]; then
load_drivers input $MAP_CURRENT "$LABEL"
fi
* /etc/hotplug/usb.agent :
# on 2.4 systems, modutils 2.4.2+ maintains MAP_CURRENT
# ... otherwise we can't rely on it (sigh)
case "$KERNEL" in
2.4.*|2.5.*|2.6.*)
if [ -r $MAP_CURRENT ]; then
load_drivers usb $MAP_CURRENT "$LABEL"
fi;;
*)
# cope with special driver module configurations
# (mostly HID devices, until we have an input.agent)
# not needed on 2.6 - they are loaded by hotplug
case "$KERNEL" in
2.6.* )
: nothing
;;
# some devices have user-mode drivers (no kernel module, but config)
# or specialized user-mode setup helpers
MODPROBE=:
for MAP in $MAP_USERMAP $HOTPLUG_DIR/usb/*.usermap
do
if [ -r $MAP ]; then
load_drivers usb $MAP "$LABEL"
$ ll /etc/hotplug/usb/*.usermap
ls: /etc/hotplug/usb/*.usermap: Aucun fichier ou répertoire de ce type
En gros sous Linux _2.6_, ça ne charge jamais de module. Sauf pour SCSI mais ce n'est pas de la détection matériel. C'est le noyau qui a fait la détection, puis le communique à hotplug pour configurer la matériel.
> Pour la détection au boot, c'est encore plus con, on appelle les scripts *.rc qui scannent chaque bus a la recherche du matos et ils chargent les modules de chaque matériel détecté(usb, pci, ...).
Sous Linux 2.4 et pour certain...
De plus, ce n'est pas du "hotplug" mais si le projet hotplug fournis les scripts.
> Redhat/Fedora: on fait bande a part, on prend ce qui nous interesse dans hotplug et on fait tout a notre sauce histoire d'etre bien incompatible avec le reste de la planete.
C'est du pure FUD. Renseigne toi 2 secondes. La méthode Debian, est la vieille méthode. De plus cette méthode "pue" car ça charge plein de modules pour rien.
Exemple de ma dernière expérience (catastrophique) Debian : ( http://linuxfr.org/~ehoebadoag/15279.html(...) )
Je regarde /proc/modules juste après le boot et j'ai 58 modules de chargé ! Je n'ai pas usb et pourtant il y a des modules usb de chargés, etc. Je comprend maintenant pourquoi on explique très tôt qu'il faut recompiler un noyau...
Ici j'ai 33 modules dont le réseau alors que j'avais pas le réseau sous debian (normal, je l'avais pas configuré). Dans ces 34, je retire sch_tbf, pppoatm, ppp_generic, atm, unicorn_pci_atm et dm_mod que je n'avais pas sous Debian et j'ai au final, 31 modules de trop sous Debian !
Tu trouves ça "moderne" ?
Fedora applique la nouvelle méthode. Hotplug sert à communiquer et configurer le matériel. Pas à le détecter. C'est le noyau qui doit détecter le matériel (sans charger les modules). C'est aux autres applis (donc hald qui va prendre une place de plus en plus importante) d'utiliser ces informations pour, pourquoi pas, charger un module.
Debian est _toujours_ en retard.
Ce que fait Debian, n'est pas la référence.
[^] # Re: Drôle de surprise !
Posté par 007 . En réponse à la dépêche Sortie de la Debian Woody 3.0r3. Évalué à 0.
Moi j'en teste plein et je les trouve toutes bonnes.
[^] # Re: Drôle de surprise !
Posté par 007 . En réponse à la dépêche Sortie de la Debian Woody 3.0r3. Évalué à 1.
Mandrake a sa version stable et une branche de développement (cooker).
La branche de développement peut exploser "grave" à tout moment. Elle a seulement pour but de sortir une branche stable de temps à autre.
Mandrake s'impose des contraintes de temps.
Mandrake sort une release stable pour i386 en premier et fait le portage des autres archs après.
Mandrake se concentre sur son "noyau" (3 cd).
Debian sorte une nouvelle release "quand ils le sentent".
Dans Debian il y a : stable, testing, unstable, experimental, backport.
La branche testing est sensé être utilisable à tout moment.
Debian sort 11 archs en même temps.
Debian sort une distribution avec tout (10 cd).
Bref, c'est vraiment différent.
[^] # Re: Drôle de surprise !
Posté par 007 . En réponse à la dépêche Sortie de la Debian Woody 3.0r3. Évalué à 0.
Tu peux répéter stp ?
[^] # Re: Impressionnant !
Posté par 007 . En réponse à la dépêche « Autocompiler » son noyau au démarrage avec TCCBoot. Évalué à 1.
Ooops :
Les sources dans l'image font : 399 742 lignes (251 fichiers ".c")
[^] # Re: Impressionnant !
Posté par 007 . En réponse à la dépêche « Autocompiler » son noyau au démarrage avec TCCBoot. Évalué à 2.
J'ai été claire (il me semble).
La différence c'est que les autres disent qu'il est normal de compiler un noyau "classique" en 15 secondes et n'ont pas à le prouver.
Moi je dois prouver noir sur blanc que ce n'est pas possible alors que c'est évident.
Cherchez l'erreur.
[^] # Re: Impressionnant !
Posté par 007 . En réponse à la dépêche « Autocompiler » son noyau au démarrage avec TCCBoot. Évalué à 4.
Où tu vois ça ?
Je dis qu'il ne faut pas 15 secondes pour compiler un noyau linux classique.
Je suis sûr que TCC ne fait pas ça.
L'image initrd décompressée avec les sources linux à compiler fait 18Mo (compilateur compris) ! Linux en fait 10 fois plus.
Les sources dans l'image font : 399 742 (251 fichiers ".c")
Linux 2.6.9 (non, je ne vais pas downloader le 2.4.18 pour ça) : 6 463 002 (6841 fichiers ".c")
Le README :
http://fabrice.bellard.free.fr/tcc/tccboot_readme.html(...)
For your information, the patch 'linux-2.4.26-tcc.patch' gives the
necessary modifications to build a Linux kernel with TCCBOOT (NOTE: it
is not suffisant to build the kernel with its own Makefiles - I never
tried)
Voilà comment est compilé le noyau :
# This file contains the TinyCC command line arguments needed to
# produce the kernel.
# the output binary (DO NOT CHANGE IT)
-o kernel
# LDFLAGS
-nostdlib -static -Wl,-Ttext,c0100000 -Wl,--oformat,binary
# CFLAGS
-D__KERNEL__ -nostdinc -Iusr/local/lib/tcc/include -Iusr/src/linux/include
-D__GNUC__=2 -D__GNUC_MINOR__=95 -D__OPTIMIZE__ -fno-common
# sources files
usr/src/linux/tcc/kstart.S
usr/src/linux/arch/i386/kernel/head.S
usr/src/linux/arch/i386/kernel/init_task.c
...
Pas de dépendances, etc...
Je ne critique pas son boulot _ni_ ne remets en cause ses chiffres, _ni_ sont exploit !
Par contre l'interprétation de certains "Super, je vais pouvoir compiler mon noyau en 15 seconde avec TinyCC" m'énerve.
C'est chiant de devoir toujours se justifier pour des trucs aussi évidents.
[^] # Re: Impressionnant !
Posté par 007 . En réponse à la dépêche « Autocompiler » son noyau au démarrage avec TCCBoot. Évalué à -2.
Compilation speed for the Links Browser project. There are 76936 lines (including headers). 1632659 lines (57.9 MBytes) are compiled because the same headers are included in many files.
Notes que _tout_ tient dans le cache.
Ça doit beaucoup jouer sur le temps de chargement de gcc.
Le 4.8 Mo/s est en tenant compte de la _relecture_ des entêtes.
Soit (sans compter la relecture des headers) : 0.226 Mo/s (beau score) !
Pour Linux (en imaginant qu'on peut extrapoler car Linux est beaucoup plus complexe que links) à ce rythme, il faut 867 secondes (14 minutes et 27 secondes).
Je ne critique pas TCC, c'est peut-être un truc super. Mais il ne faut pas "n'importe quoi".
[^] # Re: Impressionnant !
Posté par 007 . En réponse à la dépêche « Autocompiler » son noyau au démarrage avec TCCBoot. Évalué à -4.
Pour un noyau "classique" comme c'est indiqué ?
Mon vmlinuz (compressé) "classique" (de la distribution) fait 1.4 Mo et j'ai 31 Mo de modules.
Mon vmlinuz au petit oignons fait 930 Ko et j'ai 2.5 Mo de modules. 15 secondes pour mon noyau customiser, je n'y crois pas 0,0002 quart de seconde.
Arrêter les cigarettes qui font rire.
[^] # Re: Impressionnant !
Posté par 007 . En réponse à la dépêche « Autocompiler » son noyau au démarrage avec TCCBoot. Évalué à -5.
Un noyau classique... C'est celà oouuiii...
> TCCBOOT is only 138 KB big (uncompressed code)
Ben ici le tar décompressé de Linux 2.6.9 fait 196 Mo ! Plus de mille fois plus.
Rien que pour lire l'archive (un gros fichier et pas des milliers de fichier) en 15 seconde il faut la "bouffer" à plus de 10 Mo/s.
[^] # Re: Drôle de surprise !
Posté par 007 . En réponse à la dépêche Sortie de la Debian Woody 3.0r3. Évalué à 0.
Certe, il parait que DOS est encore beaucoup utilisé pour la même raison.
> Ce qui ne semble pas être le cas des utilisateurs des autres distri vu qu'ils passent leur temps à essayer autres choses.
Et tu crois qu'ils n'ont pas essayé Debian ?
Pour toi il y a deux catégories :
- ceux qui utilisent Debian et qui sont contents.
- ceux qui testent tout _sauf_ Debian et qui ne sont pas contents.
[^] # Re: Vive le C !!
Posté par 007 . En réponse à la dépêche « Autocompiler » son noyau au démarrage avec TCCBoot. Évalué à 0.
# CD live ?
Posté par 007 . En réponse à la dépêche « Autocompiler » son noyau au démarrage avec TCCBoot. Évalué à 8.
[^] # Re: Interface de ce site
Posté par 007 . En réponse au journal FC3rc2. Évalué à 1.
On fait une usine à gaz.
[^] # Re: Correction lien ? ou Correction drapeau?
Posté par 007 . En réponse à la dépêche Sortie de la Debian Woody 3.0r3. Évalué à 1.
Ou de moi, j'en sais rien.