Beaves, ik bedoel meer dat de linux ontwikkelaars een grote groep gratis test-engineers tot hun beschikking hebben, met een groot palet aan verschillende hardware, dus test-setups.
MS moet dat allemaal zelf doen, intern, met eigen mankracht tegen eigen kosten.
Als je niet weet hoe het bij MS toegaat, zeg dan niets. Je blaat over Linux, wat off topic is, en maakt een vergelijking die nergens op slaat. MS heeft een zeer groot testlab met meer hardware configuraties dan menige linux user. Elke nacht draaien automatic builds die de dag daarop 24/7 getest worden door een groot aantal testers, die dan bugs rapporteren die daarna gefixt worden en die fixes duiken daarna weer in een build op etc. Bij Linux is het maar afwachten OF iemand een 32proc Unisys doos overheeft om het te testen. Bij MS staat zo'n ding in het testlab. Waarom? Omdat Unisys zelf dat ding komt brengen. IBM zat ook met 120 engineers te testen aan windows2000 op IBM hardware op de MS campus.
Voor de linux wereld zijn er genoeg fanaten die beta tester willen spelen, maar zoals gezegd staan bedrijven niet te popelen om daarmee tijd te verspillen.
En terecht. de 'fanaten' zijn er wellicht wel, maar 200.000 testers met een amd athlon op 1GHz heb je niet veel aan, als je AMD64bit compiles wil testen of bv de EPIC support van GCC. (Wat Linux ermee te maken heeft met het hele verhaal begrijp ik overigens niet, je zult Open Source wel met Linux verwarren. Vaak gemaakte domme fout)
Ik ben bang voor AMD dat ook hier de acceptatie niet zo snel zal zijn als men nu denkt, bedrijven kijken liever de kat uit de boom en kiezen voor de geijkte oplossing (intel in veel gevallen, voor 64-bit misschien andere oplossingen, sun hp oid).
We praten over een COMPILER, niet over systemen of operating systems!. Een nieuwe proc met een nieuwe instructieset introduceren kost een lange tijd. Als AMD verwacht dat ze binnen 6 maanden een grote hap van de 'big-iron' servers in handen hebben, zijn ze aan het dagdromen. En ja, het gaat over de big-iron bakken: dus bakken met meer dan 4GB mem, met meer dan 2 procs. Die koop je niet elke dag.
En linux moet wel redelijk werken vanaf het begin, maar er zal een 'steep learning curve' zijn, omdat het open source is, en er gewoon duidelijk bijstaat dat het een alfa versie betreft. Toegegeven, pas als het stabiel (verklaard) is, zullen bedrijven ervoor kunnen gaan, maar voor die tijd zal linux met amd-64 support allang ruim voorhanden zijn op het web, dus in het publieke zicht.
Nou en! Ik weet niet of je meekijkt bij de Linux development, maar de verschillende processortakken lopen ALTIJD achter op de x86-32 tak. GCC support die klinkt als een klok zal zeker een tijd op zich laten wachten, x86-32 is al niet al te best (de output is niet dermate goed geoptimized). Support voor bv EPIC is ronduit belabberd (ze optimaliseren niet voor die instructieset).
Het boeit de gemiddelde gebruiker van een 64bit processor geen reet of iets in alpha stadium is of beta. Dat gebruik je nl. niet op zo'n dure bak. Daar gebruik je productiespul op wat 24/7 in de lucht blijft. Immers, daarvoor koop je een 64bit doos met veel memory en veel processoren.
The Inquirer schijnt een aantal bewijzen gevonden te hebben dat Microsoft druk bezig is met het inbouwen van ondersteuning voor waarschijnlijk de x86-64 Hammer in zowel de Visual C++ compiler als Windows.NET. Ze hebben namelijk deze foutmelding van Visual C++ gevonden in MSDN . Uit de foutmelding valt op te maken dat zowel de frontend als de backend compiler de volgende processoren ondersteund: x86, IA64, en AMD64. Waar zou AMD64 voor staan? Het kan bijna niks anders zijn dan de x86-64 architectuur van de Hammer. Een andere pagina op MSDN beschrijft een C++ structure, STACKFRAME, en ook hier staat er een verwijzing naar zowel x86, IA64 en AMD64. Op de MSDN is nog meer bewijs te vinden:
)
Software
