Munich Linux Migration Project LiMux Reports Success

Le Sat, 07 Jan 2012 13:00:39 +1100, Doug713705 a écrit :

Et si on faisait ce "benchmark" partout où MS à installé son système ?
Histoire d'être vraiment objectif, hein, et un benchmark qui prend
financièrement en compte les temps d'indisponibilté pour cause de
plantage et autres reboots tant qu'à faire.

Un témoignage sans aucune valeur statistique, mais ça m'a bien fait
ricaner : je suis récemment passé dans un aéroport international de
retour du continent africain.
La vérif du passeport à l'entrée sur le territoire européen consistait au
passage dans des portillons automatiques vérifiant le passeport
biométrique et la correspondance entre la photo et la tronche du porteur
dudit passeport (camera pilotée par l'automate).

Les portillons étaient pilotés par un soft windows vu l'interface à
l'écran.

Sur 8 portillons en fonction, 4 étaient plantés : 2 écrans bleus, et deux
planté sous explorer avec une fenêtre d'erreur à l'écran.

Joli score, on est loin des pires stats d'absentéisme dans
l'entreprise. :)

--
La Bête des Vosges

Le 09/01/2012 00:41, Dellara a écrit :

PP wrote:

Ça fonctionnait même avec un Amiga 1000; c'est pas peu dire.

ouais :D
C'était quand même des bonnes babasses, y'a pas à dire :)

arrêtez vous allez me donner une bouffée d'angoisse !
c'est que je l'aimais bien mon Amiga2000 ;)
Avec son processeur 68K d'une simplicité telle que j'arrivais à
comprendre comment çà marchait !

Et que dire de l'Amiga 3000. J'avais alors la Roll Royce dans le genre.
Toutes les cartes de périphériques disponibles, une tour pleine
grandeur, plein de mémoire, le plus gros disque dur du moment, le
Workbench dernier cri. Ah la nostalgie des ordinateurs de qualité! N'eut
été de l'absence de gestion de la mémoire, Amiga aurait pu faire un
tabac et éventuellement remplacer le X86 (Nan! Je rêve là :)

Le succès d'une architecture !!!!!
Sûr qu'Intel et Microsoft ont su faire ce qu'il fallait quand il fallait
pour s'imposer ...
L'ouverture du Hardware est, je pense, une part du succès, même si les
pratiques commerciales ont eu le dernier mot.

Stephane CARPENTIER <sc@fiat-linux.fr> wrote:

Je ne te dis pas que tu ne fais pas du multitâche, je te dis que si tu en
fais, c'est parce que softimage permet à XP de rester multitâche. Si ton
logiciel veut accaparer les ressources, il peut bloquer XP. C'est ce que je
constate au boulot avec plein de logiciels, surtout les trucs du genre
antivirus.

Je crois que tu te trompes, Windows XP est multitache préemptif
exactemnt comme les Unix. Je te réfère à:
http://fr.wikipedia.org/wiki/Multit%C3%A2che
en particulier la section "Cas particuliers" qui se termine par:
Cette particularité ne s'applique pas à Windows NT/2000/XP qui utilisent
un système de virtualisation (Win16 on Win32 / WoW) pour effectuer les
mêmes opérations.


Maintenant la qualité de la gestion du dit multitache est une autre
chose. Mais selon les bruits qui courent sur Windows, celui-ci est
plutôt bon dans la commutation des threads et mauvais dans celle des
processus, alors que Linux est performant dans les deux cas.

Ensuite il y a aussi la gestion de la priorité des processus qui permet
d'allouer plus de quantums de temps à certains qu'à d'autres. Je crois
que Windows favorise les processus associés à une fenêtre active, ce qui
donne une impression de meilleure interactivité mais pénalise les
processus qui travaillent en tâche de fond.



--

Michel TALON

Le 09/01/2012 16:59, Michel Talon a écrit :

Stephane CARPENTIER<sc@fiat-linux.fr> wrote:

Je ne te dis pas que tu ne fais pas du multitâche, je te dis que si tu en
fais, c'est parce que softimage permet à XP de rester multitâche. Si ton
logiciel veut accaparer les ressources, il peut bloquer XP. C'est ce que je
constate au boulot avec plein de logiciels, surtout les trucs du genre
antivirus.

Je crois que tu te trompes, Windows XP est multitache préemptif
exactemnt comme les Unix. Je te réfère à:
http://fr.wikipedia.org/wiki/Multit%C3%A2che
en particulier la section "Cas particuliers" qui se termine par:
Cette particularité ne s'applique pas à Windows NT/2000/XP qui utilisent
un système de virtualisation (Win16 on Win32 / WoW) pour effectuer les
mêmes opérations.


Maintenant la qualité de la gestion du dit multitache est une autre
chose. Mais selon les bruits qui courent sur Windows, celui-ci est
plutôt bon dans la commutation des threads et mauvais dans celle des
processus, alors que Linux est performant dans les deux cas.

Ensuite il y a aussi la gestion de la priorité des processus qui permet
d'allouer plus de quantums de temps à certains qu'à d'autres. Je crois
que Windows favorise les processus associés à une fenêtre active, ce qui
donne une impression de meilleure interactivité mais pénalise les
processus qui travaillent en tâche de fond.

Cette dernière caractéristique est désactivable, notamment sur les
serveurs, par défaut.

Le Mon, 9 Jan 2012 15:59:01 +0000 (UTC),
Michel Talon <talon@lpthe.jussieu.fr> écrivait :

Stephane CARPENTIER <sc@fiat-linux.fr> wrote:

Je ne te dis pas que tu ne fais pas du multitâche, je te dis que si tu en
fais, c'est parce que softimage permet à XP de rester multitâche. Si ton
logiciel veut accaparer les ressources, il peut bloquer XP. C'est ce que je
constate au boulot avec plein de logiciels, surtout les trucs du genre
antivirus.

Je crois que tu te trompes, Windows XP est multitache préemptif
exactemnt comme les Unix. Je te réfère à:
http://fr.wikipedia.org/wiki/Multit%C3%A2che
en particulier la section "Cas particuliers" qui se termine par:
Cette particularité ne s'applique pas à Windows NT/2000/XP qui utilisent
un système de virtualisation (Win16 on Win32 / WoW) pour effectuer les
mêmes opérations.


Maintenant la qualité de la gestion du dit multitache est une autre
chose. Mais selon les bruits qui courent sur Windows, celui-ci est
plutôt bon dans la commutation des threads et mauvais dans celle des
processus, alors que Linux est performant dans les deux cas.

Ensuite il y a aussi la gestion de la priorité des processus qui permet
d'allouer plus de quantums de temps à certains qu'à d'autres. Je crois
que Windows favorise les processus associés à une fenêtre active, ce qui
donne une impression de meilleure interactivité mais pénalise les
processus qui travaillent en tâche de fond.

Si tu as l'occasion de regarder les sources de Windows (jusqu'à XP
64 inclus, je ne suis pas allé voir plus loin dans le détail),
regarde bien les routines de gestion de la MMU. Tu verras qu'il n'y
a pas de cloisonnement entre les processus dès lors qu'ils 'montent'
des DLL dans leur espace de mémoire. C'est le gros problème de la
gestion des processus de Windows (et entre nous, je ne comprends pas
qu'ils gardent une telle aberration en contournant les problèmes par
la libcrt.dll).

JKB

--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr

Le 09/01/2012 21:23, JKB a écrit :

Si tu as l'occasion de regarder les sources de Windows (jusqu'à XP
64 inclus, je ne suis pas allé voir plus loin dans le détail),
regarde bien les routines de gestion de la MMU. Tu verras qu'il n'y
a pas de cloisonnement entre les processus dès lors qu'ils 'montent'
des DLL dans leur espace de mémoire. C'est le gros problème de la
gestion des processus de Windows (et entre nous, je ne comprends pas
qu'ils gardent une telle aberration en contournant les problèmes par
la libcrt.dll).

Le sujet m'intéresse. Pourrais-tu préciser le problème avec les DLLs
et le contournement dans la libcrt ?

Le Wed, 11 Jan 2012 15:13:05 +0100,
Manuel Leclerc <manuel.leclerc@alussinan.org> écrivait :

Le 09/01/2012 21:23, JKB a écrit :

Si tu as l'occasion de regarder les sources de Windows (jusqu'à XP
64 inclus, je ne suis pas allé voir plus loin dans le détail),
regarde bien les routines de gestion de la MMU. Tu verras qu'il n'y
a pas de cloisonnement entre les processus dès lors qu'ils 'montent'
des DLL dans leur espace de mémoire. C'est le gros problème de la
gestion des processus de Windows (et entre nous, je ne comprends pas
qu'ils gardent une telle aberration en contournant les problèmes par
la libcrt.dll).

Le sujet m'intéresse. Pourrais-tu préciser le problème avec les DLLs
et le contournement dans la libcrt ?

Tu as la description complète du problème dans la KB de Microsoft
(je te l'accorde, il faut un peu chercher parce qu'ils ne doivent
pas être fier du problème).

Pour faire simple : une DLL n'est pas mappée dans un espace de
processus sous Windows mais dans un espace commun aux processus qui
l'utilisent (ils n'ont _rien_ compris au fonctionnement de base de
la mémoire virtuelle. Passons ! Pour branlibranla, la mémoire
virtuelle, même sur l'architecture moisie du x86, c'est un truc qui
permet d'avoir une zone de mémoire physique mappée sur plusieurs
zones de mémoire virtuelle dans des espaces mémoire différents).
La conséquence de ce choix (de ce bug ? de cette fonctionnalité ?)
est que la mémoire allouée dans une DLL n'est pas allouée sur le tas du
processus utilisant cette DLL, mais sur le 'tas' de la DLL. Ce qui
fait que lorsque tu fermes le programme utilisant la DLL sans
libérer explicitement ce qui a été alloué par la DLL en question, tu
as une belle fuite mémoire. Depuis je ne sais plus quelle version de
Visual C++, la libcrt contient une rustine qui piste les allocations
de mémoire dans les DLL pour les libérer explicitement à la fin de
l'exécution d'un processus.

Un autre truc amusant avec cette façon de faire, c'est qu'un
processus peut marcher sur les données d'un autre processus au
travers de l'utilisation d'un pointeur hasardeux en mémoire pour peu
qu'il a été alloué dans la mémoire d'une DLL.

Donc, lorsqu'on doit écrire une DLL sous Windows, on évite autant
que possible d'utiliser de la mémorie dynamique avec allocation
_dans_ la DLL.

JKB

--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr

Le 13/01/2012 09:53, JKB a écrit :

Tu as la description complète du problème dans la KB de Microsoft
(je te l'accorde, il faut un peu chercher parce qu'ils ne doivent
pas être fier du problème).

Pour faire simple : une DLL n'est pas mappée dans un espace de
processus sous Windows mais dans un espace commun aux processus qui
l'utilisent (ils n'ont _rien_ compris au fonctionnement de base de
la mémoire virtuelle. Passons ! Pour branlibranla, la mémoire
virtuelle, même sur l'architecture moisie du x86, c'est un truc qui
permet d'avoir une zone de mémoire physique mappée sur plusieurs
zones de mémoire virtuelle dans des espaces mémoire différents).
La conséquence de ce choix (de ce bug ? de cette fonctionnalité ?)
est que la mémoire allouée dans une DLL n'est pas allouée sur le tas du
processus utilisant cette DLL, mais sur le 'tas' de la DLL. Ce qui
fait que lorsque tu fermes le programme utilisant la DLL sans
libérer explicitement ce qui a été alloué par la DLL en question, tu
as une belle fuite mémoire. Depuis je ne sais plus quelle version de
Visual C++, la libcrt contient une rustine qui piste les allocations
de mémoire dans les DLL pour les libérer explicitement à la fin de
l'exécution d'un processus.

Un autre truc amusant avec cette façon de faire, c'est qu'un
processus peut marcher sur les données d'un autre processus au
travers de l'utilisation d'un pointeur hasardeux en mémoire pour peu
qu'il a été alloué dans la mémoire d'une DLL.

Donc, lorsqu'on doit écrire une DLL sous Windows, on évite autant
que possible d'utiliser de la mémorie dynamique avec allocation
_dans_ la DLL.

En simplifiant un peu, mon métier consiste à coder des DLLs, et ça
fait un paquet d'années. Donc ton message m'inquiète au plus haut
point, car je n'y comprends strictement rien. Tu serais bien
aimable de m'aider à trouver la référence vers l'article de KB
dont tu parles.

Le Tue, 17 Jan 2012 11:07:03 +0100,
Manuel Leclerc <manuel.leclerc@alussinan.org> écrivait :

Le 13/01/2012 09:53, JKB a écrit :

Tu as la description complète du problème dans la KB de Microsoft
(je te l'accorde, il faut un peu chercher parce qu'ils ne doivent
pas être fier du problème).

Pour faire simple : une DLL n'est pas mappée dans un espace de
processus sous Windows mais dans un espace commun aux processus qui
l'utilisent (ils n'ont _rien_ compris au fonctionnement de base de
la mémoire virtuelle. Passons ! Pour branlibranla, la mémoire
virtuelle, même sur l'architecture moisie du x86, c'est un truc qui
permet d'avoir une zone de mémoire physique mappée sur plusieurs
zones de mémoire virtuelle dans des espaces mémoire différents).
La conséquence de ce choix (de ce bug ? de cette fonctionnalité ?)
est que la mémoire allouée dans une DLL n'est pas allouée sur le tas du
processus utilisant cette DLL, mais sur le 'tas' de la DLL. Ce qui
fait que lorsque tu fermes le programme utilisant la DLL sans
libérer explicitement ce qui a été alloué par la DLL en question, tu
as une belle fuite mémoire. Depuis je ne sais plus quelle version de
Visual C++, la libcrt contient une rustine qui piste les allocations
de mémoire dans les DLL pour les libérer explicitement à la fin de
l'exécution d'un processus.

Un autre truc amusant avec cette façon de faire, c'est qu'un
processus peut marcher sur les données d'un autre processus au
travers de l'utilisation d'un pointeur hasardeux en mémoire pour peu
qu'il a été alloué dans la mémoire d'une DLL.

Donc, lorsqu'on doit écrire une DLL sous Windows, on évite autant
que possible d'utiliser de la mémorie dynamique avec allocation
_dans_ la DLL.

En simplifiant un peu, mon métier consiste à coder des DLLs, et ça
fait un paquet d'années. Donc ton message m'inquiète au plus haut
point, car je n'y comprends strictement rien. Tu serais bien
aimable de m'aider à trouver la référence vers l'article de KB
dont tu parles.

J'ai le numéro de KB dans mes notes chez moi. Je vais essayer d'y
penser ce soir.

--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr

Manuel Leclerc <manuel.leclerc@alussinan.org> wrote:

Le 13/01/2012 09:53, JKB a écrit :

> Tu as la description complète du problème dans la KB de Microsoft
> (je te l'accorde, il faut un peu chercher parce qu'ils ne doivent
> pas être fier du problème).
>
> Pour faire simple : une DLL n'est pas mappée dans un espace de
> processus sous Windows mais dans un espace commun aux processus qui
> l'utilisent (ils n'ont _rien_ compris au fonctionnement de base de
> la mémoire virtuelle. Passons ! Pour branlibranla, la mémoire
> virtuelle, même sur l'architecture moisie du x86, c'est un truc qui
> permet d'avoir une zone de mémoire physique mappée sur plusieurs
> zones de mémoire virtuelle dans des espaces mémoire différents).
> La conséquence de ce choix (de ce bug ? de cette fonctionnalité ?)
> est que la mémoire allouée dans une DLL n'est pas allouée sur le tas du
> processus utilisant cette DLL, mais sur le 'tas' de la DLL. Ce qui
> fait que lorsque tu fermes le programme utilisant la DLL sans
> libérer explicitement ce qui a été alloué par la DLL en question, tu
> as une belle fuite mémoire. Depuis je ne sais plus quelle version de
> Visual C++, la libcrt contient une rustine qui piste les allocations
> de mémoire dans les DLL pour les libérer explicitement à la fin de
> l'exécution d'un processus.
>
> Un autre truc amusant avec cette façon de faire, c'est qu'un
> processus peut marcher sur les données d'un autre processus au
> travers de l'utilisation d'un pointeur hasardeux en mémoire pour peu
> qu'il a été alloué dans la mémoire d'une DLL.
>
> Donc, lorsqu'on doit écrire une DLL sous Windows, on évite autant
> que possible d'utiliser de la mémorie dynamique avec allocation
> _dans_ la DLL.

En simplifiant un peu, mon métier consiste à coder des DLLs, et ça
fait un paquet d'années. Donc ton message m'inquiète au plus haut
point, car je n'y comprends strictement rien. Tu serais bien
aimable de m'aider à trouver la référence vers l'article de KB
dont tu parles.

Comme je trouvais ça hautement bizarre, j'ai cherché un peu sur le web
et trouvé ceci:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms682594(v=vs.85).aspx
A Dynamic-Link Library (DLL) can contain global data or local data.

Variable Scope
Variables that are declared as global in a DLL source code file are
treated as global variables by the compiler and linker, but each process
that loads a given DLL gets its own copy of that DLL's global variables.
The scope of static variables is limited to the block in which the
static variables are declared. As a result, each process has its own
instance of the DLL global and static variables by default.

Note Your development tools may allow you to override the default
behavior. For example, the Visual C++ compiler supports #pragma section
and the linker supports the /SECTION option. For more information, see
the documentation included with your development tools.

Je suppose que la note ci-dessus laisse la possibilité d'avoir un
comportement comme dit JKB, mais pas par défaut.

Par contre le fait que le segment de *texte* d'une librairie partagée
soit commun à plusieurs processus qui l'utilisent c'est évidemment la
notion même de librairie partagée qui le demande, et c'est certainement
ainsi sous Unix.

On peut imaginer qu'une librairie partagée ait des données communes à
plusieurs processus, sous Unix c'est le mécanisme de la mémoire partagée
protégée par un sémaphore - je ne sais pas si de telles acrobaties sont
d'usage courant.






--

Michel TALON