L'argument de la place occupée sur les machines de très petite taille ne tient pas un instant, il suffit de virer manu militari /usr/include et /usr/share/doc si on veut faire une installation très légère.
En gros, tu considères qu'il est plus rapide d'installer la distribution complète, puis de virer ce qui est inutile que de n'installer que ce qui est nécessaire. C'est rigolo comme façon, de voir.
Le monsieur est en train de parler d'un veritable OS.
/usr/include et /usr/share/doc ne sont pas pollues par les applications tierces, qui s'installent naturellement dans /usr/local.
-- Bruno Ducrot
-- Which is worse: ignorance or apathy? -- Don't know. Don't care.
On 2009-11-29, Stéphane CARPENTIER wrote:
Michel Talon wrote:
L'argument
de la place occupée sur les machines de très petite taille ne tient pas
un instant, il suffit de virer manu militari /usr/include et
/usr/share/doc si on veut faire une installation très légère.
En gros, tu considères qu'il est plus rapide d'installer la distribution
complète, puis de virer ce qui est inutile que de n'installer que ce qui
est nécessaire. C'est rigolo comme façon, de voir.
Le monsieur est en train de parler d'un veritable OS.
/usr/include et /usr/share/doc ne sont pas pollues par les
applications tierces, qui s'installent naturellement dans
/usr/local.
--
Bruno Ducrot
-- Which is worse: ignorance or apathy?
-- Don't know. Don't care.
L'argument de la place occupée sur les machines de très petite taille ne tient pas un instant, il suffit de virer manu militari /usr/include et /usr/share/doc si on veut faire une installation très légère.
En gros, tu considères qu'il est plus rapide d'installer la distribution complète, puis de virer ce qui est inutile que de n'installer que ce qui est nécessaire. C'est rigolo comme façon, de voir.
Le monsieur est en train de parler d'un veritable OS.
/usr/include et /usr/share/doc ne sont pas pollues par les applications tierces, qui s'installent naturellement dans /usr/local.
-- Bruno Ducrot
-- Which is worse: ignorance or apathy? -- Don't know. Don't care.
totof01
On 30 nov, 18:03, Bruno Ducrot wrote:
On 2009-11-29, Stéphane CARPENTIER wrote:
> Michel Talon wrote: >> L'argument >> de la place occupée sur les machines de très petite taille ne tien t pas >> un instant, il suffit de virer manu militari /usr/include et >> /usr/share/doc si on veut faire une installation très légère.
> En gros, tu considères qu'il est plus rapide d'installer la distribut ion > complète, puis de virer ce qui est inutile que de n'installer que ce qui > est nécessaire. C'est rigolo comme façon, de voir.
Le monsieur est en train de parler d'un veritable OS.
/usr/include et /usr/share/doc ne sont pas pollues par les applications tierces, qui s'installent naturellement dans /usr/local.
Sur mon véritable OS, les applis tierces s'installent dans /usr/pkg. Les seuls trucs que je mets dans /usr/local sont des trucs compilés hors système de packages. Ca c'est un _vrai_ OS.
-- Bruno Ducrot
-- Which is worse: ignorance or apathy? -- Don't know. Don't care.
On 30 nov, 18:03, Bruno Ducrot <duc...@echo.fr> wrote:
On 2009-11-29, Stéphane CARPENTIER wrote:
> Michel Talon wrote:
>> L'argument
>> de la place occupée sur les machines de très petite taille ne tien t pas
>> un instant, il suffit de virer manu militari /usr/include et
>> /usr/share/doc si on veut faire une installation très légère.
> En gros, tu considères qu'il est plus rapide d'installer la distribut ion
> complète, puis de virer ce qui est inutile que de n'installer que ce qui
> est nécessaire. C'est rigolo comme façon, de voir.
Le monsieur est en train de parler d'un veritable OS.
/usr/include et /usr/share/doc ne sont pas pollues par les
applications tierces, qui s'installent naturellement dans
/usr/local.
Sur mon véritable OS, les applis tierces s'installent dans /usr/pkg.
Les seuls trucs que je mets dans /usr/local sont des trucs compilés
hors système de packages. Ca c'est un _vrai_ OS.
--
Bruno Ducrot
-- Which is worse: ignorance or apathy?
-- Don't know. Don't care.
> Michel Talon wrote: >> L'argument >> de la place occupée sur les machines de très petite taille ne tien t pas >> un instant, il suffit de virer manu militari /usr/include et >> /usr/share/doc si on veut faire une installation très légère.
> En gros, tu considères qu'il est plus rapide d'installer la distribut ion > complète, puis de virer ce qui est inutile que de n'installer que ce qui > est nécessaire. C'est rigolo comme façon, de voir.
Le monsieur est en train de parler d'un veritable OS.
/usr/include et /usr/share/doc ne sont pas pollues par les applications tierces, qui s'installent naturellement dans /usr/local.
Sur mon véritable OS, les applis tierces s'installent dans /usr/pkg. Les seuls trucs que je mets dans /usr/local sont des trucs compilés hors système de packages. Ca c'est un _vrai_ OS.
-- Bruno Ducrot
-- Which is worse: ignorance or apathy? -- Don't know. Don't care.
Patrice Karatchentzeff
totof01 a écrit :
Sur mon véritable OS, les applis tierces s'installent dans /usr/pkg. Les seuls trucs que je mets dans /usr/local sont des trucs compilés hors système de packages. Ca c'est un _vrai_ OS.
Sur mon véritable OS, les applis tierces s'installent dans /usr/pkg.
Les seuls trucs que je mets dans /usr/local sont des trucs compilés
hors système de packages. Ca c'est un _vrai_ OS.
Sur mon véritable OS, les applis tierces s'installent dans /usr/pkg. Les seuls trucs que je mets dans /usr/local sont des trucs compilés hors système de packages. Ca c'est un _vrai_ OS.
Sur mon véritable OS, les applis tierces s'installent dans /usr/pkg. Les seuls trucs que je mets dans /usr/local sont des trucs compilés hors système de packages. Ca c'est un _vrai_ OS.
Oui, je suis assez d'accord avec le point de vue de NetBSD a ce niveau. /usr pour le systeme, /usr/pkg pour les application en packages et /usr/local pour les trucs compiles maison.
100 fois plus propre que la politique debianesque (et bordelique) de tout mettre dans /usr
totof01 wrote:
Sur mon véritable OS, les applis tierces s'installent dans /usr/pkg.
Les seuls trucs que je mets dans /usr/local sont des trucs compilés
hors système de packages. Ca c'est un _vrai_ OS.
Oui, je suis assez d'accord avec le point de vue de NetBSD a ce niveau.
/usr pour le systeme, /usr/pkg pour les application en packages et
/usr/local pour les trucs compiles maison.
100 fois plus propre que la politique debianesque (et bordelique) de
tout mettre dans /usr
Sur mon véritable OS, les applis tierces s'installent dans /usr/pkg. Les seuls trucs que je mets dans /usr/local sont des trucs compilés hors système de packages. Ca c'est un _vrai_ OS.
Oui, je suis assez d'accord avec le point de vue de NetBSD a ce niveau. /usr pour le systeme, /usr/pkg pour les application en packages et /usr/local pour les trucs compiles maison.
100 fois plus propre que la politique debianesque (et bordelique) de tout mettre dans /usr
JKB
Le 01-12-2009, ? propos de Re: Journées portes-ouvertes sur fcold., Stephane TOUGARD ?crivait dans fr.comp.os.linux.debats :
totof01 wrote:
Sur mon véritable OS, les applis tierces s'installent dans /usr/pkg. Les seuls trucs que je mets dans /usr/local sont des trucs compilés hors système de packages. Ca c'est un _vrai_ OS.
Oui, je suis assez d'accord avec le point de vue de NetBSD a ce niveau. /usr pour le systeme, /usr/pkg pour les application en packages et /usr/local pour les trucs compiles maison.
100 fois plus propre que la politique debianesque (et bordelique) de tout mettre dans /usr
Marchons gaiment dans le troll ! Et la politique de Solaris de remplacer à la fin de la phase d'installation /bin et /sbin par un lien sur /usr/bin et /usr/sbin obligeant d'avoir /usr accessible lors du boot ? Et le fait pour le même système d'avoir je ne sais pas combien de 'ps' tous différents ?
Le côté 'je colle ce qui est nécessaire au boot dans /bin et /sbin et les applications dans /usr/bin et /usr/sbini' n'est pas idiot du tout. Le fait de coller les applications dans /usr/local peut se justifier aussi. Mais le coup de NetBSD qui les met dans /usr/pkg, c'est assez amusant d'autant que tu as rapidement des problèmes d'édition des liens avec des applications dont les scripts configure ont été écrits par des pieds (du style je cherche /usr/pkg/lib/libpq.so qui n'est pas là, mais dans /usr/pkg/lib/postgres/libpq.so alors que les fichiers include sont dans /usr/pkg/include et non /usr/pkg/include/postgresql !). C'est vraiment l'un des trucs cons dans NetBSD. Sur ce coup, FreeBSD est plus logique avec /usr/local. Tu vas encore me dire que ça ne change rien, et bien si. Les scripts configure créent par défaut une installation dans /usr/local, donc les développeurs ont testé l'installation dans /usr/local alors qu'ils ne testent que rarement une installation ailleurs.
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
Le 01-12-2009, ? propos de
Re: Journées portes-ouvertes sur fcold.,
Stephane TOUGARD ?crivait dans fr.comp.os.linux.debats :
totof01 wrote:
Sur mon véritable OS, les applis tierces s'installent dans /usr/pkg.
Les seuls trucs que je mets dans /usr/local sont des trucs compilés
hors système de packages. Ca c'est un _vrai_ OS.
Oui, je suis assez d'accord avec le point de vue de NetBSD a ce niveau.
/usr pour le systeme, /usr/pkg pour les application en packages et
/usr/local pour les trucs compiles maison.
100 fois plus propre que la politique debianesque (et bordelique) de
tout mettre dans /usr
Marchons gaiment dans le troll ! Et la politique de Solaris de
remplacer à la fin de la phase d'installation /bin et /sbin par un
lien sur /usr/bin et /usr/sbin obligeant d'avoir /usr accessible
lors du boot ? Et le fait pour le même système d'avoir je ne sais
pas combien de 'ps' tous différents ?
Le côté 'je colle ce qui est nécessaire au boot dans /bin et /sbin et
les applications dans /usr/bin et /usr/sbini' n'est pas idiot du tout.
Le fait de coller les applications dans /usr/local peut se justifier
aussi. Mais le coup de NetBSD qui les met dans /usr/pkg, c'est assez
amusant d'autant que tu as rapidement des problèmes d'édition des
liens avec des applications dont les scripts configure ont été
écrits par des pieds (du style je cherche /usr/pkg/lib/libpq.so qui
n'est pas là, mais dans /usr/pkg/lib/postgres/libpq.so alors que les
fichiers include sont dans /usr/pkg/include et non
/usr/pkg/include/postgresql !). C'est vraiment l'un des trucs cons
dans NetBSD. Sur ce coup, FreeBSD est plus logique avec /usr/local.
Tu vas encore me dire que ça ne change rien, et bien si. Les scripts
configure créent par défaut une installation dans /usr/local, donc
les développeurs ont testé l'installation dans /usr/local alors
qu'ils ne testent que rarement une installation ailleurs.
JKB
--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
Le 01-12-2009, ? propos de Re: Journées portes-ouvertes sur fcold., Stephane TOUGARD ?crivait dans fr.comp.os.linux.debats :
totof01 wrote:
Sur mon véritable OS, les applis tierces s'installent dans /usr/pkg. Les seuls trucs que je mets dans /usr/local sont des trucs compilés hors système de packages. Ca c'est un _vrai_ OS.
Oui, je suis assez d'accord avec le point de vue de NetBSD a ce niveau. /usr pour le systeme, /usr/pkg pour les application en packages et /usr/local pour les trucs compiles maison.
100 fois plus propre que la politique debianesque (et bordelique) de tout mettre dans /usr
Marchons gaiment dans le troll ! Et la politique de Solaris de remplacer à la fin de la phase d'installation /bin et /sbin par un lien sur /usr/bin et /usr/sbin obligeant d'avoir /usr accessible lors du boot ? Et le fait pour le même système d'avoir je ne sais pas combien de 'ps' tous différents ?
Le côté 'je colle ce qui est nécessaire au boot dans /bin et /sbin et les applications dans /usr/bin et /usr/sbini' n'est pas idiot du tout. Le fait de coller les applications dans /usr/local peut se justifier aussi. Mais le coup de NetBSD qui les met dans /usr/pkg, c'est assez amusant d'autant que tu as rapidement des problèmes d'édition des liens avec des applications dont les scripts configure ont été écrits par des pieds (du style je cherche /usr/pkg/lib/libpq.so qui n'est pas là, mais dans /usr/pkg/lib/postgres/libpq.so alors que les fichiers include sont dans /usr/pkg/include et non /usr/pkg/include/postgresql !). C'est vraiment l'un des trucs cons dans NetBSD. Sur ce coup, FreeBSD est plus logique avec /usr/local. Tu vas encore me dire que ça ne change rien, et bien si. Les scripts configure créent par défaut une installation dans /usr/local, donc les développeurs ont testé l'installation dans /usr/local alors qu'ils ne testent que rarement une installation ailleurs.
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
Stephane TOUGARD
JKB wrote:
Marchons gaiment dans le troll ! Et la politique de Solaris de remplacer à la fin de la phase d'installation /bin et /sbin par un lien sur /usr/bin et /usr/sbin obligeant d'avoir /usr accessible lors du boot ? Et le fait pour le même système d'avoir je ne sais pas combien de 'ps' tous différents ?
Que Solaris soit un bordel absolu n'est un secret pour personne. Il y a meme pas de troll la dedans, au pire un consensus mou.
JKB wrote:
Marchons gaiment dans le troll ! Et la politique de Solaris de
remplacer à la fin de la phase d'installation /bin et /sbin par un
lien sur /usr/bin et /usr/sbin obligeant d'avoir /usr accessible
lors du boot ? Et le fait pour le même système d'avoir je ne sais
pas combien de 'ps' tous différents ?
Que Solaris soit un bordel absolu n'est un secret pour personne. Il y a
meme pas de troll la dedans, au pire un consensus mou.
Marchons gaiment dans le troll ! Et la politique de Solaris de remplacer à la fin de la phase d'installation /bin et /sbin par un lien sur /usr/bin et /usr/sbin obligeant d'avoir /usr accessible lors du boot ? Et le fait pour le même système d'avoir je ne sais pas combien de 'ps' tous différents ?
Que Solaris soit un bordel absolu n'est un secret pour personne. Il y a meme pas de troll la dedans, au pire un consensus mou.
totof01
On 1 déc, 09:16, JKB wrote:
Marchons gaiment dans le troll ! Et la politique de Solar is de remplacer à la fin de la phase d'installation /bin et / sbin par un lien sur /usr/bin et /usr/sbin obligeant d'avoir /usr acc essible lors du boot ? Et le fait pour le même système d'avoi r je ne sais pas combien de 'ps' tous différents ?
Tu trouve que sur HP-UX c'est mieux ? Un seul PS et devoir initialiser une variable pour avoir le comportement voulu ? Au moins sur Solaris c'est identifiable : les diverses versions de ps si je me souviens bien sont dans des répertoires différents.
Le côté 'je colle ce qui est nécessaire au boot dan s /bin et /sbin et les applications dans /usr/bin et /usr/sbini' n'est pas i diot du tout. Le fait de coller les applications dans /usr/local peut s e justifier aussi.
Mais le coup de NetBSD qui les met dans /usr/pkg, c'est assez
amusant d'autant que tu as rapidement des problèmes d' édition des liens avec des applications dont les scripts configure on t été écrits par des pieds (du style je cherche /usr/pkg/lib/ libpq.so qui n'est pas là, mais dans /usr/pkg/lib/postgres/libpq.so alors que les fichiers include sont dans /usr/pkg/include et non /usr/pkg/include/postgresql !). C'est vraiment l'un des t rucs cons dans NetBSD. Sur ce coup, FreeBSD est plus logique avec / usr/local. Tu vas encore me dire que ça ne change rien, et bien si . Les scripts configure créent par défaut une installation dans /us r/local, donc les développeurs ont testé l'installation dans /usr/l ocal alors qu'ils ne testent que rarement une installation ailleurs.
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2 % de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
On 1 déc, 09:16, JKB <knatsc...@koenigsberg.fr> wrote:
Marchons gaiment dans le troll ! Et la politique de Solar is de
remplacer à la fin de la phase d'installation /bin et / sbin par un
lien sur /usr/bin et /usr/sbin obligeant d'avoir /usr acc essible
lors du boot ? Et le fait pour le même système d'avoi r je ne sais
pas combien de 'ps' tous différents ?
Tu trouve que sur HP-UX c'est mieux ? Un seul PS et devoir initialiser
une variable pour avoir le comportement voulu ? Au moins sur Solaris
c'est identifiable : les diverses versions de ps si je me souviens
bien sont dans des répertoires différents.
Le côté 'je colle ce qui est nécessaire au boot dan s /bin et /sbin et
les applications dans /usr/bin et /usr/sbini' n'est pas i diot du tout.
Le fait de coller les applications dans /usr/local peut s e justifier
aussi.
Mais le coup de NetBSD qui les met dans /usr/pkg, c'est assez
amusant d'autant que tu as rapidement des problèmes d' édition des
liens avec des applications dont les scripts configure on t été
écrits par des pieds (du style je cherche /usr/pkg/lib/ libpq.so qui
n'est pas là, mais dans /usr/pkg/lib/postgres/libpq.so alors que les
fichiers include sont dans /usr/pkg/include et non
/usr/pkg/include/postgresql !). C'est vraiment l'un des t rucs cons
dans NetBSD. Sur ce coup, FreeBSD est plus logique avec / usr/local.
Tu vas encore me dire que ça ne change rien, et bien si . Les scripts
configure créent par défaut une installation dans /us r/local, donc
les développeurs ont testé l'installation dans /usr/l ocal alors
qu'ils ne testent que rarement une installation ailleurs.
JKB
--
Le cerveau, c'est un véritable scandale écologique. Il représente 2 % de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
Marchons gaiment dans le troll ! Et la politique de Solar is de remplacer à la fin de la phase d'installation /bin et / sbin par un lien sur /usr/bin et /usr/sbin obligeant d'avoir /usr acc essible lors du boot ? Et le fait pour le même système d'avoi r je ne sais pas combien de 'ps' tous différents ?
Tu trouve que sur HP-UX c'est mieux ? Un seul PS et devoir initialiser une variable pour avoir le comportement voulu ? Au moins sur Solaris c'est identifiable : les diverses versions de ps si je me souviens bien sont dans des répertoires différents.
Le côté 'je colle ce qui est nécessaire au boot dan s /bin et /sbin et les applications dans /usr/bin et /usr/sbini' n'est pas i diot du tout. Le fait de coller les applications dans /usr/local peut s e justifier aussi.
Mais le coup de NetBSD qui les met dans /usr/pkg, c'est assez
amusant d'autant que tu as rapidement des problèmes d' édition des liens avec des applications dont les scripts configure on t été écrits par des pieds (du style je cherche /usr/pkg/lib/ libpq.so qui n'est pas là, mais dans /usr/pkg/lib/postgres/libpq.so alors que les fichiers include sont dans /usr/pkg/include et non /usr/pkg/include/postgresql !). C'est vraiment l'un des t rucs cons dans NetBSD. Sur ce coup, FreeBSD est plus logique avec / usr/local. Tu vas encore me dire que ça ne change rien, et bien si . Les scripts configure créent par défaut une installation dans /us r/local, donc les développeurs ont testé l'installation dans /usr/l ocal alors qu'ils ne testent que rarement une installation ailleurs.
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2 % de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
totof01
GRRRRR !!!! Pas pratique Google News .... Vous connaissez un moyen plus efficace de troller gaiement derrière un proxy ?
On 1 déc, 09:16, JKB wrote:
Le fait de coller les applications dans /usr/local peut s e justifier aussi. Mais le coup de NetBSD qui les met dans /usr/pkg, c'est assez amusant d'autant que tu as rapidement des problèmes d' édition des liens avec des applications dont les scripts configure on t été écrits par des pieds (du style je cherche /usr/pkg/lib/ libpq.so qui n'est pas là, mais dans /usr/pkg/lib/postgres/libpq.so alors que les fichiers include sont dans /usr/pkg/include et non /usr/pkg/include/postgresql !).
Si les gens écrivent des scripts avec les pieds, c'est quand même pas la faute aux dev NetBSD non ?
C'est vraiment l'un des trucs cons dans NetBSD.
NetBSD n'est pas fautif ici, ce sont les développeurs qui ne savent pas écrire un script configure. Et puis je ne suis pas sur que ce soit insurmontable pour le packager .....
Sur ce coup, FreeBSD est plus logique avec /usr/local. Tu vas encore me dire que ça ne change rien, et bien si . Les scripts configure créent par défaut une installation dans /us r/local, donc les développeurs ont testé l'installation dans /usr/l ocal alors qu'ils ne testent que rarement une installation ailleurs.
Ben avec Debian ça se passe comment, vu que tout est dans /usr ?
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2 % de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
GRRRRR !!!! Pas pratique Google News .... Vous connaissez un moyen
plus efficace de troller gaiement derrière un proxy ?
On 1 déc, 09:16, JKB <knatsc...@koenigsberg.fr> wrote:
Le fait de coller les applications dans /usr/local peut s e justifier
aussi. Mais le coup de NetBSD qui les met dans /usr/pkg, c'est assez
amusant d'autant que tu as rapidement des problèmes d' édition des
liens avec des applications dont les scripts configure on t été
écrits par des pieds (du style je cherche /usr/pkg/lib/ libpq.so qui
n'est pas là, mais dans /usr/pkg/lib/postgres/libpq.so alors que les
fichiers include sont dans /usr/pkg/include et non
/usr/pkg/include/postgresql !).
Si les gens écrivent des scripts avec les pieds, c'est quand même pas
la faute aux dev NetBSD non ?
C'est vraiment l'un des trucs cons dans NetBSD.
NetBSD n'est pas fautif ici, ce sont les développeurs qui ne savent
pas écrire un script configure. Et puis je ne suis pas sur que ce soit
insurmontable pour le packager .....
Sur ce coup, FreeBSD est plus logique avec /usr/local.
Tu vas encore me dire que ça ne change rien, et bien si . Les scripts
configure créent par défaut une installation dans /us r/local, donc
les développeurs ont testé l'installation dans /usr/l ocal alors
qu'ils ne testent que rarement une installation ailleurs.
Ben avec Debian ça se passe comment, vu que tout est dans /usr ?
JKB
--
Le cerveau, c'est un véritable scandale écologique. Il représente 2 % de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
GRRRRR !!!! Pas pratique Google News .... Vous connaissez un moyen plus efficace de troller gaiement derrière un proxy ?
On 1 déc, 09:16, JKB wrote:
Le fait de coller les applications dans /usr/local peut s e justifier aussi. Mais le coup de NetBSD qui les met dans /usr/pkg, c'est assez amusant d'autant que tu as rapidement des problèmes d' édition des liens avec des applications dont les scripts configure on t été écrits par des pieds (du style je cherche /usr/pkg/lib/ libpq.so qui n'est pas là, mais dans /usr/pkg/lib/postgres/libpq.so alors que les fichiers include sont dans /usr/pkg/include et non /usr/pkg/include/postgresql !).
Si les gens écrivent des scripts avec les pieds, c'est quand même pas la faute aux dev NetBSD non ?
C'est vraiment l'un des trucs cons dans NetBSD.
NetBSD n'est pas fautif ici, ce sont les développeurs qui ne savent pas écrire un script configure. Et puis je ne suis pas sur que ce soit insurmontable pour le packager .....
Sur ce coup, FreeBSD est plus logique avec /usr/local. Tu vas encore me dire que ça ne change rien, et bien si . Les scripts configure créent par défaut une installation dans /us r/local, donc les développeurs ont testé l'installation dans /usr/l ocal alors qu'ils ne testent que rarement une installation ailleurs.
Ben avec Debian ça se passe comment, vu que tout est dans /usr ?
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2 % de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
JKB
Le 01-12-2009, ? propos de Re: Journées portes-ouvertes sur fcold., totof01 ?crivait dans fr.comp.os.linux.debats :
On 1 déc, 09:16, JKB wrote:
Marchons gaiment dans le troll ! Et la politique de Solaris de remplacer à la fin de la phase d'installation /bin et /sbin par un lien sur /usr/bin et /usr/sbin obligeant d'avoir /usr accessible lors du boot ? Et le fait pour le même système d'avoir je ne sais pas combien de 'ps' tous différents ?
Tu trouve que sur HP-UX c'est mieux ? Un seul PS et devoir initialiser une variable pour avoir le comportement voulu ? Au moins sur Solaris c'est identifiable : les diverses versions de ps si je me souviens bien sont dans des répertoires différents.
Oui, mais en contrepartie, tu es contraint d'utiliser PATH ou tout autre mécanisme pour avoir le bon.
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
Le 01-12-2009, ? propos de
Re: Journées portes-ouvertes sur fcold.,
totof01 ?crivait dans fr.comp.os.linux.debats :
On 1 déc, 09:16, JKB <knatsc...@koenigsberg.fr> wrote:
Marchons gaiment dans le troll ! Et la politique de Solaris de
remplacer à la fin de la phase d'installation /bin et /sbin par un
lien sur /usr/bin et /usr/sbin obligeant d'avoir /usr accessible
lors du boot ? Et le fait pour le même système d'avoir je ne sais
pas combien de 'ps' tous différents ?
Tu trouve que sur HP-UX c'est mieux ? Un seul PS et devoir initialiser
une variable pour avoir le comportement voulu ? Au moins sur Solaris
c'est identifiable : les diverses versions de ps si je me souviens
bien sont dans des répertoires différents.
Oui, mais en contrepartie, tu es contraint d'utiliser PATH ou tout
autre mécanisme pour avoir le bon.
JKB
--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
Le 01-12-2009, ? propos de Re: Journées portes-ouvertes sur fcold., totof01 ?crivait dans fr.comp.os.linux.debats :
On 1 déc, 09:16, JKB wrote:
Marchons gaiment dans le troll ! Et la politique de Solaris de remplacer à la fin de la phase d'installation /bin et /sbin par un lien sur /usr/bin et /usr/sbin obligeant d'avoir /usr accessible lors du boot ? Et le fait pour le même système d'avoir je ne sais pas combien de 'ps' tous différents ?
Tu trouve que sur HP-UX c'est mieux ? Un seul PS et devoir initialiser une variable pour avoir le comportement voulu ? Au moins sur Solaris c'est identifiable : les diverses versions de ps si je me souviens bien sont dans des répertoires différents.
Oui, mais en contrepartie, tu es contraint d'utiliser PATH ou tout autre mécanisme pour avoir le bon.
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
