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 :-)
patpro ~ patrick proniewski wrote: > > Je ne sais pas, moi je persiste avec FreeBSD, et j'en suis content, dans > un contexte "serveur". Je ne supporte pas d'avoir un truc ? compiler sur > mes machines Mac OS X, mais je suis tr?s content de le faire sur mes > serveurs FreeBSD. Deux utilisations tr?s diff?rentes.
Voilà si on se limite à des serveurs je tombe entièrement d'accord avec toi, il y a peu de ports installés, relativement simples,donc les tenir à jour avec un quelconque portupgrade ou portmaster ne pose pas de problème majeur. Le problème vient quand on a un desktop avec tous les monstres usuels et > 1000 ports installés. Dans ce cas, Debian, Ubuntu, etc. restent faciles à maintenir et upgrader, pas FreeBSD.
ha oui, quand même... je pensais pas qu'un desktop puisse nécessiter autant de ports. Je trouve déjà que j'en ai trop sur mes serveurs (entre 130 et 280 suivant les machines)...
Mais pour cet usage, qui n'est pas du tout ma pratique, NetBSD et OpenBSD (selon qu'on souhaite ou pas un minimum de performance) ne sont ils pas (*) plus adaptés? Je me demande quel est exactement le domaine d'application de FreeBSD en fait.
Disons qu'après 10 ans de pratique, je commence à connaître FreeBSD suffisamment pour pouvoir faire face à pas mal de problèmes ou d'urgences avec sérénité. Je ne changerai pas maintenant pour un autre BSD. Ma problématique actuelle c'est plutôt de m'assurer que FreeBSD fonctionne pas trop mal en guest sur une infra VMWare (VSphere+esx). Et ça, comparé à Linux, c'est pas trop la fête.
patpro
-- A vendre ! http://www.patpro.net/blog/index.php/2008/01/12/133
In article <ij9l2r$1fjg$1@asmodee.lpthe.jussieu.fr>,
talon@lpthe.jussieu.fr (Michel Talon) wrote:
patpro ~ patrick proniewski <patpro@boleskine.patpro.net> wrote:
>
> Je ne sais pas, moi je persiste avec FreeBSD, et j'en suis content, dans
> un contexte "serveur". Je ne supporte pas d'avoir un truc ? compiler sur
> mes machines Mac OS X, mais je suis tr?s content de le faire sur mes
> serveurs FreeBSD. Deux utilisations tr?s diff?rentes.
Voilà si on se limite à des serveurs je tombe entièrement d'accord avec
toi, il y a peu de ports installés, relativement simples,donc les tenir à
jour avec un quelconque portupgrade ou portmaster ne pose pas de
problème majeur. Le problème vient quand on a un desktop avec tous les
monstres usuels et > 1000 ports installés. Dans ce cas, Debian, Ubuntu,
etc. restent faciles à maintenir et upgrader, pas FreeBSD.
ha oui, quand même... je pensais pas qu'un desktop puisse nécessiter
autant de ports. Je trouve déjà que j'en ai trop sur mes serveurs (entre
130 et 280 suivant les machines)...
Mais pour cet usage, qui n'est pas du tout ma pratique, NetBSD et
OpenBSD (selon qu'on souhaite ou pas un minimum de performance) ne sont
ils pas (*) plus adaptés? Je me demande quel est exactement le domaine
d'application de FreeBSD en fait.
Disons qu'après 10 ans de pratique, je commence à connaître FreeBSD
suffisamment pour pouvoir faire face à pas mal de problèmes ou
d'urgences avec sérénité. Je ne changerai pas maintenant pour un autre
BSD. Ma problématique actuelle c'est plutôt de m'assurer que FreeBSD
fonctionne pas trop mal en guest sur une infra VMWare (VSphere+esx). Et
ça, comparé à Linux, c'est pas trop la fête.
patpro
--
A vendre ! http://www.patpro.net/blog/index.php/2008/01/12/133
patpro ~ patrick proniewski wrote: > > Je ne sais pas, moi je persiste avec FreeBSD, et j'en suis content, dans > un contexte "serveur". Je ne supporte pas d'avoir un truc ? compiler sur > mes machines Mac OS X, mais je suis tr?s content de le faire sur mes > serveurs FreeBSD. Deux utilisations tr?s diff?rentes.
Voilà si on se limite à des serveurs je tombe entièrement d'accord avec toi, il y a peu de ports installés, relativement simples,donc les tenir à jour avec un quelconque portupgrade ou portmaster ne pose pas de problème majeur. Le problème vient quand on a un desktop avec tous les monstres usuels et > 1000 ports installés. Dans ce cas, Debian, Ubuntu, etc. restent faciles à maintenir et upgrader, pas FreeBSD.
ha oui, quand même... je pensais pas qu'un desktop puisse nécessiter autant de ports. Je trouve déjà que j'en ai trop sur mes serveurs (entre 130 et 280 suivant les machines)...
Mais pour cet usage, qui n'est pas du tout ma pratique, NetBSD et OpenBSD (selon qu'on souhaite ou pas un minimum de performance) ne sont ils pas (*) plus adaptés? Je me demande quel est exactement le domaine d'application de FreeBSD en fait.
Disons qu'après 10 ans de pratique, je commence à connaître FreeBSD suffisamment pour pouvoir faire face à pas mal de problèmes ou d'urgences avec sérénité. Je ne changerai pas maintenant pour un autre BSD. Ma problématique actuelle c'est plutôt de m'assurer que FreeBSD fonctionne pas trop mal en guest sur une infra VMWare (VSphere+esx). Et ça, comparé à Linux, c'est pas trop la fête.
patpro
-- A vendre ! http://www.patpro.net/blog/index.php/2008/01/12/133
talon
patpro ~ Patrick Proniewski wrote:
ha oui, quand m?me... je pensais pas qu'un desktop puisse n?cessiter autant de ports. Je trouve d?j? que j'en ai trop sur mes serveurs (entre 130 et 280 suivant les machines)...
Sur ma machine que j'ai réinstallée récemment en enlevant la quasi totalité de gnome niobe% ls /var/db/pkg|wc -l 781
--
Michel TALON
patpro ~ Patrick Proniewski <patpro@boleskine.patpro.net> wrote:
ha oui, quand m?me... je pensais pas qu'un desktop puisse n?cessiter
autant de ports. Je trouve d?j? que j'en ai trop sur mes serveurs (entre
130 et 280 suivant les machines)...
Sur ma machine que j'ai réinstallée récemment en enlevant la quasi
totalité de gnome
niobe% ls /var/db/pkg|wc -l
781
ha oui, quand m?me... je pensais pas qu'un desktop puisse n?cessiter autant de ports. Je trouve d?j? que j'en ai trop sur mes serveurs (entre 130 et 280 suivant les machines)...
Sur ma machine que j'ai réinstallée récemment en enlevant la quasi totalité de gnome niobe% ls /var/db/pkg|wc -l 781
--
Michel TALON
Francois Tigeot
Antoine Leca wrote:
Je ne dis pas que pkgsrc c'est beurk, en fait cela me donne plutôt l'impression d'être mieux que ce qu'il y a ailleurs
(avec peut-être un peu trop d'embompoint, renforcé par l'utilisation de git au lieu de CVS pour Dragonfly ou Minix)
Attention, pkgsrc en lui-même n'utilise pas git. C'est uniquement des OS précis qui se sont mis en tête de redistribuer le contenu CVS par git parce que ça fait plus moderne.
Perso, je ne suis pas trop convaincu, et même si j'utilise pkgsrc sous DragonFly, c'est toujours à partir des dépôts CVS.
-- Francois Tigeot
Antoine Leca wrote:
Je ne dis pas que pkgsrc c'est beurk, en fait cela me donne plutôt
l'impression d'être mieux que ce qu'il y a ailleurs
(avec peut-être un
peu trop d'embompoint, renforcé par l'utilisation de git au lieu de CVS
pour Dragonfly ou Minix)
Attention, pkgsrc en lui-même n'utilise pas git.
C'est uniquement des OS précis qui se sont mis en tête de redistribuer
le contenu CVS par git parce que ça fait plus moderne.
Perso, je ne suis pas trop convaincu, et même si j'utilise pkgsrc sous
DragonFly, c'est toujours à partir des dépôts CVS.
Je ne dis pas que pkgsrc c'est beurk, en fait cela me donne plutôt l'impression d'être mieux que ce qu'il y a ailleurs
(avec peut-être un peu trop d'embompoint, renforcé par l'utilisation de git au lieu de CVS pour Dragonfly ou Minix)
Attention, pkgsrc en lui-même n'utilise pas git. C'est uniquement des OS précis qui se sont mis en tête de redistribuer le contenu CVS par git parce que ça fait plus moderne.
Perso, je ne suis pas trop convaincu, et même si j'utilise pkgsrc sous DragonFly, c'est toujours à partir des dépôts CVS.
-- Francois Tigeot
Patrick Lamaizière
Michel Talon :
Sur ma machine que j'ai réinstallée récemment en enlevant la quasi totalité de gnome niobe% ls /var/db/pkg|wc -l 781
738 ici. Le problème n'est pas seulement le nombre, il devient quasi impossible de prédire ce que fourni une dépendance et les options à utiliser.
Rien que pour avoir cups sous XFCE c'est dur... (à part un WITH_CUPS et une recompile complète de TOUT)
Michel Talon :
Sur ma machine que j'ai réinstallée récemment en enlevant la quasi
totalité de gnome
niobe% ls /var/db/pkg|wc -l
781
738 ici. Le problème n'est pas seulement le nombre, il devient quasi
impossible de prédire ce que fourni une dépendance et les options à
utiliser.
Rien que pour avoir cups sous XFCE c'est dur... (à part un WITH_CUPS et
une recompile complète de TOUT)
Sur ma machine que j'ai réinstallée récemment en enlevant la quasi totalité de gnome niobe% ls /var/db/pkg|wc -l 781
738 ici. Le problème n'est pas seulement le nombre, il devient quasi impossible de prédire ce que fourni une dépendance et les options à utiliser.
Rien que pour avoir cups sous XFCE c'est dur... (à part un WITH_CUPS et une recompile complète de TOUT)
espie
In article <ijbsgu$9tg$, Patrick Lamaizière wrote:
Michel Talon :
Sur ma machine que j'ai réinstallée récemment en enlevant la quasi totalité de gnome niobe% ls /var/db/pkg|wc -l 781
738 ici. Le problème n'est pas seulement le nombre, il devient quasi impossible de prédire ce que fourni une dépendance et les options à utiliser.
Rien que pour avoir cups sous XFCE c'est dur... (à part un WITH_CUPS et une recompile complète de TOUT)
C'est pas pour vous narguer, mais avec un systeme de flavors et multi-packages bien concu, l'utilisateur final evite les 9/10 de ca. On passe pas mal de temps a bosser avec upstream pour essayer de s'arranger pour que la plupart des bouts "optionnels" soient des plugins quand c'est possible. Du coup, on n'a pas 25 packages differents selon les options, mais des packages principaux, et des trucs additionnels comme les bouts qui dependent de cups... comme ca, le type qui n'utilise pas cups ne se coltine pas les 25 dependances supplementaires, et celui qui veut cups n'a pas tout a recompiler.
Evidemment, c'est un peu plus de boulot, mais le fait de pouvoir generer plusieurs packages avec une seule compil' et d'avoir des dependances runtime qui dependent du package simplifient enormement les choses.
In article <ijbsgu$9tg$1@news.davenulle.org>,
Patrick Lamaizière <patnews1@davenulle.org> wrote:
Michel Talon :
Sur ma machine que j'ai réinstallée récemment en enlevant la quasi
totalité de gnome
niobe% ls /var/db/pkg|wc -l
781
738 ici. Le problème n'est pas seulement le nombre, il devient quasi
impossible de prédire ce que fourni une dépendance et les options à
utiliser.
Rien que pour avoir cups sous XFCE c'est dur... (à part un WITH_CUPS et
une recompile complète de TOUT)
C'est pas pour vous narguer, mais avec un systeme de flavors et multi-packages
bien concu, l'utilisateur final evite les 9/10 de ca. On passe pas mal de
temps a bosser avec upstream pour essayer de s'arranger pour que la plupart
des bouts "optionnels" soient des plugins quand c'est possible. Du coup, on
n'a pas 25 packages differents selon les options, mais des packages principaux,
et des trucs additionnels comme les bouts qui dependent de cups... comme ca,
le type qui n'utilise pas cups ne se coltine pas les 25 dependances
supplementaires, et celui qui veut cups n'a pas tout a recompiler.
Evidemment, c'est un peu plus de boulot, mais le fait de pouvoir generer
plusieurs packages avec une seule compil' et d'avoir des dependances runtime
qui dependent du package simplifient enormement les choses.
In article <ijbsgu$9tg$, Patrick Lamaizière wrote:
Michel Talon :
Sur ma machine que j'ai réinstallée récemment en enlevant la quasi totalité de gnome niobe% ls /var/db/pkg|wc -l 781
738 ici. Le problème n'est pas seulement le nombre, il devient quasi impossible de prédire ce que fourni une dépendance et les options à utiliser.
Rien que pour avoir cups sous XFCE c'est dur... (à part un WITH_CUPS et une recompile complète de TOUT)
C'est pas pour vous narguer, mais avec un systeme de flavors et multi-packages bien concu, l'utilisateur final evite les 9/10 de ca. On passe pas mal de temps a bosser avec upstream pour essayer de s'arranger pour que la plupart des bouts "optionnels" soient des plugins quand c'est possible. Du coup, on n'a pas 25 packages differents selon les options, mais des packages principaux, et des trucs additionnels comme les bouts qui dependent de cups... comme ca, le type qui n'utilise pas cups ne se coltine pas les 25 dependances supplementaires, et celui qui veut cups n'a pas tout a recompiler.
Evidemment, c'est un peu plus de boulot, mais le fait de pouvoir generer plusieurs packages avec une seule compil' et d'avoir des dependances runtime qui dependent du package simplifient enormement les choses.
talon
Marc Espie wrote:
Evidemment, c'est un peu plus de boulot, mais le fait de pouvoir generer plusieurs packages avec une seule compil' et d'avoir des dependances runtime qui dependent du package simplifient enormement les choses.
Franchement, je crois que la plupart des mainteneurs de ports de FreeBSD ne sortent pas de Normale Sup.
--
Michel TALON
Marc Espie <espie@lain.home> wrote:
Evidemment, c'est un peu plus de boulot, mais le fait de pouvoir generer
plusieurs packages avec une seule compil' et d'avoir des dependances runtime
qui dependent du package simplifient enormement les choses.
Franchement, je crois que la plupart des mainteneurs de ports de FreeBSD
ne sortent pas de Normale Sup.
Evidemment, c'est un peu plus de boulot, mais le fait de pouvoir generer plusieurs packages avec une seule compil' et d'avoir des dependances runtime qui dependent du package simplifient enormement les choses.
Franchement, je crois que la plupart des mainteneurs de ports de FreeBSD ne sortent pas de Normale Sup.
--
Michel TALON
espie
In article <ijc5b3$29p6$, Michel Talon wrote:
Marc Espie wrote:
Evidemment, c'est un peu plus de boulot, mais le fait de pouvoir generer plusieurs packages avec une seule compil' et d'avoir des dependances runtime qui dependent du package simplifient enormement les choses.
Franchement, je crois que la plupart des mainteneurs de ports de FreeBSD ne sortent pas de Normale Sup.
Ceux d'Open non plus, hein.
Et puis il y en a aussi dans les utilisateurs d'autres OS, comme Erwan.
C'est pas pour rien qu'on a monstrueusement simplifie ET documente le fonctionnement de tout ca au cours des annees.
In article <ijc5b3$29p6$1@asmodee.lpthe.jussieu.fr>,
Michel Talon <talon@lpthe.jussieu.fr> wrote:
Marc Espie <espie@lain.home> wrote:
Evidemment, c'est un peu plus de boulot, mais le fait de pouvoir generer
plusieurs packages avec une seule compil' et d'avoir des dependances runtime
qui dependent du package simplifient enormement les choses.
Franchement, je crois que la plupart des mainteneurs de ports de FreeBSD
ne sortent pas de Normale Sup.
Ceux d'Open non plus, hein.
Et puis il y en a aussi dans les utilisateurs d'autres OS, comme Erwan.
C'est pas pour rien qu'on a monstrueusement simplifie ET documente le
fonctionnement de tout ca au cours des annees.
Evidemment, c'est un peu plus de boulot, mais le fait de pouvoir generer plusieurs packages avec une seule compil' et d'avoir des dependances runtime qui dependent du package simplifient enormement les choses.
Franchement, je crois que la plupart des mainteneurs de ports de FreeBSD ne sortent pas de Normale Sup.
Ceux d'Open non plus, hein.
Et puis il y en a aussi dans les utilisateurs d'autres OS, comme Erwan.
C'est pas pour rien qu'on a monstrueusement simplifie ET documente le fonctionnement de tout ca au cours des annees.
Stephane Catteau
Michel Talon n'était pas loin de dire :
Marc Espie wrote:
Evidemment, c'est un peu plus de boulot, mais le fait de pouvoir generer plusieurs packages avec une seule compil' et d'avoir des dependances runtime qui dependent du package simplifient enormement les choses.
Franchement, je crois que la plupart des mainteneurs de ports de FreeBSD ne sortent pas de Normale Sup.
Par contre les utilisateurs doivent en sortir, ce qui est absurde. A part les mises à jours de sécurité, je n'ai pas du mettre à jour ma passerelle depuis trois ans. La dernière fois que je l'ai fait il m'a fallut une semaine et une machine relais, et apparament ça ne s'est pas arrangé depuis :/ FreeBSD dispose d'un parc logiciel conséquent et configurable à loisir, et dispose aussi d'une interface utilisateur assez intuitive. Du coup un débutant peut utiliser FreeBSD sans problème, même en n'ayant jamais utilisé de système *nix ou assimilé de sa vie, mais dès lors qu'il veut faire quelque chose avec son système, il se fait des noeuds au cerveau à chaque nouveau logiciel qu'il installe.
-- 17/06/1969 - 18/01/2011
Repose en paix mon amour :'(
Michel Talon n'était pas loin de dire :
Marc Espie <espie@lain.home> wrote:
Evidemment, c'est un peu plus de boulot, mais le fait de pouvoir generer
plusieurs packages avec une seule compil' et d'avoir des dependances runtime
qui dependent du package simplifient enormement les choses.
Franchement, je crois que la plupart des mainteneurs de ports de FreeBSD
ne sortent pas de Normale Sup.
Par contre les utilisateurs doivent en sortir, ce qui est absurde. A
part les mises à jours de sécurité, je n'ai pas du mettre à jour ma
passerelle depuis trois ans. La dernière fois que je l'ai fait il m'a
fallut une semaine et une machine relais, et apparament ça ne s'est pas
arrangé depuis :/
FreeBSD dispose d'un parc logiciel conséquent et configurable à
loisir, et dispose aussi d'une interface utilisateur assez intuitive.
Du coup un débutant peut utiliser FreeBSD sans problème, même en
n'ayant jamais utilisé de système *nix ou assimilé de sa vie, mais dès
lors qu'il veut faire quelque chose avec son système, il se fait des
noeuds au cerveau à chaque nouveau logiciel qu'il installe.
Evidemment, c'est un peu plus de boulot, mais le fait de pouvoir generer plusieurs packages avec une seule compil' et d'avoir des dependances runtime qui dependent du package simplifient enormement les choses.
Franchement, je crois que la plupart des mainteneurs de ports de FreeBSD ne sortent pas de Normale Sup.
Par contre les utilisateurs doivent en sortir, ce qui est absurde. A part les mises à jours de sécurité, je n'ai pas du mettre à jour ma passerelle depuis trois ans. La dernière fois que je l'ai fait il m'a fallut une semaine et une machine relais, et apparament ça ne s'est pas arrangé depuis :/ FreeBSD dispose d'un parc logiciel conséquent et configurable à loisir, et dispose aussi d'une interface utilisateur assez intuitive. Du coup un débutant peut utiliser FreeBSD sans problème, même en n'ayant jamais utilisé de système *nix ou assimilé de sa vie, mais dès lors qu'il veut faire quelque chose avec son système, il se fait des noeuds au cerveau à chaque nouveau logiciel qu'il installe.
-- 17/06/1969 - 18/01/2011
Repose en paix mon amour :'(
patpro ~ Patrick Proniewski
In article , Stephane Catteau wrote:
Michel Talon n'était pas loin de dire :
> Marc Espie wrote: >> >> Evidemment, c'est un peu plus de boulot, mais le fait de pouvoir generer >> plusieurs packages avec une seule compil' et d'avoir des dependances >> runtime >> qui dependent du package simplifient enormement les choses. > > Franchement, je crois que la plupart des mainteneurs de ports de FreeBSD > ne sortent pas de Normale Sup.
Par contre les utilisateurs doivent en sortir, ce qui est absurde. A part les mises à jours de sécurité, je n'ai pas du mettre à jour ma passerelle depuis trois ans. La dernière fois que je l'ai fait il m'a fallut une semaine et une machine relais, et apparament ça ne s'est pas arrangé depuis :/
C'est l'erreur que j'essaye d'éviter. Je mets mes ports à jour relativement souvent, pour être sûr de ne pas prendre un mur quand le saut de version est trop haut, ou que trop de ports ont été modifiés dans l'intervalle.
patpro
-- A vendre ! http://www.patpro.net/blog/index.php/2008/01/12/133
In article <mn.7abe7db2113d08d9.30736@sc4x.org>,
Stephane Catteau <steph.nospam@sc4x.net> wrote:
Michel Talon n'était pas loin de dire :
> Marc Espie <espie@lain.home> wrote:
>>
>> Evidemment, c'est un peu plus de boulot, mais le fait de pouvoir generer
>> plusieurs packages avec une seule compil' et d'avoir des dependances
>> runtime
>> qui dependent du package simplifient enormement les choses.
>
> Franchement, je crois que la plupart des mainteneurs de ports de FreeBSD
> ne sortent pas de Normale Sup.
Par contre les utilisateurs doivent en sortir, ce qui est absurde. A
part les mises à jours de sécurité, je n'ai pas du mettre à jour ma
passerelle depuis trois ans. La dernière fois que je l'ai fait il m'a
fallut une semaine et une machine relais, et apparament ça ne s'est pas
arrangé depuis :/
C'est l'erreur que j'essaye d'éviter. Je mets mes ports à jour
relativement souvent, pour être sûr de ne pas prendre un mur quand le
saut de version est trop haut, ou que trop de ports ont été modifiés
dans l'intervalle.
patpro
--
A vendre ! http://www.patpro.net/blog/index.php/2008/01/12/133
> Marc Espie wrote: >> >> Evidemment, c'est un peu plus de boulot, mais le fait de pouvoir generer >> plusieurs packages avec une seule compil' et d'avoir des dependances >> runtime >> qui dependent du package simplifient enormement les choses. > > Franchement, je crois que la plupart des mainteneurs de ports de FreeBSD > ne sortent pas de Normale Sup.
Par contre les utilisateurs doivent en sortir, ce qui est absurde. A part les mises à jours de sécurité, je n'ai pas du mettre à jour ma passerelle depuis trois ans. La dernière fois que je l'ai fait il m'a fallut une semaine et une machine relais, et apparament ça ne s'est pas arrangé depuis :/
C'est l'erreur que j'essaye d'éviter. Je mets mes ports à jour relativement souvent, pour être sûr de ne pas prendre un mur quand le saut de version est trop haut, ou que trop de ports ont été modifiés dans l'intervalle.
patpro
-- A vendre ! http://www.patpro.net/blog/index.php/2008/01/12/133
Kevin Denis
Le 12-02-2011, Michel Talon a écrit :
C'est ce que je disais. Je défends l'opinion que seul un système de paquets binaires peut fonctionner de manière fiable, ainsi qu'il est attesté par OpenBSD ou Debian, tandis qu'un système basé sur la compilation des sources vire inéluctablement au bordel généralisé.
Pas sur. J'ai eu un exemple récent. Recompilation de mplayer. Et le ./configure est allé chercher la lib Samba pour se lier dessus. Samba avait été installé pour un test, puis supprimé. Et mplayer est devenu cassé. Et ça, c'est le problème avec les distribs basées sur des sources, j'imagine que FreeBSD à le même souci.
Il y a en fait deux moyens de résoudre ce problème. Soit on lance un ./configure avec des myriades d'options (--disable-smb je suppose dans mon cas) et le paquet se comporte _correctement_ comme attendu, soit on se débrouille pour tout piocher au runtime. Comment? Je ne sais pas vraiment, peut-être des systèmes de plugins.
L'empaquetage binaire souffre du même problème. Debian découpe netcat en trois paquets distincts, c'est pas tellement plus malin.
On pourrait aussi imaginer que chaque paquet binaire embarque la totalité de ses libs, et détecte les libs déjà présentes au lancement pour les utiliser au cas où. En cas de mises à jour système qui casse le fonctionnement du programme, on a le fallback vers les libs associées au paquet [Avec un Warning éventuel]. On est sûr que le programme fonctionne, on mutualise les libs existantes, on suit les pbs de sécurité corrigés. Ceci dit, chaque paquet risque d'être énorme, mais puisque chacun dispose d'internet illimité et des disques de même propriété, cela reste une idée intéressante. -- Kevin
Le 12-02-2011, Michel Talon <talon@lpthe.jussieu.fr> a écrit :
C'est ce que je disais. Je défends l'opinion que seul un système de
paquets binaires peut fonctionner de manière fiable, ainsi qu'il est
attesté par OpenBSD ou Debian, tandis qu'un système basé sur
la compilation des sources vire inéluctablement au bordel généralisé.
Pas sur. J'ai eu un exemple récent. Recompilation de mplayer. Et
le ./configure est allé chercher la lib Samba pour se lier dessus.
Samba avait été installé pour un test, puis supprimé.
Et mplayer est devenu cassé. Et ça, c'est le problème avec les distribs
basées sur des sources, j'imagine que FreeBSD à le même souci.
Il y a en fait deux moyens de résoudre ce problème. Soit on lance
un ./configure avec des myriades d'options (--disable-smb je suppose
dans mon cas) et le paquet se comporte _correctement_ comme attendu,
soit on se débrouille pour tout piocher au runtime. Comment? Je ne
sais pas vraiment, peut-être des systèmes de plugins.
L'empaquetage binaire souffre du même problème. Debian découpe
netcat en trois paquets distincts, c'est pas tellement plus malin.
On pourrait aussi imaginer que chaque paquet binaire embarque la
totalité de ses libs, et détecte les libs déjà présentes au lancement
pour les utiliser au cas où. En cas de mises à jour système qui casse
le fonctionnement du programme, on a le fallback vers les libs
associées au paquet [Avec un Warning éventuel]. On est sûr que le
programme fonctionne, on mutualise les libs existantes, on suit
les pbs de sécurité corrigés. Ceci dit, chaque paquet risque d'être
énorme, mais puisque chacun dispose d'internet illimité et des
disques de même propriété, cela reste une idée intéressante.
--
Kevin
C'est ce que je disais. Je défends l'opinion que seul un système de paquets binaires peut fonctionner de manière fiable, ainsi qu'il est attesté par OpenBSD ou Debian, tandis qu'un système basé sur la compilation des sources vire inéluctablement au bordel généralisé.
Pas sur. J'ai eu un exemple récent. Recompilation de mplayer. Et le ./configure est allé chercher la lib Samba pour se lier dessus. Samba avait été installé pour un test, puis supprimé. Et mplayer est devenu cassé. Et ça, c'est le problème avec les distribs basées sur des sources, j'imagine que FreeBSD à le même souci.
Il y a en fait deux moyens de résoudre ce problème. Soit on lance un ./configure avec des myriades d'options (--disable-smb je suppose dans mon cas) et le paquet se comporte _correctement_ comme attendu, soit on se débrouille pour tout piocher au runtime. Comment? Je ne sais pas vraiment, peut-être des systèmes de plugins.
L'empaquetage binaire souffre du même problème. Debian découpe netcat en trois paquets distincts, c'est pas tellement plus malin.
On pourrait aussi imaginer que chaque paquet binaire embarque la totalité de ses libs, et détecte les libs déjà présentes au lancement pour les utiliser au cas où. En cas de mises à jour système qui casse le fonctionnement du programme, on a le fallback vers les libs associées au paquet [Avec un Warning éventuel]. On est sûr que le programme fonctionne, on mutualise les libs existantes, on suit les pbs de sécurité corrigés. Ceci dit, chaque paquet risque d'être énorme, mais puisque chacun dispose d'internet illimité et des disques de même propriété, cela reste une idée intéressante. -- Kevin
