Et comme beaucoup ici (même si on n'est peut-être pas la majorité mais on doit être un part significative) je ne dis pas que Linux est au top pour le desktop et va tout déchirer dans les semaines à venir. D'ailleurs des journaux avec "Linux est-il près pour le desktop ?", etc... on en voit des tonnes.
C'est donc que ce journal ne s'addresse pas a toi !
Là tu fais une erreur. Linux décolle. Mais il est parti à 0,01 %. S'il grippe à 33 % par ans (ce qui est fort respectable), il faut plus de 8 ans pour arriver à 0,1 %, et encore 8 ans pour arriver à 1 %, et encore 8 ans pour arriver à 10 %. Donc il faut 24 ans !
Il suffit de bases minimum en mathématique pour savoir ça.
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.
Pourquoi Windows peine à avoir des applis et des drivers 64 bit ?
Car les éditeurs de logiciel et de driver trainent la pate ? C'est seulement à cause de ça ? Probable que l'API windows sucks car si j'ai bonne mémoire, la version Alpha de Windows tourne en 32 bit pour les int... Alors que le int naturel d'Alpha (son mot machine) est en 64 bit sur les unix (idem pour Linux). C'est juste un exemple...
L'API n'a rien a voir, il est identique en 32 et 64bits(sauf pour tout ce qui est relatif a la compatibilite des softs 32bit sur 64bit evidemment). 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.
MS met son poids dans la balance pour changer ca(Exchange 2007 est 64bits uniquement par exemple) mais ca prend du temps.
Quand a la version Alpha de Windows, Win2000 beta etait 64bits sur Alpha, mais Compaq a decide d'arreter les frais, ce qui a coule l'Alpha en passant, et Win2000 pour Alpha n'est jamais sorti.
>L'argument est pertinant. Mais je parle d'offres aux entreprises (désolé, je ne l'ai pas signalé plus haut). Je ne parle pas d'un truc qui marche au fond d'une université. Je sais qu'il faut du temps entre l'innovation et son déployement.
Red Hat 7 (voire encore plus vieux) proposait au entreprise i386, Alpha, Mips (peut être plus encore). RHEL 4 propose i386, AMD/Intel 64, PPC32, PPC64 et peut-être encore d'autres.
Tout a fait, mais moi je parles techniquement, NT n'avait aucun probleme a passer a 64bits techniquement. Le probleme c'est le marche. Combien est-ce que Redhat fait de chiffre d'affaire sur PPC et autres ? Rien du tout, raison pour laquelle MS a abandonne NT pour Alpha, MIPS, PPC et Sparc(il y avait un port en cours), et raison pour laquelle NT pour Itanium existe uniquement en version serveur alors qu'il y avait un XP pour Itanium.
Exemple ?
Xbill ?
Qu'es-ce qui ne supporte pas UTF-8 dans Linux et qui est utilisé ?
Pas grand chose.
In what follows I investigate the state of UTF-8 support under Linux (especially Debian, the newest version, called ‘unstable’ or ‘Sid’) from a user point of view. ‘Support’ has several aspects:
Applications must be able to accept UTF-8 strings and files, and must be able to display them.
You should be able to perform keyboard input, in a variety of languages, easily.
Printing UTF-8 documents, web pages, e-mail messages, or whatever, should work.
Copying (by selection from the screen) and pasting from one application to another should work.
In all these areas, MS Windows performs pretty well. If you install the correct fonts, and Microsoft’s ‘Global IME’ components for input, your computer becomes, in effect, multilingual.
For Linux, the picture is mixed, but improving rapidly. Display of UTF-8 largely works (if you have the correct fonts); but really complicated (‘Complex Text Layout’) scripts like Devanāgarī do not seem to have good support (supported in Openoffice, but not in Mozilla)1.
Diantre, Microsoft, ton maitre, dit que Linux est une technologie de 30 ans et que Windows c'est tout beau tout moderne.
MS c'est trompé, ou c'était encore un gros FUD, ou Linux a rattrapé ses 30 ans de retard en moins de 10 ans ?
Rien a voir, car ils ne parlent pas de la meme chose, au niveau securite les 2 ont :
a) separation user / kernel
b) separation entre users
c) notion d'administrateur / user avec acces limite
Bref, architecturalement parlant, ils sont quasi-identiques la dessus. Les signaux, select et autres n'ont rien a voir la dedans, on parlait securite.
Par contre pour l'API bas niveau (tout ce qui est équivalent à glibc) c'est beurk. Les noms de fonction sont bizarres, il y a des HANDLE (void*) partout, des fonctions qui attendent un HINSTANCE (void *) fournit pas main() (diable, pourquoi la libc de Windows ne gère pas ça !), il y a des structures et des fonctions avec des membres/paramètres réservés, ou il faut la renseigner avec sizeof(struct), etc... Quel est la différence entre un HANDLE un HINSTANCE et HMODULE ?
J'ai rarement (jamais ?) vu API aussi moche. Et c'est diablement difficile à retenir.
Les MFCs sont moches, tout le reste par contre est tout a fait normal. HINSTANCE et HMODULE sont identiques(les 2 existent pour des raisons de compatibilite avec Windows 16bit), HANDLE par contre c'est generique pour tous types de handles(HINSTANCE/HMODULE c'est pour un handle de DLL), c'est l'utilite des typedefs: le compilo t'avertira si tu passes un HANDLE a une fonction qui veut un HINSTANCE.
L'API il t'es difficile a retenir parce que tu debutes, moi je m'y sens comme un poisson dans l'eau, tout comme je me trouvais quand je passais tout mon temps sous Linux
[^] # Re: Re:
Posté par pasBill pasGates . En réponse au journal [TROP LONG] Réflexions sur le libre. Évalué à 0.
C'est donc que ce journal ne s'addresse pas a toi !
Là tu fais une erreur. Linux décolle. Mais il est parti à 0,01 %. S'il grippe à 33 % par ans (ce qui est fort respectable), il faut plus de 8 ans pour arriver à 0,1 %, et encore 8 ans pour arriver à 1 %, et encore 8 ans pour arriver à 10 %. Donc il faut 24 ans !
Il suffit de bases minimum en mathématique pour savoir ça.
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.
Pourquoi Windows peine à avoir des applis et des drivers 64 bit ?
Car les éditeurs de logiciel et de driver trainent la pate ? C'est seulement à cause de ça ? Probable que l'API windows sucks car si j'ai bonne mémoire, la version Alpha de Windows tourne en 32 bit pour les int... Alors que le int naturel d'Alpha (son mot machine) est en 64 bit sur les unix (idem pour Linux). C'est juste un exemple...
L'API n'a rien a voir, il est identique en 32 et 64bits(sauf pour tout ce qui est relatif a la compatibilite des softs 32bit sur 64bit evidemment). 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.
MS met son poids dans la balance pour changer ca(Exchange 2007 est 64bits uniquement par exemple) mais ca prend du temps.
Quand a la version Alpha de Windows, Win2000 beta etait 64bits sur Alpha, mais Compaq a decide d'arreter les frais, ce qui a coule l'Alpha en passant, et Win2000 pour Alpha n'est jamais sorti.
>L'argument est pertinant. Mais je parle d'offres aux entreprises (désolé, je ne l'ai pas signalé plus haut). Je ne parle pas d'un truc qui marche au fond d'une université. Je sais qu'il faut du temps entre l'innovation et son déployement.
Red Hat 7 (voire encore plus vieux) proposait au entreprise i386, Alpha, Mips (peut être plus encore). RHEL 4 propose i386, AMD/Intel 64, PPC32, PPC64 et peut-être encore d'autres.
Tout a fait, mais moi je parles techniquement, NT n'avait aucun probleme a passer a 64bits techniquement. Le probleme c'est le marche. Combien est-ce que Redhat fait de chiffre d'affaire sur PPC et autres ? Rien du tout, raison pour laquelle MS a abandonne NT pour Alpha, MIPS, PPC et Sparc(il y avait un port en cours), et raison pour laquelle NT pour Itanium existe uniquement en version serveur alors qu'il y avait un XP pour Itanium.
Exemple ?
Xbill ?
Qu'es-ce qui ne supporte pas UTF-8 dans Linux et qui est utilisé ?
Pas grand chose.
Ben je te propose d'aller visiter http://www.jw-stumpel.nl/input.html
In what follows I investigate the state of UTF-8 support under Linux (especially Debian, the newest version, called ‘unstable’ or ‘Sid’) from a user point of view. ‘Support’ has several aspects:
Applications must be able to accept UTF-8 strings and files, and must be able to display them.
You should be able to perform keyboard input, in a variety of languages, easily.
Printing UTF-8 documents, web pages, e-mail messages, or whatever, should work.
Copying (by selection from the screen) and pasting from one application to another should work.
In all these areas, MS Windows performs pretty well. If you install the correct fonts, and Microsoft’s ‘Global IME’ components for input, your computer becomes, in effect, multilingual.
For Linux, the picture is mixed, but improving rapidly. Display of UTF-8 largely works (if you have the correct fonts); but really complicated (‘Complex Text Layout’) scripts like Devanāgarī do not seem to have good support (supported in Openoffice, but not in Mozilla)1.
Diantre, Microsoft, ton maitre, dit que Linux est une technologie de 30 ans et que Windows c'est tout beau tout moderne.
MS c'est trompé, ou c'était encore un gros FUD, ou Linux a rattrapé ses 30 ans de retard en moins de 10 ans ?
Rien a voir, car ils ne parlent pas de la meme chose, au niveau securite les 2 ont :
a) separation user / kernel
b) separation entre users
c) notion d'administrateur / user avec acces limite
Bref, architecturalement parlant, ils sont quasi-identiques la dessus. Les signaux, select et autres n'ont rien a voir la dedans, on parlait securite.
Par contre pour l'API bas niveau (tout ce qui est équivalent à glibc) c'est beurk. Les noms de fonction sont bizarres, il y a des HANDLE (void*) partout, des fonctions qui attendent un HINSTANCE (void *) fournit pas main() (diable, pourquoi la libc de Windows ne gère pas ça !), il y a des structures et des fonctions avec des membres/paramètres réservés, ou il faut la renseigner avec sizeof(struct), etc... Quel est la différence entre un HANDLE un HINSTANCE et HMODULE ?
J'ai rarement (jamais ?) vu API aussi moche. Et c'est diablement difficile à retenir.
Les MFCs sont moches, tout le reste par contre est tout a fait normal. HINSTANCE et HMODULE sont identiques(les 2 existent pour des raisons de compatibilite avec Windows 16bit), HANDLE par contre c'est generique pour tous types de handles(HINSTANCE/HMODULE c'est pour un handle de DLL), c'est l'utilite des typedefs: le compilo t'avertira si tu passes un HANDLE a une fonction qui veut un HINSTANCE.
L'API il t'es difficile a retenir parce que tu debutes, moi je m'y sens comme un poisson dans l'eau, tout comme je me trouvais quand je passais tout mon temps sous Linux