C'est très facile. Sous Solaris, par exemple, tu n'as pas ncurses,
mais un curses fourni par Sun^Oracle qui est subtilement
incompatible avec ncurses.
Tu dois donc recompiler ncurses, et là,
tu as intérêt de lier statiquement le ncurses à ton exécutable
Ponctuel ? Ça m'a juste pris deux ans parce que mes architectures
cibles n'étaient pas vraiment une priorité.
Et lorsqu'il te _faut_ openssl 1.0.0 ? Tu réponds aussi 'tu n'as
qu'à utiliser 0.9.8x ' ?
C'est très facile. Sous Solaris, par exemple, tu n'as pas ncurses,
mais un curses fourni par Sun^Oracle qui est subtilement
incompatible avec ncurses.
Tu dois donc recompiler ncurses, et là,
tu as intérêt de lier statiquement le ncurses à ton exécutable
Ponctuel ? Ça m'a juste pris deux ans parce que mes architectures
cibles n'étaient pas vraiment une priorité.
Et lorsqu'il te _faut_ openssl 1.0.0 ? Tu réponds aussi 'tu n'as
qu'à utiliser 0.9.8x ' ?
C'est très facile. Sous Solaris, par exemple, tu n'as pas ncurses,
mais un curses fourni par Sun^Oracle qui est subtilement
incompatible avec ncurses.
Tu dois donc recompiler ncurses, et là,
tu as intérêt de lier statiquement le ncurses à ton exécutable
Ponctuel ? Ça m'a juste pris deux ans parce que mes architectures
cibles n'étaient pas vraiment une priorité.
Et lorsqu'il te _faut_ openssl 1.0.0 ? Tu réponds aussi 'tu n'as
qu'à utiliser 0.9.8x ' ?
On 08/09/2010 10:15 PM, JEf wrote:On 08/08/10 22:24, Tonton Th wrote:Quand à tirer les libs dans le répertoire de l'application,
c'est quand même un truc de merde. Amha.systèmes de machines virtuelles). Mais sur un desktop grand public où le
but est que toute appli doit fonctionner peu importe les autres softs
installés ?
C'est toujours un truc de merde.
On 08/09/2010 10:15 PM, JEf wrote:
On 08/08/10 22:24, Tonton Th wrote:
Quand à tirer les libs dans le répertoire de l'application,
c'est quand même un truc de merde. Amha.
systèmes de machines virtuelles). Mais sur un desktop grand public où le
but est que toute appli doit fonctionner peu importe les autres softs
installés ?
C'est toujours un truc de merde.
On 08/09/2010 10:15 PM, JEf wrote:On 08/08/10 22:24, Tonton Th wrote:Quand à tirer les libs dans le répertoire de l'application,
c'est quand même un truc de merde. Amha.systèmes de machines virtuelles). Mais sur un desktop grand public où le
but est que toute appli doit fonctionner peu importe les autres softs
installés ?
C'est toujours un truc de merde.
Je prends cet exemple là car il m'est arrivé récemment.
Je prends cet exemple là car il m'est arrivé récemment.
Je prends cet exemple là car il m'est arrivé récemment.
JKB wrote in message :C'est très facile. Sous Solaris, par exemple, tu n'as pas ncurses,
mais un curses fourni par Sun^Oracle qui est subtilement
incompatible avec ncurses.
Solaris seul (par opposition à Solaris où on a installé tous les outils GNU
et les bibliothèques libres principales) est une merde. So what?
Tu dois donc recompiler ncurses, et là,
tu as intérêt de lier statiquement le ncurses à ton exécutable
Quel exécutable ? Tu écris « nécessite ncurses » dans le README, et tu
laisses celui qui veut le compiler pour un système qui n'a pas ncurses en
standard se débrouiller.
Ponctuel ? Ça m'a juste pris deux ans parce que mes architectures
cibles n'étaient pas vraiment une priorité.
Oui, ponctuel. Le temps mis à corriger n'a pas d'importance, ça reste un
seul bug, certainement pas une généralité.
Et lorsqu'il te _faut_ openssl 1.0.0 ? Tu réponds aussi 'tu n'as
qu'à utiliser 0.9.8x ' ?
Non, je réponds : tu écris dans le README qu'il faut OpenSSL 1.0.0 au moins,
et tu laisses ceux qui veulent compiler ur un système trop ancien se
débrouiller.
Livrer une version perso d'OpenSSL, que ce soit par liaison statique ou un
.so embarqué, est particulièrement irresponsable, parce qu'OpenSSL a trait à
la sécurité et qu'une version perso ne sera pas concernée par les mises à
jour.
JKB wrote in message <slrni624dg.4v8.jkb@rayleigh.systella.fr>:
C'est très facile. Sous Solaris, par exemple, tu n'as pas ncurses,
mais un curses fourni par Sun^Oracle qui est subtilement
incompatible avec ncurses.
Solaris seul (par opposition à Solaris où on a installé tous les outils GNU
et les bibliothèques libres principales) est une merde. So what?
Tu dois donc recompiler ncurses, et là,
tu as intérêt de lier statiquement le ncurses à ton exécutable
Quel exécutable ? Tu écris « nécessite ncurses » dans le README, et tu
laisses celui qui veut le compiler pour un système qui n'a pas ncurses en
standard se débrouiller.
Ponctuel ? Ça m'a juste pris deux ans parce que mes architectures
cibles n'étaient pas vraiment une priorité.
Oui, ponctuel. Le temps mis à corriger n'a pas d'importance, ça reste un
seul bug, certainement pas une généralité.
Et lorsqu'il te _faut_ openssl 1.0.0 ? Tu réponds aussi 'tu n'as
qu'à utiliser 0.9.8x ' ?
Non, je réponds : tu écris dans le README qu'il faut OpenSSL 1.0.0 au moins,
et tu laisses ceux qui veulent compiler ur un système trop ancien se
débrouiller.
Livrer une version perso d'OpenSSL, que ce soit par liaison statique ou un
.so embarqué, est particulièrement irresponsable, parce qu'OpenSSL a trait à
la sécurité et qu'une version perso ne sera pas concernée par les mises à
jour.
JKB wrote in message :C'est très facile. Sous Solaris, par exemple, tu n'as pas ncurses,
mais un curses fourni par Sun^Oracle qui est subtilement
incompatible avec ncurses.
Solaris seul (par opposition à Solaris où on a installé tous les outils GNU
et les bibliothèques libres principales) est une merde. So what?
Tu dois donc recompiler ncurses, et là,
tu as intérêt de lier statiquement le ncurses à ton exécutable
Quel exécutable ? Tu écris « nécessite ncurses » dans le README, et tu
laisses celui qui veut le compiler pour un système qui n'a pas ncurses en
standard se débrouiller.
Ponctuel ? Ça m'a juste pris deux ans parce que mes architectures
cibles n'étaient pas vraiment une priorité.
Oui, ponctuel. Le temps mis à corriger n'a pas d'importance, ça reste un
seul bug, certainement pas une généralité.
Et lorsqu'il te _faut_ openssl 1.0.0 ? Tu réponds aussi 'tu n'as
qu'à utiliser 0.9.8x ' ?
Non, je réponds : tu écris dans le README qu'il faut OpenSSL 1.0.0 au moins,
et tu laisses ceux qui veulent compiler ur un système trop ancien se
débrouiller.
Livrer une version perso d'OpenSSL, que ce soit par liaison statique ou un
.so embarqué, est particulièrement irresponsable, parce qu'OpenSSL a trait à
la sécurité et qu'une version perso ne sera pas concernée par les mises à
jour.
JEf wrote in message:Je prends cet exemple là car il m'est arrivé récemment.
Ou bien parce que tu n'en as pas d'autres ?
Des bugs dans le référencement des dépendances des paquets, ça arrive, de
temps en temps. Évidemment. Mais du fait de la gestion centralisée des
paquets, qui vient avec la gestion des dépendances, ça finit par être
corrigé.
D'un autre côté, chez mac, combien de bundles restent avec une version
buggée d'une bibliothèque, alors que la bibliothèque elle-même a été
corrigée depuis longtemps, simplement parce que l'application elle-même n'a
pas eu de nouvelle version ?
JEf wrote in message<6d6dnTWHe7cJh_zRnZ2dnUVZ8qqdnZ2d@giganews.com>:
Je prends cet exemple là car il m'est arrivé récemment.
Ou bien parce que tu n'en as pas d'autres ?
Des bugs dans le référencement des dépendances des paquets, ça arrive, de
temps en temps. Évidemment. Mais du fait de la gestion centralisée des
paquets, qui vient avec la gestion des dépendances, ça finit par être
corrigé.
D'un autre côté, chez mac, combien de bundles restent avec une version
buggée d'une bibliothèque, alors que la bibliothèque elle-même a été
corrigée depuis longtemps, simplement parce que l'application elle-même n'a
pas eu de nouvelle version ?
JEf wrote in message:Je prends cet exemple là car il m'est arrivé récemment.
Ou bien parce que tu n'en as pas d'autres ?
Des bugs dans le référencement des dépendances des paquets, ça arrive, de
temps en temps. Évidemment. Mais du fait de la gestion centralisée des
paquets, qui vient avec la gestion des dépendances, ça finit par être
corrigé.
D'un autre côté, chez mac, combien de bundles restent avec une version
buggée d'une bibliothèque, alors que la bibliothèque elle-même a été
corrigée depuis longtemps, simplement parce que l'application elle-même n'a
pas eu de nouvelle version ?
Le fait que le curses de Solaris est subtilement incomaptible avec
le ncurses de Gnu et que la présence des deux dans les chemins par
défaut fout le bordel, soit pour les outils du système, soit pour
les outils Gnu en fonction de l'ordre de résolution. Je ne vois pas
ce que tu refuses de comprendre.
C'est un peu facile.
Non, ça reste un ensemble de bugs inhérents au script configure qui
prétendait utiliser -lform (et d'autres) pour lier statiquement des
bibliothèques.
Debian/squeeze est donc un système ancien.
Conclure aussi abruptement est une connerie car tu ne sais pas ce
que j'utilise dans OpenSSL ni même si j'utilise des fonctions
critiques du point de vue de la sécurité du système. Il y a des tas
de fonctions utiles dans OpenSSL qui ne concernent absolument pas la
sécurité du système hôte.
Le fait que le curses de Solaris est subtilement incomaptible avec
le ncurses de Gnu et que la présence des deux dans les chemins par
défaut fout le bordel, soit pour les outils du système, soit pour
les outils Gnu en fonction de l'ordre de résolution. Je ne vois pas
ce que tu refuses de comprendre.
C'est un peu facile.
Non, ça reste un ensemble de bugs inhérents au script configure qui
prétendait utiliser -lform (et d'autres) pour lier statiquement des
bibliothèques.
Debian/squeeze est donc un système ancien.
Conclure aussi abruptement est une connerie car tu ne sais pas ce
que j'utilise dans OpenSSL ni même si j'utilise des fonctions
critiques du point de vue de la sécurité du système. Il y a des tas
de fonctions utiles dans OpenSSL qui ne concernent absolument pas la
sécurité du système hôte.
Le fait que le curses de Solaris est subtilement incomaptible avec
le ncurses de Gnu et que la présence des deux dans les chemins par
défaut fout le bordel, soit pour les outils du système, soit pour
les outils Gnu en fonction de l'ordre de résolution. Je ne vois pas
ce que tu refuses de comprendre.
C'est un peu facile.
Non, ça reste un ensemble de bugs inhérents au script configure qui
prétendait utiliser -lform (et d'autres) pour lier statiquement des
bibliothèques.
Debian/squeeze est donc un système ancien.
Conclure aussi abruptement est une connerie car tu ne sais pas ce
que j'utilise dans OpenSSL ni même si j'utilise des fonctions
critiques du point de vue de la sécurité du système. Il y a des tas
de fonctions utiles dans OpenSSL qui ne concernent absolument pas la
sécurité du système hôte.
Mais que j'utilise plutôt linux en server et c'est généralement
corrigé plus vite que là car le bug est présent en ubuntu server 9.04 et
9.10
En effet c'est possible. Mais je préfère utiliser la librairie que le
dev à utiliser que de toujours avoir la dernière. En effet, un soft peu
très bien ne plus fonctionner avec la dernière version de la lib.
En tout état de cause, si le soft est opensource tu peux toujours
compiler la dernière version.
Mais que j'utilise plutôt linux en server et c'est généralement
corrigé plus vite que là car le bug est présent en ubuntu server 9.04 et
9.10
En effet c'est possible. Mais je préfère utiliser la librairie que le
dev à utiliser que de toujours avoir la dernière. En effet, un soft peu
très bien ne plus fonctionner avec la dernière version de la lib.
En tout état de cause, si le soft est opensource tu peux toujours
compiler la dernière version.
Mais que j'utilise plutôt linux en server et c'est généralement
corrigé plus vite que là car le bug est présent en ubuntu server 9.04 et
9.10
En effet c'est possible. Mais je préfère utiliser la librairie que le
dev à utiliser que de toujours avoir la dernière. En effet, un soft peu
très bien ne plus fonctionner avec la dernière version de la lib.
En tout état de cause, si le soft est opensource tu peux toujours
compiler la dernière version.
JKB wrote in message :Le fait que le curses de Solaris est subtilement incomaptible avec
le ncurses de Gnu et que la présence des deux dans les chemins par
défaut fout le bordel, soit pour les outils du système, soit pour
les outils Gnu en fonction de l'ordre de résolution. Je ne vois pas
ce que tu refuses de comprendre.
C'est toi qui ne comprend pas ce que je dis. Tu peux citer toutes les
difficultés liées à Solaris que tu veux, tu ne feras qu'abonder dans mon
sens, puisque mon point est :
Si quelqu'un veut utiliser Solaris, qu'il se débrouille avec les merdes
inhérentes à Solaris, ce n'est pas le problème des développeurs.
C'est un peu facile.
C'est très facile. Justement.
Non, ça reste un ensemble de bugs inhérents au script configure qui
prétendait utiliser -lform (et d'autres) pour lier statiquement des
bibliothèques.
Aaaah, tu as des problèmes pour lier statiquement... Alors justement que
j'essaie de t'expliquer qu'il ne faut pas le faire.
Debian/squeeze est donc un système ancien.
Pour certaines choses, oui, évidemment.
Conclure aussi abruptement est une connerie car tu ne sais pas ce
que j'utilise dans OpenSSL ni même si j'utilise des fonctions
critiques du point de vue de la sécurité du système. Il y a des tas
de fonctions utiles dans OpenSSL qui ne concernent absolument pas la
sécurité du système hôte.
À part de la crypto, on se demande ce que tu pourrais faire avec OpenSSL.
Une faiblesse cryptographique, c'est toujours grave. Ou alors c'est que tu
n'avais pas besoin de crypto pour commencer.
JKB wrote in message <slrni627iq.4v8.jkb@rayleigh.systella.fr>:
Le fait que le curses de Solaris est subtilement incomaptible avec
le ncurses de Gnu et que la présence des deux dans les chemins par
défaut fout le bordel, soit pour les outils du système, soit pour
les outils Gnu en fonction de l'ordre de résolution. Je ne vois pas
ce que tu refuses de comprendre.
C'est toi qui ne comprend pas ce que je dis. Tu peux citer toutes les
difficultés liées à Solaris que tu veux, tu ne feras qu'abonder dans mon
sens, puisque mon point est :
Si quelqu'un veut utiliser Solaris, qu'il se débrouille avec les merdes
inhérentes à Solaris, ce n'est pas le problème des développeurs.
C'est un peu facile.
C'est très facile. Justement.
Non, ça reste un ensemble de bugs inhérents au script configure qui
prétendait utiliser -lform (et d'autres) pour lier statiquement des
bibliothèques.
Aaaah, tu as des problèmes pour lier statiquement... Alors justement que
j'essaie de t'expliquer qu'il ne faut pas le faire.
Debian/squeeze est donc un système ancien.
Pour certaines choses, oui, évidemment.
Conclure aussi abruptement est une connerie car tu ne sais pas ce
que j'utilise dans OpenSSL ni même si j'utilise des fonctions
critiques du point de vue de la sécurité du système. Il y a des tas
de fonctions utiles dans OpenSSL qui ne concernent absolument pas la
sécurité du système hôte.
À part de la crypto, on se demande ce que tu pourrais faire avec OpenSSL.
Une faiblesse cryptographique, c'est toujours grave. Ou alors c'est que tu
n'avais pas besoin de crypto pour commencer.
JKB wrote in message :Le fait que le curses de Solaris est subtilement incomaptible avec
le ncurses de Gnu et que la présence des deux dans les chemins par
défaut fout le bordel, soit pour les outils du système, soit pour
les outils Gnu en fonction de l'ordre de résolution. Je ne vois pas
ce que tu refuses de comprendre.
C'est toi qui ne comprend pas ce que je dis. Tu peux citer toutes les
difficultés liées à Solaris que tu veux, tu ne feras qu'abonder dans mon
sens, puisque mon point est :
Si quelqu'un veut utiliser Solaris, qu'il se débrouille avec les merdes
inhérentes à Solaris, ce n'est pas le problème des développeurs.
C'est un peu facile.
C'est très facile. Justement.
Non, ça reste un ensemble de bugs inhérents au script configure qui
prétendait utiliser -lform (et d'autres) pour lier statiquement des
bibliothèques.
Aaaah, tu as des problèmes pour lier statiquement... Alors justement que
j'essaie de t'expliquer qu'il ne faut pas le faire.
Debian/squeeze est donc un système ancien.
Pour certaines choses, oui, évidemment.
Conclure aussi abruptement est une connerie car tu ne sais pas ce
que j'utilise dans OpenSSL ni même si j'utilise des fonctions
critiques du point de vue de la sécurité du système. Il y a des tas
de fonctions utiles dans OpenSSL qui ne concernent absolument pas la
sécurité du système hôte.
À part de la crypto, on se demande ce que tu pourrais faire avec OpenSSL.
Une faiblesse cryptographique, c'est toujours grave. Ou alors c'est que tu
n'avais pas besoin de crypto pour commencer.
JEf wrote in message:Mais que j'utilise plutôt linux en server et c'est généralement
corrigé plus vite que là car le bug est présent en ubuntu server 9.04 et
9.10
Peut-être que cette merde de fail2ban est la dernière préoccupation des
développeurs Ubuntu...
En effet c'est possible. Mais je préfère utiliser la librairie que le
dev à utiliser que de toujours avoir la dernière. En effet, un soft peu
très bien ne plus fonctionner avec la dernière version de la lib.
Ça ne donne pas confiance dans les développeurs mac, ça. Les développeurs
sérieux se préoccupent de compatibilité, quand ils corrigent un bug dans une
bibliothèque, ils le font en préservant la compatibilité, vérifiée par une
batterie de tests si nécessaire, ou en annonçant clairement, par un
changement de version majeur, que la compatibilité n'est pas préservée.
En tout état de cause, si le soft est opensource tu peux toujours
compiler la dernière version.
Génial : le mac, pour qu'il soit utilisable, il faut l'utiliser comme on
utiliserait un Linux from scratch.
JEf wrote in message<gsudnTu7XryQvPzRnZ2dnUVZ7r-dnZ2d@giganews.com>:
Mais que j'utilise plutôt linux en server et c'est généralement
corrigé plus vite que là car le bug est présent en ubuntu server 9.04 et
9.10
Peut-être que cette merde de fail2ban est la dernière préoccupation des
développeurs Ubuntu...
En effet c'est possible. Mais je préfère utiliser la librairie que le
dev à utiliser que de toujours avoir la dernière. En effet, un soft peu
très bien ne plus fonctionner avec la dernière version de la lib.
Ça ne donne pas confiance dans les développeurs mac, ça. Les développeurs
sérieux se préoccupent de compatibilité, quand ils corrigent un bug dans une
bibliothèque, ils le font en préservant la compatibilité, vérifiée par une
batterie de tests si nécessaire, ou en annonçant clairement, par un
changement de version majeur, que la compatibilité n'est pas préservée.
En tout état de cause, si le soft est opensource tu peux toujours
compiler la dernière version.
Génial : le mac, pour qu'il soit utilisable, il faut l'utiliser comme on
utiliserait un Linux from scratch.
JEf wrote in message:Mais que j'utilise plutôt linux en server et c'est généralement
corrigé plus vite que là car le bug est présent en ubuntu server 9.04 et
9.10
Peut-être que cette merde de fail2ban est la dernière préoccupation des
développeurs Ubuntu...
En effet c'est possible. Mais je préfère utiliser la librairie que le
dev à utiliser que de toujours avoir la dernière. En effet, un soft peu
très bien ne plus fonctionner avec la dernière version de la lib.
Ça ne donne pas confiance dans les développeurs mac, ça. Les développeurs
sérieux se préoccupent de compatibilité, quand ils corrigent un bug dans une
bibliothèque, ils le font en préservant la compatibilité, vérifiée par une
batterie de tests si nécessaire, ou en annonçant clairement, par un
changement de version majeur, que la compatibilité n'est pas préservée.
En tout état de cause, si le soft est opensource tu peux toujours
compiler la dernière version.
Génial : le mac, pour qu'il soit utilisable, il faut l'utiliser comme on
utiliserait un Linux from scratch.
Si quelqu'un veut utiliser Solaris, qu'il se débrouille avec les merdes
inhérentes à Solaris, ce n'est pas le problème des développeurs.
Ah bon ?
Non, ça montre juste ta mentalité. Tu ne peux pas reprocher à
quelqu'un d'utiliser Solaris pour de _bonnes_ raisons.
Et lorsqu'il
utilise Solaris, c'est à toi de t'adapter puisque tu ne peux pas
l'envoyer balader d'un simple revers de main.
Là où ça se corse, c'est juste au moment où les
différentes bibliothèques se parchent sur les pieds et que les
versions qui se suivent de la même bibliothèque ont des ABI
subtilement incompatibles.
Tu peux utiliser OpenSSL pour cryper un fichier. S'il y a une
faiblesse de OpenSSL, elle est déjà dans le fichier que tu as
chiffré avec une version foireuse de la bibliothèque. Autre argument ?
Si quelqu'un veut utiliser Solaris, qu'il se débrouille avec les merdes
inhérentes à Solaris, ce n'est pas le problème des développeurs.
Ah bon ?
Non, ça montre juste ta mentalité. Tu ne peux pas reprocher à
quelqu'un d'utiliser Solaris pour de _bonnes_ raisons.
Et lorsqu'il
utilise Solaris, c'est à toi de t'adapter puisque tu ne peux pas
l'envoyer balader d'un simple revers de main.
Là où ça se corse, c'est juste au moment où les
différentes bibliothèques se parchent sur les pieds et que les
versions qui se suivent de la même bibliothèque ont des ABI
subtilement incompatibles.
Tu peux utiliser OpenSSL pour cryper un fichier. S'il y a une
faiblesse de OpenSSL, elle est déjà dans le fichier que tu as
chiffré avec une version foireuse de la bibliothèque. Autre argument ?
Si quelqu'un veut utiliser Solaris, qu'il se débrouille avec les merdes
inhérentes à Solaris, ce n'est pas le problème des développeurs.
Ah bon ?
Non, ça montre juste ta mentalité. Tu ne peux pas reprocher à
quelqu'un d'utiliser Solaris pour de _bonnes_ raisons.
Et lorsqu'il
utilise Solaris, c'est à toi de t'adapter puisque tu ne peux pas
l'envoyer balader d'un simple revers de main.
Là où ça se corse, c'est juste au moment où les
différentes bibliothèques se parchent sur les pieds et que les
versions qui se suivent de la même bibliothèque ont des ABI
subtilement incompatibles.
Tu peux utiliser OpenSSL pour cryper un fichier. S'il y a une
faiblesse de OpenSSL, elle est déjà dans le fichier que tu as
chiffré avec une version foireuse de la bibliothèque. Autre argument ?