mboost-dp1
unknown
er det her ikke bare endnu et af deres mange tricks for at lokke flere penge ud af folk? eller skal der seriøst så mange kræfter til?
Jeg håber blot at der til den tid vil være ordentlig driver understøttelse.
Jeg fik min WinX64 for nogle måneder siden af MS, og installere den cirka 2 gange om måneden, for at se om driverunderstøttelsen er blevet bedre. Det går fremad, men LAAANGSOMT...
Jeg fik min WinX64 for nogle måneder siden af MS, og installere den cirka 2 gange om måneden, for at se om driverunderstøttelsen er blevet bedre. Det går fremad, men LAAANGSOMT...
Det må man da kalde, at presse penge ud af folk.
Eller også bruger de programmer bare utrolig mange hestekræfter?
Eller også bruger de programmer bare utrolig mange hestekræfter?
#1 og #3
Er i kloner?
Anyways... hvad har det at gøre med at presse penge ud af folk? Tror i drenge virkelig at MS er gået ind i en ond konspirationb med AMD og Intel om at tage penge fra folk.
Nu er det jo sådan at firmaer ofte skifter hardware mindst lige så hurtigt som de skifter OS.
Der er mange fordele ved at have en ordlængde på 64bit, specilet på servere. Desuden er det da kun rart at MS har nosser nok til at tvinge udviklingen i gang.
Hvis man kigger på hvor god support der er for x64 er det virkeligt ringe for LANGT de fleste virksomheder. Det er stadig svært at finde drivere til meget hardware.
Er i kloner?
Anyways... hvad har det at gøre med at presse penge ud af folk? Tror i drenge virkelig at MS er gået ind i en ond konspirationb med AMD og Intel om at tage penge fra folk.
Nu er det jo sådan at firmaer ofte skifter hardware mindst lige så hurtigt som de skifter OS.
Der er mange fordele ved at have en ordlængde på 64bit, specilet på servere. Desuden er det da kun rart at MS har nosser nok til at tvinge udviklingen i gang.
Hvis man kigger på hvor god support der er for x64 er det virkeligt ringe for LANGT de fleste virksomheder. Det er stadig svært at finde drivere til meget hardware.
Jeg tror dette er et spørgsmål om at MS kan gøre udvikling, support,distribution mm. nemere for dem selv. Det viser blot at de ikke er på forbrugerenes side. De er røv ligeglade om deres kunder skal ud og købe ny hardware.
Med linux har det da altid været sådan, at hvis du skulle knalde en server op, så kunne du bare finde en gammel skod computer og bruge, og så virker det hele helt fint.
De er til grin.
Med linux har det da altid været sådan, at hvis du skulle knalde en server op, så kunne du bare finde en gammel skod computer og bruge, og så virker det hele helt fint.
De er til grin.
Kun godt der kommer noget software til 64bit cpu'er så det bliver lidt mere meningsfuldt at bruge dem sammen med windows.
Jeg kan bare ikke have disse gamere der køber 64bit cpu'er og udelukkende kører 32bit styresystem/applikationer alligevel :D
Jeg kan bare ikke have disse gamere der køber 64bit cpu'er og udelukkende kører 32bit styresystem/applikationer alligevel :D
Hold kæft en omgang M$ bashing. Jeg er fuldstændig enig med #4 i at dette netop gør at andre udviklere incl. open source får øjnene op for at 64bit er den næste generation og at de SKAL skrive software/drivere til det, hvis det blot havde været en nyhed om at M$ laver endnu et 64bit version af deres software havde alle jo bare sagt "nå".
Selvfølgelig giver det også PR, og den slags er jo altid velkommen, men det har intet at gøre med at presse penge ud af folk. Så længe de stadig supporterer deres gamle versioner (mange år endnu), er det jo penge ud af lommen for dem selv, fordi mange ikke gider opgradere.
Selvfølgelig giver det også PR, og den slags er jo altid velkommen, men det har intet at gøre med at presse penge ud af folk. Så længe de stadig supporterer deres gamle versioner (mange år endnu), er det jo penge ud af lommen for dem selv, fordi mange ikke gider opgradere.
#1+#3
Man kan jo heller ikke blive ved med at spilde sin tid på bagud kompatibilitet, på et eller andet tidspunkt skal der jo være et "break" hvor man ser fremad. Der er jo absolut ingen der tvinger firmaerne der har sådanne servere kørende til at opgradere, de kan jo bare forsætte med at bruge den gamle version som der jo stadig vil blive udgivet opdateringer til hvis der bliver fundet huller.
Man kan jo heller ikke blive ved med at spilde sin tid på bagud kompatibilitet, på et eller andet tidspunkt skal der jo være et "break" hvor man ser fremad. Der er jo absolut ingen der tvinger firmaerne der har sådanne servere kørende til at opgradere, de kan jo bare forsætte med at bruge den gamle version som der jo stadig vil blive udgivet opdateringer til hvis der bliver fundet huller.
Det er vel bare en naturlig udvikling. Forstår ikke folk skal til at pive over at MS nu vil forsøge få flere penge ud af deres kunder, de tilbyder et nyt produkt som kan købes for penge, ligesom alle andre firmaer der udvikler nye produkter.
Nu er jeg indædt Linux person. Men jeg kan ikke se problemet, det er da fornuftigt nok at de kommer videre.
Men i øvrigt er jeg ikke enig i at firmaer skifter server og OS hele tiden. Tværtimod syntes jeg de oftest har servere kørende til hardwaren ikke kan mere og/eller man ikke kan få patches til OS længere.
For de Linux servere jeg arbejder med er de med 2x eller 4x CPU så er de så stærke at man har brug for bl.a. at sætte mange gb RAM i for at udnytte dem 100% med mange programmer på dem. og med Dual Core så bliver det mere nødvendigt med et 64bits OS.
Selvf. kan det være en løsning at køre VMWare i stedet for.
Men i øvrigt er jeg ikke enig i at firmaer skifter server og OS hele tiden. Tværtimod syntes jeg de oftest har servere kørende til hardwaren ikke kan mere og/eller man ikke kan få patches til OS længere.
For de Linux servere jeg arbejder med er de med 2x eller 4x CPU så er de så stærke at man har brug for bl.a. at sætte mange gb RAM i for at udnytte dem 100% med mange programmer på dem. og med Dual Core så bliver det mere nødvendigt med et 64bits OS.
Selvf. kan det være en løsning at køre VMWare i stedet for.
#13
Eller da vi i sin tid gik fra 16 til 32 bit. men den diskusion er jo irrelevant, da det bare er naturlig udvikling.
Og det var da på tide at der begynder at komme mere 64 bit understøttelse.
Man må så bare håbe at det betyder at firmaerne snart begynder at lave fler 64bit drivere.
Eller da vi i sin tid gik fra 16 til 32 bit. men den diskusion er jo irrelevant, da det bare er naturlig udvikling.
Og det var da på tide at der begynder at komme mere 64 bit understøttelse.
Man må så bare håbe at det betyder at firmaerne snart begynder at lave fler 64bit drivere.
#1, #3 prøv at whine lidt mere
det er kun godt at der er nogen der kan sige "fuck bagudkompatibilitet. I burde tænke over, at vi stadig sidder med maskiner som er kompatible med den første IBM PC fra 1981, og det er ikke ligefrem fremmende for udviklingen, at man er nødt til at tilgodese x86 kompatibiliteten hver gang man laver en ny CPU generation - al software som laves, er jo lavet til at være kompatibelt med det ældgamle instruktionssæt, alene af den grund, at man stadig kører med dette ældgamle instruktionssæt, pga. gammel software.
Alle moderne CPUer kører med en RISC kerne internt, men pga. bagudkompatibiliteten med x86, ligger der et lag som fortolker softwarens CISC instruktioner og oversætter dem til RISC laget og tilbage igen. Ikke ligefrem nogen køn løsning.
Jeg ser med glæde, at flere og flere ting bliver x64 only, så kan vi håbe på, at vi om nogle år, når alle har anskaffet sig x64 hardware, kan få nogle operativsystemer hvor alt ikke skal være gennemsyret af bagudkompatiblitet med de gamle x86 instruktioner.
Det ER samme overgang som fra 16 til 32 bit, én af grundene til at win9x kørte så ringe, var jo netop at det skulle være bagudkompatibelt med folks gamle spil og programmer til DOS og win311, og det tog perioden fra 1995 til 2001, før der kom et ægte 32-bit OS (WinXP) til mainstream-consumer markedet. Lad der for alt i verden gå kortere tid denne gang!
#16 han har ikke lavet ret meget, for han har aldrig ejet IBM :-)
det er kun godt at der er nogen der kan sige "fuck bagudkompatibilitet. I burde tænke over, at vi stadig sidder med maskiner som er kompatible med den første IBM PC fra 1981, og det er ikke ligefrem fremmende for udviklingen, at man er nødt til at tilgodese x86 kompatibiliteten hver gang man laver en ny CPU generation - al software som laves, er jo lavet til at være kompatibelt med det ældgamle instruktionssæt, alene af den grund, at man stadig kører med dette ældgamle instruktionssæt, pga. gammel software.
Alle moderne CPUer kører med en RISC kerne internt, men pga. bagudkompatibiliteten med x86, ligger der et lag som fortolker softwarens CISC instruktioner og oversætter dem til RISC laget og tilbage igen. Ikke ligefrem nogen køn løsning.
Jeg ser med glæde, at flere og flere ting bliver x64 only, så kan vi håbe på, at vi om nogle år, når alle har anskaffet sig x64 hardware, kan få nogle operativsystemer hvor alt ikke skal være gennemsyret af bagudkompatiblitet med de gamle x86 instruktioner.
Det ER samme overgang som fra 16 til 32 bit, én af grundene til at win9x kørte så ringe, var jo netop at det skulle være bagudkompatibelt med folks gamle spil og programmer til DOS og win311, og det tog perioden fra 1995 til 2001, før der kom et ægte 32-bit OS (WinXP) til mainstream-consumer markedet. Lad der for alt i verden gå kortere tid denne gang!
#16 han har ikke lavet ret meget, for han har aldrig ejet IBM :-)
ehh, driver problemer, Spil problemer.. Hvad har det lige at gøre med Server applikationer og servere.. tror ikke firmaer installerer Nvidia/ATI killer gfx kort og installerer halflive på deres exchange server..
Mon ikke de som leverer hardware til servere, vil få lavet drivere til vista servere.. (Iøvrigt osse til gavn for os andre)
Mon ikke de som leverer hardware til servere, vil få lavet drivere til vista servere.. (Iøvrigt osse til gavn for os andre)
jeg har intet imod at de prøver at fremskynde udviklingen til den næste generation... teknologi skal trods alt være up to date hvis i spørger mig, men jeg synes bare det lyder mærkeligt at de programmer de laver ikke kan køre på en fx xp.
det må skyldes et kompatibilitets problem, enten det eller osse er det udelukkende for at få folk til at investere i et x64 system IMHO...
det må skyldes et kompatibilitets problem, enten det eller osse er det udelukkende for at få folk til at investere i et x64 system IMHO...
Dette er jo alletiders gode grund til at skifte til Linux. Når man nu alligevel skal til at vænne sig til de nye applikationer samt et nyt styresystem i form af Vista, kan man ligeså godt prøve Linux.
Hvis man så ender med at kunne li' det behvøer man ikke efterfølgende bekymre sig om at skulle ud og betale mange penge hver gang MS vælger at skifte ud i program-portefølgen.
Hvis man så ender med at kunne li' det behvøer man ikke efterfølgende bekymre sig om at skulle ud og betale mange penge hver gang MS vælger at skifte ud i program-portefølgen.
#21 det kunne man jo, men tvivler stadig på at det er lige nemt nok for dem der kører en virksomhed med alle de licenser de i forvejen har anskaffet sig, ellers en god tanke og vil anbefale alle jeg kender om at gøre det før en opgradering ;)
de kunne jo trods alt spare en del...
#18 kan ikke se det onde i at gøre ting bagudkompatible, det fører faktisk i de fleste tilfælde også til at virksomhederne (der i denne sammenhæng er fx microsoft) tjener mange flere penge da forbrugerne bruger penge på produkterne på deres nuværende system og alligevel oftest skifter deres computer ud senere hen.
en ting er sikkert, jeg glæder mig til at se hvor dette fører hen :P
de kunne jo trods alt spare en del...
#18 kan ikke se det onde i at gøre ting bagudkompatible, det fører faktisk i de fleste tilfælde også til at virksomhederne (der i denne sammenhæng er fx microsoft) tjener mange flere penge da forbrugerne bruger penge på produkterne på deres nuværende system og alligevel oftest skifter deres computer ud senere hen.
en ting er sikkert, jeg glæder mig til at se hvor dette fører hen :P
#14 - Jeg har spillet Far Cry kompileret til 64 bit :-) Hvis man kigger på diverse spils hjemmesider er der faktisk en del der er begyndt at udgive 64-bit opdateringer. Desværre hjælper det ikke så meget på fps i de fleste tilfælde, da grafikkortet jo ikke opgraderes. Jeg kan dog forestille mig at load-tider bliver kortere, selvom jeg ikke har kunnet mærke nogen egentlig forskel i den korte tid jeg nåede at køre xp i 64bit sidst...
[url=#1]#1[/url] HashKagen
Med andre ord, det er f.... på tide der sker noget. Faktisk har jeg et eksemplar af bladet Unix Review fra juni 96, hvor der er en hel del artikler om 64 bits arkitekturer og portering fra 32 til 64 bits. Hvor var Microsoft nået til på det tidspunkt? Jo, de var såmænd så småt begyndt på at flytte fra 16 til 32 bits, mens de seriøse systemer allerede var i gang med at planlægge vejen væk fra 32 bits.
[url=#5]#5[/url] oleo
[url=#12]#12[/url] dasbutt
Men at Microsoft vælger at skubbe på for at der kan ske et skift fra 32 til 64 bits systemer mener jeg ikke er en handling, de bør kritiseres for. Der er visse skift, som bør foretages, men som ikke kommer af sig selv. Nogen er nødt til at skubbe til udviklingen. Det gælder f.eks. skift fra 16/32 bits arkitekturer til 64 bits arkitekturer, det gælder også skift fra IPv4 til IPv6. (Og endeligt er der nogle behov indenfor character encoding, men på det punkt mener jeg først der er brug for en passende standard. Det nytter ikke at skubbe til udviklingen uden at have et klart mål).
[url=#16]#16[/url] rum_
[url=#18]#18[/url] amokk
Selvom AMD64 er bagudkompatibel med IA32, så har AMD alligevel lavet et par væsentlige begrænsninger i bagudkompatibiliteten. I 64 bits mode har de totalt droppet virtuel 86 mode, og de har stort set droppet segmentering. Samtidigt har de udvidet registersættet. Jeg ved ikke med instruktionssættet, men med de tre væsentlige ændringer (64 bits, ingen segmentering, flere registre) er der ikke ret meget, som er ved det gamle. Så tidspunktet ville i hvert fald være helt rigtigt for en total revidering af instruktionssættet.
Lad os håbe udviklingen fortsætter i en retning hvor det kan ende med CPUer, der booter i 64 bits mode og ikke har nogen levn af IA32 tilbage.
Der er i øvrigt en ting jeg har spekuleret over. Nu hvor der ikke mere er nogen virtuel 86 mode, kan en 64 bits Windows så stadigvæk køre DOS programmer? Og såfremt den kan, hvordan foregår det så?
eller skal der seriøst så mange kræfter til?Det er jo ikke et spørgsmål om kræfter. Det er et spørgsmål om, at så snart der skal arbejdes med tal større end to milliarder, så kommer 32 bits til kort. Det vil sige på et 32 bits system bliver man nødt til at håndtere den slags tal på en upraktisk måde. Det betyder f.eks., at hvis din harddisk er på 2GB eller derover, så er der steder, hvor systemet har brug for at arbejde med tal, der er for store til 32 bits.
Med andre ord, det er f.... på tide der sker noget. Faktisk har jeg et eksemplar af bladet Unix Review fra juni 96, hvor der er en hel del artikler om 64 bits arkitekturer og portering fra 32 til 64 bits. Hvor var Microsoft nået til på det tidspunkt? Jo, de var såmænd så småt begyndt på at flytte fra 16 til 32 bits, mens de seriøse systemer allerede var i gang med at planlægge vejen væk fra 32 bits.
[url=#5]#5[/url] oleo
Jeg tror dette er et spørgsmål om at MS kan gøre udvikling, support,distribution mm. nemere for dem selv.Hvis det betyder, at de kan slippe for en masse upraktiske workarounds omkring begrænsningerne i 32 bits, så burde det give mulighed for at softwaren bliver af en bedre kvalitet. Det synes jeg ikke man skal kritisere Microsoft for.
[url=#12]#12[/url] dasbutt
Nu er jeg indædt Linux person. Men jeg kan ikke se problemet, det er da fornuftigt nok at de kommer videre.Jeg bruger også selv Linux. Jeg synes Unix designet i store træk er rigtigt, og jeg foretrækker software under GPL. Givet de to præferencer er Linux det naturlige valg. Og jeg bryder mig da heller ikke om Microsoft og ser da også tit grund til at kritisere deres handlinger.
Men at Microsoft vælger at skubbe på for at der kan ske et skift fra 32 til 64 bits systemer mener jeg ikke er en handling, de bør kritiseres for. Der er visse skift, som bør foretages, men som ikke kommer af sig selv. Nogen er nødt til at skubbe til udviklingen. Det gælder f.eks. skift fra 16/32 bits arkitekturer til 64 bits arkitekturer, det gælder også skift fra IPv4 til IPv6. (Og endeligt er der nogle behov indenfor character encoding, men på det punkt mener jeg først der er brug for en passende standard. Det nytter ikke at skubbe til udviklingen uden at have et klart mål).
Selvf. kan det være en løsning at køre VMWare i stedet for.Kører den overhovedet på 64 bits Windows? Det er da så systemnært, at det har behov for at få smidt en del af sin kode direkte ned i kernen. Så det kan ikke uden videre bruges på en 64 bits Windows selvom den i princippet kan køre 32 bits applikationer fuldstændig problemfrit.
[url=#16]#16[/url] rum_
Grineren, i har vidst ikke forstået hvad Bill har lavet siden han solgte IBMOg hvor intelligent ser den kommentar så lige ud for os, der godt ved, at Bill aldrig har ejet IBM?
[url=#18]#18[/url] amokk
det er kun godt at der er nogen der kan sige "fuck bagudkompatibilitet.Ja, det er der nogen gange behov for. Egentlig var det jo Intel der startede med deres IA64, det blev bare aldrig nogen stor succes. Så kom AMD64 og sagde fuck bagudkompatibiliteten, men ikke alt for meget. Det blev så en langt større succes end IA64. At AMD64 var mere bagudkompatibel end IA64 var nok ikke den eneste grund til succesen, prisen var nok også en væsentlig faktor. Faktisk var AMD64 en så stor succes, at Intel så sig nødsaget til at begynde at lave AMD64 kompatible CPUer.
Selvom AMD64 er bagudkompatibel med IA32, så har AMD alligevel lavet et par væsentlige begrænsninger i bagudkompatibiliteten. I 64 bits mode har de totalt droppet virtuel 86 mode, og de har stort set droppet segmentering. Samtidigt har de udvidet registersættet. Jeg ved ikke med instruktionssættet, men med de tre væsentlige ændringer (64 bits, ingen segmentering, flere registre) er der ikke ret meget, som er ved det gamle. Så tidspunktet ville i hvert fald være helt rigtigt for en total revidering af instruktionssættet.
Lad os håbe udviklingen fortsætter i en retning hvor det kan ende med CPUer, der booter i 64 bits mode og ikke har nogen levn af IA32 tilbage.
Der er i øvrigt en ting jeg har spekuleret over. Nu hvor der ikke mere er nogen virtuel 86 mode, kan en 64 bits Windows så stadigvæk køre DOS programmer? Og såfremt den kan, hvordan foregår det så?
#24
VMware kører fint på en x64 windows. Jeg har selv både kørt Linux i386, FreeBSD, Windows Vista 32bit og MacOSX Tiger 32bit på min Windows x64 maskine, igennem VMWARE. Det kører mindst lige så godt som på 32bit windows
Som jeg ser det, er AMD64 en slags overgangs-CPU imellem 32 og 64 bit, og IMHO den første af slagsen der har kunnet lave et smertefrit skift (tænk på itanium osv)
Du kan godt køre DOS programmer i x64, da windows (fra NT og op) emulerer en virtuel PC når du starter et DOS program. Dog kan du ikke umiddelbart bruge gamle programmer der tilgår COM og LPT porte osv. og visse spil virker heller ikke - så det er nok et sprøgsmål om hvor hardware-nært tingene er skrevet.
VMware kører fint på en x64 windows. Jeg har selv både kørt Linux i386, FreeBSD, Windows Vista 32bit og MacOSX Tiger 32bit på min Windows x64 maskine, igennem VMWARE. Det kører mindst lige så godt som på 32bit windows
Som jeg ser det, er AMD64 en slags overgangs-CPU imellem 32 og 64 bit, og IMHO den første af slagsen der har kunnet lave et smertefrit skift (tænk på itanium osv)
Du kan godt køre DOS programmer i x64, da windows (fra NT og op) emulerer en virtuel PC når du starter et DOS program. Dog kan du ikke umiddelbart bruge gamle programmer der tilgår COM og LPT porte osv. og visse spil virker heller ikke - så det er nok et sprøgsmål om hvor hardware-nært tingene er skrevet.
#6 keke
Selvfølgelig skal man da også, have koden med til de ting man køber eller henter...
Kan have lidt blandede følelser, omkring sådan en udmelding. Specielt nu hvor deres software, jo ikke "lever" evigt. (Rent supportmæssigt. Og de frateger folk fra, at få produkterne holdt vedlige ved egen eller andres hjælp. Hvis et firma som deres postserver, filserver og gateway, om to år stadig er tilfredse med deres 600Mhz Pentium 3, så er de ikke velkomne som kunder hos Microsoft. Sådan en vil i serversammenhæng, være mere end rigeligt til de fleste små virksomheder i nogle år endnu. Når Microsoft stopper supporten på deres nuværende Windows 2000 server, så kan de så ikke få mere serversoftware fra Microsoft til den. Dan slags her er jo med til at gøre, at der bliver kasseret massevis af ganske godt brugbart IT udstyr. Hverken særligt klogt eller miljøvenligt.
Microsoft har altid været, og vil nok også altid være, hardwareproducenternes bedste ven... ;)
Det er jo kun fordi du har kilde koden til linux. Så du kan kompilere den til netop lige dit system.
Selvfølgelig skal man da også, have koden med til de ting man køber eller henter...
Kan have lidt blandede følelser, omkring sådan en udmelding. Specielt nu hvor deres software, jo ikke "lever" evigt. (Rent supportmæssigt. Og de frateger folk fra, at få produkterne holdt vedlige ved egen eller andres hjælp. Hvis et firma som deres postserver, filserver og gateway, om to år stadig er tilfredse med deres 600Mhz Pentium 3, så er de ikke velkomne som kunder hos Microsoft. Sådan en vil i serversammenhæng, være mere end rigeligt til de fleste små virksomheder i nogle år endnu. Når Microsoft stopper supporten på deres nuværende Windows 2000 server, så kan de så ikke få mere serversoftware fra Microsoft til den. Dan slags her er jo med til at gøre, at der bliver kasseret massevis af ganske godt brugbart IT udstyr. Hverken særligt klogt eller miljøvenligt.
Microsoft har altid været, og vil nok også altid være, hardwareproducenternes bedste ven... ;)
#26 hvis de er tilfredse med en 600mhz maskine som mailserver, mon ikke de så også er tilfredse med exchange 2000 eller hvad de kører pt? hvis man alligevel investerer i en licens til den slags software + brugerlicenser, er de småpenge en AMD64 koster, jo pebernødder ved siden af
#27 amokk
Microsoft gør jo udskiftningen af software nødvendigt, når de stopper for supporten. Men derfor kan hardwaren jo være god nok. Så hvorfor kassere fuldt funktionsdygtigt udstyr?.
Lad os tage min stedfars nye firma som eksempel:
Han har to ansatte og sig selv. Og så har de hver en arbejdsstation, hvor de bogfører og laver regnskab. Deres server er i dag primært filserver og domænecontroller. At presse dem til, at købe ny server til det formål er komplet tåbeligt. Deres behov bliver maks 1% større for hvert år. Så jeg forestiller mig, cirka 6-8år mere i den løsning. De skal bare kunne, præcis hvadde kan i dag. Men blive ved at kunne det, meden nogenlunde sikkerhed. Hvilket i praksis tvinger dem til at opgradere softwaren, til nogen som også kan langt mere end de har brug for. Hvis ikke deres behov var så Windows specifikke, så lå løsningen jo ligefor.
Microsoft gør jo udskiftningen af software nødvendigt, når de stopper for supporten. Men derfor kan hardwaren jo være god nok. Så hvorfor kassere fuldt funktionsdygtigt udstyr?.
Lad os tage min stedfars nye firma som eksempel:
Han har to ansatte og sig selv. Og så har de hver en arbejdsstation, hvor de bogfører og laver regnskab. Deres server er i dag primært filserver og domænecontroller. At presse dem til, at købe ny server til det formål er komplet tåbeligt. Deres behov bliver maks 1% større for hvert år. Så jeg forestiller mig, cirka 6-8år mere i den løsning. De skal bare kunne, præcis hvadde kan i dag. Men blive ved at kunne det, meden nogenlunde sikkerhed. Hvilket i praksis tvinger dem til at opgradere softwaren, til nogen som også kan langt mere end de har brug for. Hvis ikke deres behov var så Windows specifikke, så lå løsningen jo ligefor.
Set i det lys at virksomheder der har behov for Exchange servere og lign. sjældent anvender servere til seriøse formål der er mere end 2 år gamle så får det vist ikke den store betydning på den front.
Og det er irrelevant at blande linux ind i denne debat, det er sjældent uden grund at de virksomheder denne nyhed er relevant for kører med de Microsoft-løsninger som de gør. Om I vil det eller ej, så laver Microsoft altså nogle virksomheds-produkter der har høj relevans for rigtig mange virksomheder og som der ganske enkelt ikke findes alternativer til der kan måle sig på de faktorer der gør sig gældene for de enkelte virksomheder rent kvalitetsmæssigt.
Og det er irrelevant at blande linux ind i denne debat, det er sjældent uden grund at de virksomheder denne nyhed er relevant for kører med de Microsoft-løsninger som de gør. Om I vil det eller ej, så laver Microsoft altså nogle virksomheds-produkter der har høj relevans for rigtig mange virksomheder og som der ganske enkelt ikke findes alternativer til der kan måle sig på de faktorer der gør sig gældene for de enkelte virksomheder rent kvalitetsmæssigt.
Jeg har svært ved at se hvorfor MS ikke skulle have lov at gøre dette.
Det er helt naturligt at deres udvikilng bliver nemmere når de skal understøtte færre systemer.
Det er helt naturligt at deres udvikilng bliver nemmere når de skal understøtte færre systemer.
#1: Nu behøver 64 bit processorne jo ikke være super meget hurtigere end samme processortype i en 32 bit version. Set fra netop serveres synspunkt er 64 bit spændende. Tænk bare på muligheden for langt større databasestørrelser, filstørrelser, ram o.s.v. Alt sammen noget der går fint i spænd med den fortsatte udvikling inden for servere.
Det lyder som et udemærket tiltag at komme et skridt videre (32bit til 64bit)
Nu er jeg selv ansvarlig for indkøb i det firma som jeg arbejder i og amokk har ret i at det er bedøvende ligegyldigt hvad en processor koster i forhold til det totale budget. Det eneste som det handler om ar at ydelsen er som den skal være. Softwaren (server/klient) er LANGT den største udgift
:)LeonM
Nu er jeg selv ansvarlig for indkøb i det firma som jeg arbejder i og amokk har ret i at det er bedøvende ligegyldigt hvad en processor koster i forhold til det totale budget. Det eneste som det handler om ar at ydelsen er som den skal være. Softwaren (server/klient) er LANGT den største udgift
:)LeonM
#20 Hvorfor skulle de programmer som er beskrevet kunne køre på en Windows XP???
Ingen i sine vildeste drømme kunne vel finde på ar installere en Exchange server på en XP, da den jo har begrænset brugerlicenser. XP kan heller ikke køre med flere webservere sin er nødvendigt for Exchange.
Alle virksomheder der vil skifte til en Exchange 12, vil sikkert også købe en ny server at køre det på og så er 64 bit problemet løst.
Næsten alle de store leverandører som IBM, DELL, HP, Fujitsu osv. kan levere servere med 64 bit processor og OS. De er alle testet og har de rigtige drivere.
Ingen i sine vildeste drømme kunne vel finde på ar installere en Exchange server på en XP, da den jo har begrænset brugerlicenser. XP kan heller ikke køre med flere webservere sin er nødvendigt for Exchange.
Alle virksomheder der vil skifte til en Exchange 12, vil sikkert også købe en ny server at køre det på og så er 64 bit problemet løst.
Næsten alle de store leverandører som IBM, DELL, HP, Fujitsu osv. kan levere servere med 64 bit processor og OS. De er alle testet og har de rigtige drivere.
#30 amokk
Det er ikke et spørgsmål jeg overhovedet kommer ind på.
Jeg konstantere blot at det er komplet åndsvagt,at måtte smide komplet funktionsdygtigt udstyr i containeren. Sagen er en helt anden, hvis behovet diktere det. Men det drejer denne nyhed sig, desværre ikke om.
hvad koster det at opgradere deres software på serveren? set i forhold til prisen for at opgradere til en athlon 64?
Det er ikke et spørgsmål jeg overhovedet kommer ind på.
håber du kan se min pointe om at det her er softwaren der er dyr og ikke hardwaren
Jeg konstantere blot at det er komplet åndsvagt,at måtte smide komplet funktionsdygtigt udstyr i containeren. Sagen er en helt anden, hvis behovet diktere det. Men det drejer denne nyhed sig, desværre ikke om.
#24
En 32-bits adresse giver altså 2^32=4.294.967.296 forskellige adresseringsmuligheder. Dvs. 32-bits processorer kan rent faktisk håndtere 4GB og ikke 2GB på en hensigtsmæssig måde. Det er også derfor at man absolut max. kan have 4 GB ram i en spand der kører 32 bit.
Det er jo ikke et spørgsmål om kræfter. Det er et spørgsmål om, at så snart der skal arbejdes med tal større end to milliarder, så kommer 32 bits til kort. Det vil sige på et 32 bits system bliver man nødt til at håndtere den slags tal på en upraktisk måde. Det betyder f.eks., at hvis din harddisk er på 2GB eller derover, så er der steder, hvor systemet har brug for at arbejde med tal, der er for store til 32 bits.
En 32-bits adresse giver altså 2^32=4.294.967.296 forskellige adresseringsmuligheder. Dvs. 32-bits processorer kan rent faktisk håndtere 4GB og ikke 2GB på en hensigtsmæssig måde. Det er også derfor at man absolut max. kan have 4 GB ram i en spand der kører 32 bit.
[url=#37]#37[/url] Dica
Når jeg siger 2GB og ikke 4GB skyldes det, at man mange steder arbejder med tal med fortegn. Der er naturligvis nogle steder, hvor man kan undvære fortegnsbitten, og hvis man bruger unsigned variable der, så kan man presse grænsen til 4GB. Det giver så bare problemer fordi man nemt introducerer bugs, når der skal blandes tal med og uden fortegn.
At der skulle være en begrænsning på 4GB på 32 bits maskiner er nu ikke helt korrekt. Der er en begrænsning på, hvor meget der kan tilgås på praktiske måder. Hvis man begynder at anvende upraktiske lappeløsninger kan man sagtens presse mere RAM i maskinen.
Der er ikke noget nyt i at presse mere RAM i end adresserummet tillader. En C64 havde også 64KB RAM, 8KB ROM (så vidt jeg husker) og noget memory mapped I/O. Alt sammen presset ind i de 64KB adresserum 16 bits giver. Det skete vha. bank switching, og betød bla. at BASIC programmer aldrig kunne udnytte alt RAM. Og de fortsatte stilen og pressede 128KB RAM ind i samme adresserum.
8086-80286 havde mulighed for endnu mere RAM selvom det stadigvæk var 16 bits maskiner. På dem var det CPUen selv, der foretog segmentering for at udvide mængden af RAM. Men selv det var ikke nok, så der kom noget bank switching hardware, som tillod endnu mere RAM. Det hed vist LIM EMS eller noget i den retning. På et senere tidspunkt blev det så muligt vha. en 386 af lave en software emulering af denne bankswitching hardware.
Fint nok at man udnyttede mulighederne i en 386 til at køre gamle programmer. Men native 386 kode var jo 32 bits, og ville kunne udnytte i nærheden af 4GB. På trods af det, blev man stadig i stor stil ved med at køre 16 bits kode som ad diverse omveje tilgik væsentligt mere end 64KB RAM.
Tja, tilgang til mere end de 16MB som en 286 kunne adressere var jo godt nok lidt akavet på en 386. Den skulle jo være bagudkompatibel. Et segment på en 386 kan være fra 1 byte til 4GB, og størrelsen angives med 21 bits. (Der er nok nogen der undrer sig over, hvordan det kunne lade sig gøre).
Og udover de 4GB kan man så bruge PAE som er endnu en lappeløsning, som tillader op til 64GB RAM.
Så jo, man kan tilgå mere RAM end man direkte kan adressere, men det foregår altid på en mere eller mindre upraktisk måde. Sørgeligt at PC'er stadigvæk i dag starter op i en 16 bits mode som vha. diverse lappeløsninger kan tilgå op til 1MB, men det skal jo være bagudkompatibelt med 80'ernes hardwaredesign.
Det er også derfor at man absolut max. kan have 4 GB ram i en spand der kører 32 bit.For det første er det ikke kun et spørgsmål om RAM. Jeg har kun 1280MB RAM og render alligevel ind i problemer. Der er jo ting som virtuel RAM og memory mappings, som også bruger adresserum. Og man har jo altid haft brug for at regne på f.eks. diskkapacitet, så selv hvis det er harddisken, der er for stor, så har man et problem. Det er jo derfor, der er programmer, som har vist forkerte oplysninger om fri diskplads, hvis disken var større end der kunne angives med 32 bits.
Når jeg siger 2GB og ikke 4GB skyldes det, at man mange steder arbejder med tal med fortegn. Der er naturligvis nogle steder, hvor man kan undvære fortegnsbitten, og hvis man bruger unsigned variable der, så kan man presse grænsen til 4GB. Det giver så bare problemer fordi man nemt introducerer bugs, når der skal blandes tal med og uden fortegn.
At der skulle være en begrænsning på 4GB på 32 bits maskiner er nu ikke helt korrekt. Der er en begrænsning på, hvor meget der kan tilgås på praktiske måder. Hvis man begynder at anvende upraktiske lappeløsninger kan man sagtens presse mere RAM i maskinen.
Der er ikke noget nyt i at presse mere RAM i end adresserummet tillader. En C64 havde også 64KB RAM, 8KB ROM (så vidt jeg husker) og noget memory mapped I/O. Alt sammen presset ind i de 64KB adresserum 16 bits giver. Det skete vha. bank switching, og betød bla. at BASIC programmer aldrig kunne udnytte alt RAM. Og de fortsatte stilen og pressede 128KB RAM ind i samme adresserum.
8086-80286 havde mulighed for endnu mere RAM selvom det stadigvæk var 16 bits maskiner. På dem var det CPUen selv, der foretog segmentering for at udvide mængden af RAM. Men selv det var ikke nok, så der kom noget bank switching hardware, som tillod endnu mere RAM. Det hed vist LIM EMS eller noget i den retning. På et senere tidspunkt blev det så muligt vha. en 386 af lave en software emulering af denne bankswitching hardware.
Fint nok at man udnyttede mulighederne i en 386 til at køre gamle programmer. Men native 386 kode var jo 32 bits, og ville kunne udnytte i nærheden af 4GB. På trods af det, blev man stadig i stor stil ved med at køre 16 bits kode som ad diverse omveje tilgik væsentligt mere end 64KB RAM.
Tja, tilgang til mere end de 16MB som en 286 kunne adressere var jo godt nok lidt akavet på en 386. Den skulle jo være bagudkompatibel. Et segment på en 386 kan være fra 1 byte til 4GB, og størrelsen angives med 21 bits. (Der er nok nogen der undrer sig over, hvordan det kunne lade sig gøre).
Og udover de 4GB kan man så bruge PAE som er endnu en lappeløsning, som tillader op til 64GB RAM.
Så jo, man kan tilgå mere RAM end man direkte kan adressere, men det foregår altid på en mere eller mindre upraktisk måde. Sørgeligt at PC'er stadigvæk i dag starter op i en 16 bits mode som vha. diverse lappeløsninger kan tilgå op til 1MB, men det skal jo være bagudkompatibelt med 80'ernes hardwaredesign.
#24
Jeg vil nu ikke sige jeg er enig i din 32-bits tal størrelses argument. Det er absolut intet problem at bruge 64-bit enheder på en 32-bit maskine, at det ikke er den naturlige heltals type på den arkitektur har kun indflydelse på hastigheden af afviklingen, ikke skrivningen af programmet. Så dette kan bestemt ikke være et fornuftigt argument.
Argumentet må være at disse programmer har brug for et større adresserum end en 32-bit maskine giver mulighed for. Nu ved jeg ikke om Windows kernen laver et 4G/4G split af adresserummet mellem kernel og user space, eller om den deler adresserummet op (som Linux gør). Under alle omstændigheder er det grimt at supportere > 4GB adresserum til 32-bit applikationer.
Har man brug for mere end 4GB adresserum -> 64-bit maskiner, punktum, ingen diskussion. Derudover kan der være hastighedsargumenter, men det er bestemt ikke sort/hvidt som adressrummet et.
Jeg vil nu ikke sige jeg er enig i din 32-bits tal størrelses argument. Det er absolut intet problem at bruge 64-bit enheder på en 32-bit maskine, at det ikke er den naturlige heltals type på den arkitektur har kun indflydelse på hastigheden af afviklingen, ikke skrivningen af programmet. Så dette kan bestemt ikke være et fornuftigt argument.
Argumentet må være at disse programmer har brug for et større adresserum end en 32-bit maskine giver mulighed for. Nu ved jeg ikke om Windows kernen laver et 4G/4G split af adresserummet mellem kernel og user space, eller om den deler adresserummet op (som Linux gør). Under alle omstændigheder er det grimt at supportere > 4GB adresserum til 32-bit applikationer.
Har man brug for mere end 4GB adresserum -> 64-bit maskiner, punktum, ingen diskussion. Derudover kan der være hastighedsargumenter, men det er bestemt ikke sort/hvidt som adressrummet et.
#39 læs nu lige #38 igen - adresserummet er ikke det eneste argument, og x86 arkitekturen har historisk set - som kasperd også skriver, benyttet sig at segmentering ting at adressere mere RAM end CPUens interface tillader. denne segmentering er stadig understøttet af moderne CPUer, da de jo skal være bagudkompatible med gamle programmer til 286 osv. hvor man kun havde 16 bits at gøre godt med.
"at det ikke er den naturlige heltals type på den arkitektur har kun indflydelse på hastigheden af afviklingen, ikke skrivningen af programmet. Så dette kan bestemt ikke være et fornuftigt argument."
Det er NETOP hastigheden der er argumentet her. Tænk over hvor mange instruktioner det kræver, at behandle 64 bits hvis du kun kan behandle 32 ad gangen, og dermed skal ud og hente og gemme i registre, og udføre diverse aritmetiske operationer på resultatet - hvorimod en 64bit CPU kan gøre det hele i én omgang - groft sagt
"at det ikke er den naturlige heltals type på den arkitektur har kun indflydelse på hastigheden af afviklingen, ikke skrivningen af programmet. Så dette kan bestemt ikke være et fornuftigt argument."
Det er NETOP hastigheden der er argumentet her. Tænk over hvor mange instruktioner det kræver, at behandle 64 bits hvis du kun kan behandle 32 ad gangen, og dermed skal ud og hente og gemme i registre, og udføre diverse aritmetiske operationer på resultatet - hvorimod en 64bit CPU kan gøre det hele i én omgang - groft sagt
selvfølgelig er det positivt at microsoft følger udviklingen og udgiver 64-bit versioner af disse systemer, men måske var det en mulighed at udgive disse 2 styresystemer og exchange porgrammet i begge versioner, altså både 64 og 32bit. Dog er problemet ikke af nogen særlig betydning for den almindelige bruger, der højst sandsynlig ikke vil bruge server OS. Så længe de holder sig fra at lave "64-bit only" versioner af deres andre nye systemer...
#40
Adresserummet _er_ det eneste argument, det er min påstand. Segmentering virker til en vis grad, men kun i den forstand at det sætter operativ systemet i stand til at adressere mere end 32-bit (36-bit med PAE, Intel havde vist endda et 40-bit PAE foreslag på et tidspunkt som jeg ikke ved om blev til noget. Man kan håbe det ikke gjorde) med passende overhead. Det hjælper ikke meget for user space programmer. Så de sidste vundne bits i adresserummet er af begrænset nyttighed.
Jeg ved udemærket godt hvad overhead er for 64-bit heltal på en 32-bit platform, jeg arbejder med det til daglig. Hvordan tror du store devices/filsystemer er supporteret i feks Linux på 32-bit platforme? En hurtig test med gcc viser at en 32-bit heltals (indirekte) inkrementering på en 32-bit maskine er 4 mov og en lea. En 64-bit heltals inkrementering er er 6 movs og to adds. Selvfølgelig er der overhead og det er da også ret nemt at skrive en syntetisk mikrobenchmark der viser at det er langsommere, men i det store hele er det tit bare støj. Er din variable feks ikke cached, vil det cache miss koste langt mere end aritmetikken på variablen.
Så jeg mener bestemt hvad jeg skrev.
Adresserummet _er_ det eneste argument, det er min påstand. Segmentering virker til en vis grad, men kun i den forstand at det sætter operativ systemet i stand til at adressere mere end 32-bit (36-bit med PAE, Intel havde vist endda et 40-bit PAE foreslag på et tidspunkt som jeg ikke ved om blev til noget. Man kan håbe det ikke gjorde) med passende overhead. Det hjælper ikke meget for user space programmer. Så de sidste vundne bits i adresserummet er af begrænset nyttighed.
Jeg ved udemærket godt hvad overhead er for 64-bit heltal på en 32-bit platform, jeg arbejder med det til daglig. Hvordan tror du store devices/filsystemer er supporteret i feks Linux på 32-bit platforme? En hurtig test med gcc viser at en 32-bit heltals (indirekte) inkrementering på en 32-bit maskine er 4 mov og en lea. En 64-bit heltals inkrementering er er 6 movs og to adds. Selvfølgelig er der overhead og det er da også ret nemt at skrive en syntetisk mikrobenchmark der viser at det er langsommere, men i det store hele er det tit bare støj. Er din variable feks ikke cached, vil det cache miss koste langt mere end aritmetikken på variablen.
Så jeg mener bestemt hvad jeg skrev.
#43
Okay. Har ikke lige den store forstand på forskellen i at programmere i 64- og 32bit kode men hvis du siger der er en minimal forskel, så vil jeg da regne med det:)
Ville i hvertfald være fordelagtigt, da de ville nå en bredere kundekreds medmindre de, som det i denne annoncering ser ud til, ønsker af presse penge ud af folk ved at tvinge dem til at opgradere til 64-bit hardware hvis de ikke allerede er i besiddelse af det.
Okay. Har ikke lige den store forstand på forskellen i at programmere i 64- og 32bit kode men hvis du siger der er en minimal forskel, så vil jeg da regne med det:)
Ville i hvertfald være fordelagtigt, da de ville nå en bredere kundekreds medmindre de, som det i denne annoncering ser ud til, ønsker af presse penge ud af folk ved at tvinge dem til at opgradere til 64-bit hardware hvis de ikke allerede er i besiddelse af det.
#44
Der er ingen forskel. Typisk sørger man bare for at ingen pointere/numre trunkeres ved 64-bit kode. Kode der er 64-bit 'clean' virker typisk out-of-the-box på en 32-bit maskine. Det er hvad kompileren kan klare for dig.
Derudover er der selvfølgelig lige den hage, er der også er en del kode som er arkitektur specifikt. Selvom der er en del overlap mellem ia32 og x86-64, så er det stadig to arkitekturer. Det kan kompileren ikke klare for dig :-)
Der er ingen forskel. Typisk sørger man bare for at ingen pointere/numre trunkeres ved 64-bit kode. Kode der er 64-bit 'clean' virker typisk out-of-the-box på en 32-bit maskine. Det er hvad kompileren kan klare for dig.
Derudover er der selvfølgelig lige den hage, er der også er en del kode som er arkitektur specifikt. Selvom der er en del overlap mellem ia32 og x86-64, så er det stadig to arkitekturer. Det kan kompileren ikke klare for dig :-)
#8
Bare fordi det virker til din webserver, der skal bruges til hostning af et website, om nyheder inden for hamsterlegetøj med 3 besøgende om måneden, er det ikke ensbetyden med, at det faktisk også virker sådan for virksomheder.
Det har jeg nu aldrig gjort. Det er nemmere at hente en en distro der passer til ens processor. Så virker resten som regl.
Prøv det.
Bare fordi det virker til din webserver, der skal bruges til hostning af et website, om nyheder inden for hamsterlegetøj med 3 besøgende om måneden, er det ikke ensbetyden med, at det faktisk også virker sådan for virksomheder.
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Nyheder
Gå til bund