debug this fifo a formulé la demande :
> Jérémie Bottone wrote:
>
>> - Lent
>
> windows aussi est lent.
Faut, il n'y a qu'à voir le temps pour ouvrir OpenOffice ou Mozilla
sous Windows ou Linux, et on jette Linux
Dans l'ensemble, n'importe quellles t'aches faites sous Windows, par un
utilisateur expérimenté ou pas, sont faites beaucoup plus rapidment,
qu'elles soient locales ou distantes
Pourquoi ? Car Linux est un système bricolé par des bricoleurs, basé
sur du code UNIX datant de 30 ans
Les programmeurs LINUX sont incapable de faire des logiciels terminés
qui fonctionnement bien, d'où e pourquoi du larmoyement et du
pleurnichage perpetuel, de la victimisation même
Alors ils disent: Bouhhhhhh, tous les codes sources doivent être
ouverts !
(Ceci pour éviter de se donner de la peine de développer, et de pouvoir
"pomper" allieurs ce qu'ils sont incapanle de réaliser)
Je hais LINUX et cette mentalité
Microsoft, est une usine de développement, dont il sort des milliers de
logiciels de qualité, s'attirant la jalousie de tous les pingouins du
monde
Mon clavier Sun n'a que 120 touches. Il me manque le point d'ironie et surtout le point virgule renversé pour cligner de l'autre oeil...
M'en vait faire une demande sur la liste typo, moi...
Pas besoin (-;
google me dit que non.
-- Toxico Nimbus Google connait la vérité Google sait tout
pehache-tolai
"doug713705" a écrit dans le message de news:
On Fri, 31 Jul 2009 06:56:55 -0700, pehache-tolai wrote:
Non : il pourrait faire appel aux fonctions internes au noyau, mais rien ne l'y oblige. On peut très bien mettre dans le noyau un code qui ne fait appel à aucune fonction interne du noyau et qui "réinvente" tout.
Ah mais rien ne t'empèche de coder avec 2 pieds gauches ;-) Dans le cas que tu énnonces, oui le code resterait une émulation à mon avis.
Donc tu fais l'assimilation "émulation" = "mauvaise implémentation"
-- pehache http://pehache.free.fr/public.html
"doug713705" <doug.letough@free.fr> a écrit dans le message de news:
pan.2009.07.31.14.28.48.187000@free.fr
On Fri, 31 Jul 2009 06:56:55 -0700, pehache-tolai wrote:
Non : il pourrait faire appel aux fonctions internes au noyau, mais
rien ne l'y oblige. On peut très bien mettre dans le noyau un code
qui ne fait appel à aucune fonction interne du noyau et qui
"réinvente" tout.
Ah mais rien ne t'empèche de coder avec 2 pieds gauches ;-)
Dans le cas que tu énnonces, oui le code resterait une émulation à mon
avis.
Donc tu fais l'assimilation "émulation" = "mauvaise implémentation"
On Fri, 31 Jul 2009 06:56:55 -0700, pehache-tolai wrote:
Non : il pourrait faire appel aux fonctions internes au noyau, mais rien ne l'y oblige. On peut très bien mettre dans le noyau un code qui ne fait appel à aucune fonction interne du noyau et qui "réinvente" tout.
Ah mais rien ne t'empèche de coder avec 2 pieds gauches ;-) Dans le cas que tu énnonces, oui le code resterait une émulation à mon avis.
Donc tu fais l'assimilation "émulation" = "mauvaise implémentation"
-- pehache http://pehache.free.fr/public.html
Doug713705
Le Fri, 31 Jul 2009 19:16:10 +0200, pehache-tolai a gâché de la bande passante pour nous écrire :
Ah mais rien ne t'empèche de coder avec 2 pieds gauches ;-) Dans le cas que tu énnonces, oui le code resterait une émulation à mon avis.
Donc tu fais l'assimilation "émulation" = "mauvaise implémentation"
[NON]
Je dis que passer par une émulation pour obtenir quelque chose qui peut être obtenu nativement est un non-sens.
-- @+ Doug - Linux user #307925 - Slamd64 roulaize ;-) [ Plus ou moins avec une chance de peut-être ]
Le Fri, 31 Jul 2009 19:16:10 +0200, pehache-tolai a gâché de la bande
passante pour nous écrire :
Ah mais rien ne t'empèche de coder avec 2 pieds gauches ;-) Dans le
cas que tu énnonces, oui le code resterait une émulation à mon avis.
Donc tu fais l'assimilation "émulation" = "mauvaise implémentation"
[NON]
Je dis que passer par une émulation pour obtenir quelque chose qui peut
être obtenu nativement est un non-sens.
--
@+
Doug - Linux user #307925 - Slamd64 roulaize ;-)
[ Plus ou moins avec une chance de peut-être ]
Ah mais rien ne t'empèche de coder avec 2 pieds gauches ;-) Dans le cas que tu énnonces, oui le code resterait une émulation à mon avis.
:D on arrive a du niveau JKB la : "c'est une emulation parce que c'est un code de merde".
Stephane TOUGARD
Toxico Nimbus wrote:
Si ton bout de code ne peut pas suivre les spécifications parce qu'il lui manque des fonctions implémentables uniquement en kernelland, alors tu ne peux pas dire qu'il implémente la norme.
Ce n'est pas implementable uniquement en kernelland, puisqu'il semblerait que sous Cygwin (et sur certains micro-kernels), ca soit implemente en "userland".
D'ailleurs POSIX ne definit pas ou le dit fonctionnement doit etre implemente.
Je t'accorde que tu peux chipoter en disant qu'il l'implémente de travers, mais pour moi ce n'est ni une émulation, ni une implémentation.
Non, c'est du code de merde et une mauvaise implementation incomplete. Personne ne le nie. Mais c'est PAS une emulation.
Toxico Nimbus wrote:
Si ton bout de code ne peut pas suivre les spécifications parce qu'il
lui manque des fonctions implémentables uniquement en kernelland, alors
tu ne peux pas dire qu'il implémente la norme.
Ce n'est pas implementable uniquement en kernelland, puisqu'il
semblerait que sous Cygwin (et sur certains micro-kernels), ca soit
implemente en "userland".
D'ailleurs POSIX ne definit pas ou le dit fonctionnement doit etre
implemente.
Je t'accorde que tu peux chipoter en disant qu'il l'implémente de
travers, mais pour moi ce n'est ni une émulation, ni une implémentation.
Non, c'est du code de merde et une mauvaise implementation incomplete.
Personne ne le nie. Mais c'est PAS une emulation.
Si ton bout de code ne peut pas suivre les spécifications parce qu'il lui manque des fonctions implémentables uniquement en kernelland, alors tu ne peux pas dire qu'il implémente la norme.
Ce n'est pas implementable uniquement en kernelland, puisqu'il semblerait que sous Cygwin (et sur certains micro-kernels), ca soit implemente en "userland".
D'ailleurs POSIX ne definit pas ou le dit fonctionnement doit etre implemente.
Je t'accorde que tu peux chipoter en disant qu'il l'implémente de travers, mais pour moi ce n'est ni une émulation, ni une implémentation.
Non, c'est du code de merde et une mauvaise implementation incomplete. Personne ne le nie. Mais c'est PAS une emulation.
Stephane TOUGARD
doug713705 wrote:
Par contre, _pour_pouvoir_obtenir_le_résultat_souhaité_en_userland_, il _faut_ que se soit une émulation.
Une emulation de quoi ?
Relis mes messages.
Tes messages ne disent rien de bien interessant et je ne le redemanderais pas si tu l'avais deja demontre.
Je me bornerai a la definition de Wikipedia qui etabli la relation de Cygwin a POSIX de la facon suivante :
"Cygwin se compose d'une bibliothèque qui implémente l'API système de POSIX en faisant appel au système Win32, ..."
Et qui etablie la relation a Unix (mais ca n'a pas de rapport avec POSIX en soit) :
"Cygwin est une collection de logiciels libres à l'origine développés par Cygnus Solutions permettant à différentes versions de Windows de Microsoft d'émuler un système Unix".
On emule un systeme d'exploitation et on implemente l'API systeme d'une norme.
doug713705 wrote:
Par contre, _pour_pouvoir_obtenir_le_résultat_souhaité_en_userland_, il
_faut_ que se soit une émulation.
Une emulation de quoi ?
Relis mes messages.
Tes messages ne disent rien de bien interessant et je ne le
redemanderais pas si tu l'avais deja demontre.
Je me bornerai a la definition de Wikipedia qui etabli la relation de
Cygwin a POSIX de la facon suivante :
"Cygwin se compose d'une bibliothèque qui implémente l'API système de
POSIX en faisant appel au système Win32, ..."
Et qui etablie la relation a Unix (mais ca n'a pas de rapport avec
POSIX en soit) :
"Cygwin est une collection de logiciels libres à
l'origine développés par Cygnus Solutions permettant à différentes
versions de Windows de Microsoft d'émuler un système Unix".
On emule un systeme d'exploitation et on implemente l'API systeme d'une
norme.
Par contre, _pour_pouvoir_obtenir_le_résultat_souhaité_en_userland_, il _faut_ que se soit une émulation.
Une emulation de quoi ?
Relis mes messages.
Tes messages ne disent rien de bien interessant et je ne le redemanderais pas si tu l'avais deja demontre.
Je me bornerai a la definition de Wikipedia qui etabli la relation de Cygwin a POSIX de la facon suivante :
"Cygwin se compose d'une bibliothèque qui implémente l'API système de POSIX en faisant appel au système Win32, ..."
Et qui etablie la relation a Unix (mais ca n'a pas de rapport avec POSIX en soit) :
"Cygwin est une collection de logiciels libres à l'origine développés par Cygnus Solutions permettant à différentes versions de Windows de Microsoft d'émuler un système Unix".
On emule un systeme d'exploitation et on implemente l'API systeme d'une norme.
pehache-tolai
"Doug713705" a écrit dans le message de news:
Le Fri, 31 Jul 2009 19:16:10 +0200, pehache-tolai a gâché de la bande passante pour nous écrire :
Ah mais rien ne t'empèche de coder avec 2 pieds gauches ;-) Dans le cas que tu énnonces, oui le code resterait une émulation à mon avis.
Donc tu fais l'assimilation "émulation" = "mauvaise implémentation"
[NON]
Je dis que passer par une émulation pour obtenir quelque chose qui peut être obtenu nativement est un non-sens.
Sur un PC nu (sans OS) les threads ne peuvent pas être "obtenus nativement", il faut écrire du code qui va les implémenter.C'est donc ta (nouvelle) distinction "émulation"/obtenu nativement" qui est un non-sens.
-- pehache http://pehache.free.fr/public.html
"Doug713705" <doug.letough@free.fr> a écrit dans le message de news:
pan.2009.07.31.19.44.57@bourzy-wlan
Le Fri, 31 Jul 2009 19:16:10 +0200, pehache-tolai a gâché de la bande
passante pour nous écrire :
Ah mais rien ne t'empèche de coder avec 2 pieds gauches ;-) Dans le
cas que tu énnonces, oui le code resterait une émulation à mon avis.
Donc tu fais l'assimilation "émulation" = "mauvaise implémentation"
[NON]
Je dis que passer par une émulation pour obtenir quelque chose qui
peut être obtenu nativement est un non-sens.
Sur un PC nu (sans OS) les threads ne peuvent pas être "obtenus nativement",
il faut écrire du code qui va les implémenter.C'est donc ta (nouvelle)
distinction "émulation"/obtenu nativement" qui est un non-sens.
Le Fri, 31 Jul 2009 19:16:10 +0200, pehache-tolai a gâché de la bande passante pour nous écrire :
Ah mais rien ne t'empèche de coder avec 2 pieds gauches ;-) Dans le cas que tu énnonces, oui le code resterait une émulation à mon avis.
Donc tu fais l'assimilation "émulation" = "mauvaise implémentation"
[NON]
Je dis que passer par une émulation pour obtenir quelque chose qui peut être obtenu nativement est un non-sens.
Sur un PC nu (sans OS) les threads ne peuvent pas être "obtenus nativement", il faut écrire du code qui va les implémenter.C'est donc ta (nouvelle) distinction "émulation"/obtenu nativement" qui est un non-sens.
-- pehache http://pehache.free.fr/public.html
doug713705
On Sat, 01 Aug 2009 08:59:35 +0800, Stephane TOUGARD wrote:
On emule un systeme d'exploitation et on implemente l'API systeme d'une norme.
Où ai-je dis le contraire ? J'ai dit exactement la même chose et toi ou péhache (flemme de chercher) me disait que ce n'était pas possible.
Par ailleurs, tu noteras que cygwin n'est pas autre chose qu'un _émulateur_, une partie de son code doit donc bien émuler quelque chose et en l'occurence le comportement attendu du système cible, non ?
Système cible qui n'est autre qu'un système POSIX théorique et seulement un système POSIX théorique (pas un Linux, pas un Unix, pas un Mac).
Figure toi que c'est exactement ce que j'ai tenté de t'expliquer avec plus ou moins de succès.
-- Doug713705
On Sat, 01 Aug 2009 08:59:35 +0800, Stephane TOUGARD wrote:
On emule un systeme d'exploitation et on implemente l'API systeme d'une
norme.
Où ai-je dis le contraire ?
J'ai dit exactement la même chose et toi ou péhache (flemme de chercher)
me disait que ce n'était pas possible.
Par ailleurs, tu noteras que cygwin n'est pas autre chose qu'un
_émulateur_, une partie de son code doit donc bien émuler quelque chose
et en l'occurence le comportement attendu du système cible, non ?
Système cible qui n'est autre qu'un système POSIX théorique et seulement
un système POSIX théorique (pas un Linux, pas un Unix, pas un Mac).
Figure toi que c'est exactement ce que j'ai tenté de t'expliquer avec
plus ou moins de succès.
On Sat, 01 Aug 2009 08:59:35 +0800, Stephane TOUGARD wrote:
On emule un systeme d'exploitation et on implemente l'API systeme d'une norme.
Où ai-je dis le contraire ? J'ai dit exactement la même chose et toi ou péhache (flemme de chercher) me disait que ce n'était pas possible.
Par ailleurs, tu noteras que cygwin n'est pas autre chose qu'un _émulateur_, une partie de son code doit donc bien émuler quelque chose et en l'occurence le comportement attendu du système cible, non ?
Système cible qui n'est autre qu'un système POSIX théorique et seulement un système POSIX théorique (pas un Linux, pas un Unix, pas un Mac).
Figure toi que c'est exactement ce que j'ai tenté de t'expliquer avec plus ou moins de succès.
-- Doug713705
doug713705
On Sat, 01 Aug 2009 09:12:47 +0200, pehache-tolai wrote:
Sur un PC nu (sans OS) les threads ne peuvent pas être "obtenus nativement", il faut écrire du code qui va les implémenter.C'est donc ta (nouvelle) distinction "émulation"/obtenu nativement" qui est un non-sens.
Bon, on va reprendre depuis le début : Soit 1 système A composé d'un ordinateur quelconque et d'un système d'eploitation _non_préemptif_ au code source ouvert.
Soit 1 système B composé d'un ordinateur quelconque et d'un système d'eploitation _non_préemptif_ au code source fermé.
Problème : Sur chacun des systèmes, je dois faire en sorte d'obtenir le comportement d'un système préemptif afin d'y installer une application qui en a le besoin.
Solutions : Sur le système A aux sources ouvertes j'ai 2 options : a - Modifier directement le code source du système d'exploitation afin de le rendre préemptif. b - Ajouter une surcouche au système d'exploitation afin d'émuler un système préemptif (en kernelland ou en userland, ça n'a pas d'importance).
Sur le système B aux sources fermées je n'ai pas le choix : a - Ajouter une surcouche au système d'exploitation afin d'émuler un système préemptif.
Resultats : - Sur le système A que la solution b soit implémentée en kernelland ou en userland, cela reste une émulation. - Sur le système B, on a _nécessairement_ une émulation.
Conclusions : - Une émulation _ne_dépend_pas_ : a - de l'endroit où on implémente le code. b - de la qualité du code. c - Une implémentation sous forme d'émulation n'est pas forcément une "mauvaise implémentation" mais ce n'est pas la meilleure dans le cadre d'un système d'exploitation aux sources ouvertes.
Par contre : - Sur le système A, la solution b me semble relever du non-sens mais tu as certainement des arguments pour pouvoir affirmer le contraire. - Sur le système B, je n'ai malheureusment pas le choix et ce n'est donc pas un non-sens bien que se soit môche.
Nota : Les exemples cités sont fictifs et simplement théoriques, il s'agit d'un exercice de pensée qui demande un tant soit peu d'abstraction et l'aspect purement technique n'entre pas nécessairement en compte. Il ne s'agit pas ici de savoir s'il est _possible_de_ mais plutôt de simplement comprendre un raisonnement et le mot "préemptif" doit se comprendre comme "fonctionalité spécifique du _noyau_ d'un système d'exploitation".
-- Doug713705
On Sat, 01 Aug 2009 09:12:47 +0200, pehache-tolai wrote:
Sur un PC nu (sans OS) les threads ne peuvent pas être "obtenus nativement",
il faut écrire du code qui va les implémenter.C'est donc ta (nouvelle)
distinction "émulation"/obtenu nativement" qui est un non-sens.
Bon, on va reprendre depuis le début :
Soit 1 système A composé d'un ordinateur quelconque et d'un système
d'eploitation _non_préemptif_ au code source ouvert.
Soit 1 système B composé d'un ordinateur quelconque et d'un
système d'eploitation _non_préemptif_ au code source fermé.
Problème :
Sur chacun des systèmes, je dois faire en sorte d'obtenir le comportement
d'un système préemptif afin d'y installer une application qui en a le
besoin.
Solutions :
Sur le système A aux sources ouvertes j'ai 2 options :
a - Modifier directement le code source du système d'exploitation afin
de le rendre préemptif.
b - Ajouter une surcouche au système d'exploitation afin d'émuler un
système préemptif (en kernelland ou en userland, ça n'a pas
d'importance).
Sur le système B aux sources fermées je n'ai pas le choix :
a - Ajouter une surcouche au système d'exploitation afin d'émuler un
système préemptif.
Resultats :
- Sur le système A que la solution b soit implémentée en kernelland ou
en userland, cela reste une émulation.
- Sur le système B, on a _nécessairement_ une émulation.
Conclusions :
- Une émulation _ne_dépend_pas_ :
a - de l'endroit où on implémente le code.
b - de la qualité du code.
c - Une implémentation sous forme d'émulation n'est pas forcément une
"mauvaise implémentation" mais ce n'est pas la meilleure dans le cadre
d'un système d'exploitation aux sources ouvertes.
Par contre :
- Sur le système A, la solution b me semble relever du non-sens mais tu
as certainement des arguments pour pouvoir affirmer le contraire.
- Sur le système B, je n'ai malheureusment pas le choix et ce n'est donc
pas un non-sens bien que se soit môche.
Nota :
Les exemples cités sont fictifs et simplement théoriques, il s'agit d'un
exercice de pensée qui demande un tant soit peu d'abstraction et
l'aspect purement technique n'entre pas nécessairement en compte.
Il ne s'agit pas ici de savoir s'il est _possible_de_ mais plutôt de
simplement comprendre un raisonnement et le mot "préemptif" doit se
comprendre comme "fonctionalité spécifique du _noyau_ d'un système
d'exploitation".
On Sat, 01 Aug 2009 09:12:47 +0200, pehache-tolai wrote:
Sur un PC nu (sans OS) les threads ne peuvent pas être "obtenus nativement", il faut écrire du code qui va les implémenter.C'est donc ta (nouvelle) distinction "émulation"/obtenu nativement" qui est un non-sens.
Bon, on va reprendre depuis le début : Soit 1 système A composé d'un ordinateur quelconque et d'un système d'eploitation _non_préemptif_ au code source ouvert.
Soit 1 système B composé d'un ordinateur quelconque et d'un système d'eploitation _non_préemptif_ au code source fermé.
Problème : Sur chacun des systèmes, je dois faire en sorte d'obtenir le comportement d'un système préemptif afin d'y installer une application qui en a le besoin.
Solutions : Sur le système A aux sources ouvertes j'ai 2 options : a - Modifier directement le code source du système d'exploitation afin de le rendre préemptif. b - Ajouter une surcouche au système d'exploitation afin d'émuler un système préemptif (en kernelland ou en userland, ça n'a pas d'importance).
Sur le système B aux sources fermées je n'ai pas le choix : a - Ajouter une surcouche au système d'exploitation afin d'émuler un système préemptif.
Resultats : - Sur le système A que la solution b soit implémentée en kernelland ou en userland, cela reste une émulation. - Sur le système B, on a _nécessairement_ une émulation.
Conclusions : - Une émulation _ne_dépend_pas_ : a - de l'endroit où on implémente le code. b - de la qualité du code. c - Une implémentation sous forme d'émulation n'est pas forcément une "mauvaise implémentation" mais ce n'est pas la meilleure dans le cadre d'un système d'exploitation aux sources ouvertes.
Par contre : - Sur le système A, la solution b me semble relever du non-sens mais tu as certainement des arguments pour pouvoir affirmer le contraire. - Sur le système B, je n'ai malheureusment pas le choix et ce n'est donc pas un non-sens bien que se soit môche.
Nota : Les exemples cités sont fictifs et simplement théoriques, il s'agit d'un exercice de pensée qui demande un tant soit peu d'abstraction et l'aspect purement technique n'entre pas nécessairement en compte. Il ne s'agit pas ici de savoir s'il est _possible_de_ mais plutôt de simplement comprendre un raisonnement et le mot "préemptif" doit se comprendre comme "fonctionalité spécifique du _noyau_ d'un système d'exploitation".
-- Doug713705
pehache-tolai
"doug713705" a écrit dans le message de news:
Par ailleurs, tu noteras que cygwin n'est pas autre chose qu'un _émulateur_,
Non, c'est une bibliothèque qui implémente (partiellement sans doute) les spécifications Posix
une partie de son code doit donc bien émuler quelque chose et en l'occurence le comportement attendu du système cible, non ?
Il n'y a pas de "comportement attendu d'un système"
Système cible qui n'est autre qu'un système POSIX théorique et seulement un système POSIX théorique (pas un Linux, pas un Unix, pas un Mac).
Un "système Posix théorique" ça n'existe pas. Posix ne requiert pas explicitement que l'implémentation soit dans le système.
-- pehache http://pehache.free.fr/public.html
"doug713705" <doug.letough@free.fr> a écrit dans le message de news:
pan.2009.08.01.07.38.39.578000@free.fr
Par ailleurs, tu noteras que cygwin n'est pas autre chose qu'un
_émulateur_,
Non, c'est une bibliothèque qui implémente (partiellement sans doute) les
spécifications Posix
une partie de son code doit donc bien émuler quelque
chose et en l'occurence le comportement attendu du système cible, non
?
Il n'y a pas de "comportement attendu d'un système"
Système cible qui n'est autre qu'un système POSIX théorique et
seulement un système POSIX théorique (pas un Linux, pas un Unix, pas
un Mac).
Un "système Posix théorique" ça n'existe pas. Posix ne requiert pas
explicitement que l'implémentation soit dans le système.
