> Si j'en crois les statistiques, il etait deja a 2-3% il y a 2-3 ans(ils parlaient de Linux passant le Mac), hors rien ne montre qu'il soit alle plus loin, d'ou le "manque de decollage" de mon point de vue.
D'accord. M'enfin, les stats ça change du jours au lendemain.
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 ?
Autre aspect a remarquer. Linux a été vite adopté par les geeks en tant que desktop (d'où une croissance rapide). Pour les geek, la partie est "gagnée". Je veux dire que Linux n'est plus une alternative exotique. Un geek qui utilise Linux, ça n'étonne personne. Au pif et sans le moindre chiffre, je dirais que Linux à 20 % des geeks ou hackers. 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.
> Le probleme c'est que les editeurs n'en ont rien a battre du 64bit jusqu'a ce qu'il commence a se repandre, le meme probleme que Linux a avec les editeurs.
Mais pourquoi les éditeurs (oracle, ibm, etc) font des versions 64 bits pour Linux et pas pour Windows ?
> MS met son poids dans la balance pour changer ca(Exchange 2007 est 64bits uniquement par exemple) mais ca prend du temps.
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.
Le fait est là, Linux à tout (ou 99,9 %) en 64 bits et Windows pas grand chose.
> le meme probleme que Linux a avec les editeurs.
Les éditeurs Linux font du 64 bits. Tu nous dis que Linux a gagné la partie pour le 64 bits ?
> Tout a fait, mais moi je parles techniquement, NT n'avait aucun probleme a passer a 64bits techniquement.
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.
> Combien est-ce que Redhat fait de chiffre d'affaire sur PPC et autres ? Rien du tout,
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. Si ça coutait cher, Red Hat auraient tord de faire du 64 bits (surtout que Red Hat est ridicule à côté de MS) et ça fait depuis longtemps qu'ils auraient arrêté de le faire. Si Red Hat le fait, c'est qu'il y voir un intérêt et en monnai sonnante et trébuchante. Mais clairement Red Hat ne doit pas perdre d'argent.
Red Hat vend beaucoup de 64 bits. D'ailleurs pour RHEL 5 il y aura encore le support pour IA64 (ce qui montre que Red Hat a beaucoup vendu de RHEL 3 et 4 pour IA64).
> In what follows I investigate the state of UTF-8 support under Linux (especially Debian
Debian est l'un des derniers distribution a être passé à UTF-8 !
Red Hat est passé à UTF-8 depuis la Red Hat 8.0 ! C'est configuré par défaut depuis RHL 8.0. Puis il y a eu RHL 9, FC1, FC2, FC3, FC4, FC5 et FC6. Il n'y a pas encore eu de Debian stable en UTF-8 ! (OK, ça ne devrait pas tarder).
Aussi, RHEL utilise UTF-8 par défaut depuis RHEL 3.
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).
Sous Linux en mode texte ça concerne la libc. En mode graphique ça concerne principalement gtk (pango). Malheureusement OpenOffice ne supporte pas pango et Mozilla que via un patch non officiel (qui marche bien mais impact significativement les performances). Le patch est dans Fedora depuis FC2 (pour Mozilla) et activé par défaut depuis FC3.
Notons que Firefox est principalement développé pour Windows (normal, il y a beaucoup plus d'utilisateur).
Ceci dit le support d'Unicode est une tâche énorme (avec les problèmes lorsqu'on mixe des écritures de gauche à droite et droite à gauche, par exemple, etc...), donc qu'il y ait des problèmes ne m'étonne pas.
> Les MFCs sont moches
Tu me fous la trouille. Je n'ai pas encore regardé MFC. Mais si MFC est pire que le reste, ça fous vraiment la trouille.
> HINSTANCE et HMODULE sont identiques(les 2 existent pour des raisons de compatibilite avec Windows 16bit)
Ben les deux sont dans le dernier SDK platform de Windows... (de 2006).
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.
> L'API il t'es difficile a retenir parce que tu debutes
Non. Par exemple DirectX, plus spécifiquement Direct3D, passe très bien. Et pourtant j'y connaissais rien dans le domaine des cartes graphiques.
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).
Regardes les fonctions liés à la mémoire sous Windows et compare avec Linux. T'as même un LOCALHANDLE... Des relant de Windows 16 bits dans le dernier SDK de Windows...
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.
> c'est l'utilite des typedefs: le compilo t'avertira si tu passes un HANDLE a une fonction qui veut un HINSTANCE.
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.
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é). Linux utilise des typedef là où c'est pertinant : quand le concèpt est différent. Un pid même si c'est stocké réellement dans un int (DWORD dans le language Windows) n'est pas un int, pour des raisons de portabilité, d'évolution système (lorsque le pid passe de 16 bits à 32), etc.
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. Donc le diff de deux pointeurs ou une taille mémoire n'est plus un int (DWORD) mais un long. Ben avec tous les DWORD dans l'API de Windows qui désigne des concepts différents (nombre, quantité de mémoire, etc), ça doit foutre un sacré bordel.
Linux (en fait POSIX) n'a pas ce problème. 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.
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...
De ce que j'ai vu jusqu'à maintenant il n'y a que Direct3D qui est une bonne API (et pourtant Direct3D est particulièrement complexe ce qui ce comprend très bien).
Quand on sait que les constructeurs de hardware sont très impliqués dans le développement de Direct3D, on comprend que Direct3D n'a pas le "Windows touch".
[^] # Re: Re:
Posté par IsNotGood . En réponse au journal [TROP LONG] Réflexions sur le libre. Évalué à 2.
D'accord. M'enfin, les stats ça change du jours au lendemain.
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 ?
Autre aspect a remarquer. Linux a été vite adopté par les geeks en tant que desktop (d'où une croissance rapide). Pour les geek, la partie est "gagnée". Je veux dire que Linux n'est plus une alternative exotique. Un geek qui utilise Linux, ça n'étonne personne. Au pif et sans le moindre chiffre, je dirais que Linux à 20 % des geeks ou hackers. 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.
> Le probleme c'est que les editeurs n'en ont rien a battre du 64bit jusqu'a ce qu'il commence a se repandre, le meme probleme que Linux a avec les editeurs.
Mais pourquoi les éditeurs (oracle, ibm, etc) font des versions 64 bits pour Linux et pas pour Windows ?
> MS met son poids dans la balance pour changer ca(Exchange 2007 est 64bits uniquement par exemple) mais ca prend du temps.
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.
Le fait est là, Linux à tout (ou 99,9 %) en 64 bits et Windows pas grand chose.
> le meme probleme que Linux a avec les editeurs.
Les éditeurs Linux font du 64 bits. Tu nous dis que Linux a gagné la partie pour le 64 bits ?
> Tout a fait, mais moi je parles techniquement, NT n'avait aucun probleme a passer a 64bits techniquement.
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.
> Combien est-ce que Redhat fait de chiffre d'affaire sur PPC et autres ? Rien du tout,
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. Si ça coutait cher, Red Hat auraient tord de faire du 64 bits (surtout que Red Hat est ridicule à côté de MS) et ça fait depuis longtemps qu'ils auraient arrêté de le faire. Si Red Hat le fait, c'est qu'il y voir un intérêt et en monnai sonnante et trébuchante. Mais clairement Red Hat ne doit pas perdre d'argent.
Red Hat vend beaucoup de 64 bits. D'ailleurs pour RHEL 5 il y aura encore le support pour IA64 (ce qui montre que Red Hat a beaucoup vendu de RHEL 3 et 4 pour IA64).
> In what follows I investigate the state of UTF-8 support under Linux (especially Debian
Debian est l'un des derniers distribution a être passé à UTF-8 !
Red Hat est passé à UTF-8 depuis la Red Hat 8.0 ! C'est configuré par défaut depuis RHL 8.0. Puis il y a eu RHL 9, FC1, FC2, FC3, FC4, FC5 et FC6. Il n'y a pas encore eu de Debian stable en UTF-8 ! (OK, ça ne devrait pas tarder).
Aussi, RHEL utilise UTF-8 par défaut depuis RHEL 3.
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).
Sous Linux en mode texte ça concerne la libc. En mode graphique ça concerne principalement gtk (pango). Malheureusement OpenOffice ne supporte pas pango et Mozilla que via un patch non officiel (qui marche bien mais impact significativement les performances). Le patch est dans Fedora depuis FC2 (pour Mozilla) et activé par défaut depuis FC3.
Notons que Firefox est principalement développé pour Windows (normal, il y a beaucoup plus d'utilisateur).
Ceci dit le support d'Unicode est une tâche énorme (avec les problèmes lorsqu'on mixe des écritures de gauche à droite et droite à gauche, par exemple, etc...), donc qu'il y ait des problèmes ne m'étonne pas.
> Les MFCs sont moches
Tu me fous la trouille. Je n'ai pas encore regardé MFC. Mais si MFC est pire que le reste, ça fous vraiment la trouille.
> HINSTANCE et HMODULE sont identiques(les 2 existent pour des raisons de compatibilite avec Windows 16bit)
Ben les deux sont dans le dernier SDK platform de Windows... (de 2006).
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.
> L'API il t'es difficile a retenir parce que tu debutes
Non. Par exemple DirectX, plus spécifiquement Direct3D, passe très bien. Et pourtant j'y connaissais rien dans le domaine des cartes graphiques.
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).
Regardes les fonctions liés à la mémoire sous Windows et compare avec Linux. T'as même un LOCALHANDLE... Des relant de Windows 16 bits dans le dernier SDK de Windows...
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.
> c'est l'utilite des typedefs: le compilo t'avertira si tu passes un HANDLE a une fonction qui veut un HINSTANCE.
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.
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é). Linux utilise des typedef là où c'est pertinant : quand le concèpt est différent. Un pid même si c'est stocké réellement dans un int (DWORD dans le language Windows) n'est pas un int, pour des raisons de portabilité, d'évolution système (lorsque le pid passe de 16 bits à 32), etc.
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. Donc le diff de deux pointeurs ou une taille mémoire n'est plus un int (DWORD) mais un long. Ben avec tous les DWORD dans l'API de Windows qui désigne des concepts différents (nombre, quantité de mémoire, etc), ça doit foutre un sacré bordel.
Linux (en fait POSIX) n'a pas ce problème. 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.
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...
De ce que j'ai vu jusqu'à maintenant il n'y a que Direct3D qui est une bonne API (et pourtant Direct3D est particulièrement complexe ce qui ce comprend très bien).
Quand on sait que les constructeurs de hardware sont très impliqués dans le développement de Direct3D, on comprend que Direct3D n'a pas le "Windows touch".