Ça fait toujours plaisir de voir un programme windows se libérer, mais de là à envisager le portage pour linux, je suis pas sûr que ça ait un intérêt. Y'a déjà pas mal de soft similaires sous linux. Par contre tous ceux que je connais ne savent rapatrier leur info que depuis IMDB, donc les scripts pour les autres sources du web eux sont clairement intérressants à récupérer pour les compléter.
Vu les méthodes de SCO et de Microsoft, on peut espérer une plainte contre Eric S. Raymond pour publication d'une correspondance privée sans autorisation. C'est vrai quoi, pour qui il se prend, il est même pas journaliste, allez messieurs les avocats, un peu de nerf. Et comme ça au moins on saura que l'email était authentique. :p
Est-ce que vous savez si le xdm (ou autre gdm/kdm) fait partie des services démarrés en parallèle au reste ? Car c'est un morceau non négligeable du temps de boot, mais pas si facile que ça à démarrer en avance puisqu'il a tendance à se coller sur la première console disponible au lieu de la traditionnelle 7ème si on le démarre avant que init ait fini son taf et lancé les getty.
Sous gentoo ça fait longtemps que le démarrage des services est parallélisé en fait (dans les limites imposées par les dépendances inter-services bien sûr, je suppose que là le "raisonnablement" ça doit être ça qu'il impose aussi), mais celui là ne l'étant pas, ça fait perdre un peu de son intérêt à la chose pour les machines de bureau (càd celle pour lesquelles le temps de boot est, un tout petit peu, important), donc voilà, c'est pour ça que je me demandais, histoire de savoir si c'est effectivement insoluble ou non.
> j'achéterais l'official en dvd pour faire mes tournées d'évangelisation sans avoir
> à faire des mises à jour pour des bugs comme celui des menus chaotiques dans
> la 9.2.
Bah y'a pas déjà eu les RC pour virer ce type de gros bug ?
Grub ne permet pas d'avoir un splash screen d'origine, mais y'a un patch (d'origine Suse je crois) qui traine et que pas mal de distribs utilisent dans leur paquets. Je pense pas qu'il fasse du 1280x1024 ceci dit, ça doit plutôt être du VGA, mais enfin bon on s'en fout.
> En effet, que se passera t'il si on bouge entre 2 versions de kernel avec des
> changements dans les devices? on chage udev et le config file à chaque
> boot?
Je ne comprends sincèrement pas à quel problème tu pense. Est-ce que tu peux concrétiser, même avec un exemple bidon stp ?
> Par example, sur Digital unix, il y a un système basé sur une minibase de
> donnée. dès qu'un nouveau device est détecté, le devfs équivalent recherche
> l'identité de ce périphérique dans cette minibase. S'il est trouvé (ex: un disque
> SCSI avec un serial number de 2423SSS-UX auquel est assigné le device
> /dev/hde) on met l'inode hde dans le /dev virtuel. Si ce périphérique n'est pas
> trouvé dans la base, on mémorise son identité et on lui donne un device libre
> (example: /dev/hdf).
C'est pas une mauvaise, rien ne t'empêche d'implémenter cette politique de nommage dans un petit script appelé par une règle udev. C'est tout l'intérêt d'avoir déporté cette gestion des noms en userspace : ça ouvre plein de possibilités. Le fichier de conf par défaut reprenant un nommage standard est un simple exemple, fait pour nous laisser en terrain connu, mais ils y a clairement mieux à faire. Là je crois que c'est maintenant plus aux distributions de faire leur boulot pour rendre les choses plus conviviales, elles en ont enfin la possibilité.
Sur ce topic de rendre les choses conviviales, cf aussi ce qui se prépare du côté de freedesktop autour de hotplug/udev/dbus. Par exemple les slides de Robert Love au dernier Fosdem : http://tech9.net/rml/talks/rml_fosdem_2004.sxi(...)
> En ajoutant udevfs, ce sera encore pire, car on va rajouter des crottes dans
> /dev et je ne sais pas comment on va faire le ménage.
J'ai actuellement 140 noeuds dans mon /dev, dont 64 pour les consoles virtuelles. C'est largement moins que ce que j'ai pu voir par le passé, et ça n'est (sauf les fameuses consoles virtuelles, mais bon, je pourrais baisser leur nombre dans le noyau) que des devices utiles. Mais où sont les crottes ? :)
> Donc si on fait modprobe raw1394 et qu'on l'utilise avec le camescope
> connecté, pour quoi ne pas rajouter un mécanisme qui se souvient que pour
> ce périphérique, on voulait aussi raw1394 (hope dans la base).
S'en "souvenir", moi je suis contre sans hésiter. J'ai aucune envie quand je teste un module de me le trainer après à chaque fois que je reviens dans un contexte similaire et d'avoir à bidouiller pour forcer l'oubli de la chose, merci. Par contre donner la possibilité de le spécifier quelque part, oui, ça parait utile. Ça peut se rajouter facilement à la main dans le handler firewire de hotplug, mais c'est pas très user friendly. Ça peut aussi se rajouter dans un script appelé depuis la règle udev qui match le dit caméscope, c'est sûrement le plus simple, reste à savoir si c'est propre. Y'a sûrement effectivement une méthode plus standard à inventer, mais de toute façon maintenant techniquement l'infrastructure est là pour la mettre en place sans problème. (Ça pourrait aussi être fait par une appli/démon qui gère ça en réagissant à un évenement dbus "caméscope branché".)
1/ Un problème cependant, c'est que Guy Nègre promet une démo aux journalistes depuis des mois et des mois et que personnes n'a toujours rien vu venir...
Et pourtant il parait que c'est bien réel, je crois même qu'en fait il comprime son vent avec i2bp.
Pas la peine de prendre les autres pour des abrutis.
Ça n'est pas la peine de me prêter des intentions que je n'ai pas. Le monsieur là-haut, il a l'air d'avoir une grosse dent contre udev, je n'ai jamais pensé que ça faisait de lui un abruti pour autant. Mais il aligne plusieures critiques majeures d'udev sans la moindre argumentation, c'est un post d'humeur, c'est pas grave on en fait tous parfois, mais c'est effectivement pas ceux qui attirent les réponses les plus sympathiques. En l'occurence, je me trouvais plutôt modéré sur ce coup là, fait chier, faut croire que c'est pas encore ça.
Pour le support de LVM, j'ai essayé un peu (enfin LVM2), et j'avais eu à créer le /dev/mapper/control à la main. Je dis pas que 100% des devices peuvent être créés par udev. Déjà, y'en a qui n'exportent rien dans /sys/ (genre les drivers nvidia sans le bon patch), donc là c'est mal barré, y'en a aussi dont on peut avoir besoin avant même d'avoir lancé udev (genre /dev/null), etc. Mais simplement, ça n'enlève rien à udev, et ça n'empêche absolument pas de l'utiliser de façon pleinement fonctionnelle comme remplacement de devfs. Par contre, c'est clair que ça demande un peu plus de travail sur les scripts d'init que devfs, donc si vous êtes justement là dedans, effectivement, ça peut apparaître comme une certaine régression sur le coup.
Pour ce qui est de la boucle de population du /dev/, bah... c'est quoi le problème de faire une boucle d'appel d'un aussi petit programme ? On fait ça tous les jours dans n'importe quel script shell, non ? Ici sur un portable 1,3 GHz la boucle s'execute en 0,28 secondes pour 112 itérations. Que ça puisse monter à qlqs secondes chez vous, ça me parait beaucoup, mais c'est effectivement pas impossible. Ceci dit, on s'en fout un peu, ça n'arrive qu'au boot, enfin bon, je trouve pas que l'argument pèse bien lourd. C'est pour ça que je voulais m'assurer que c'était bien là la lenteur désignée (parceque dans plusieurs trolls on peut lire en gros "udev c'est user-space donc ça va ramer d'accéder au devices", ce qui est bien sûr totalement absurde).
Tu peux créer le noeud qui va bien à la mimine dans un script d'init par exemple. Ça ne pose pas de pb d'avoir des noeuds qui n'ont pas été générés par udev, et le noyau lui est bien sûr toujours capable de faire du chargement de module au besoin. Bref tu reviens, pour ce périphérique particulier, à la situation d'avant devfs. Là, udev, n'est tout simplement pas concerné en fait.
Le truc que devfs/devfsd savaient faire et que udev ne fait pas, c'était l'auto-chargement-et-création pour des noeuds qui n'existaient pas encore : tu pouvais avoir une règle pour dire «si on essaye d'accéder à un dénommé /dev/zip, alors charge le module machin, et fait un lien de /dev/zip vers /dev/scsi/truc». (Donc le chargement systématique du module comme tu le décris n'était pas nécéssaire en fait.)
Quand tu branches ce type de périph, hotplug réveille udev pour que ce dernier crée le/les nodes et symlinks dans ton répertoire des périphériques. Après, ce que fait udev dépend de ta config. Tu peux te contenter d'une config par défaut immitant le nommage de feu devfs (-> "/dev/sdX" + des trucs dans "/dev/scsi/..." + des trucs dans "/dev/usb/..."), ou bien spécifier des règles plus particulière, par exemple en fonction des numéros de série de tes clefs usb, et avoir donc un node "sesame" pour l'une et "deschamps" pour une autre. Bref, tu gères un peu comme tu veux. Tu spécifies aussi tes permissions bien sûr. Y'a qlqs exemples assez représentatifs dans le fichier de conf par défaut, qui montrent la souplesse de la chose. Faut bien voir que udev peut appeler des scripts externes au sein des règles, donc y'a moyen de faire des trucs vraiment rigolos (je me souviens d'avoir vu passer sur la lkml un script utilisant freedb pour créer un nom de dvice device /dev/artiste/album quand tu inserais un cd audio...).
> Je vais jeter un oeil sur udev avec intérêt, en espérant qu'il ne soit pas trop
> difficile de faire le changement
Ça dépend fortement de la distrib' utilisée. Par expérience, je peux dire que ça se fait très bien sous Gentoo, et par lecture à droite à gauche que ça n'est pas un problème sous Fedora. À part ça, je sais pas, ce serait intérressant que des utilisateurs d'autres distribs se manifestent.
Il utilise hotplug. Le PCI Hotplug, c'est autre chose, c'est pour gérer le branchement à chaud de périphériques PCI, et ça effectivement c'est expérimental, mais ça n'est pas du tout nécéssaire pour utiliser udev.
À part ça, effectivement, le support de udev sous Gentoo est très bon. Azarah qui maintiens ça a d'ailleurs contribué régulièrement au développement de udev à mesure qu'il rencontrait de nouveaux problèmes, et Greg KH lui rôde maintenant sur gentoo-dev et bugs.gentoo.org et aide à fignoler les choses. Bref, un échange fructueux.
> udev est censé le gérer
Pourquoi "censé" ? Il le gère tout court, d'où nous vient ce bémol ?
> il gére les device directement dans le système de fichier racine
Il gère les devices où tu veux. Perso je les mets dans un répertoire /dev où est monté un ramfs.
> ça prend de la place
Gné ?
> c'est lent
C'est lent à faire quoi ? Tu as des chiffres ?
> même pas foutu de créer TOUT les devices nécessaire
Mince, moi qui croyait que mon système fonctionnait très bien, en fait je dois rêver.
Enfin bref, tout ça pour dire que j'ai bien du mal à trouver tes "100 000 lieues", et que je ne vois là qu'un gros troll fudesque. Ce serait pas mal de développer un peu là si tu as vraiment des arguments à nous faire partager.
Posté par tgl .
En réponse à la dépêche Gentoo 2004.0.
Évalué à 2.
Ça doit pouvoir être encore plus facile avec l'ebuild de Sleeper (développeur du driver, gentooiste, et hotliner officiel du forum sur les questions relatives à ce modem :)) : http://forums.gentoo.org/viewtopic.php?t=137649(...)
Posté par tgl .
En réponse à la dépêche Gentoo 2004.0.
Évalué à 2.
C'est faux. Gentoo ne fait aucune distinction libre / non libre, elle se contente de respecter les clauses particulières de certaines licences. Quand y'a pas le droit de redistribuer, on renvoie à un téléchargement manuel, et quand il faut explicitement accepter une licence au cours d'une licence, on prompt l'utilisateur, etc. Mais il y a plein de paquet non libres qu'y n'imposent pas pour autant ce genre de restrictions, et qui donc s'installent de façon aussi transparente que les autres. Certains simplement quand on les demandent (au hasard, Adobe Acroread), d'autre même sous forme de dépendance (divx pour les x86 en dépendance de certaines applis video - l'exemple de mon post juste au dessus).
Posté par tgl .
En réponse à la dépêche Gentoo 2004.0.
Évalué à 1.
> Attribution du copyright (sans le sens "c'est moi l'auteur") à Gentoo: illégal en
> France et en Allemagne et probablement ailleurs aussi.
Oui mais l'attribution d'un copyright à personne morale malgré le fait qu'elle n'ait pas de main pour taper le texte/code est bien autorisé non ? Les pages web des sociétés sont copyrightée par les sociétés et pas par le/la secrétaire qui l'a remplie en général, et souvent pareil pour le code qui n'est pas réparti entre les développeurs individuels mais regroupé sous l'égide de la société qui les emploie. Non ? Enfin je pose la question hein, parceque ta remarque m'interpelle... Tu pourrais déveloper un peu si tu as le temps ? Merci.
Posté par tgl .
En réponse à la dépêche Gentoo 2004.0.
Évalué à 2.
Etant donné que j'ai poster la dépêche hier, la version est disponnible depuis la 28/02 mais l'annonce a bien été faite hier : voir www.gentoo.org et la newsletter d'hier.
Hier en début de soirée quand la news a été publier, il n'y avait pas encore d'annonce sur le site de gentoo, et pour la bonne raison que c'était trop tôt pour être annoncé parceque pas près.
Apres être à un jour près... un site d'information n'est valable que si les news sont "fraiche" et que l'on ne la pas deja lu ailleur, (un jour ou deux ne vont pas changer grand chose étant donné que d'autres sites auront publiés la news).
À mon avis ça aurait été encore frais aujoud'hui. On va pas se mettre à jouer le jeux des agences de presse et journaux télévisés qui font primer l'immediateté de leurs "scoops" sur l'intérêt et la volonté des intérressés, sous prétexte de dure loi de la concurrence.
Posté par tgl .
En réponse à la dépêche Gentoo 2004.0.
Évalué à 3.
Quand le contrat social dit que gentoo ne dependra jamais de soft proprio, ça veut dire:
- que les paquets de base (ceux de la classe "system") sont libres. Ça c'est facile à vérifier, et ça l'est d'ailleurs systématiquement. Le problème s'est posé une fois ou le USE flag "java" était activé par défaut dans le profile, et ou du coup un paquet de système (db je crois, mais je peux me gourrer) s'est mis à dépendre d'une jvm non libre. Ça avait été détecté et corrigé très vite. Là dessus ils font gaffe, après, le reste, pour l'instant c'est toi qui gère comme tu veux/peux.
- que l'infrastructure de Gentoo repose uniquement sur du libre. Ça ça a été discuté au moins à deux reprises, une fois pour le logiciel du forum, et la conclusion a été qu'il fallait rester en phpBB parceque c'était le moins pire des trucs libres, et une fois pour le gestionnaire de version pour portage, ou l'utilisation de BitKeeper (il me semble, mais la encore je peux me gourrer, enfin bref d'un truc pas libre) avait été envisagée en remplacement de CVS, et ça a été vite écarté pour la même raison.
Après, effectivement, on peut se retrouver pour l'instant avec du proprio sans faire gaffe. Il suffit par exemple d'installer mplayer sur un x86, on activera alors une dépendance sur un codec divx proprio. Ça, ça sux, je suis d'accord, mais c'est pas une violation du contrat social pour autant.
Posté par tgl .
En réponse à la dépêche Gentoo 2004.0.
Évalué à 4.
Ça ne le fait pas pour beaucoup de licences en fait. Pour les machins d'idsoftware, ça a été rajouté parceque idsoftware l'a explicitement demandé (enfin, parcequ'ils aimaient pas l'ancien mode d'installation qui acceptait systématiquement la licence, et que ça a été trouvé comme compromis). Mais:
- pour pas mal de soft proprios, le téléchargement manuel est requis, et c'est sur le site web qu'est présentée la licence. (par exemple les jdk de sun)
- il est très vraisemblable que soit intégré à une version prochaine de portage la gestion d'une variable de type ACCEPTED_LICENSES, ou qqch comme ça, pour déclarer ce que l'on accepte (en détail ou en s'aidant de groupes de type OSI_approved, GPL_compatible, etc.). L'idée à fait son chemin, y'a eu des patchs, après, bon bah, les changement dans portage faut toujours pousser longtemps dessus pour qu'ils aboutissent quoi... Le problème par contre est que le champs LICENSE de nombreux ebuilds est ambigüe quand il y a de multiples licences applicables : des opérateurs booléens pour dire si c'est plutôt un choix ou bien plusieurs licences pour différents bouts de code existent bien, mais ils n'ont jamais été utilisés avec rigueur puisque cette variable n'était pas exploitée jusqu'ici. Donc y'a pas mal de truc du genre LICENSE="MPL-1.1 NPL-1.1" sans qu'on sache s'il s'agit d'une conjonction ou d'une disjonction.
Posté par tgl .
En réponse à la dépêche Gentoo 2004.0.
Évalué à 9.
Serait-il possible, de la part des modérateurs comme des posteurs, d'essayer les annonces officielles avant de publier ce genre de niouzes ? En l'occurence, celle ci est parue alors que les mirroirs n'étaient pas près du tout. La ruée sur les premières isos disponibles rendent difficile la bonne distribution de l'ensemble de la release, et c'est d'autant plus ballot que la plupart des gens vont de toute façon remettre ça demain pour remplacer leur version x86 générique d'aujourd'hui par une version pentium truc ou athlon machin. Et puis d'attendre l'annonce, ça permet d'avoir du contenu avec de l'information dedans et tout et tout, le genre changelog du livecd, tout ça quoi... On n'est pas à un jour près, si ? Enfin bon, voilà, mon petit bémol, vous en faites ce que vous voulez.
# Re: Quel est le(s) nom(s) de votre(vos) machine(s) ?
Posté par tgl . En réponse au journal Quel est le(s) nom(s) de votre(vos) machine(s) ?. Évalué à 1.
# Re: Ant Movie Catalog passe en GPL
Posté par tgl . En réponse à la dépêche Ant Movie Catalog passe en GPL. Évalué à -1.
# Re: Nouveau memo Halloween - SCO attaque
Posté par tgl . En réponse à la dépêche Nouveau memo Halloween - SCO attaque. Évalué à 10.
[^] # Re: Release Note
Posté par tgl . En réponse à la dépêche Mandrake Linux 10.0 Community disponible au téléchargement. Évalué à 2.
Sous gentoo ça fait longtemps que le démarrage des services est parallélisé en fait (dans les limites imposées par les dépendances inter-services bien sûr, je suppose que là le "raisonnablement" ça doit être ça qu'il impose aussi), mais celui là ne l'étant pas, ça fait perdre un peu de son intérêt à la chose pour les machines de bureau (càd celle pour lesquelles le temps de boot est, un tout petit peu, important), donc voilà, c'est pour ça que je me demandais, histoire de savoir si c'est effectivement insoluble ou non.
[^] # Re: Mandrake Linux 10.0 Community est lancée !
Posté par tgl . En réponse à la dépêche Mandrake Linux 10.0 Community disponible au téléchargement. Évalué à 2.
Je n'ai aucun mérite, cette histoire est une si belle perche...
[^] # Re: Mandrake Linux 10.0 Community est lancée !
Posté par tgl . En réponse à la dépêche Mandrake Linux 10.0 Community disponible au téléchargement. Évalué à 3.
> à faire des mises à jour pour des bugs comme celui des menus chaotiques dans
> la 9.2.
Bah y'a pas déjà eu les RC pour virer ce type de gros bug ?
...pompopom... []
[^] # Re: Comment ça se passe avec chroot?
Posté par tgl . En réponse à la dépêche Udev atteint la maturité. Évalué à 1.
[^] # Re: Et on réinvente ocre la roue carré alors que d'autres ont déjà la roue ronde.....
Posté par tgl . En réponse à la dépêche Udev atteint la maturité. Évalué à 3.
> changements dans les devices? on chage udev et le config file à chaque
> boot?
Je ne comprends sincèrement pas à quel problème tu pense. Est-ce que tu peux concrétiser, même avec un exemple bidon stp ?
> Par example, sur Digital unix, il y a un système basé sur une minibase de
> donnée. dès qu'un nouveau device est détecté, le devfs équivalent recherche
> l'identité de ce périphérique dans cette minibase. S'il est trouvé (ex: un disque
> SCSI avec un serial number de 2423SSS-UX auquel est assigné le device
> /dev/hde) on met l'inode hde dans le /dev virtuel. Si ce périphérique n'est pas
> trouvé dans la base, on mémorise son identité et on lui donne un device libre
> (example: /dev/hdf).
C'est pas une mauvaise, rien ne t'empêche d'implémenter cette politique de nommage dans un petit script appelé par une règle udev. C'est tout l'intérêt d'avoir déporté cette gestion des noms en userspace : ça ouvre plein de possibilités. Le fichier de conf par défaut reprenant un nommage standard est un simple exemple, fait pour nous laisser en terrain connu, mais ils y a clairement mieux à faire. Là je crois que c'est maintenant plus aux distributions de faire leur boulot pour rendre les choses plus conviviales, elles en ont enfin la possibilité.
Sur ce topic de rendre les choses conviviales, cf aussi ce qui se prépare du côté de freedesktop autour de hotplug/udev/dbus. Par exemple les slides de Robert Love au dernier Fosdem : http://tech9.net/rml/talks/rml_fosdem_2004.sxi(...)
> En ajoutant udevfs, ce sera encore pire, car on va rajouter des crottes dans
> /dev et je ne sais pas comment on va faire le ménage.
J'ai actuellement 140 noeuds dans mon /dev, dont 64 pour les consoles virtuelles. C'est largement moins que ce que j'ai pu voir par le passé, et ça n'est (sauf les fameuses consoles virtuelles, mais bon, je pourrais baisser leur nombre dans le noyau) que des devices utiles. Mais où sont les crottes ? :)
> Donc si on fait modprobe raw1394 et qu'on l'utilise avec le camescope
> connecté, pour quoi ne pas rajouter un mécanisme qui se souvient que pour
> ce périphérique, on voulait aussi raw1394 (hope dans la base).
S'en "souvenir", moi je suis contre sans hésiter. J'ai aucune envie quand je teste un module de me le trainer après à chaque fois que je reviens dans un contexte similaire et d'avoir à bidouiller pour forcer l'oubli de la chose, merci. Par contre donner la possibilité de le spécifier quelque part, oui, ça parait utile. Ça peut se rajouter facilement à la main dans le handler firewire de hotplug, mais c'est pas très user friendly. Ça peut aussi se rajouter dans un script appelé depuis la règle udev qui match le dit caméscope, c'est sûrement le plus simple, reste à savoir si c'est propre. Y'a sûrement effectivement une méthode plus standard à inventer, mais de toute façon maintenant techniquement l'infrastructure est là pour la mettre en place sans problème. (Ça pourrait aussi être fait par une appli/démon qui gère ça en réagissant à un évenement dbus "caméscope branché".)
[^] # Re: Après le biodiesel : le moteur à air comprimé
Posté par tgl . En réponse au journal Après le biodiesel : le moteur à air comprimé. Évalué à 2.
Et pourtant il parait que c'est bien réel, je crois même qu'en fait il comprime son vent avec i2bp.
...pom popom... []
# Re: Udev atteint la maturité
Posté par tgl . En réponse à la dépêche Udev atteint la maturité. Évalué à 2.
http://webpages.charter.net/decibelshelp/LinuxHelp_UDEVPrimer.html(...)
http://www.reactivated.net/udevrules.php(...)
http://www.gentoo.org/doc/en/udev-guide.xml(...)
[^] # Re: Udev atteint la maturité
Posté par tgl . En réponse à la dépêche Udev atteint la maturité. Évalué à 8.
Ça n'est pas la peine de me prêter des intentions que je n'ai pas. Le monsieur là-haut, il a l'air d'avoir une grosse dent contre udev, je n'ai jamais pensé que ça faisait de lui un abruti pour autant. Mais il aligne plusieures critiques majeures d'udev sans la moindre argumentation, c'est un post d'humeur, c'est pas grave on en fait tous parfois, mais c'est effectivement pas ceux qui attirent les réponses les plus sympathiques. En l'occurence, je me trouvais plutôt modéré sur ce coup là, fait chier, faut croire que c'est pas encore ça.
Pour le support de LVM, j'ai essayé un peu (enfin LVM2), et j'avais eu à créer le /dev/mapper/control à la main. Je dis pas que 100% des devices peuvent être créés par udev. Déjà, y'en a qui n'exportent rien dans /sys/ (genre les drivers nvidia sans le bon patch), donc là c'est mal barré, y'en a aussi dont on peut avoir besoin avant même d'avoir lancé udev (genre /dev/null), etc. Mais simplement, ça n'enlève rien à udev, et ça n'empêche absolument pas de l'utiliser de façon pleinement fonctionnelle comme remplacement de devfs. Par contre, c'est clair que ça demande un peu plus de travail sur les scripts d'init que devfs, donc si vous êtes justement là dedans, effectivement, ça peut apparaître comme une certaine régression sur le coup.
Pour ce qui est de la boucle de population du /dev/, bah... c'est quoi le problème de faire une boucle d'appel d'un aussi petit programme ? On fait ça tous les jours dans n'importe quel script shell, non ? Ici sur un portable 1,3 GHz la boucle s'execute en 0,28 secondes pour 112 itérations. Que ça puisse monter à qlqs secondes chez vous, ça me parait beaucoup, mais c'est effectivement pas impossible. Ceci dit, on s'en fout un peu, ça n'arrive qu'au boot, enfin bon, je trouve pas que l'argument pèse bien lourd. C'est pour ça que je voulais m'assurer que c'était bien là la lenteur désignée (parceque dans plusieurs trolls on peut lire en gros "udev c'est user-space donc ça va ramer d'accéder au devices", ce qui est bien sûr totalement absurde).
Bon courage pour passer le cap irritant.
[^] # Re: Udev atteint la maturité
Posté par tgl . En réponse à la dépêche Udev atteint la maturité. Évalué à 3.
Le truc que devfs/devfsd savaient faire et que udev ne fait pas, c'était l'auto-chargement-et-création pour des noeuds qui n'existaient pas encore : tu pouvais avoir une règle pour dire «si on essaye d'accéder à un dénommé /dev/zip, alors charge le module machin, et fait un lien de /dev/zip vers /dev/scsi/truc». (Donc le chargement systématique du module comme tu le décris n'était pas nécéssaire en fait.)
[^] # Re: Maturité de devfs
Posté par tgl . En réponse à la dépêche Udev atteint la maturité. Évalué à 5.
[^] # Re: Maturité de devfs
Posté par tgl . En réponse à la dépêche Udev atteint la maturité. Évalué à 3.
> difficile de faire le changement
Ça dépend fortement de la distrib' utilisée. Par expérience, je peux dire que ça se fait très bien sous Gentoo, et par lecture à droite à gauche que ça n'est pas un problème sous Fedora. À part ça, je sais pas, ce serait intérressant que des utilisateurs d'autres distribs se manifestent.
[^] # Re: devfs est déclaré obsolète dans le kernel 2.6.
Posté par tgl . En réponse à la dépêche Udev atteint la maturité. Évalué à 1.
[^] # Re: devfs est déclaré obsolète dans le kernel 2.6.
Posté par tgl . En réponse à la dépêche Udev atteint la maturité. Évalué à 8.
À part ça, effectivement, le support de udev sous Gentoo est très bon. Azarah qui maintiens ça a d'ailleurs contribué régulièrement au développement de udev à mesure qu'il rencontrait de nouveaux problèmes, et Greg KH lui rôde maintenant sur gentoo-dev et bugs.gentoo.org et aide à fignoler les choses. Bref, un échange fructueux.
[^] # Re: Udev atteint la maturité
Posté par tgl . En réponse à la dépêche Udev atteint la maturité. Évalué à 10.
Pourquoi "censé" ? Il le gère tout court, d'où nous vient ce bémol ?
> il gére les device directement dans le système de fichier racine
Il gère les devices où tu veux. Perso je les mets dans un répertoire /dev où est monté un ramfs.
> ça prend de la place
Gné ?
> c'est lent
C'est lent à faire quoi ? Tu as des chiffres ?
> même pas foutu de créer TOUT les devices nécessaire
Mince, moi qui croyait que mon système fonctionnait très bien, en fait je dois rêver.
Enfin bref, tout ça pour dire que j'ai bien du mal à trouver tes "100 000 lieues", et que je ne vois là qu'un gros troll fudesque. Ce serait pas mal de développer un peu là si tu as vraiment des arguments à nous faire partager.
[^] # Re: Gentoo 2004.0
Posté par tgl . En réponse à la dépêche Gentoo 2004.0. Évalué à 2.
[^] # Re: Gentoo 2004.0
Posté par tgl . En réponse à la dépêche Gentoo 2004.0. Évalué à 2.
[^] # Re: Qq réponses rapides
Posté par tgl . En réponse à la dépêche Gentoo 2004.0. Évalué à 1.
> France et en Allemagne et probablement ailleurs aussi.
Oui mais l'attribution d'un copyright à personne morale malgré le fait qu'elle n'ait pas de main pour taper le texte/code est bien autorisé non ? Les pages web des sociétés sont copyrightée par les sociétés et pas par le/la secrétaire qui l'a remplie en général, et souvent pareil pour le code qui n'est pas réparti entre les développeurs individuels mais regroupé sous l'égide de la société qui les emploie. Non ? Enfin je pose la question hein, parceque ta remarque m'interpelle... Tu pourrais déveloper un peu si tu as le temps ? Merci.
[^] # Re: Gentoo 2004.0
Posté par tgl . En réponse à la dépêche Gentoo 2004.0. Évalué à 2.
Hier en début de soirée quand la news a été publier, il n'y avait pas encore d'annonce sur le site de gentoo, et pour la bonne raison que c'était trop tôt pour être annoncé parceque pas près.
Apres être à un jour près... un site d'information n'est valable que si les news sont "fraiche" et que l'on ne la pas deja lu ailleur, (un jour ou deux ne vont pas changer grand chose étant donné que d'autres sites auront publiés la news).
À mon avis ça aurait été encore frais aujoud'hui. On va pas se mettre à jouer le jeux des agences de presse et journaux télévisés qui font primer l'immediateté de leurs "scoops" sur l'intérêt et la volonté des intérressés, sous prétexte de dure loi de la concurrence.
[^] # Re: Gentoo 2004.0
Posté par tgl . En réponse à la dépêche Gentoo 2004.0. Évalué à 1.
Je voulais bien sûr dire « Ça n'est plus seulement un problème [...] ». Pourvu que la suite soit plus compréhensible...
[^] # Re: Gentoo 2004.0
Posté par tgl . En réponse à la dépêche Gentoo 2004.0. Évalué à 3.
- que les paquets de base (ceux de la classe "system") sont libres. Ça c'est facile à vérifier, et ça l'est d'ailleurs systématiquement. Le problème s'est posé une fois ou le USE flag "java" était activé par défaut dans le profile, et ou du coup un paquet de système (db je crois, mais je peux me gourrer) s'est mis à dépendre d'une jvm non libre. Ça avait été détecté et corrigé très vite. Là dessus ils font gaffe, après, le reste, pour l'instant c'est toi qui gère comme tu veux/peux.
- que l'infrastructure de Gentoo repose uniquement sur du libre. Ça ça a été discuté au moins à deux reprises, une fois pour le logiciel du forum, et la conclusion a été qu'il fallait rester en phpBB parceque c'était le moins pire des trucs libres, et une fois pour le gestionnaire de version pour portage, ou l'utilisation de BitKeeper (il me semble, mais la encore je peux me gourrer, enfin bref d'un truc pas libre) avait été envisagée en remplacement de CVS, et ça a été vite écarté pour la même raison.
Après, effectivement, on peut se retrouver pour l'instant avec du proprio sans faire gaffe. Il suffit par exemple d'installer mplayer sur un x86, on activera alors une dépendance sur un codec divx proprio. Ça, ça sux, je suis d'accord, mais c'est pas une violation du contrat social pour autant.
[^] # Re: Gentoo 2004.0
Posté par tgl . En réponse à la dépêche Gentoo 2004.0. Évalué à 4.
- pour pas mal de soft proprios, le téléchargement manuel est requis, et c'est sur le site web qu'est présentée la licence. (par exemple les jdk de sun)
- il est très vraisemblable que soit intégré à une version prochaine de portage la gestion d'une variable de type ACCEPTED_LICENSES, ou qqch comme ça, pour déclarer ce que l'on accepte (en détail ou en s'aidant de groupes de type OSI_approved, GPL_compatible, etc.). L'idée à fait son chemin, y'a eu des patchs, après, bon bah, les changement dans portage faut toujours pousser longtemps dessus pour qu'ils aboutissent quoi... Le problème par contre est que le champs LICENSE de nombreux ebuilds est ambigüe quand il y a de multiples licences applicables : des opérateurs booléens pour dire si c'est plutôt un choix ou bien plusieurs licences pour différents bouts de code existent bien, mais ils n'ont jamais été utilisés avec rigueur puisque cette variable n'était pas exploitée jusqu'ici. Donc y'a pas mal de truc du genre LICENSE="MPL-1.1 NPL-1.1" sans qu'on sache s'il s'agit d'une conjonction ou d'une disjonction.
# Re: Gentoo 2004.0
Posté par tgl . En réponse à la dépêche Gentoo 2004.0. Évalué à 9.