pasBill pasGates a écrit 16060 commentaires

Aujourd'hui encore, 7 ans après leur sortie donc, j'entends toujours des gens expliquer que, à moins d'avoir plus de 4 Gio de mémoire, il vaut mieux utiliser Windows en 32 bits parce qu'il y a des problèmes en 64 bits.

On va dire que tes sources pour Windows sont douteuses pour le moins vu la quantite de choses fausses que tu as dites dessus ces dernieres annees hein. Plein de gens utilisaient XP 64bits, mais evidemment si tu es une grand-mere et que tu t'attends a ce que ton imprimante d'il y a 6 ans fonctionne, ca va pas aller.

Donc pour ce qui est de la prise en charge d'architectures même pas exotiques, vous repasserez. Et je me moque que ce soit de la faute des méchants fabricants qui ne codent pas leurs pilotes en 64 bits comme il faut, là je prends le point de vue d'un utilisateur, si des pilotes viennent avec Windows pour lui ça fait partie de Windows, peu importe que ce ne soit pas MS qui les ait codés et testés.

Le pilote il vient pas avec Windows, il vient (ou ne vient pas, ce qui etait le probleme) avec le PC, pas vraiment la meme chose. Si il venait avec Windows, ben il y aurait pas de probleme, vu que le driver serait la justement...

Ah ca, Microsoft et sa maniere de nommer les produits, c'est pas moi qui vait dire qu'ils sont forts pour ca... Genre Windows Phone 7, si ca ne tenait qu'a moi le responsable de ce nom serait a Guantanamo Bay

La pile IP de Linux sur x86/x64/arm elle est tres bien testee, il y a une armee de gens et societes qui le font.

sur les archis exotiques par contre, beaucoup moins. Il y a qui qui fait ces tests automatiques pour 68k ? Alpha ? etc... Personne

Les 2, t'es au courant que c'est un document qui est passe de l'un a l'autre ? T'es au courant qu'un soft peut supporter moins de features du format qu'un autre ? Genre KOffice <-> OpenOffice

Je t'ai dit que les suites Office sont compatibles entre n-1 <-> n , ce qui est le cas, Office 2003 <-> Office 2007 <-> Office 2010
Le cas MacOffice <-> Office Windows c'est similaire a KOffice <-> OpenOffice (en moins prononce quand meme), les features supportees ne sont pas les memes(du moins ne l'etaient pas a l'epoque, aujourd'hui j'en sais rien)

Une fonctionnalite qui manque a KOffice par rapport a OpenOffice c'est un bug ? La reponse est la meme

Tu crois ? Un XP x64 de base, tu prends l'equivalent Debian PPC en enlevant les paquets non presents dans XP, je te garantis qu'un des deux a ete teste 100 fois plus que l'autre, et c'est pas Debian.

Parce que le XP x64, il a SMB, la partie group policy, explorer, media player, IE, etc... qui ont ete testes de fond en comble.

KDE, Firefox, ... sous Debian PPC ? Ils ont ete utilise par quoi ? 3000 gars grand maximum avant la sortie de Debian PPC stable on va dire pour etre gentils, et j'ai bien dit "utilise", pas "teste", et cette utilisation sur un echantillon de 3000 personnes, elle ne represente pas grand chose compare au code des softs en question.

On y a pense mais on avait peur d'etre poursuivi par nous meme pour piratage

Je t'invites plutot a te renseigner sur les causes de cela plutot que t'engouffrer dans un sujet auquel tu ne connais visiblement pas grand-chose... (je t'aide, ils'agit de plugins externes et d'une representation "backup" a travers une image au cas ou le plugin ne serait pas la, ce qui est le cas sur Mac ou Office est litterallement un produit different de Office pour Windows avec des features differentes, resultat tout fonctionne comme il est sense fonctionner)

Certainement oui, l'OS etait tres stable, je te mets bien au defi de prouver le contraire.

Sachant que les suites Office sont toutes largement compatible entre elles, certainement bien plus que les releases d'OOo entre elles, je me permets de rire un grand coup.

Pourriez-tu m'aidé svp ?* » Et qui passe ensuite deux semaines à travailler sans accès aux machines pour réussir à faire tourner son programme sur une architecture pas encore (ou quasiment) dans le commerce, c'est se « foutre » de la gueule des utilisateurs.

J'ai dit quelque part que les developpeurs se foutaient de la gueule des utilisateurs ?

Non, j'ai dit que les developpeurs se fichaient des architectures exotiques, ils ne s'en occupent que, comme tu l'as dit, lorsque un utilisateur final vient rapporter un probleme. Le reste du temps ils ne s'en preoccupent pas et n'y touchent pas.

Ce qui revient au probleme initial : la personne trouvant les problemes, c'est l'utilisateur final, pas l'equipe de developpement/test avant la sortie, et c'est la que le bat blesse.

Si tu avais vu la demo donnee au CES, elle etait justement de Office sur l'architecture ARM.

Et a la difference de OOo sur les debian exotiques, Office sur ARM sera teste de fond en comble, tu auras une garantie bien plus forte qu'il ne va pas t'exploser dans les doigts en mettant du texte en gras+italique que OOo sur PPC ou autre, suffit de regarder les architectures dispo sur openoffice.org pour se rendre compte des architectures qui sont prises en compte et lesquelles sont en gros ignorees.

Les distribs genre Redhat en x86/x64 elles sont testees bien a fond, peut-etre pas au meme niveau que nous mais proche.

Les autres, elles me font rire niveau qualite.

C'est pas grand-chose si on compte que les architectures avec un minimum de garanties niveau qualite du code.

Hahaha, et tu crois que "utiliser" c'est du test ?

Tu veux venir voir chez nous les labos qui ont des milliers de machines faisant tourner des tests ecrits pour couvrir quasiment tous les recoins du systeme 24h/24 ?
Pour te donner une idee, rien que TCP/IP cela prenait des jours, en etant 100% automatise sur plusieurs machines avec des drivers specifiques de tests ajoutes pour simuler des conditions reseau differentes(des dizaines de milliers de cas specifiques en tout), un reseau complet de plusieurs machines generant un traffic enorme de different types entre elles non-stop afin de pousser la stack dans ses derniers retranchements, ...

Va me comparer ca a 30 gars sur une architecture exotique qui probablement n'iront jamais mettre en marche les selective acks, qui pour la plupart ne se retrouveront jamais sur un link WAN, qui n'auront quasiment jamais un timeout de leur timer keepalive, etc...

"Utiliser" cest de la rigolade, ca permet de savoir que KDE se lance et que Mozilla arrive a loader une page web, ca va pas beaucoup plus loin sauf si t'as un nombre gigantesque de beta-testeurs qui par leur nombre et usage different couvre la majorite du systeme, et ca clairement c'est pas le cas sur les architectures exotiques, ni meme sur les archis mainstream de linux. Linux est solide grace aux societes qui batissent des tests pour, mais ces tests ils sont effectues sur les architectures principales, pas sur les archis exotiques.

J'exageres enormement le cote negatif ? Attends he, c'est pas moi qui plus haut dit que VLC dans Debian PPC stable, un soft pourtant largement repandu, sur une architecture qui n'est pas la moins repandue, a une fonction de base qui ne fonctionne pas.

C'est la realite tout simplement : le systeme il boot, les trucs vraiment bateau fonctionnent (KDE se lance, Mozilla se lance, etc...) mais ensuite c'est dur a dire, t'as aucune garantie, car il n'y a absolument aucune phase de test faite pour ces plateformes.

C'est a ca que ca sert la phase de test quand meme hein : donner un minimum de garanties quand a la qualite du soft, et sur ces plateformes cette garantie elle ne'st clairement pas la, la phase de test c'est l'utilisateur final qui se la tape.

Ben ta description est EXACTEMENT ce dont je parles.

Les developpeurs n'ont pas les systemes sous la main et s'en foutent pas mal vu le cote exotique, et les seules personnes a tester la chose sont les rares utilisateurs finaux dudit systeme.

Resultat, c'est une situation de merde pour l'utilisateur final, les updates sont synchronisees avec les autres plateformes c'est a dire frequentes, et il ne sait jamais ce qui va marcher et ce qui ne va pas marcher, car personne n'a pris la peine de tester les modifications sur son systeme avant la release.

Quel humour quand meme !

Alors que nous non, on a porte Windows en 2h chrono entre l'arrivee du systeme et le boot de Windows, chose incroyable c'est moins de temps que la compilation du systeme, on est baleze !

Reste qu'attaquer Linux sur le portage c'est petit.. ça a été un des premiers OS à adopter l'architecture AMD64, là où Microsoft a pris son temps (et l'ensemble des éditeurs propriétaires encore plus, y'a qu'à voir Flash).

Pris son temps ? Ca depend de comment tu le vois.

Le temps entre l'arrivee d'un vrai CPU x64 chez MS et le boot de Windows dessus ? 2 heures

Ensuite l'arrivee chez le grand public c'est autre chose, mais de nouveau, ca ca ne depend pas simplement du cote technique.

Qu'on se comprenne hein, je dis pas que Debian fait zero tests, le temps de maturation des packages est la pour ca, mais justement, ce temps de maturation ne vaut rien pour les plateformes sous-utilisees.

Absolument oui, vu que Debian ne s'occupe que de tester le packaging, pas le soft lui-meme, faut bien comprendre ce que 'stable' veut dire chez Debian hein, ca veut pas dire que le soft lui-meme est stable et bug-free, mais que le packaging est bon.

Fais la difference entre "ca compile" et "c'est supporte et teste completement" , c'est vraiment pas du tout la meme chose.

L'enorme majorite des testeurs et developpeurs n'est ni sous PPC, ni sous Sparc, ni sous XYZ mais sous x86/x64/ARM , et en gros personne ne fait de vraie passe de test sur ces autres plateformes, ca se resume a "j'installes, les trucs que je fais marchent, le reste j'en sais rien"

Ces autres plateformes, c'est du petit bonheur la chance, faut etre un peu fou pour poser dessus quelque chose de sensible.

J'incluais les serveurs aussi, c'est quand meme la ou la presence de Linux est la plus grosse (avec ARM pour ce qui est embedded)

C'est bien vrai ca, et c'est tout a l'honneur de Linux, le probleme c'est quand on regarde le nombre de plateformes qui ont un support digne de ce nom pour l'OS entier(=pas que le kernel) et les softs principaux par dessus, la subitement la liste retrecit enormement, suffit de voir le support que les distribs ont pour Sparc et PPC qui sont pourtant parmis les plus importants des CPUs de la liste pour comprendre.

Ben c'est l'equivalent proprietaire d'OpenGraphane