Je pense que ce qui était justifié c'était l'ajout du premier windows avec ms
dos
Je sais que ms depuis windows 95 fait de l'artifice
La super blonde américaine qui se maquille de plus en plus au fur et a mesure
qu'elle vieillie
Je pense que ce qui était justifié c'était l'ajout du premier windows avec ms
dos
Je sais que ms depuis windows 95 fait de l'artifice
La super blonde américaine qui se maquille de plus en plus au fur et a mesure
qu'elle vieillie
Je pense que ce qui était justifié c'était l'ajout du premier windows avec ms
dos
Je sais que ms depuis windows 95 fait de l'artifice
La super blonde américaine qui se maquille de plus en plus au fur et a mesure
qu'elle vieillie
Le 02/01/2014 21:05, Moreira David a écrit :Toxico Nimbus writes:Le 01/01/2014 10:25, Moreira David a écrit :sedenion writes:Le C++ marche très bien, le java est inutile (comment ce truc a fait
pour percer ?), et les autres sont des trucs plus spécialisà ©s.. Les
merdes de microsoft comme le C# ou le M# sont des trucs inutiles comme
le Java si non à rendre les développeurs dépendants d' une plate-forme
qui ne font, en gros, qu'exploiter le surplus de puissance du matà ©riel
par leur architecture lourde et mal optimisée histoire de justif ier
qu'on vende du 16 cores en V à injection direct à 4.0Ghz.
- Le C++ est lourd et complexe. Cependant, c'est un langage amusant
qu'il faut essayer.
Je ne vois vraiment pas ce qu'il y a de récréatif dans le C++ . S'il y
a un langage qu'il vaut mieux aborder avec rigueur, c'est surement
celui-là .
Tu vas dire le contraireâ¦
Non, je n'ai pas écrit après que le C++ est amusant.
Après l'idée de compile-once run-everywhere n'est pas une ma uvaise idée
en soi⦠si un compilateur natif n'était inclus dans la VM . Du coup,
aucun n'intéreÌt de perdre tu temps lors de l'execution pour compiler
vers du natif.
Pour tout ce qui est transactionnel, un langage à VM+JIT s'exà ©cute
aussi vite que du code compilé. L'avantage est que ton code compil é
est distribuable partout, avec une compatibilité ascendante
quasi-parfaite, et ce en gardant le code fermé.
Car c'est limité par les e/s. Je ne penses pas que quelqu'un pense Ã
faire une db in-memory dans un langage Jitté ou sous VM.
1° Une bd "in-memory", ça ne sert à rien, et ce dans 100% des cas.
2° Du point de vue performances, je ne vois pas où un langage " jitté"
pêcherait.
Le 02/01/2014 21:05, Moreira David a écrit :
Toxico Nimbus <toxn@free.fr> writes:
Le 01/01/2014 10:25, Moreira David a écrit :
sedenion <root@sedenion.42> writes:
Le C++ marche très bien, le java est inutile (comment ce truc a fait
pour percer ?), et les autres sont des trucs plus spécialisà ©s.. Les
merdes de microsoft comme le C# ou le M# sont des trucs inutiles comme
le Java si non à rendre les développeurs dépendants d' une plate-forme
qui ne font, en gros, qu'exploiter le surplus de puissance du matà ©riel
par leur architecture lourde et mal optimisée histoire de justif ier
qu'on vende du 16 cores en V à injection direct à 4.0Ghz.
- Le C++ est lourd et complexe. Cependant, c'est un langage amusant
qu'il faut essayer.
Je ne vois vraiment pas ce qu'il y a de récréatif dans le C++ . S'il y
a un langage qu'il vaut mieux aborder avec rigueur, c'est surement
celui-là .
Tu vas dire le contraireâ¦
Non, je n'ai pas écrit après que le C++ est amusant.
Après l'idée de compile-once run-everywhere n'est pas une ma uvaise idée
en soi⦠si un compilateur natif n'était inclus dans la VM . Du coup,
aucun n'intéreÌt de perdre tu temps lors de l'execution pour compiler
vers du natif.
Pour tout ce qui est transactionnel, un langage à VM+JIT s'exà ©cute
aussi vite que du code compilé. L'avantage est que ton code compil é
est distribuable partout, avec une compatibilité ascendante
quasi-parfaite, et ce en gardant le code fermé.
Car c'est limité par les e/s. Je ne penses pas que quelqu'un pense Ã
faire une db in-memory dans un langage Jitté ou sous VM.
1° Une bd "in-memory", ça ne sert à rien, et ce dans 100% des cas.
2° Du point de vue performances, je ne vois pas où un langage " jitté"
pêcherait.
Le 02/01/2014 21:05, Moreira David a écrit :Toxico Nimbus writes:Le 01/01/2014 10:25, Moreira David a écrit :sedenion writes:Le C++ marche très bien, le java est inutile (comment ce truc a fait
pour percer ?), et les autres sont des trucs plus spécialisà ©s.. Les
merdes de microsoft comme le C# ou le M# sont des trucs inutiles comme
le Java si non à rendre les développeurs dépendants d' une plate-forme
qui ne font, en gros, qu'exploiter le surplus de puissance du matà ©riel
par leur architecture lourde et mal optimisée histoire de justif ier
qu'on vende du 16 cores en V à injection direct à 4.0Ghz.
- Le C++ est lourd et complexe. Cependant, c'est un langage amusant
qu'il faut essayer.
Je ne vois vraiment pas ce qu'il y a de récréatif dans le C++ . S'il y
a un langage qu'il vaut mieux aborder avec rigueur, c'est surement
celui-là .
Tu vas dire le contraireâ¦
Non, je n'ai pas écrit après que le C++ est amusant.
Après l'idée de compile-once run-everywhere n'est pas une ma uvaise idée
en soi⦠si un compilateur natif n'était inclus dans la VM . Du coup,
aucun n'intéreÌt de perdre tu temps lors de l'execution pour compiler
vers du natif.
Pour tout ce qui est transactionnel, un langage à VM+JIT s'exà ©cute
aussi vite que du code compilé. L'avantage est que ton code compil é
est distribuable partout, avec une compatibilité ascendante
quasi-parfaite, et ce en gardant le code fermé.
Car c'est limité par les e/s. Je ne penses pas que quelqu'un pense Ã
faire une db in-memory dans un langage Jitté ou sous VM.
1° Une bd "in-memory", ça ne sert à rien, et ce dans 100% des cas.
2° Du point de vue performances, je ne vois pas où un langage " jitté"
pêcherait.
On 2014-01-02, Moreira David wrote:Oups, je parlais de la planification des processus, soit l'ordonanceur
de processus.
Dans ce cas, pourquoi ne pas dire juste « scheduler » ?
On 2014-01-02, Moreira David <vash2593@myopera.com> wrote:
Oups, je parlais de la planification des processus, soit l'ordonanceur
de processus.
Dans ce cas, pourquoi ne pas dire juste « scheduler » ?
On 2014-01-02, Moreira David wrote:Oups, je parlais de la planification des processus, soit l'ordonanceur
de processus.
Dans ce cas, pourquoi ne pas dire juste « scheduler » ?
On 2014-01-02, Toxico Nimbus wrote:particulier. Preuve en est que mono peut l'implémenter à peu près
partout, DotGNU n'en était pas loin.
Et au niveau de l'embarrassement des brevets, il en est où,
ce bidule faramineux ?
On 2014-01-02, Toxico Nimbus <toxn@free.fr> wrote:
particulier. Preuve en est que mono peut l'implémenter à peu près
partout, DotGNU n'en était pas loin.
Et au niveau de l'embarrassement des brevets, il en est où,
ce bidule faramineux ?
On 2014-01-02, Toxico Nimbus wrote:particulier. Preuve en est que mono peut l'implémenter à peu près
partout, DotGNU n'en était pas loin.
Et au niveau de l'embarrassement des brevets, il en est où,
ce bidule faramineux ?
Toxico Nimbus writes:2° Du point de vue performances, je ne vois pas où un langage "jitté"
pêcherait.
À cause du jit, peut être ? Si on enlève le problème des e/s.
Toxico Nimbus <toxn@free.fr> writes:
2° Du point de vue performances, je ne vois pas où un langage "jitté"
pêcherait.
À cause du jit, peut être ? Si on enlève le problème des e/s.
Toxico Nimbus writes:2° Du point de vue performances, je ne vois pas où un langage "jitté"
pêcherait.
À cause du jit, peut être ? Si on enlève le problème des e/s.
Toxico Nimbus , dans le message <52c5de55$0$3649$,
a écrit :1° Une bd "in-memory", ça ne sert à rien, et ce dans 100% des cas.
Je vois beaucoup de cas où ce serait une solution beaucoup plus efficace et
simple que les usines à gaz habituelles : quand l'ensemble des données ne
représente que quelques dizaines de méga-octets au total, ce qui est quand
même très fréquent.
Toxico Nimbus , dans le message <52c5de55$0$3649$426a74cc@news.free.fr>,
a écrit :
1° Une bd "in-memory", ça ne sert à rien, et ce dans 100% des cas.
Je vois beaucoup de cas où ce serait une solution beaucoup plus efficace et
simple que les usines à gaz habituelles : quand l'ensemble des données ne
représente que quelques dizaines de méga-octets au total, ce qui est quand
même très fréquent.
Toxico Nimbus , dans le message <52c5de55$0$3649$,
a écrit :1° Une bd "in-memory", ça ne sert à rien, et ce dans 100% des cas.
Je vois beaucoup de cas où ce serait une solution beaucoup plus efficace et
simple que les usines à gaz habituelles : quand l'ensemble des données ne
représente que quelques dizaines de méga-octets au total, ce qui est quand
même très fréquent.
After serious thinking Trolleur Polémiqueur wrote :Je pense que ce qui était justifié c'était l'ajout du premier windows avec ms
dos
Je sais que ms depuis windows 95 fait de l'artifice
La super blonde américaine qui se maquille de plus en plus au fur et a mesure
qu'elle vieillie
Je vois que tu ne connait rien du tout à la technique des systèmes...
Win95 (et partiellement Win3.11 Workgroup) mettait en place une
architecture basée sur Win32 qui s'affranchissait de DOS, même si ces
systèmes bootaient dessus.
En effet, les logicies dans l'environnement Windows héritaient de
possibilités qui n'avaient plus aucun rapport avec MSDOS..., notamment
en terme de gestion de mémoire et de multitâche, puisque MSDOS n'était
pas multitâche...
Avec Windows NT, le DOS a été totalement retiré, et de la slquence de
démarrage, et ne subsistait plus alors qu'un interptéteur de commande
qui fournissait une EMULATION de DOS, afin de faire fonctionner
"certains" programmes DOS en 16 bits.
Par la suite les versions Windows 64 bits ont totelement perdu cette
compatibilité, puisque le support 16 bits ne fonctionne simplement pas
dans les environnements 64 bits, ce qui est valable pour Windows 2003
64, WinXP 64, WinVista 64, Win7 et Win8 64 bits.
Les éditions 32 bits ont toujours une émulation de compatiblité limité.
En fait Windows NT et Win9X/Me supportent les 2 l'environnement WIN32,
mais l'architecture est totalement différentes.
Midori sera aussi une nouvelle architecture, avec la même différence
que l'on trouve entre Win9X/ME et WinNT.
Maintenant, y'âura t'il aussi une compatibilité DOS, c'est assez
incertain
Y'aura t'il une compatibilité WIN32 et WoW64 pour faire fonctionner les
logiciels actuels, cela me parait assez vraisemblable, mais pas
certain.
Y'aura t'il des logiciels à redévelopper entioèrement ? Et bien oui, il
devront être ré-écrit pour bénéficier des nouveautés de Midori.
L'architecture WINNT a maintenant 20 ans, cela parait opportun de la
laisser passer à la retraite.
Pour info, Apple travaille aussi sur un nouveau système qui devrait
mettre de côté l'architecture UNIX.
Gageons que les 2 entreprises sortiront leurs successeurs en même temps
;>)
After serious thinking Trolleur Polémiqueur wrote :
Je pense que ce qui était justifié c'était l'ajout du premier windows avec ms
dos
Je sais que ms depuis windows 95 fait de l'artifice
La super blonde américaine qui se maquille de plus en plus au fur et a mesure
qu'elle vieillie
Je vois que tu ne connait rien du tout à la technique des systèmes...
Win95 (et partiellement Win3.11 Workgroup) mettait en place une
architecture basée sur Win32 qui s'affranchissait de DOS, même si ces
systèmes bootaient dessus.
En effet, les logicies dans l'environnement Windows héritaient de
possibilités qui n'avaient plus aucun rapport avec MSDOS..., notamment
en terme de gestion de mémoire et de multitâche, puisque MSDOS n'était
pas multitâche...
Avec Windows NT, le DOS a été totalement retiré, et de la slquence de
démarrage, et ne subsistait plus alors qu'un interptéteur de commande
qui fournissait une EMULATION de DOS, afin de faire fonctionner
"certains" programmes DOS en 16 bits.
Par la suite les versions Windows 64 bits ont totelement perdu cette
compatibilité, puisque le support 16 bits ne fonctionne simplement pas
dans les environnements 64 bits, ce qui est valable pour Windows 2003
64, WinXP 64, WinVista 64, Win7 et Win8 64 bits.
Les éditions 32 bits ont toujours une émulation de compatiblité limité.
En fait Windows NT et Win9X/Me supportent les 2 l'environnement WIN32,
mais l'architecture est totalement différentes.
Midori sera aussi une nouvelle architecture, avec la même différence
que l'on trouve entre Win9X/ME et WinNT.
Maintenant, y'âura t'il aussi une compatibilité DOS, c'est assez
incertain
Y'aura t'il une compatibilité WIN32 et WoW64 pour faire fonctionner les
logiciels actuels, cela me parait assez vraisemblable, mais pas
certain.
Y'aura t'il des logiciels à redévelopper entioèrement ? Et bien oui, il
devront être ré-écrit pour bénéficier des nouveautés de Midori.
L'architecture WINNT a maintenant 20 ans, cela parait opportun de la
laisser passer à la retraite.
Pour info, Apple travaille aussi sur un nouveau système qui devrait
mettre de côté l'architecture UNIX.
Gageons que les 2 entreprises sortiront leurs successeurs en même temps
;>)
After serious thinking Trolleur Polémiqueur wrote :Je pense que ce qui était justifié c'était l'ajout du premier windows avec ms
dos
Je sais que ms depuis windows 95 fait de l'artifice
La super blonde américaine qui se maquille de plus en plus au fur et a mesure
qu'elle vieillie
Je vois que tu ne connait rien du tout à la technique des systèmes...
Win95 (et partiellement Win3.11 Workgroup) mettait en place une
architecture basée sur Win32 qui s'affranchissait de DOS, même si ces
systèmes bootaient dessus.
En effet, les logicies dans l'environnement Windows héritaient de
possibilités qui n'avaient plus aucun rapport avec MSDOS..., notamment
en terme de gestion de mémoire et de multitâche, puisque MSDOS n'était
pas multitâche...
Avec Windows NT, le DOS a été totalement retiré, et de la slquence de
démarrage, et ne subsistait plus alors qu'un interptéteur de commande
qui fournissait une EMULATION de DOS, afin de faire fonctionner
"certains" programmes DOS en 16 bits.
Par la suite les versions Windows 64 bits ont totelement perdu cette
compatibilité, puisque le support 16 bits ne fonctionne simplement pas
dans les environnements 64 bits, ce qui est valable pour Windows 2003
64, WinXP 64, WinVista 64, Win7 et Win8 64 bits.
Les éditions 32 bits ont toujours une émulation de compatiblité limité.
En fait Windows NT et Win9X/Me supportent les 2 l'environnement WIN32,
mais l'architecture est totalement différentes.
Midori sera aussi une nouvelle architecture, avec la même différence
que l'on trouve entre Win9X/ME et WinNT.
Maintenant, y'âura t'il aussi une compatibilité DOS, c'est assez
incertain
Y'aura t'il une compatibilité WIN32 et WoW64 pour faire fonctionner les
logiciels actuels, cela me parait assez vraisemblable, mais pas
certain.
Y'aura t'il des logiciels à redévelopper entioèrement ? Et bien oui, il
devront être ré-écrit pour bénéficier des nouveautés de Midori.
L'architecture WINNT a maintenant 20 ans, cela parait opportun de la
laisser passer à la retraite.
Pour info, Apple travaille aussi sur un nouveau système qui devrait
mettre de côté l'architecture UNIX.
Gageons que les 2 entreprises sortiront leurs successeurs en même temps
;>)
Je ne vois pas, tu as un exemple concret ?
Je ne vois pas, tu as un exemple concret ?
Je ne vois pas, tu as un exemple concret ?
Le Fri, 03 Jan 2014 01:27:19 +0100,
P4nd1-P4nd4 <P4nd1-P4nd4@> écrivait :Y'aura t'il une compatibilité WIN32 et WoW64 pour faire fonctionner les
logiciels actuels, cela me parait assez vraisemblable, mais pas
certain.
Y'aura t'il des logiciels à redévelopper entioèrement ? Et bien oui, il
devront être ré-écrit pour bénéficier des nouveautés de Midori.
Pourquoi ? Faudrait-il croire que les API WIN machin chose sont
tellement moisies qu'il faut les reprendre à chaque nouvelle mouture
du bousin ?
L'architecture WINNT a maintenant 20 ans, cela parait opportun de la
laisser passer à la retraite.
Je ne vois pas pourquoi. Sous tous les systèmes dignes de ce nom, il
y a une couche d'abstraction entre le matériel et le coeur du
système. Sous Unix, c'est la libc, sous VMS, c'est la LIB$RTL, sous
OS/2, j'ai oublié le nom mais elle existe aussi. Si l'API de Windows
était potable, rien n'empêcherait de la conserver même si le moteur
sous le capot changeait du tout au tout.
Le Fri, 03 Jan 2014 01:27:19 +0100,
P4nd1-P4nd4 <P4nd1-P4nd4@> écrivait :
Y'aura t'il une compatibilité WIN32 et WoW64 pour faire fonctionner les
logiciels actuels, cela me parait assez vraisemblable, mais pas
certain.
Y'aura t'il des logiciels à redévelopper entioèrement ? Et bien oui, il
devront être ré-écrit pour bénéficier des nouveautés de Midori.
Pourquoi ? Faudrait-il croire que les API WIN machin chose sont
tellement moisies qu'il faut les reprendre à chaque nouvelle mouture
du bousin ?
L'architecture WINNT a maintenant 20 ans, cela parait opportun de la
laisser passer à la retraite.
Je ne vois pas pourquoi. Sous tous les systèmes dignes de ce nom, il
y a une couche d'abstraction entre le matériel et le coeur du
système. Sous Unix, c'est la libc, sous VMS, c'est la LIB$RTL, sous
OS/2, j'ai oublié le nom mais elle existe aussi. Si l'API de Windows
était potable, rien n'empêcherait de la conserver même si le moteur
sous le capot changeait du tout au tout.
Le Fri, 03 Jan 2014 01:27:19 +0100,
P4nd1-P4nd4 <P4nd1-P4nd4@> écrivait :Y'aura t'il une compatibilité WIN32 et WoW64 pour faire fonctionner les
logiciels actuels, cela me parait assez vraisemblable, mais pas
certain.
Y'aura t'il des logiciels à redévelopper entioèrement ? Et bien oui, il
devront être ré-écrit pour bénéficier des nouveautés de Midori.
Pourquoi ? Faudrait-il croire que les API WIN machin chose sont
tellement moisies qu'il faut les reprendre à chaque nouvelle mouture
du bousin ?
L'architecture WINNT a maintenant 20 ans, cela parait opportun de la
laisser passer à la retraite.
Je ne vois pas pourquoi. Sous tous les systèmes dignes de ce nom, il
y a une couche d'abstraction entre le matériel et le coeur du
système. Sous Unix, c'est la libc, sous VMS, c'est la LIB$RTL, sous
OS/2, j'ai oublié le nom mais elle existe aussi. Si l'API de Windows
était potable, rien n'empêcherait de la conserver même si le moteur
sous le capot changeait du tout au tout.
Toxico Nimbus , dans le message <52c668c3$0$2214$,
a écrit :Je ne vois pas, tu as un exemple concret ?
Tu n'arrives pas à imaginer des cas où tu as une base de données de moins de
50 Mo ? Ou moins de 1 Go avec une machine dédiée ?
Toxico Nimbus , dans le message <52c668c3$0$2214$426a74cc@news.free.fr>,
a écrit :
Je ne vois pas, tu as un exemple concret ?
Tu n'arrives pas à imaginer des cas où tu as une base de données de moins de
50 Mo ? Ou moins de 1 Go avec une machine dédiée ?
Toxico Nimbus , dans le message <52c668c3$0$2214$,
a écrit :Je ne vois pas, tu as un exemple concret ?
Tu n'arrives pas à imaginer des cas où tu as une base de données de moins de
50 Mo ? Ou moins de 1 Go avec une machine dédiée ?
