Les chiffres de Red Hat sont des chiffres comptables. De plus Red Hat étant en bourse ils sont vérifiables. Là tu dis que Red Hat magouille et tu pousses le bouchon un peu loin si tu n'as aucune preuve
Ben non, moi je croyais que tu parlais de parts de marche, pas de chiffres comptables. Qui te dit que les 2 chiffres sont lies chez Redhat ? Ils vendent du JBoss aussi par exemple.
Cherches openoffice, tu le trouveras en 64 bits. Ce n'est qu'un exemple.
Ceci dit, c'est récent. Mais Openoffice est aussi dispo sur Sparc depuis longtemps.
Sparc je sais, mais on parle de Linux ici.
De ce que j'en ai lu, c'est pas tres utilisable, notamment vis a vis de problemes avec Java sur plateforme 64bit.
Ouais, il manque flash.
Tout n'est pas dispo en 64 bit sur Linux. Seulement 99,9 %.
Ah oui ? T'as Quake 64bits ? Flash 64bits ? Acrobat Reader 64bits ? ...
La plupart des softs "grand public" ne sont pas dispo en 64bit sur Linux, et les softs "serveurs" le sont, tout comme sous Windows. Car Oracle, Mathematica, DB2, ... sont dispo en 64bits pour Windows.
Ben si tout nickel (au moins autant que Linux), MS-Office en 64 bits ne coûte rien à faire et devrait déjà être là !
Alors pourquoi il n'y a pas de MS-Office en 64 bits alors que depuis Windows NT il y a une version de Windows en 64 bits ?
Parce qu'OpenOffice 64bit sur Linux n'est pas encore utilisable(cf. problemes Java plus haut), bref, ils en sont au meme point.
Sauf qu'il y a tout dedans. Et pour PowerPPC, c'est 64 bits.
De plus, je n'ai pas souvenir que Windows a une version AMD64 ! J'ai seulement entendu parlé de versions béta et qu'il y a une version AMD64 pour Vista. C'est donc très récent.
C'est dispo au public depuis 2005(XP x64 et WS03 x64), et ca tournait depuis bien plus longtemps en interne.
Ce qui est du pipo. Windows est passé à ucs-2 avec Windows NT (ou 2000?). Et je dis bien ucs-2 (2^16 caractères) et non utf-8 (2^32 caractères). Windows 2000 utilise ucs-2 (j'en mettrais ma main au feu) et XP n'est qu'une évolution de Windows 2000.
J'espère que tu vois maintenant la logique évidente.
C'est comme ça pour LinuxThread et NPTL.
Ca ne date en fait que depuis 2002-2003, j'en parles car j'avais eu le probleme a l'epoque, du code qui fonctionnait parfaitement sur Solaris devait etre trifouille pour tourner sur Linux a cause de cette anerie. C'est une bonne chose qu'ils l'aient corrige, mais ca a pris du temps.
Ce qui est de la connerie. Le modèle "plusieurs processus" a ses avantages et idem pour le multi-threading.
Le gros problème du multi-threading est que le plantage d'un thread fait planter pour le processus. Et c'est la même chose sous Windows.
Tout a fait, mais la ou sur Unix il est habituel d'utiliser des processus simplement pour faire du traitement en parralelle, sous Windows c'est fait avec des threads d'habitude. Il y a bien entendu des cas ou tu utilises des processus separes, mais c'est assez rare.
Et il me semble bien que Windows fournit un truc style "job control" pour "mimer" Unix. Les "jobs" sont des processus et non des thread.
Un job c'est en fait bien plus qu'un processus, c'est un ensemble de processus, sur lesquels tu peux mettre plein de contraintes.
Rires. Tous les Unix commerciaux ont du multi-thread depuis longtemps. Il n'y a que Linux qui a mis du temps car Linux a débuté en 91 (il était embryonnaire). La version 2.0 de Linux avait le multi-thread. Linux 2.0 est sorti quasiment en même temps que Windows 95/NT (en fait Linux l'avait pour la version 1.2.13 mais pas pour 1.2.0). Donc Windows n'a pas le multi-threading depuis plus longtemps que Linux et assurément pas avant les Unix commerciaux.
J'ai melange Unix et Linux, Solaris a toujours eu un tres bon support des threads, ma cible ici c'est Linux qui m'en a fait baver a l'epoque car l'implementation des pthreads jusqu'a recemment etait vraiment a chier(va t'amuser a passer des signaux a des threads avec un Linux de l'epoque, tu comprendras ma douleur)
Sous Linux pour attendre la fin d'un thread on fait pthread_join(pthread_t, void **). Ce n'est pas la mer à boire, c'est lisible.
Tout a fait c'est lisible, le probleme c'est que c'est uniquement pour un thread, il te faut 10 APIs pour faire la meme chose: attendre sur un objet.
Donc on a des api qui exige spécifiquement du uint32...
Sous Linux on n'a pas ça. On a pid_t qui on une taille qui colle au hardware ou au besoin de la fonction. Mais on ne dit pas qu'un pid_t doit être un uint32. Un jour c'est un int16, un autre c'est un int32, on s'en fout. Il y a toujours des exceptions.
Attends tu me fais bien rire, je parles de uint32, qui clairement a ete cree pour representer un entier 32bits et rien d'autres, tout comme il y a un equivalent sous Linux,et tu parles de pid_t, quel rapport ? Jettes un oeil sur les APIs, tu verras plein d'APIs qui utilisent un size_t par exemple(qui varie selon la machine, ...)
difference entre WCHAR/CHAR et LPWSTR/LPCSTR
La difference est pourtant simple, LPWSTR/LPCSTR sont la pour representer une chaine de texte(un pointer sur un array de char quoi), WCHAR/CHAR c'est un caractere, et un pointeur sur WCHAR/CHAR, c'est un pointeur sur un caractere.
Alors meme si au final c'est la meme chose, conceptuellement ca ne l'est pas, tu utilises LPWSTR quand tu veux une chaine de caracteres, et tu utilises WCHAR* quand tu veux un pointeur sur un caractere.
Donc Windows ne support que ucs-2. Merci d'en faire la démonstration.
Va lire la page du dessus et tu comprendras que tu as tort, c'est pas a moi que tu vas apprendre quel character set Windows supporte :+)
Très bien, fais ce que tu dis et arrêtes de parler du logiciel libre.
Le truc est que j'ai passe des annees sur Linux, a une periode meme exclusivement sur Linux, je connais le systeme.
Toi ça fait depuis des années et tu ne sais toujours pas que Windows ne supporte que ucs-2 et pas UTF-8. UTF-8 est une façon de coder usc-4 (unicode) et a 2^32 valeurs. Ça ne rentre pas dans du 16 bits. wchar_t sous Linux est dans son implémentation actuelle du 32 bits. wchar_t n'est pas défini comme étant un int32, mais comme étant un wide caractère. Qu'il occupe 8, 16, 24 ou 32 bits, n'est pas une propriété que le développeur doit utiliser ni savoir (sauf pour débuggeur).
Avec la définition qu'a Windows de wchar_t, ça ne va pas être facile de passer à usc-4...
Ben moi je te propose de relire la doc, et te rendre compte que le fait que WCHAR est 16bit n'y change rien(cf. l'article que je t'ai donne plus haut). De meme que sous Linux que wchar_t soit 16,32 ou autre, si plusieurs caracteres peuvent avoir des tailles differentes, t'es dans la mouise quand tu parses la chaine. Raison pour laquelle il est des APIs specifiques pour ca sur les 2 plateformes.
M'enfin, tu as peut-être une autre explication. Les développeurs Linux seraient 100 plus doués que les développeurs Windows ?
"Tiens tete" sur quoi ? l'OS lui-meme ? On a 100x plus de developpeurs que Linux+KDE+... reunis ? Permets moi d'en douter.
[^] # Re: Re:
Posté par pasBill pasGates . En réponse au journal [TROP LONG] Réflexions sur le libre. Évalué à 1.
Ben non, moi je croyais que tu parlais de parts de marche, pas de chiffres comptables. Qui te dit que les 2 chiffres sont lies chez Redhat ? Ils vendent du JBoss aussi par exemple.
Cherches openoffice, tu le trouveras en 64 bits. Ce n'est qu'un exemple.
Ceci dit, c'est récent. Mais Openoffice est aussi dispo sur Sparc depuis longtemps.
Sparc je sais, mais on parle de Linux ici.
De ce que j'en ai lu, c'est pas tres utilisable, notamment vis a vis de problemes avec Java sur plateforme 64bit.
Ouais, il manque flash.
Tout n'est pas dispo en 64 bit sur Linux. Seulement 99,9 %.
Ah oui ? T'as Quake 64bits ? Flash 64bits ? Acrobat Reader 64bits ? ...
La plupart des softs "grand public" ne sont pas dispo en 64bit sur Linux, et les softs "serveurs" le sont, tout comme sous Windows. Car Oracle, Mathematica, DB2, ... sont dispo en 64bits pour Windows.
Ben si tout nickel (au moins autant que Linux), MS-Office en 64 bits ne coûte rien à faire et devrait déjà être là !
Alors pourquoi il n'y a pas de MS-Office en 64 bits alors que depuis Windows NT il y a une version de Windows en 64 bits ?
Parce qu'OpenOffice 64bit sur Linux n'est pas encore utilisable(cf. problemes Java plus haut), bref, ils en sont au meme point.
Sauf qu'il y a tout dedans. Et pour PowerPPC, c'est 64 bits.
De plus, je n'ai pas souvenir que Windows a une version AMD64 ! J'ai seulement entendu parlé de versions béta et qu'il y a une version AMD64 pour Vista. C'est donc très récent.
C'est dispo au public depuis 2005(XP x64 et WS03 x64), et ca tournait depuis bien plus longtemps en interne.
Ce qui est du pipo. Windows est passé à ucs-2 avec Windows NT (ou 2000?). Et je dis bien ucs-2 (2^16 caractères) et non utf-8 (2^32 caractères). Windows 2000 utilise ucs-2 (j'en mettrais ma main au feu) et XP n'est qu'une évolution de Windows 2000.
Moi je te proposes d'aller lire http://blogs.msdn.com/michkap/archive/2005/05/11/416552.aspx pour comprendre que tu as tort.
J'espère que tu vois maintenant la logique évidente.
C'est comme ça pour LinuxThread et NPTL.
Ca ne date en fait que depuis 2002-2003, j'en parles car j'avais eu le probleme a l'epoque, du code qui fonctionnait parfaitement sur Solaris devait etre trifouille pour tourner sur Linux a cause de cette anerie. C'est une bonne chose qu'ils l'aient corrige, mais ca a pris du temps.
Ce qui est de la connerie. Le modèle "plusieurs processus" a ses avantages et idem pour le multi-threading.
Le gros problème du multi-threading est que le plantage d'un thread fait planter pour le processus. Et c'est la même chose sous Windows.
Tout a fait, mais la ou sur Unix il est habituel d'utiliser des processus simplement pour faire du traitement en parralelle, sous Windows c'est fait avec des threads d'habitude. Il y a bien entendu des cas ou tu utilises des processus separes, mais c'est assez rare.
Et il me semble bien que Windows fournit un truc style "job control" pour "mimer" Unix. Les "jobs" sont des processus et non des thread.
Un job c'est en fait bien plus qu'un processus, c'est un ensemble de processus, sur lesquels tu peux mettre plein de contraintes.
Rires. Tous les Unix commerciaux ont du multi-thread depuis longtemps. Il n'y a que Linux qui a mis du temps car Linux a débuté en 91 (il était embryonnaire). La version 2.0 de Linux avait le multi-thread. Linux 2.0 est sorti quasiment en même temps que Windows 95/NT (en fait Linux l'avait pour la version 1.2.13 mais pas pour 1.2.0). Donc Windows n'a pas le multi-threading depuis plus longtemps que Linux et assurément pas avant les Unix commerciaux.
J'ai melange Unix et Linux, Solaris a toujours eu un tres bon support des threads, ma cible ici c'est Linux qui m'en a fait baver a l'epoque car l'implementation des pthreads jusqu'a recemment etait vraiment a chier(va t'amuser a passer des signaux a des threads avec un Linux de l'epoque, tu comprendras ma douleur)
Sous Linux pour attendre la fin d'un thread on fait pthread_join(pthread_t, void **). Ce n'est pas la mer à boire, c'est lisible.
Tout a fait c'est lisible, le probleme c'est que c'est uniquement pour un thread, il te faut 10 APIs pour faire la meme chose: attendre sur un objet.
Donc on a des api qui exige spécifiquement du uint32...
Sous Linux on n'a pas ça. On a pid_t qui on une taille qui colle au hardware ou au besoin de la fonction. Mais on ne dit pas qu'un pid_t doit être un uint32. Un jour c'est un int16, un autre c'est un int32, on s'en fout. Il y a toujours des exceptions.
Attends tu me fais bien rire, je parles de uint32, qui clairement a ete cree pour representer un entier 32bits et rien d'autres, tout comme il y a un equivalent sous Linux,et tu parles de pid_t, quel rapport ? Jettes un oeil sur les APIs, tu verras plein d'APIs qui utilisent un size_t par exemple(qui varie selon la machine, ...)
difference entre WCHAR/CHAR et LPWSTR/LPCSTR
La difference est pourtant simple, LPWSTR/LPCSTR sont la pour representer une chaine de texte(un pointer sur un array de char quoi), WCHAR/CHAR c'est un caractere, et un pointeur sur WCHAR/CHAR, c'est un pointeur sur un caractere.
Alors meme si au final c'est la meme chose, conceptuellement ca ne l'est pas, tu utilises LPWSTR quand tu veux une chaine de caracteres, et tu utilises WCHAR* quand tu veux un pointeur sur un caractere.
Donc Windows ne support que ucs-2. Merci d'en faire la démonstration.
Va lire la page du dessus et tu comprendras que tu as tort, c'est pas a moi que tu vas apprendre quel character set Windows supporte :+)
Très bien, fais ce que tu dis et arrêtes de parler du logiciel libre.
Le truc est que j'ai passe des annees sur Linux, a une periode meme exclusivement sur Linux, je connais le systeme.
Toi ça fait depuis des années et tu ne sais toujours pas que Windows ne supporte que ucs-2 et pas UTF-8. UTF-8 est une façon de coder usc-4 (unicode) et a 2^32 valeurs. Ça ne rentre pas dans du 16 bits. wchar_t sous Linux est dans son implémentation actuelle du 32 bits. wchar_t n'est pas défini comme étant un int32, mais comme étant un wide caractère. Qu'il occupe 8, 16, 24 ou 32 bits, n'est pas une propriété que le développeur doit utiliser ni savoir (sauf pour débuggeur).
Avec la définition qu'a Windows de wchar_t, ça ne va pas être facile de passer à usc-4...
Ben moi je te propose de relire la doc, et te rendre compte que le fait que WCHAR est 16bit n'y change rien(cf. l'article que je t'ai donne plus haut). De meme que sous Linux que wchar_t soit 16,32 ou autre, si plusieurs caracteres peuvent avoir des tailles differentes, t'es dans la mouise quand tu parses la chaine. Raison pour laquelle il est des APIs specifiques pour ca sur les 2 plateformes.
M'enfin, tu as peut-être une autre explication. Les développeurs Linux seraient 100 plus doués que les développeurs Windows ?
"Tiens tete" sur quoi ? l'OS lui-meme ? On a 100x plus de developpeurs que Linux+KDE+... reunis ? Permets moi d'en douter.