Erwann ABALEA writes:
| Je ne vois pas comment un système Bien Conçu (tm) pourrait se sortir de
| cette situation sans tuer quelques process.
Le point était qu'un système bien conçu s'abstiendrait d'user de la
stupidité où l'utilisation de la valeur de retour (non nulle !) de
malloc provoque l'effondrement du système. Ou bien, il n'y a pas de
mémoire suffisante et l'implémentation remplit le contrat spécifié dans
la documentation en renvoyant un pointeur nul, ou bien il y en a assez
et il renvoie un pointeur sur une zone de mémoire utilisable selon le
contrat spécifié.
Cette idée d'overcommit n'est pas une nouveauté inventée par le
système que tu cites.
Elle a bien longtemps existé dans d'autres OS
commerciaux, qui l'ont essayée sur leurs utilisateurs avant de
finalement l'abandonner -- sur la pression des utilisateurs et
devant le besoin de plus de robustesse. Mais, les mauvaies idées ont
la vie dure, spécialement dans certaines parties du ghetto du logiciel
dit libre.
Erwann ABALEA <erwann@abalea.com> writes:
| Je ne vois pas comment un système Bien Conçu (tm) pourrait se sortir de
| cette situation sans tuer quelques process.
Le point était qu'un système bien conçu s'abstiendrait d'user de la
stupidité où l'utilisation de la valeur de retour (non nulle !) de
malloc provoque l'effondrement du système. Ou bien, il n'y a pas de
mémoire suffisante et l'implémentation remplit le contrat spécifié dans
la documentation en renvoyant un pointeur nul, ou bien il y en a assez
et il renvoie un pointeur sur une zone de mémoire utilisable selon le
contrat spécifié.
Cette idée d'overcommit n'est pas une nouveauté inventée par le
système que tu cites.
Elle a bien longtemps existé dans d'autres OS
commerciaux, qui l'ont essayée sur leurs utilisateurs avant de
finalement l'abandonner -- sur la pression des utilisateurs et
devant le besoin de plus de robustesse. Mais, les mauvaies idées ont
la vie dure, spécialement dans certaines parties du ghetto du logiciel
dit libre.
Erwann ABALEA writes:
| Je ne vois pas comment un système Bien Conçu (tm) pourrait se sortir de
| cette situation sans tuer quelques process.
Le point était qu'un système bien conçu s'abstiendrait d'user de la
stupidité où l'utilisation de la valeur de retour (non nulle !) de
malloc provoque l'effondrement du système. Ou bien, il n'y a pas de
mémoire suffisante et l'implémentation remplit le contrat spécifié dans
la documentation en renvoyant un pointeur nul, ou bien il y en a assez
et il renvoie un pointeur sur une zone de mémoire utilisable selon le
contrat spécifié.
Cette idée d'overcommit n'est pas une nouveauté inventée par le
système que tu cites.
Elle a bien longtemps existé dans d'autres OS
commerciaux, qui l'ont essayée sur leurs utilisateurs avant de
finalement l'abandonner -- sur la pression des utilisateurs et
devant le besoin de plus de robustesse. Mais, les mauvaies idées ont
la vie dure, spécialement dans certaines parties du ghetto du logiciel
dit libre.
Je crois qu'il y a une habitude que le monde dit du logiciel libre
doit abandonner, si il veut être pris au sérieux et être un
compétiteur serieux : arrêter de dire que parce que le source est
diposnible, l'utilisateur peut tout modifier (même si cette liberté
lui conférée par les licences idioines) et arrêter les
expérimentations hasardeuses -- même si elles sont corrigées plus tard.
Il est plus dur de corriger une mauvaise réputation et perdurer une
bonne nouvelle ou une bonne cote. Dans les limites de mes moyens
Je crois qu'il y a une habitude que le monde dit du logiciel libre
doit abandonner, si il veut être pris au sérieux et être un
compétiteur serieux : arrêter de dire que parce que le source est
diposnible, l'utilisateur peut tout modifier (même si cette liberté
lui conférée par les licences idioines) et arrêter les
expérimentations hasardeuses -- même si elles sont corrigées plus tard.
Il est plus dur de corriger une mauvaise réputation et perdurer une
bonne nouvelle ou une bonne cote. Dans les limites de mes moyens
Je crois qu'il y a une habitude que le monde dit du logiciel libre
doit abandonner, si il veut être pris au sérieux et être un
compétiteur serieux : arrêter de dire que parce que le source est
diposnible, l'utilisateur peut tout modifier (même si cette liberté
lui conférée par les licences idioines) et arrêter les
expérimentations hasardeuses -- même si elles sont corrigées plus tard.
Il est plus dur de corriger une mauvaise réputation et perdurer une
bonne nouvelle ou une bonne cote. Dans les limites de mes moyens
Erwann ABALEA writes:
| On 26 Dec 2003, Gabriel Dos Reis wrote:
|
| > Erwann ABALEA writes:
| > malloc provoque l'effondrement du système. Ou bien, il n'y a pas de
| > mémoire suffisante et l'implémentation remplit le contrat spécifié dans
| > la documentation en renvoyant un pointeur nul, ou bien il y en a assez
| > et il renvoie un pointeur sur une zone de mémoire utilisable selon le
| > contrat spécifié.
|
| Du point de vue du noyau, l'overcommit n'était pas utilisé simplement lors
| d'un appel à malloc(), il est utilisé lors de toute allocation mémoire, en
| gros tout ce qui se termine par un mmap(), y compris une allocation
| statique comme celle-ci:
|
| unsigned char mongrosbuffer[1024*1024];
Cela fait partie de la stupidité à laquelle je faisais allusion.
Par exemple, la fonction malloc() -- dont il est question ici -- est
suffisamment spéciale pour ne pas faire l'objet de fantasmes avec les
conséquences que l'on sait. Ce n'est pas pour rien que le C distingue
l'allocation statique de l'allocation dynamique.
| > Elle a bien longtemps existé dans d'autres OS
| > commerciaux, qui l'ont essayée sur leurs utilisateurs avant de
| > finalement l'abandonner -- sur la pression des utilisateurs et
| > devant le besoin de plus de robustesse. Mais, les mauvaies idées ont
| > la vie dure, spécialement dans certaines parties du ghetto du logiciel
| > dit libre.
| Et ses detracteurs ont la rancune tenace, puisque l'overcommit est
| contrôlable et désactivé depuis au moins le kernel 2.3.99, qui date de
(1) tu le sais, mais je le rappelle pour l'assistance, les noyaux
2.x.y avec x impair sont des versions expérimentales, par
définition instables, et on ne s'attend pas à ce que tout le
monde l'installe.
(2) visiblement, tu n'as pas été sérieusement mordu par cette
erreur stupide -- par exemple, perdre des données de calculs
précieux, parce que qu'un a fait mumuse avec l'implémentation
de malloc.
Tu vois que tu utilises encore 2.2.20 -- alors ne blâme pas ceux qui
l'utilisent encore et sont victimes de cette stupidité à propos de malloc.
| Quoi qu'il en soit, même parmi les acteurs du libre (dont tu fais partie
| pour ton travail sur gcc, et je t'en remercie) on trouve des colporteurs
| de ragots qui ne vérifient pas leurs infos. Par exemple, en août 2003,
| parmi les développeurs de PostgreSQL, on trouvait encore des gens qui
| proposaient de placer la valeur 3 à la variable système overcommit_memory
| pour supprimer l'overcommit (avec un peu plus de contrôle qu'en plaçant un
| 2, soit disant). Il suffit de lire le source du noyau 2.4.x pour se rendre
| compte que cette variable n'est pas utilisée comme ça, qu'elle n'a que 2
| valeurs utiles: nul, et non nul, et qu'une valeur non nulle autorise
| l'overcommit, ayant du même coup l'effet contraire de ce qu'ils
| souhaitaient. Cette vérification prend 5 minutes (mesure obtenue par un
| time(), et non un clock(), pour rester en charte).
Tu n'as jamais rencontré des gens qui invoquent GCC avec -On, où n > 3 ?
;-p
Je crois qu'il y a une habitude que le monde dit du logiciel libre
doit abandonner, si il veut être pris au sérieux et être un
compétiteur serieux : arrêter de dire que parce que le source est
diposnible, l'utilisateur peut tout modifier (même si cette liberté
lui conférée par les licences idioines)
et arrêter les
expérimentations hasardeuses -- même si elles sont corrigées plus tard.
Il est plus dur de corriger une mauvaise réputation et perdurer une
bonne nouvelle ou une bonne cote. Dans les limites de mes moyens
| Windows est maintenant multitâche préemptif (depuis NT), et
| personne n'irait dire aujourd'hui que Windows ne fait que du multitâche
| coopératif (ce qu'il faisait avant).
parce que personne n'irait argumenter qu'il suffit de lire le source
de Windows pour s'en rendre compte et que cela ne prendrait que 5
minutes, chrono en main ? ;-p
| Qui installe encore du Windows 3.1 en
| production de nos jours?
Tu noteras que Windows 3.1 ne date pas de la même année que Linux
2.2.x.
J'ai travaillé l'an dernier dans un « grand institut » français
de recherche en informatique où le noyau installé était de la
préhistoire par rapport à ce que j'utilisais à la maison.
Erwann ABALEA <erwann@abalea.com> writes:
| On 26 Dec 2003, Gabriel Dos Reis wrote:
|
| > Erwann ABALEA <erwann@abalea.com> writes:
| > malloc provoque l'effondrement du système. Ou bien, il n'y a pas de
| > mémoire suffisante et l'implémentation remplit le contrat spécifié dans
| > la documentation en renvoyant un pointeur nul, ou bien il y en a assez
| > et il renvoie un pointeur sur une zone de mémoire utilisable selon le
| > contrat spécifié.
|
| Du point de vue du noyau, l'overcommit n'était pas utilisé simplement lors
| d'un appel à malloc(), il est utilisé lors de toute allocation mémoire, en
| gros tout ce qui se termine par un mmap(), y compris une allocation
| statique comme celle-ci:
|
| unsigned char mongrosbuffer[1024*1024];
Cela fait partie de la stupidité à laquelle je faisais allusion.
Par exemple, la fonction malloc() -- dont il est question ici -- est
suffisamment spéciale pour ne pas faire l'objet de fantasmes avec les
conséquences que l'on sait. Ce n'est pas pour rien que le C distingue
l'allocation statique de l'allocation dynamique.
| > Elle a bien longtemps existé dans d'autres OS
| > commerciaux, qui l'ont essayée sur leurs utilisateurs avant de
| > finalement l'abandonner -- sur la pression des utilisateurs et
| > devant le besoin de plus de robustesse. Mais, les mauvaies idées ont
| > la vie dure, spécialement dans certaines parties du ghetto du logiciel
| > dit libre.
| Et ses detracteurs ont la rancune tenace, puisque l'overcommit est
| contrôlable et désactivé depuis au moins le kernel 2.3.99, qui date de
(1) tu le sais, mais je le rappelle pour l'assistance, les noyaux
2.x.y avec x impair sont des versions expérimentales, par
définition instables, et on ne s'attend pas à ce que tout le
monde l'installe.
(2) visiblement, tu n'as pas été sérieusement mordu par cette
erreur stupide -- par exemple, perdre des données de calculs
précieux, parce que qu'un a fait mumuse avec l'implémentation
de malloc.
Tu vois que tu utilises encore 2.2.20 -- alors ne blâme pas ceux qui
l'utilisent encore et sont victimes de cette stupidité à propos de malloc.
| Quoi qu'il en soit, même parmi les acteurs du libre (dont tu fais partie
| pour ton travail sur gcc, et je t'en remercie) on trouve des colporteurs
| de ragots qui ne vérifient pas leurs infos. Par exemple, en août 2003,
| parmi les développeurs de PostgreSQL, on trouvait encore des gens qui
| proposaient de placer la valeur 3 à la variable système overcommit_memory
| pour supprimer l'overcommit (avec un peu plus de contrôle qu'en plaçant un
| 2, soit disant). Il suffit de lire le source du noyau 2.4.x pour se rendre
| compte que cette variable n'est pas utilisée comme ça, qu'elle n'a que 2
| valeurs utiles: nul, et non nul, et qu'une valeur non nulle autorise
| l'overcommit, ayant du même coup l'effet contraire de ce qu'ils
| souhaitaient. Cette vérification prend 5 minutes (mesure obtenue par un
| time(), et non un clock(), pour rester en charte).
Tu n'as jamais rencontré des gens qui invoquent GCC avec -On, où n > 3 ?
;-p
Je crois qu'il y a une habitude que le monde dit du logiciel libre
doit abandonner, si il veut être pris au sérieux et être un
compétiteur serieux : arrêter de dire que parce que le source est
diposnible, l'utilisateur peut tout modifier (même si cette liberté
lui conférée par les licences idioines)
et arrêter les
expérimentations hasardeuses -- même si elles sont corrigées plus tard.
Il est plus dur de corriger une mauvaise réputation et perdurer une
bonne nouvelle ou une bonne cote. Dans les limites de mes moyens
| Windows est maintenant multitâche préemptif (depuis NT), et
| personne n'irait dire aujourd'hui que Windows ne fait que du multitâche
| coopératif (ce qu'il faisait avant).
parce que personne n'irait argumenter qu'il suffit de lire le source
de Windows pour s'en rendre compte et que cela ne prendrait que 5
minutes, chrono en main ? ;-p
| Qui installe encore du Windows 3.1 en
| production de nos jours?
Tu noteras que Windows 3.1 ne date pas de la même année que Linux
2.2.x.
J'ai travaillé l'an dernier dans un « grand institut » français
de recherche en informatique où le noyau installé était de la
préhistoire par rapport à ce que j'utilisais à la maison.
Erwann ABALEA writes:
| On 26 Dec 2003, Gabriel Dos Reis wrote:
|
| > Erwann ABALEA writes:
| > malloc provoque l'effondrement du système. Ou bien, il n'y a pas de
| > mémoire suffisante et l'implémentation remplit le contrat spécifié dans
| > la documentation en renvoyant un pointeur nul, ou bien il y en a assez
| > et il renvoie un pointeur sur une zone de mémoire utilisable selon le
| > contrat spécifié.
|
| Du point de vue du noyau, l'overcommit n'était pas utilisé simplement lors
| d'un appel à malloc(), il est utilisé lors de toute allocation mémoire, en
| gros tout ce qui se termine par un mmap(), y compris une allocation
| statique comme celle-ci:
|
| unsigned char mongrosbuffer[1024*1024];
Cela fait partie de la stupidité à laquelle je faisais allusion.
Par exemple, la fonction malloc() -- dont il est question ici -- est
suffisamment spéciale pour ne pas faire l'objet de fantasmes avec les
conséquences que l'on sait. Ce n'est pas pour rien que le C distingue
l'allocation statique de l'allocation dynamique.
| > Elle a bien longtemps existé dans d'autres OS
| > commerciaux, qui l'ont essayée sur leurs utilisateurs avant de
| > finalement l'abandonner -- sur la pression des utilisateurs et
| > devant le besoin de plus de robustesse. Mais, les mauvaies idées ont
| > la vie dure, spécialement dans certaines parties du ghetto du logiciel
| > dit libre.
| Et ses detracteurs ont la rancune tenace, puisque l'overcommit est
| contrôlable et désactivé depuis au moins le kernel 2.3.99, qui date de
(1) tu le sais, mais je le rappelle pour l'assistance, les noyaux
2.x.y avec x impair sont des versions expérimentales, par
définition instables, et on ne s'attend pas à ce que tout le
monde l'installe.
(2) visiblement, tu n'as pas été sérieusement mordu par cette
erreur stupide -- par exemple, perdre des données de calculs
précieux, parce que qu'un a fait mumuse avec l'implémentation
de malloc.
Tu vois que tu utilises encore 2.2.20 -- alors ne blâme pas ceux qui
l'utilisent encore et sont victimes de cette stupidité à propos de malloc.
| Quoi qu'il en soit, même parmi les acteurs du libre (dont tu fais partie
| pour ton travail sur gcc, et je t'en remercie) on trouve des colporteurs
| de ragots qui ne vérifient pas leurs infos. Par exemple, en août 2003,
| parmi les développeurs de PostgreSQL, on trouvait encore des gens qui
| proposaient de placer la valeur 3 à la variable système overcommit_memory
| pour supprimer l'overcommit (avec un peu plus de contrôle qu'en plaçant un
| 2, soit disant). Il suffit de lire le source du noyau 2.4.x pour se rendre
| compte que cette variable n'est pas utilisée comme ça, qu'elle n'a que 2
| valeurs utiles: nul, et non nul, et qu'une valeur non nulle autorise
| l'overcommit, ayant du même coup l'effet contraire de ce qu'ils
| souhaitaient. Cette vérification prend 5 minutes (mesure obtenue par un
| time(), et non un clock(), pour rester en charte).
Tu n'as jamais rencontré des gens qui invoquent GCC avec -On, où n > 3 ?
;-p
Je crois qu'il y a une habitude que le monde dit du logiciel libre
doit abandonner, si il veut être pris au sérieux et être un
compétiteur serieux : arrêter de dire que parce que le source est
diposnible, l'utilisateur peut tout modifier (même si cette liberté
lui conférée par les licences idioines)
et arrêter les
expérimentations hasardeuses -- même si elles sont corrigées plus tard.
Il est plus dur de corriger une mauvaise réputation et perdurer une
bonne nouvelle ou une bonne cote. Dans les limites de mes moyens
| Windows est maintenant multitâche préemptif (depuis NT), et
| personne n'irait dire aujourd'hui que Windows ne fait que du multitâche
| coopératif (ce qu'il faisait avant).
parce que personne n'irait argumenter qu'il suffit de lire le source
de Windows pour s'en rendre compte et que cela ne prendrait que 5
minutes, chrono en main ? ;-p
| Qui installe encore du Windows 3.1 en
| production de nos jours?
Tu noteras que Windows 3.1 ne date pas de la même année que Linux
2.2.x.
J'ai travaillé l'an dernier dans un « grand institut » français
de recherche en informatique où le noyau installé était de la
préhistoire par rapport à ce que j'utilisais à la maison.
