Bonjour,
Je viens ici pour savoir quelle distribution BSD installée sur mon PC
(carte-mère récente avec processeur "dual-core" 4GO de RAM, carte-son M-
Audio Delta44) que j'utiliserai en station de travail et surtout via la
carte-son pour le décodage de signaux radioamateurs numériques (Fldigi
par exemple). Je suis sous Linux depuis de nombreuses années et la
curiosité me pousse à aller vers d'autres pâturages (L'herbe y est
toujours plus verte, ;-) )
D'avance, je vous remercie de vos réponses. Bon week-end!
Jean-Luc/F5JFA :-)
> Pour moi, FreeBSD c'est d'abord le travail des développeurs du > noyau, qui sont certainement compétents, la question des ports n'est > que périphérique, et on pourrait très bien changer complètement de > système s'il est avéré (c'est mon avis) que le système actuel > s'effondre.
Tu parles comme si FreeBSD, ce n'était qu'un noyau et des ports. Tu oublies que c'est aussi des outils systèmes fortement corrélés au noyau. Si jamais le système de base de FreeBSD ( hors ports, donc ) devient naze, la solution est de l'améliorer, pas de le remplacer par les outils GNU.
Pour moi les "outils de base fortement corrélés au noyau" ça fait par définition partie de FreeBSD et ça doit venir avec lui, y compris dans une version debianisée. Par exemple si tu n'as pas les outils pour utiliser les fonctions geom ou zfs, ça ne sert pas que ce soit dans le noyau. Le vrai problème c'est la libc, est-ce qu'on utilise celle de Linux, qui est en fait de plus en plus indispensable pour faire tourner beaucoup d'applications importantes (qui utiliseraient des linuxeries telles que futex and co), ce qui suppose qu'elle soit intégralement supportée dans le noyau, ou la libc de FreeBSD. Je n'ai aucune idée de ce qu'ont fait les debianistes, et il est clair qu'il y a là un problème de délimitation compliqué. Pour ce qui est des outils Unix standards comme awk, etc. je me moque complètement d'où ils viennent, et sur l'exemple de awk je préfère de beaucoup celui de Gnu. De toute façon ce système dit "de base" c'est une partie infinitésimale d'une machine de bureau en état de fonctionnement normal, la quasi totalité des softs tournant sur cette machine seront forcément de provenances diverses, et les outils "de base" ne serviront presque jamais (bien entendu tout ça est complètement faux pour un serveur dépouillé avec peu de ports installés).
--
Michel TALON
Vivien MOREAU <vpm+news@serengetty.fr> wrote:
On 2011-02-16, Michel Talon wrote:
> Pour moi, FreeBSD c'est d'abord le travail des développeurs du
> noyau, qui sont certainement compétents, la question des ports n'est
> que périphérique, et on pourrait très bien changer complètement de
> système s'il est avéré (c'est mon avis) que le système actuel
> s'effondre.
Tu parles comme si FreeBSD, ce n'était qu'un noyau et des ports.
Tu oublies que c'est aussi des outils systèmes fortement corrélés
au noyau. Si jamais le système de base de FreeBSD ( hors ports,
donc ) devient naze, la solution est de l'améliorer, pas de le
remplacer par les outils GNU.
Pour moi les "outils de base fortement corrélés au noyau" ça fait par
définition partie de FreeBSD et ça doit venir avec lui, y compris dans
une version debianisée. Par exemple si tu n'as pas les outils pour
utiliser les fonctions geom ou zfs, ça ne sert pas que ce soit dans le
noyau. Le vrai problème c'est la libc, est-ce qu'on utilise celle de
Linux, qui est en fait de plus en plus indispensable pour faire tourner
beaucoup d'applications importantes (qui utiliseraient des linuxeries
telles que futex and co), ce qui suppose qu'elle soit intégralement
supportée dans le noyau, ou la libc de FreeBSD. Je n'ai aucune idée de ce
qu'ont fait les debianistes, et il est clair qu'il y a là un problème de
délimitation compliqué. Pour ce qui est des outils Unix standards comme
awk, etc. je me moque complètement d'où ils viennent, et sur l'exemple
de awk je préfère de beaucoup celui de Gnu. De toute façon ce système
dit "de base" c'est une partie infinitésimale d'une machine de bureau en
état de fonctionnement normal, la quasi totalité des softs tournant sur
cette machine seront forcément de provenances diverses, et les outils
"de base" ne serviront presque jamais (bien entendu tout ça est
complètement faux pour un serveur dépouillé avec peu de ports
installés).
> Pour moi, FreeBSD c'est d'abord le travail des développeurs du > noyau, qui sont certainement compétents, la question des ports n'est > que périphérique, et on pourrait très bien changer complètement de > système s'il est avéré (c'est mon avis) que le système actuel > s'effondre.
Tu parles comme si FreeBSD, ce n'était qu'un noyau et des ports. Tu oublies que c'est aussi des outils systèmes fortement corrélés au noyau. Si jamais le système de base de FreeBSD ( hors ports, donc ) devient naze, la solution est de l'améliorer, pas de le remplacer par les outils GNU.
Pour moi les "outils de base fortement corrélés au noyau" ça fait par définition partie de FreeBSD et ça doit venir avec lui, y compris dans une version debianisée. Par exemple si tu n'as pas les outils pour utiliser les fonctions geom ou zfs, ça ne sert pas que ce soit dans le noyau. Le vrai problème c'est la libc, est-ce qu'on utilise celle de Linux, qui est en fait de plus en plus indispensable pour faire tourner beaucoup d'applications importantes (qui utiliseraient des linuxeries telles que futex and co), ce qui suppose qu'elle soit intégralement supportée dans le noyau, ou la libc de FreeBSD. Je n'ai aucune idée de ce qu'ont fait les debianistes, et il est clair qu'il y a là un problème de délimitation compliqué. Pour ce qui est des outils Unix standards comme awk, etc. je me moque complètement d'où ils viennent, et sur l'exemple de awk je préfère de beaucoup celui de Gnu. De toute façon ce système dit "de base" c'est une partie infinitésimale d'une machine de bureau en état de fonctionnement normal, la quasi totalité des softs tournant sur cette machine seront forcément de provenances diverses, et les outils "de base" ne serviront presque jamais (bien entendu tout ça est complètement faux pour un serveur dépouillé avec peu de ports installés).
--
Michel TALON
espie
In article <ijg3a8$3ll$, Antoine Leca wrote:
Pas vraiment. On a exactement le même problème sous Windows, qui n'est pas réputé pour être une distribution basée sur des sources :-) Les programmes (binaires) d'installation tentent de deviner la configuration de la machine cible, se trompent et installent les «mauvaises» DLLs ; ou, plus souvent, à la désinstallation, suppriment indument une DLL qui sert encore à autre chose (le fameux DLL hell).
Hum... pour moi, le DLL hell, c'etait plus des problemes de version, avec plusieurs softs qui utilisent des versions plus ou moins incompatibles de bibliotheques, ce qui fait qu'au lieu d'avoir les benefices des bibliotheques PARTAGEES, on se coltine 25 versions distinctes de la meme bibliotheque avec des bugs differents a chaque fois.
D'ailleurs, on s'est recemment fritte la tronche avec les connards de chez mozilla, qui voulaient absolument recompiler leur propre version de sqlite pour changer une option, option qui a ete mise sous forme de pragma au runtime, mais qu'ils n'en demordent pas parce que "ca fait un boulot de maintenance" (rajouter quatre lignes avec une PRAGMA, ouarf), et donc on a un patch local pour ca...
In article <ijg3a8$3ll$1@shakotay.alphanet.ch>,
Antoine Leca <root@localhost.invalid> wrote:
Pas vraiment. On a exactement le même problème sous Windows, qui n'est
pas réputé pour être une distribution basée sur des sources :-)
Les programmes (binaires) d'installation tentent de deviner la
configuration de la machine cible, se trompent et installent les
«mauvaises» DLLs ; ou, plus souvent, à la désinstallation, suppriment
indument une DLL qui sert encore à autre chose (le fameux DLL hell).
Hum... pour moi, le DLL hell, c'etait plus des problemes de version, avec
plusieurs softs qui utilisent des versions plus ou moins incompatibles de
bibliotheques, ce qui fait qu'au lieu d'avoir les benefices des bibliotheques
PARTAGEES, on se coltine 25 versions distinctes de la meme bibliotheque avec
des bugs differents a chaque fois.
D'ailleurs, on s'est recemment fritte la tronche avec les connards de chez
mozilla, qui voulaient absolument recompiler leur propre version de sqlite
pour changer une option, option qui a ete mise sous forme de pragma au
runtime, mais qu'ils n'en demordent pas parce que "ca fait un boulot de
maintenance" (rajouter quatre lignes avec une PRAGMA, ouarf), et donc on
a un patch local pour ca...
Pas vraiment. On a exactement le même problème sous Windows, qui n'est pas réputé pour être une distribution basée sur des sources :-) Les programmes (binaires) d'installation tentent de deviner la configuration de la machine cible, se trompent et installent les «mauvaises» DLLs ; ou, plus souvent, à la désinstallation, suppriment indument une DLL qui sert encore à autre chose (le fameux DLL hell).
Hum... pour moi, le DLL hell, c'etait plus des problemes de version, avec plusieurs softs qui utilisent des versions plus ou moins incompatibles de bibliotheques, ce qui fait qu'au lieu d'avoir les benefices des bibliotheques PARTAGEES, on se coltine 25 versions distinctes de la meme bibliotheque avec des bugs differents a chaque fois.
D'ailleurs, on s'est recemment fritte la tronche avec les connards de chez mozilla, qui voulaient absolument recompiler leur propre version de sqlite pour changer une option, option qui a ete mise sous forme de pragma au runtime, mais qu'ils n'en demordent pas parce que "ca fait un boulot de maintenance" (rajouter quatre lignes avec une PRAGMA, ouarf), et donc on a un patch local pour ca...
Antoine Leca
Michel Talon écrivit :
De toute façon ce système dit "de base" c'est une partie infinitésimale d'une machine de bureau en état de fonctionnement normal, la quasi totalité des softs tournant sur cette machine seront forcément de provenances diverses,
Voui...
et les outils "de base" ne serviront presque jamais
Et non ! Tu as l'exemple de la libc que tu as cité toi-même ; tu as aussi le shell (bash ou pas, etc.), sed et une petite dizaine d'autres qui sont utilisés en permanence par tous les scripts qui tournent dans tous les sens.
Après, si tu évacues les outils tellement basiques qu'on a tendance a les oublier, et les outils propres au système (gestion du machinfs local etc.) il est vrai que n'importe quel système Posix vient avec «en plus» une palanquée d'utilitaires qui servent peu sur une station de travail normale (et c'est exactement pareil avec les autres systèmes). Mais qu'on ne peut éliminer parce que le jour où la machine est en carafe, ou le jour où un étudiant intelligent a lancé un nouveau type de ver sur le réseau, ou le jour où le petit neveu ou le petit nouveau (stagiaire) arrive avec son dernier jouet et insiste pour l'installer, bin là il va falloir revenir au b-a-ba... et aux outils primaires.
Antoine
Michel Talon écrivit :
De toute façon ce système
dit "de base" c'est une partie infinitésimale d'une machine de bureau en
état de fonctionnement normal, la quasi totalité des softs tournant sur
cette machine seront forcément de provenances diverses,
Voui...
et les outils "de base" ne serviront presque jamais
Et non ! Tu as l'exemple de la libc que tu as cité toi-même ; tu as
aussi le shell (bash ou pas, etc.), sed et une petite dizaine d'autres
qui sont utilisés en permanence par tous les scripts qui tournent dans
tous les sens.
Après, si tu évacues les outils tellement basiques qu'on a tendance a
les oublier, et les outils propres au système (gestion du machinfs local
etc.) il est vrai que n'importe quel système Posix vient avec «en plus»
une palanquée d'utilitaires qui servent peu sur une station de travail
normale (et c'est exactement pareil avec les autres systèmes). Mais
qu'on ne peut éliminer parce que le jour où la machine est en carafe, ou
le jour où un étudiant intelligent a lancé un nouveau type de ver sur le
réseau, ou le jour où le petit neveu ou le petit nouveau (stagiaire)
arrive avec son dernier jouet et insiste pour l'installer, bin là il va
falloir revenir au b-a-ba... et aux outils primaires.
De toute façon ce système dit "de base" c'est une partie infinitésimale d'une machine de bureau en état de fonctionnement normal, la quasi totalité des softs tournant sur cette machine seront forcément de provenances diverses,
Voui...
et les outils "de base" ne serviront presque jamais
Et non ! Tu as l'exemple de la libc que tu as cité toi-même ; tu as aussi le shell (bash ou pas, etc.), sed et une petite dizaine d'autres qui sont utilisés en permanence par tous les scripts qui tournent dans tous les sens.
Après, si tu évacues les outils tellement basiques qu'on a tendance a les oublier, et les outils propres au système (gestion du machinfs local etc.) il est vrai que n'importe quel système Posix vient avec «en plus» une palanquée d'utilitaires qui servent peu sur une station de travail normale (et c'est exactement pareil avec les autres systèmes). Mais qu'on ne peut éliminer parce que le jour où la machine est en carafe, ou le jour où un étudiant intelligent a lancé un nouveau type de ver sur le réseau, ou le jour où le petit neveu ou le petit nouveau (stagiaire) arrive avec son dernier jouet et insiste pour l'installer, bin là il va falloir revenir au b-a-ba... et aux outils primaires.
Antoine
Arnaud Launay
Le 15-02-2011, Miod Vallat a écrit :
> Ah oui, tiens. Autant pour moi. Je retire ce que j'ai dit. Une camomille, et au lit ! Si tu veux il me reste de la sauge et de la verveine, à la place de la camomille.
Le 15-02-2011, Miod Vallat <miod@online.fr> a écrit :
> Ah oui, tiens. Autant pour moi. Je retire ce que j'ai dit.
Une camomille, et au lit !
Si tu veux il me reste de la sauge et de la verveine, à la
place de la camomille.
> Ah oui, tiens. Autant pour moi. Je retire ce que j'ai dit. Une camomille, et au lit ! Si tu veux il me reste de la sauge et de la verveine, à la place de la camomille.
la désinstallation, suppriment indument une DLL qui sert encore à autre chose (le fameux DLL hell).
Hum... pour moi, le DLL hell, c'etait plus des problemes de version,
Ça, c'est la version « évoluée » du problème DLL Hell (tellement évoluée que MS n'a pas trouvé d'autres « solutions » que de supprimer officiellement l'idée de bibliothèques partagées, comme tu l'expliques)
Mais le problème de fond, c'est réellement de savoir à qui «appartient» chaque fichier installé, .so ou .h ou .dll, au sens de qui en est responsable : si cette appartenance avait été correctement définie au départ --et les règles suivies par les développeurs... qui travaillent dans le bureau d'à côté :^) -- tant les problèmes de DLL hell comme celui que pointait Kevin n'auraient plus lieu d'être.
On peut toujours rêver, n'ss pas ?
Antoine
Marc Espie écrivit :
In article <ijg3a8$3ll$1@shakotay.alphanet.ch>,
Antoine Leca <root@localhost.invalid> wrote:
la désinstallation, suppriment
indument une DLL qui sert encore à autre chose (le fameux DLL hell).
Hum... pour moi, le DLL hell, c'etait plus des problemes de version,
Ça, c'est la version « évoluée » du problème DLL Hell (tellement évoluée
que MS n'a pas trouvé d'autres « solutions » que de supprimer
officiellement l'idée de bibliothèques partagées, comme tu l'expliques)
Mais le problème de fond, c'est réellement de savoir à qui «appartient»
chaque fichier installé, .so ou .h ou .dll, au sens de qui en est
responsable : si cette appartenance avait été correctement définie au
départ --et les règles suivies par les développeurs... qui travaillent
dans le bureau d'à côté :^) -- tant les problèmes de DLL hell comme
celui que pointait Kevin n'auraient plus lieu d'être.
la désinstallation, suppriment indument une DLL qui sert encore à autre chose (le fameux DLL hell).
Hum... pour moi, le DLL hell, c'etait plus des problemes de version,
Ça, c'est la version « évoluée » du problème DLL Hell (tellement évoluée que MS n'a pas trouvé d'autres « solutions » que de supprimer officiellement l'idée de bibliothèques partagées, comme tu l'expliques)
Mais le problème de fond, c'est réellement de savoir à qui «appartient» chaque fichier installé, .so ou .h ou .dll, au sens de qui en est responsable : si cette appartenance avait été correctement définie au départ --et les règles suivies par les développeurs... qui travaillent dans le bureau d'à côté :^) -- tant les problèmes de DLL hell comme celui que pointait Kevin n'auraient plus lieu d'être.
On peut toujours rêver, n'ss pas ?
Antoine
xavier
Antoine Leca wrote:
Mais le problème de fond, c'est réellement de savoir à qui «appartient» chaque fichier installé, .so ou .h ou .dll, au sens de qui en est responsable
grep truc.so /var/db/pkg/*/+CONTENTS
-- XAv In your pomp and all your glory you're a poorer man than me, as you lick the boots of death born out of fear. (Jethro Tull)
Antoine Leca <root@localhost.invalid> wrote:
Mais le problème de fond, c'est réellement de savoir à qui «appartient»
chaque fichier installé, .so ou .h ou .dll, au sens de qui en est
responsable
grep truc.so /var/db/pkg/*/+CONTENTS
--
XAv
In your pomp and all your glory you're a poorer man than me,
as you lick the boots of death born out of fear.
(Jethro Tull)
Mais le problème de fond, c'est réellement de savoir à qui «appartient» chaque fichier installé, .so ou .h ou .dll, au sens de qui en est responsable
grep truc.so /var/db/pkg/*/+CONTENTS
-- XAv In your pomp and all your glory you're a poorer man than me, as you lick the boots of death born out of fear. (Jethro Tull)
patpro ~ patrick proniewski
In article <1jwsr6y.1oyiye7jvf59zN%, (Xavier) wrote:
Antoine Leca wrote:
> Mais le problème de fond, c'est réellement de savoir à qui «appartient» > chaque fichier installé, .so ou .h ou .dll, au sens de qui en est > responsable
grep truc.so /var/db/pkg/*/+CONTENTS
ha oui tiens, c'est vachement plus rapide que `pkg_which /chemin/de/truc.so :)
$ time pkg_which /usr/local/lib/libpthread-stubs.so libpthread-stubs-0.3_3
real 0m2.023s
$ time grep libpthread-stubs.so /var/db/pkg/*/+CONTENTS /var/db/pkg/libpthread-stubs-0.3_3/+CONTENTS:lib/libpthread-stubs.so /var/db/pkg/libpthread-stubs-0.3_3/+CONTENTS:lib/libpthread-stubs.so.0
real 0m0.567s
patpro
-- A vendre : KVM IP 16 ports APC http://patpro.net/blog/index.php/2008/01/12/133
In article <1jwsr6y.1oyiye7jvf59zN%xavier@groumpf.org>,
xavier@groumpf.org (Xavier) wrote:
Antoine Leca <root@localhost.invalid> wrote:
> Mais le problème de fond, c'est réellement de savoir à qui «appartient»
> chaque fichier installé, .so ou .h ou .dll, au sens de qui en est
> responsable
grep truc.so /var/db/pkg/*/+CONTENTS
ha oui tiens, c'est vachement plus rapide que `pkg_which
/chemin/de/truc.so :)
$ time pkg_which /usr/local/lib/libpthread-stubs.so
libpthread-stubs-0.3_3
real 0m2.023s
$ time grep libpthread-stubs.so /var/db/pkg/*/+CONTENTS
/var/db/pkg/libpthread-stubs-0.3_3/+CONTENTS:lib/libpthread-stubs.so
/var/db/pkg/libpthread-stubs-0.3_3/+CONTENTS:lib/libpthread-stubs.so.0
real 0m0.567s
patpro
--
A vendre : KVM IP 16 ports APC
http://patpro.net/blog/index.php/2008/01/12/133
In article <1jwsr6y.1oyiye7jvf59zN%, (Xavier) wrote:
Antoine Leca wrote:
> Mais le problème de fond, c'est réellement de savoir à qui «appartient» > chaque fichier installé, .so ou .h ou .dll, au sens de qui en est > responsable
grep truc.so /var/db/pkg/*/+CONTENTS
ha oui tiens, c'est vachement plus rapide que `pkg_which /chemin/de/truc.so :)
$ time pkg_which /usr/local/lib/libpthread-stubs.so libpthread-stubs-0.3_3
real 0m2.023s
$ time grep libpthread-stubs.so /var/db/pkg/*/+CONTENTS /var/db/pkg/libpthread-stubs-0.3_3/+CONTENTS:lib/libpthread-stubs.so /var/db/pkg/libpthread-stubs-0.3_3/+CONTENTS:lib/libpthread-stubs.so.0
real 0m0.567s
patpro
-- A vendre : KVM IP 16 ports APC http://patpro.net/blog/index.php/2008/01/12/133
Arnaud Launay
Le 16-02-2011, patpro ~ patrick proniewski a écrit :
> grep truc.so /var/db/pkg/*/+CONTENTS ha oui tiens, c'est vachement plus rapide que `pkg_which /chemin/de/truc.so :)
Et en plus, la même syntaxe ou presque marche aussi sous Gentoo... :)
In article <1jwsr6y.1oyiye7jvf59zN%, (Xavier) wrote:
Antoine Leca wrote:
> Mais le problème de fond, c'est réellement de savoir à qui «appartient» > chaque fichier installé, .so ou .h ou .dll, au sens de qui en est > responsable
grep truc.so /var/db/pkg/*/+CONTENTS
ha oui tiens, c'est vachement plus rapide que `pkg_which /chemin/de/truc.so :)
$ time pkg_which /usr/local/lib/libpthread-stubs.so libpthread-stubs-0.3_3
real 0m2.023s
$ time grep libpthread-stubs.so /var/db/pkg/*/+CONTENTS /var/db/pkg/libpthread-stubs-0.3_3/+CONTENTS:lib/libpthread-stubs.so /var/db/pkg/libpthread-stubs-0.3_3/+CONTENTS:lib/libpthread-stubs.so.0
real 0m0.567s
Chez nous, on a un package, pkglocatedb, qui contient un fichier au format locate(8) qui contient tous les chemins de tous les packages.
time pkglocate /usr/local/lib/libtiff.so.38.3 tiff-3.9.4:graphics/tiff:/usr/local/lib/libtiff.so.38.3 0m0.08s real 0m0.07s user 0m0.00s system
time grep libtiff.so /var/db/pkg/*/+CONTENTS /var/db/pkg/tiff-3.9.4/+CONTENTS:@lib lib/libtiff.so.38.3 0m2.84s real 0m0.20s user 0m0.20s system
(meme machine, bon d'accord il y a 1837 packages installes dessus).
In article <patpro-8E63EA.21000616022011@news.free.fr>,
patpro ~ patrick proniewski <patpro@boleskine.patpro.net> wrote:
In article <1jwsr6y.1oyiye7jvf59zN%xavier@groumpf.org>,
xavier@groumpf.org (Xavier) wrote:
Antoine Leca <root@localhost.invalid> wrote:
> Mais le problème de fond, c'est réellement de savoir à qui «appartient»
> chaque fichier installé, .so ou .h ou .dll, au sens de qui en est
> responsable
grep truc.so /var/db/pkg/*/+CONTENTS
ha oui tiens, c'est vachement plus rapide que `pkg_which
/chemin/de/truc.so :)
$ time pkg_which /usr/local/lib/libpthread-stubs.so
libpthread-stubs-0.3_3
real 0m2.023s
$ time grep libpthread-stubs.so /var/db/pkg/*/+CONTENTS
/var/db/pkg/libpthread-stubs-0.3_3/+CONTENTS:lib/libpthread-stubs.so
/var/db/pkg/libpthread-stubs-0.3_3/+CONTENTS:lib/libpthread-stubs.so.0
real 0m0.567s
Chez nous, on a un package, pkglocatedb, qui contient un fichier au format
locate(8) qui contient tous les chemins de tous les packages.
time pkglocate /usr/local/lib/libtiff.so.38.3
tiff-3.9.4:graphics/tiff:/usr/local/lib/libtiff.so.38.3
0m0.08s real 0m0.07s user 0m0.00s system
time grep libtiff.so /var/db/pkg/*/+CONTENTS
/var/db/pkg/tiff-3.9.4/+CONTENTS:@lib lib/libtiff.so.38.3
0m2.84s real 0m0.20s user 0m0.20s system
(meme machine, bon d'accord il y a 1837 packages installes dessus).
In article <1jwsr6y.1oyiye7jvf59zN%, (Xavier) wrote:
Antoine Leca wrote:
> Mais le problème de fond, c'est réellement de savoir à qui «appartient» > chaque fichier installé, .so ou .h ou .dll, au sens de qui en est > responsable
grep truc.so /var/db/pkg/*/+CONTENTS
ha oui tiens, c'est vachement plus rapide que `pkg_which /chemin/de/truc.so :)
$ time pkg_which /usr/local/lib/libpthread-stubs.so libpthread-stubs-0.3_3
real 0m2.023s
$ time grep libpthread-stubs.so /var/db/pkg/*/+CONTENTS /var/db/pkg/libpthread-stubs-0.3_3/+CONTENTS:lib/libpthread-stubs.so /var/db/pkg/libpthread-stubs-0.3_3/+CONTENTS:lib/libpthread-stubs.so.0
real 0m0.567s
Chez nous, on a un package, pkglocatedb, qui contient un fichier au format locate(8) qui contient tous les chemins de tous les packages.
time pkglocate /usr/local/lib/libtiff.so.38.3 tiff-3.9.4:graphics/tiff:/usr/local/lib/libtiff.so.38.3 0m0.08s real 0m0.07s user 0m0.00s system
time grep libtiff.so /var/db/pkg/*/+CONTENTS /var/db/pkg/tiff-3.9.4/+CONTENTS:@lib lib/libtiff.so.38.3 0m2.84s real 0m0.20s user 0m0.20s system
(meme machine, bon d'accord il y a 1837 packages installes dessus).
talon
Marc Espie wrote:
Chez nous, on a un package, pkglocatedb, qui contient un fichier au format locate(8) qui contient tous les chemins de tous les packages.
Sous FreeBSD les utilisateurs de portupgrade disposent d'une base de données au format bsd qui contient aussi les origines de tous les fichiers installés, interrogeable par pkgdb. Je ne sais pas si c'est très utile, en dernier ressort ce qui compte c'est que les mainteneurs de ports, individuellement, n'aillent pas déclarer des dépendances contradictoires dans chacun de leurs ports.
Un système de ports ne vaut que par la qualité du travail des mainteneurs, et le soin apporté au test du système. Les automatismes programmés (apt-get etc.) ne peuvent pas fonctionner correctement s'il n'y a pas des paquets de bonne qualité. Je pense que c'est ce qui fait la force de Debian, une armée de mainteneurs, considérable, et des procédures strictes de test, avec unstable -> testing -> stable.
Si je regarde par exemple FreeBSD, rien de ce qui peut amener à cette qualité n'est en place, donc les outils d'upgrade, comme portupgrade, portmaster, etc. marchent les jours de lune bleue. L'infrastructure pour un upgrade automatique est de toute façon officiellement absente, puisqu'on préconise officiellement de lire UPGRADING avant tout upgrade, ce qui en bon français veut dire qu'il faut faire une partie des choses manuellement. Ca veut aussi dire que la nomenclature des paquets n'est pas suffisante pour décider dans quel ordre il faut les upgrader. De telles aberrations seraient impensables dans Debian.
J'ai beaucoup de mal à croire que les choses sont bien différentes avec le système de NetBSD qui est similaire. Il est possible que ça aille mieux avec OpenBSD, mais le prix à payer est aussi un ensemble de ports considérablement réduit, ce qui facilite la tâche.
--
Michel TALON
Marc Espie <espie@lain.home> wrote:
Chez nous, on a un package, pkglocatedb, qui contient un fichier au format
locate(8) qui contient tous les chemins de tous les packages.
Sous FreeBSD les utilisateurs de portupgrade disposent d'une base de
données au format bsd qui contient aussi les origines de tous les
fichiers installés, interrogeable par pkgdb.
Je ne sais pas si c'est très utile, en dernier ressort ce qui compte
c'est que les mainteneurs de ports, individuellement, n'aillent pas
déclarer des dépendances contradictoires dans chacun de leurs ports.
Un système de ports ne vaut que par la qualité du travail des
mainteneurs, et le soin apporté au test du système. Les automatismes
programmés (apt-get etc.) ne peuvent pas fonctionner correctement s'il
n'y a pas des paquets de bonne qualité. Je pense que c'est ce qui fait
la force de Debian, une armée de mainteneurs, considérable, et des
procédures strictes de test, avec unstable -> testing -> stable.
Si je regarde par exemple FreeBSD, rien de ce qui peut amener à cette
qualité n'est en place, donc les outils d'upgrade, comme portupgrade,
portmaster, etc. marchent les jours de lune bleue. L'infrastructure
pour un upgrade automatique est de toute façon officiellement absente,
puisqu'on préconise officiellement de lire UPGRADING avant tout
upgrade, ce qui en bon français veut dire qu'il faut faire une partie
des choses manuellement. Ca veut aussi dire que la nomenclature des
paquets n'est pas suffisante pour décider dans quel ordre il faut
les upgrader. De telles aberrations seraient impensables dans Debian.
J'ai beaucoup de mal à croire que les choses sont bien différentes avec
le système de NetBSD qui est similaire. Il est possible que ça aille
mieux avec OpenBSD, mais le prix à payer est aussi un ensemble de ports
considérablement réduit, ce qui facilite la tâche.
Chez nous, on a un package, pkglocatedb, qui contient un fichier au format locate(8) qui contient tous les chemins de tous les packages.
Sous FreeBSD les utilisateurs de portupgrade disposent d'une base de données au format bsd qui contient aussi les origines de tous les fichiers installés, interrogeable par pkgdb. Je ne sais pas si c'est très utile, en dernier ressort ce qui compte c'est que les mainteneurs de ports, individuellement, n'aillent pas déclarer des dépendances contradictoires dans chacun de leurs ports.
Un système de ports ne vaut que par la qualité du travail des mainteneurs, et le soin apporté au test du système. Les automatismes programmés (apt-get etc.) ne peuvent pas fonctionner correctement s'il n'y a pas des paquets de bonne qualité. Je pense que c'est ce qui fait la force de Debian, une armée de mainteneurs, considérable, et des procédures strictes de test, avec unstable -> testing -> stable.
Si je regarde par exemple FreeBSD, rien de ce qui peut amener à cette qualité n'est en place, donc les outils d'upgrade, comme portupgrade, portmaster, etc. marchent les jours de lune bleue. L'infrastructure pour un upgrade automatique est de toute façon officiellement absente, puisqu'on préconise officiellement de lire UPGRADING avant tout upgrade, ce qui en bon français veut dire qu'il faut faire une partie des choses manuellement. Ca veut aussi dire que la nomenclature des paquets n'est pas suffisante pour décider dans quel ordre il faut les upgrader. De telles aberrations seraient impensables dans Debian.
J'ai beaucoup de mal à croire que les choses sont bien différentes avec le système de NetBSD qui est similaire. Il est possible que ça aille mieux avec OpenBSD, mais le prix à payer est aussi un ensemble de ports considérablement réduit, ce qui facilite la tâche.
