For den jevne bruker har man hatt 3 begrensninger som har hindret overgangen fra 32 bit til 64 bit i Linux. Disse ser ut til å bli løst en etter en, og nå ser det ut til at den siste biten faller på plass.
- Opera har forlengst kommet med 64 bits versjon som kan lastes ned fra Opera's hjemmesider for mange distibusjoner.
- Adobe har kommet med en alphaversjon av Flash 10.
- Sun har kommet med en 64 bits versjon av Sun Java plugin.
Dette betyr at mye ligger til rette for overgang til 64bits OS for mange brukere. Noe modning av 64bitsversjonene av Flash og Java er nok påkrevet før de blir selvfølgeligheter, men det ligger også til rette for økt prioritering av 64bits fra distroenes side.
Kilde:Phoronix
olear 15. desember 2008 - 22:42
Hmm, fristende. Eneste som har holdt meg tilbake er Sun JRE.
Roberth 16. desember 2008 - 1:30
For å være helt ærlig så klarer ikke jeg å se noen fordeler med 64 bit ennå, siden de fleste vil oppleve 2 GB RAM som overkill til vanlig desktop bruk.
moma 16. desember 2008 - 9:42
Endelig, endelig kom Suns java-plugin for Firefox3 i 64 bits utgave. Jeg vil nå migrere til 64bits Ubuntu/Fedora for godt. Vil dok beholde et par 32 bits linux partisjoner for testing av programvare. Kan hende jeg vil lansere Screendump... kun for 64 bits Linux, bare for å være litt sær.
Fordelene med 64 bits system vil være:
* 64 bits kode på 64 bits CPU (AMD64 eller Intel EM64T) er noe raskere enn tilsvarende kode på 32 bits system. F.eks se denne testen på Phoronix. Noen påstår at grafisk GUI på 64bits også føles raskere. Enig.
* Kan benytte mer enn 2 GB minne. 32 bits har vel teoretisk grense
4GB, i praksis ca. 2GB. 64bits system kan benytte mer enn 4GB uten problemer.
* Dermed kan tildele mer minne til virtuelle maskiner / ha flere virtuelle maskiner.
* Så å si alle åpen-kildekode applikasjoner finnes både i 32 og 64 bits utgaver. Lukket kildekodeverdenen (Windows) har problemer med dette.
olear 16. desember 2008 - 11:00
Grensen på 32bit er ca 3,5. Kjører selv 3GB RAM på 32bit. Har lenge vurdert å oppgradere til 8GB, men tvunget overgang til 64bit fristet ikke tidligere.
moma 16. desember 2008 - 11:11
Denne stasjonære PCn har en minne-innstilling i BIOS som lar 32bits OS få litt ekstra RAM (~3.0GB istedet for 2GB). Jeg husker å ha skrevet om det i denne bloggen...
Limpalot 16. desember 2008 - 12:03
Bortsett fra for oss som kjører virtuelle maskiner i tillegg...da blir det fort litt snaut...
omaha 16. desember 2008 - 12:17
Ytelsesmessig har det nok ikke så mye å si for en regulær bruker foreløpig. Men virtualisering blir stadig mer mainstream, og det er vel fordelaktig om man bedriver f.eks rendering eller matematiske/fysiske beregninger osv.
En av fordelen ligger i at det vil øke tilgjengeligheten av 64-bitsversjoner (selv om de fleste er pakket for 64bit så er det fortsatt noen som kun ligger som 32bit). Jeg tror dette vil medføre at 64bit nokså raskt vil blir "default" versjon på nyere maskiner - også for mange som ikke har nytte av det.
Det er jo etterhvert mange 64bits maskiner rundt omkring, og det er derfor naturlig at mange av eierne vil ønske å kjøre et OS som er tilpasset dette.
QtanJ 16. desember 2008 - 22:08
Eg er lite kritisk til amd64(x86_64), men eg er kritisk til korleis dei ulike distribusjonane taklar 64-bit.
Gentoo har god dokumentasjon på chroot og multilib. Chroot har instruksjonar både til Ubuntu og Gentoo, men eg veit ikkje om Fedora har enkle framgangsmåter for nokon av dei. Likevel burde det vore enkelt å tilpasse mellom distribusjonane slik at einaste skilnad vert om ein vil lage runscript i /etc/init.d eller andre stader.
32-bit chroot treng ikkje eigen loggføring, ssh, eller andre tenester som 64-bit-roten køyrer.
Eg har ikkje laga meg chroot enda, men har store planer om å byte ut multilib med chroot sidan chroot har full støtte, og multilib stort sett har støtte for å køyre 32-bits program.
Wine, cedega, o.l. krever 32-bit. Kommersielle program krever ofte 32-bit. Grub må vera statisk lenka for å fungera på rein 64-bit.
Quadcore bør helst ha 4GB ram for å fungera effektivt(i forhold til dual core) slik at det er smart å bruke 64-bit kjerne på quadcore.
Ein ide kan vera å køyre 64-bit kjerne og 32-bit resten av systemet. Sidan det er kjernen som styrer korleis det viktigaste og på lågast nivå kan det hende dette er eit kompromiss, men om glib/glibc også er viktig for total minne som kan vera i bruk vil ikkje dette fungera. Ein får uansett aldri 32-bits program til å bruka meir enn så så mykje ram per program.
Denne ideen fungerer heller ikkje om ein liker å byggje kjernen(eller enkeltmoduler for kjernen, som nvidia eller ati om ein bruker kommersielle drivarar) frå kjeldekode sjølv(slik som eg gjer). Då treng ein 64-bit gcc + glib + glibc + sikkert noko meir eg ikkje hugsar i farta.
ak 22. desember 2008 - 16:33
Da har jeg byttet, til Fedora 10 i første omgang.
Ble litt masete fordi jeg må ha Google Earth og i386 Java uansett, men her er et par tips:
yum kan finne frem til pakke for manglende fil for deg:
1) Kjør updatedb som root
2) locate , sannsynligvis finner du den i lib64 et sted.
3) Kjør yum install [sti til .so fil] , bare bytt ut lib64 med lib i stien.
4) For nærmere analyse, finn programmet som skaper kluss (sjekk at det ikke startes gjennom script), kjør deretter ldd [sti til program] for å se hvilke biblioteker som mangler
hansaudun 29. desember 2008 - 14:03
Til de som "må" kjøre 32bit er det ingen problemer å ha mer enn 4GB minne. Det eneste som trengs er kjerne som støtter PAE. I *buntu kan man bruke server-kjernen for å få tilgang til alt minnet (hvis mer enn 4GB).
I Fedora heter kjernen noe med PAE. I Debian heter den noe med BIGMEM.
Når det er sagt, bruker jeg 64bit ubuntu sjøl og er strålende fornøyd :-)