pasBill pasGates a écrit 16062 commentaires

Hahaha, et c'est quoi les problemes ? Parce que ton wikipedia il ne cite aucun probleme reel.

Qu'il n'y a que des drivers 64bits ? Idem chez Linux
Qu'un soft 64bit ne charge pas de plugin 32bit ? Idem chez Linux
Que la version 64bit n'a pas l'emulation 16bit ? Linux ne l'a jamais eu
Le command prompt n'est pas plein ecran ? Oh mon dieu, quel desastre !
Certains composants sont encore 32bits ? Oui et ? T'as besoin d'un player multimedia 64bit ? 95% de l'OS est 64bit

Bref, absolument _aucun_ probleme reel

Quant à Windows 7, s'il est le premier Windows 64 bit utilisable, il a encore plein de 32 bit ! C'est un retard énorme par rapport aux distributions Linux.

Plein de 32bits ? Genre quoi ? Allez, donnes des details !

Quel gag

a) Windows XP x64 est totalement supporte, on sort les patchs pour comme pour tout le reste et il tourne sans aucun probleme
b) Il y a aussi eu Windows 2003 (meme base que XP x64) 64bit et Vista 64bit entre temps

Faudrait penser a te renseigner un peu mieux hein...

Sauf que ce sont des conneries ce qu'il dit. Sa boite a fait en sorte de part son pouvoir de faire disparaitre les netbooks a base de arm car curieusement il n'existe aucune version de windows tournant dessus

Ca doit etre ca, on envoie de tueurs a gage pour menacer les constructeurs.

Ou alors les constructeurs voient que Windows se vend bien plus que Linux, que Windows n'est pas sur ARM mais sur x86/amd64 et ils changent leur netbooks pour x86/amd64

Mais bon, toi et la logique ca fait longtemps qu'on s'est rendu compte que c'etait pas ton fort.

Dire qu'il n'y a pas de demande pour les achitectures arm, par exemple, cela montre bien a quel point Microsoft est a cote de la plaque...

Microsoft a dit ca ? J'etais pas au courant.

Elle n'etait pas sensee etre rare au debut, c'est tout le truc.

C'etait sense etre LE cpu pour les gros serveurs, avec Intel et HP derriere, alors MS qui voulait bouffer le monde de l'entreprise s'est mis dessus.

Et ca a ete une grosse erreur.

Oh c'est que tu lis tres mal alors, parce que c'en est rempli, detaillant le fonctionnement de Windows pour ceux qui parlent de ceux qu'ils ne connaissent pas, et detaillant les similarites/differences entre Linux/Windows ainsi que sur des sujets absolument sans rapport (trolls C/C++/Java/C#/programmation en general...)

Il est sacrément fort ton petit doit parce que
- sur tablette, il n'y a rien de fait, mais quand je dis rien c'est rien (peut être qu'ils sont prêt mais de là à en vendre il reste quelques malettes de billets à imprimé pour le plan com, les contrats etc...)
- sur mobile, ils vont pas avoir affaire à une série de boites qui avaient créée leur distribution et qui sont contente de ne plus avoir à le faire comme pour les netbooks, là ils vont avoir affaire à google c'est à dire un plan com, des contrats déjà passé et politique globale bien définie et (en théorie) cohérente. Sans parler des deux concurents Apple et Blackberry. Bref c'est pas la même blague. Et puis j'ai l'impression que ça amuse beaucoup le consommateur d'avoir des dizaines de milliers « appli » à la con qui font prout quand on appuie sur le gros bouton ce qui, d'après ce que j'ai compris n'est pas la politique de MS.

Ben en fait tu viens d'expliquer mon opinion :+)
MS a bien plus de chances ce bouffer le marcher tablet justement parce que rien n'est fait et qu'ils ont l'avantage de pouvoir debarquer dessus avec des dizaines de milliers d'applications _utiles_ deja ecrites
Pour le mobile c'est justement bcp plus difficile.

Pour ce qui est des par de marché. Il faudrais un temps considérable pour qu'une architecture arrive à 20% des parts de marchés (rappellons que le jeu d'instructions x86 CISC est considéré comme inéfficent comparé au RISC depuis plusieurs dizaines d'années), mais il suffit de voir comment ça c'est passé avec les netbook et les netops d'une manière générale pour comprendre que sur un marché donné il suffit de très peu de temps pour se faire prendre de cours et affronter un milieu concurentiel.

Ben justement, c'est pour ca que MS prend son temps : si t'arrives a 4-5%, MS a le temps de reagir, et les concurrents n'ont pas encore le temps d'etre bien arrimes.

Comme tu le dis, les netbooks en sont un gros exemple: ca a commence avec quasiment que du Linux, MS a vu que ca prenait, ils ont adapte leurs systemes, depuis Linux a disparu et ce n'est quasiment plus que du Windows...

Les prochains sont les tablets et telephones, le 1er me semble plus facile a bouffer pour MS que le 2eme, mais ce n'est qu'une supputation basee sur mon petit doigt de la main gauche.

Au debut on etait peut-etre pas le plus gros, je parles plutot des 2-3 dernieres annees. Remarques que je ne serais pas forcement surpris si a l'epoque deja on en avait plus que le CEA aussi, 4000 machines c'est pas grand-chose compare au nombre de machines que la division Windows a au total, il y quelque annees j'avais perso un quad-cpu Itanium de test d'HP dans mon bureau (avant de le bouger dans le labo vu le bruit enorme qu'il faisait, par contre c'etait un bon moyen de chauffer le bureau)

Ben suffit de regarder amd64 hein, visiblement ca n'a pas vraiment ete un probleme... MS typiquement ne va pas attendre qu'une plateforme ait genre 20 ou 30% du marche avant de se poser dessus, ils ont du monde qui est en contact avec tous les frabriquants de materiel, il savent a peu pres ou le marche va et reagissent en consequence.

Tres peu (parait que la societe ayant le plus grand nombre de machines Itanium est... Microsoft, pour nos passes de test, un comble), resultat la prochaine version de Windows ne supportera plus Itanium

Tu sais, niveau jugements technologiques et expertise, l'experience a vite montre qu'un de nous deux est absolument incompetent pour juger quoi que ce soit de technique, et l'autre a peu pres competent, donc bon, ton point de vue il a a peu pres la meme valeur que ma chaussette droite, et un peu moins que ma chaussette gauche.

Tout a fait, ARM est en croissance. Si il devient assez interessant pour MS, t'imagines bien qu'ils porteront le systeme dessus, tout comme ils ont fait avec amd64 et Itanium.

La question, c'est combien d'architectures est capable de supporter MS. Et visiblement, c'est un nombre ridiculement faible (3).

Les considérations techniques ou philosophiques n'ont pas énormément d'intérêt ici. MS pourrait avoir la capacité de compiler Windows sur des centaines ou même des milliers d'architectures, on s'en fout. Elle n'est capable d'en vendre que trois et c'est ça qui est important. Le reste, c'est juste de la quadrisection capillaire.

C'est quoi "capable" ?
Le faire de maniere rentable ? C'est certainement plus que 3 si on fait le meme effort de test que la communaute Linux sur ces architectures: c'est a dire quasiment aucun.
Le faire de maniere a avoir un impact sur le chiffre d'affaire de MS ? Il n'y a peut-etre que ARM qui pourrait avoir un effet.

3 gus x N architectures, c'est différent. Ne pas sous-estimer l'importance de la longue traîne.

Vraiment ? Ils ont eu quoi comme impact ces gens sous Linux sur Sparc/Alpha/MIPS/PPC ces dernieres annees ? Rien
C'est pas par hasard que Redhat lui-meme a abandonne le support de quasiment toutes ces plateformes...

Alors pourquoi les appeler gus ?

J'ai tendance a utiliser ce mot pour parler de gens isoles, il n'y a rien de negatif a ce mot.

Une question de choix ou une question de bon sens ?

C'est comme si je te disais que j'avais fait le choix de ne pas insulter Chabal quand je l'ai croisé. C'était plus rentable pour moi.

Ben quand tu vois MS et ses benefices, c'est certainement pas une obligation, c'est un choix: ajouter une plateforme supportee pour faire 3 millions de $ en plus, soit 0.005% de chiffre d'affaire en plus n'a aucun interet.

Eh j'ai une excuse hein, c'est 3h du matin ici :+)

Ah oui c'est vrai j'oubliais Windows mobile 7 c'est la version pour telephone de windows 7... Au passage je voudrais vous feliciter pour cette magnifique reussite technologique!

a) Tu m'expliqueras le rapport
b) C'est une reussite technologique, le fait que tu ne saches pas evaluer un OS (ou que tu sois de mauvaise foi, a mon avis c'est les 2) ne prejuge pas de la qualite de l'OS

Si bien sûr, ça a à voir avec ça. Si c'était facile, ça serait fait, même pour trois gus. Ce n'est certes pas impossible, mais ce n'est pas trivial.

C'est facile au niveau du code, simplement ca coute au niveau du test, packaging et formation du support, tout en ne ramenant rien a l'echelle de MS.

Avec du logiciel libre, on a un portage pour les 3 gus de MIPS, un pour les 3 gus avec de l'Alpha, un pour les 3 gus en ARM, etc.

Absolument, pour un systeme utilise par 3 gus, il est clair et net que Linux est plus approprie.

Le truc est pas que ces gus sont pas serieux, mais faut revenir un peu sur terre, MS est une societe commerciale, une marche ou ils ne peuvent pas vendre au moins un million de licences, ca ne vaut rien pour eux.
C'est une question de choix c'est tout, il y a des marches que MS choisit de ne pas poursuivre pour raisons commerciales, ca veut pas dire que les gens de ce marche sont inutiles, simplement qu'il n'y en a pas beaucoup.

Ah ben merde alors, je me suis fait eu comme on dit :+) A force de baigner dans l'anglais je le vois meme quand c'est du francais...

Je monitores
Tu monitores
Il monitore
Nous monitorons
Vous monitorez
Ils monitorent

Ah oui, ca a l'air d'etre un verbe francais

OUHAOU vous avez reussi a faire plus que 2 archis (qui sont tres similaire x86 et xx64) c'est impressionnant dis donc. Vous etes vraiment tres tres fort. Bon Ok lorsque l'on voir le nombre d'architecture supporte par Linux/xBSD vous etes des nains...

Juste pour rire:

http://en.wikipedia.org/wiki/List_of_Linux_supported_archite(...)

Une vingtaine de famille (tu me permet d'omettre les sous categories je ne veux pas trop vous enfoncer)

Oh mais ca qu'est ce que je m'en fous tu sais...

Windows a ete prouve portable, c'est un fait etabli (MIPS, i860, PPC, x86, amd64, IA64, Alpha)

Ensuite qu'on evite de sortir l'OS sur une archi donnee pour 3 gugus sur leur PPC ou autre, tout le monde sauf toi sait que cela n'a rien a voir avec la difficulte technique de le faire et tout a voir avec le fait que cela ne rapporterait quasiment rien.

Ton deuxieme point je ne vais pas me fatiguer a y repondre car tu n'as soit pas compris le sujet de la nouvelle soit tu ne sais pas lire et vu le nombre de hors sujet que tu fais l'une ou l'autre des possibilite sont valables.

Hors sujet ? Ben soit c'est hors-sujet et ton post l'etait aussi, soit il ne l'est pas, vu qu'il est directement lie a ton post...

Windows suporte a peine 2 architecture et uniquement pour les pc.

x86, amd64, ia64

1+1+1 = 3 mon cher Albert_

Naturellement le materiel present dans un telephone ou dans un super ordi est "tres legerement" different de ce que l'on peut trouver dans un pc, dernier point essaye donc d'utiliser un matos un peu ancien avec windows cela peut etre assez amusant (je connais des boites qui ont encore des pc sous windows 98 a cause de cela...), je sens venir le "ah mais linux avec le nouveau matos..." tout d'abord cela n'est presque plus vrai et de plus la proportion de nouveau matos par rapport a l'ancien fait que cet argument n'est plus du tout valable dans l'optique du nombre de matos utilisable a l'installation (c'est a dire sans rajout de drivers fait par une boite externe au projet).

Hahaha sans rajout de drivers fait par une boite externe au projet , elle est marrante celle-la, elle sort d'ou cette regle ?

On regarde la realite, dans le monde reel, 90% des gens recoivent l'OS avec le PC, partant de la, que les drivers viennent avec le projet ou pas on s'en fout un peu hein.
Faut pas demander a MS de suivre un mode absolument inutile au vu du marche, ca n'a aucun sens.

Tu mélanges deux situations différentes. Ton soft gère 32768 éléments ou MAX_INT éléments ? Ce n’est pas la même chose.
Cas où ton soft gère 32768 éléments : ben tu fais pas MAX_INT, mais #define MAXELEMS
Cas où ton soft gère MAX_INT : tu aimerais bien que ton algo scale avec les capacités de ta machine, donc il me semble normal que MAX_INT change selon l’architecture, et tant pis si ça plante pour une machine pas assez puissante.

Sans blague ? Merci je connais, mais moi je regardes pas la theorie de ce que t'es sense faire et que 1% des gens font, mais ce que l'enorme majorite des gens font, parce qu'au final si le langage est tellement alambique que personne ne sait, c'est comme si le langage ne le faisait pas.

La realite est que l'enorme majorite des developpeurs ne sait meme pas qu'un int peut avoir une taille differente d'un systeme a l'autre. Cette realite fait que tous ces softs qu'ils ont ecrits ne sont probablement pas multiplateforme.

La realite est qu'un soft ecrit par un neuneu en Java/Python/autre lui par contre il a toutes les chances de tourner sur plein de plateformes differentes.

Mais il est incapable de profiter de la puissance de ce nouvel OS flambant neuf, et au final, si tu veux en profiter, tu es obligé de recoder ton programme en changeant des int par des long.

Tout a fait, maintenant ce que Java fera c'est d'ajouter a sa spec de nouvelles methodes supportant une taille d'entier superieure pour les tableaux et autres, et ca resoudra le probleme, sans rien remettre en cause.

Ton soft gere des elements(peu importe quoi), et tu utilises un ID pour les differencier, qui est un int.

Combien d'elements maximum peut-il gerer ? MAX_INT ...

Quel est le moyen le plus rapide d'acceder a ces elements ? Une table contenant ces elements, une table de taille ... MAX_INT

--> malloc(MAX_INT) ou MAX_INT*(ce que tu veux)

C'est peut-etre pas optimal, mais c'est pas stupide non plus hein quand la taille au final est bien plus petite que la RAM dispo sur les machines standards.

Ca a tout son sens quand ton soft gere 32768 (ou 65536 avec MAX_UINT) elements, le probleme etant quand tu 4 ans plus tard un nouveau systeme sort, et il a des int sur 32bits, et boum, tu te retrouves avec ta table qui fait 2 milliards d'entrees.

Et devines quoi, aujourd'hui tout le monde a un systeme avec CPU 64bits, et des int 32bits, d'ici quelque annees tout le monde aura 128Go de RAM en standard sur son iPad/desktop/frigo et on verra regulierement des tables de 2^32 elements, tu sais, MAX_UINT, ou si ce n'est l'allocation elle-meme, une reservation d'espace d'addressage continu de cette taille a remplir au fur et a mesure des besoins(ca se fait probablement deja aujourd'hui dans des bases de donnees).

Et dans quelque annees, un nouvel OS(ou ancien et modernise) bien joli va sortir tout 64bit et tout, avec des int de 64bit vu que tout le monde a 128Go de RAM et qu'un int 32bit c'est devenu ringard, et boum, la meme merde.

Quand t'as des types de taille statique, ce genre de merde n'arrive pas, si tu passes ton soft sur le nouvel OS, ton code il marche, point.

C'est bien, tu viens de nous dire nois sur blanc que tu avais du code specifique a la machine en C, qui donc n'etait pas portable.

Merci de confirmer ce que je dis depuis le debut.

La prochaine fois, reflechis avant d'ecrire.

Ce que pBpG dit, c’est que sur une machine où l’entier est à 16 bits mais où l’adressage est sur 20 bits — à l’aide de mécanismes comme la segmentation —, malloc(INT_MAX), c’est 16 fois moins (en fait 32, il a oublié que INT_MAX était signé) que l’espace adressable, donc que ça plantera pas — au contraire de nos machines où taille de l’entier = capacités d’adressage.
C’est tout.
Le seul exemple qu’il a donné, c’est « sur 16 bits on peut utiliser malloc(INT_MAX) pour allouer 64ko, et ça plante sur 32 bits », ce que j’appelle difficilement un exemple probant.

Vraiment ? Pourtant c'est un exemple reel, qui demontre que non, C n'est pas un langage multi-plateforme du fait de la non definition de ses types de base parmis d'autres faiblesses au niveau support multiplateformes.

Tu iras des lors expliquer a ce code qu'il n'a jamais existe, et qu'il n'avait pas non plus lieu d'exister.

J'ai du bol, je serais plus la en 2015