Exemple, au-dessus tu dis (sur la base d'une étude) que Linux a crû de 6.1 %. Sur la même période, le plus gros vendeur Linux fait du +40 % (chiffre absolu) !
Qui croire ?
Je sais pas, tout comme toi, mais disons qu'une societe a des raisons d'augmenter ses chiffres, IDC un peu moins.
Par contre en poste desktop pour monsieur tout le monde (la très grande majorité), c'est une tout autre histoire. Pour Linux y a, au pif et sans le moindre chiffre, 0,1 %. Donc pour arriver à 10 % il faut ... 16 ans.
Les chiffres je sais pas, mais d'accord sur la tendance. Linux vabien pour les geeks, et a plus de problemes pour monsieur tout le monde.
Il y a MS-Office en 64 bits ? Je n'en sais rien mais je ne crois pas.
Mais il y a bien openoffice en 64 bits pour Linux et il n'y a pas de version 64 bits pour Windows d'Openoffice.
Office c'est en cours je crois.
Quand a OpenOffice 64 bit, si je vais sur http://download.openoffice.org/680/index.html je ne le vois pas, et en cherchant sur le net, je ne vois nulle part trace d'une version stable 64bit
Ce que j'ai surtout voulu dire est que l'API (ce qui est vu par les programmes) sucks et rend difficile le portage d'une appli 32 bits vers 64 bits ce qui n'est pas le cas de Linux.
S'il est facile d'avoir des applis 64 bits sous Windows, pourquoi il n'y a pas MS-Office (j'imagine qu'il n'y a pas MS-Office en 64 bits, car en fait je n'en sais rien) ?
Linux a des ressources ridicules par rapport à Windows et pourtant tout est dispo en 64 bits.
a) Tout n'est pas dispo en 64bit sur Linux, loin de la
b) Tu me montres la difference des APIs entre 32bit et 64bit sur Windows ? Je t'aides, t'auras du mal.
Quand a Office, ben pour la meme raison qu'OpenOffice faut croire...
On dit que tu as raison. Mais si ça ne coute "rien du tout" à Red Hat d'avoir une version 64 bits, ils auraient tord de ne pas proposer du 64 bits. Si ça coute "rien du tout" pour avoir du 64 bits sous Linux, alors Linux est vachement bien foutu
Autre chose, Linux support UTF-8 (donc 2^32 caractères, c'est-à-dire tout unicode). Windows (et si mes renseignement sont bons) que UCS-2 (2^16 caractères). UCS-2 est insuffisant pour certain language (c'est pour ça que Unicode est passé à 2^32).
Windows supporte UTF-16 depuis un moment deja(depuis XP en tout cas), ca fait 6 ans...
Je ne crois pas que quelqu'un va installer le dernier SDK de Windows pour faire une application 16 bit.
Ces trucs ne sont qu'un pointeur sur l'adresse du début du programme ou dll. Tout un poème.
Par contre plein de boites prennent leur ancien code 16bit et veulent le recompiler en 32bit, et la ca rend les choses bcp plus simples vu qu'ils n'auront quasiment pas a changer leur code.
Exemple : Dans Linux tout ce qui est thread débute par pthread. Sous Windows c'est une autre histoire.
Sous Linux il n'y a que le pid du thread. Sous Windows il y a l'HANDLE et le pid (parfois nécessaire pour quelques fonctions).
Il n'y a pas de PID pour les threads sous Windows, il y a un thread ID, Linux a un Process ID pour des threads, alors que ce sont des threads, pas des process, tu m'expliqueras la logique.
Pour les APIs multithread, de nouveau, c'est parece que tu ne comprends rien a l'architecture de Windows.
Tu fais comment pour attendre sur un event, un timer, la fin d'un thread, ... sous Linux ? Ah oui, des APIs differents, sous Windows, tous ces elements sont des objets, et tu utilises WaitForSingleObject.
Pour le multi thread il y a les CRITICAL_SECTION/EnterCriticalSection/LeaveCriticalSection mais ça ne marche que pour un processus. En interprocessus, il faut autre chose (via les Event). Sous Linux, c'est la même chose pour intro-process et inter-process, tu dis seulement si tu veux que ça marche en inter-process (donc passage par le noyau systèmatique) ou non. C'est tout. La librairie C fait les appels système qui vont bien dernière. Si tu veux passer d'un processus à plusieurs, ça se passe comme une lettre à la poste.
Sous Windows, personne n'utilises le modele "plusieurs processus", sous Unix c'est frequent car jusqu'a recemment le support des threads etait a chier, resultat, tout le monde utilise les CRITICAL_SECTION
C'est gentil ça. Un timer (event) et un process a le même type sous Windows. En fait tous les "objects systèmes", selon la terminologie MS, a le type HANDLE. Tu peux passer un timer ou un block mémoire à la place d'un process ou d'un fichier, le compilo ne voit aucun problème. Ce n'est en rien le cas sous Linux et fort heureusement.
Un block memoire ? Tu fais ca comment pour avoir un HANDLE sur un block memoire ?
Quand a timer/process/... sont des objets, et tu as un HANDLE sur ces objets, avec lequel tu passes a WaitForSingleObject, resultat, tu peux attendre sur tous ces objets avec le meme API. Bien plus simple que les 32 APIs differents pour faire la meme chose sous Linux.
Les typedefs Windows en utilise des tonnes et pour des conneries. Par exemple pour char il y en a plus d'une dizaine !
Linux utilise beaucoup de typedef (probablement plus que Windows) mais pas pour des conneries (comme DWORD qu'on trouve partout ce qui doit poser de gros problème de portabilité).
Plutot que dire que c'est pour des conneries, et si tu donnais des exemples ou c'est inutile ?
Autre chose rigolote, c'est DWORD. C'est un int ou un long ? Ben je crois que même MS n'en sait rien. Ce n'est pas un problème en soit. Surtout que sur du 32 bits int=long. Mais pour 64 bits on peu avoir par exemple sizeof(int) = 4 et sizeof(long) = 8.
Oh si on le sait, c'est meme documente, comme tous les autres types : http://msdn2.microsoft.com/en-gb/library/aa383751.aspx mais visiblement tu ne lis pas la doc, dans ce cas pas etonnant que tu n'y comprennes rien.
Un DWORD c'est 32bit, non signe. Un DWORD64 je te laisses deviner.
Si tu codes correctement, passer de 32 bits à 64 bits (que sizeof(int) soit 4 ou 8, qu'importe), passe comme une lettre à la poste.
Tout comme sous Windows, mais ton probleme c'est que tu n'y connais rien et en parles quand meme.
Autre problème, Windows semble avoir des conventions de nommage mais elles sont peu respectée. Exemple : utiliser le préfix P pour le pointeur alors que c'est rarement utilisé. Les types qui sont parfois uniquement en majuscule et parfois un mix. Normalement ce qui commence par '_' est à usage interne d'une lib système (une appli ne doit pas l'utiliser !), ben sous Windows pas forcément, etc...
Donnes des exemples plutot que donner des generalites, ca rendra ton discours plus credible.
[^] # Re: Re:
Posté par pasBill pasGates . En réponse au journal [TROP LONG] Réflexions sur le libre. Évalué à 0.
Qui croire ?
Je sais pas, tout comme toi, mais disons qu'une societe a des raisons d'augmenter ses chiffres, IDC un peu moins.
Par contre en poste desktop pour monsieur tout le monde (la très grande majorité), c'est une tout autre histoire. Pour Linux y a, au pif et sans le moindre chiffre, 0,1 %. Donc pour arriver à 10 % il faut ... 16 ans.
Les chiffres je sais pas, mais d'accord sur la tendance. Linux vabien pour les geeks, et a plus de problemes pour monsieur tout le monde.
Il y a MS-Office en 64 bits ? Je n'en sais rien mais je ne crois pas.
Mais il y a bien openoffice en 64 bits pour Linux et il n'y a pas de version 64 bits pour Windows d'Openoffice.
Office c'est en cours je crois.
Quand a OpenOffice 64 bit, si je vais sur http://download.openoffice.org/680/index.html je ne le vois pas, et en cherchant sur le net, je ne vois nulle part trace d'une version stable 64bit
Ce que j'ai surtout voulu dire est que l'API (ce qui est vu par les programmes) sucks et rend difficile le portage d'une appli 32 bits vers 64 bits ce qui n'est pas le cas de Linux.
S'il est facile d'avoir des applis 64 bits sous Windows, pourquoi il n'y a pas MS-Office (j'imagine qu'il n'y a pas MS-Office en 64 bits, car en fait je n'en sais rien) ?
Linux a des ressources ridicules par rapport à Windows et pourtant tout est dispo en 64 bits.
a) Tout n'est pas dispo en 64bit sur Linux, loin de la
b) Tu me montres la difference des APIs entre 32bit et 64bit sur Windows ? Je t'aides, t'auras du mal.
Quand a Office, ben pour la meme raison qu'OpenOffice faut croire...
On dit que tu as raison. Mais si ça ne coute "rien du tout" à Red Hat d'avoir une version 64 bits, ils auraient tord de ne pas proposer du 64 bits. Si ça coute "rien du tout" pour avoir du 64 bits sous Linux, alors Linux est vachement bien foutu
Ben moi je vais voir http://www.redhat.com/about/presscenter/2005/press_rhel4.htm(...) et je vois qu'ils supportent x86, Itanium, AMD64 et Power.
Voila, ca fait UN de plus que Windows, c'est a dire aucune difference a peu pres.
Autre chose, Linux support UTF-8 (donc 2^32 caractères, c'est-à-dire tout unicode). Windows (et si mes renseignement sont bons) que UCS-2 (2^16 caractères). UCS-2 est insuffisant pour certain language (c'est pour ça que Unicode est passé à 2^32).
Windows supporte UTF-16 depuis un moment deja(depuis XP en tout cas), ca fait 6 ans...
Je ne crois pas que quelqu'un va installer le dernier SDK de Windows pour faire une application 16 bit.
Ces trucs ne sont qu'un pointeur sur l'adresse du début du programme ou dll. Tout un poème.
Par contre plein de boites prennent leur ancien code 16bit et veulent le recompiler en 32bit, et la ca rend les choses bcp plus simples vu qu'ils n'auront quasiment pas a changer leur code.
Exemple : Dans Linux tout ce qui est thread débute par pthread. Sous Windows c'est une autre histoire.
Sous Linux il n'y a que le pid du thread. Sous Windows il y a l'HANDLE et le pid (parfois nécessaire pour quelques fonctions).
Il n'y a pas de PID pour les threads sous Windows, il y a un thread ID, Linux a un Process ID pour des threads, alors que ce sont des threads, pas des process, tu m'expliqueras la logique.
Pour les APIs multithread, de nouveau, c'est parece que tu ne comprends rien a l'architecture de Windows.
Tu fais comment pour attendre sur un event, un timer, la fin d'un thread, ... sous Linux ? Ah oui, des APIs differents, sous Windows, tous ces elements sont des objets, et tu utilises WaitForSingleObject.
Pour le multi thread il y a les CRITICAL_SECTION/EnterCriticalSection/LeaveCriticalSection mais ça ne marche que pour un processus. En interprocessus, il faut autre chose (via les Event). Sous Linux, c'est la même chose pour intro-process et inter-process, tu dis seulement si tu veux que ça marche en inter-process (donc passage par le noyau systèmatique) ou non. C'est tout. La librairie C fait les appels système qui vont bien dernière. Si tu veux passer d'un processus à plusieurs, ça se passe comme une lettre à la poste.
Sous Windows, personne n'utilises le modele "plusieurs processus", sous Unix c'est frequent car jusqu'a recemment le support des threads etait a chier, resultat, tout le monde utilise les CRITICAL_SECTION
C'est gentil ça. Un timer (event) et un process a le même type sous Windows. En fait tous les "objects systèmes", selon la terminologie MS, a le type HANDLE. Tu peux passer un timer ou un block mémoire à la place d'un process ou d'un fichier, le compilo ne voit aucun problème. Ce n'est en rien le cas sous Linux et fort heureusement.
Un block memoire ? Tu fais ca comment pour avoir un HANDLE sur un block memoire ?
Quand a timer/process/... sont des objets, et tu as un HANDLE sur ces objets, avec lequel tu passes a WaitForSingleObject, resultat, tu peux attendre sur tous ces objets avec le meme API. Bien plus simple que les 32 APIs differents pour faire la meme chose sous Linux.
Les typedefs Windows en utilise des tonnes et pour des conneries. Par exemple pour char il y en a plus d'une dizaine !
Linux utilise beaucoup de typedef (probablement plus que Windows) mais pas pour des conneries (comme DWORD qu'on trouve partout ce qui doit poser de gros problème de portabilité).
Plutot que dire que c'est pour des conneries, et si tu donnais des exemples ou c'est inutile ?
Autre chose rigolote, c'est DWORD. C'est un int ou un long ? Ben je crois que même MS n'en sait rien. Ce n'est pas un problème en soit. Surtout que sur du 32 bits int=long. Mais pour 64 bits on peu avoir par exemple sizeof(int) = 4 et sizeof(long) = 8.
Oh si on le sait, c'est meme documente, comme tous les autres types : http://msdn2.microsoft.com/en-gb/library/aa383751.aspx mais visiblement tu ne lis pas la doc, dans ce cas pas etonnant que tu n'y comprennes rien.
Un DWORD c'est 32bit, non signe. Un DWORD64 je te laisses deviner.
Si tu codes correctement, passer de 32 bits à 64 bits (que sizeof(int) soit 4 ou 8, qu'importe), passe comme une lettre à la poste.
Tout comme sous Windows, mais ton probleme c'est que tu n'y connais rien et en parles quand meme.
Autre problème, Windows semble avoir des conventions de nommage mais elles sont peu respectée. Exemple : utiliser le préfix P pour le pointeur alors que c'est rarement utilisé. Les types qui sont parfois uniquement en majuscule et parfois un mix. Normalement ce qui commence par '_' est à usage interne d'une lib système (une appli ne doit pas l'utiliser !), ben sous Windows pas forcément, etc...
Donnes des exemples plutot que donner des generalites, ca rendra ton discours plus credible.