W sumie mają rację. Największą zaleta Firefoxa jest masa pluginów, a największa wadą - pamięciożerność. Wersja 64-bit zniweczyłaby zaletę i pogłębiła wadę.

'(ciekawe, że nikt nie wpadł jeszcze na pomysł podawania mocy zasilacza; przecież to tak jak z odkurzaczem – im więcej prądu pobiera sprzęt, tym jest mocniejszy, prawda?).'

Nieprawda. Mocny zasilacz nie jest pro ekologiczny

Obojętnie w jakim systemie, z PAE czy bez, 32-bitowy FF nie zaadresuje więcej niż 4 GB pamięci - ciekawe na ile zakładek z obrazkami itp to się przekłada

Galvatron, powiem Tobie, że z PAE to nawet i 64 GB zaadresuje
-> https://help.ubuntu.com/community/32bit_and_64bit
x64 to popularne oznaczenie x86-64, tak jak x32 dla x86-32. Np. Windows XP na jądrze 2003 Server był oznaczany jako x64.
-> http://www.microsoft.com/windowsxp/64bit/default.mspx
Nie napisałem ponadto, że 32-bitowe nie obsłużą ponad 4 GB, tylko, że 64-bitowe obsłużą. Może pokrętnie, ale przyznasz sam, że standardowo 32-bitowe, desktopowe 'łindołsy' nie widzą więcej niż 4 GB, a tylko w XP Professional można to włączyć. Linuksom potrzeba odpowiedniej kompilacji jądra (chociaż większość nowych dystrybucji taką zawiera).

Myślę, że natywna obsługa większej ilości pamięci przez 64-bitowe systemy jest na tyle ważnym 'ficzerem' i ulepszeniem w stosunku do wersji 32-bit, że warto było o tym wspomnieć. Bzdur w tym zdaniu więc nie widzę, co najwyżej uproszczenia. Nie wymagaj jednak, żeby przy okazji newsa o Firefoksie opisywać zawiłości architektur i funkcji systemowych. Tym bardziej dzięki, że zwróciłeś na to uwagę w komentarzu i artykulik o te wiadomości uzupełniłeś. Masz ode mnie plusa

Z tego co wiem oficjalnie na stronie firefoxa nigdy nie było wersji 64bit dla Linuksa (takie wersje są kompilowane przez twórców pakietów dla dystrybucji i tak też tym razem będzie). Z tego powodu też flash 64bit powstał na linuksa, a na windowsa jeszcze nie (tylko oficjalne firefox 32bit i 32bit IE)... teraz akurat nowej wersji flasha jeszcze nie wydali w wersji 64bit dla linuksa.


x64 to oznaczenie Microsoftu na systemy 64bit na arch x86_64 (a bez niczego oznacza ze jest na x86_32)


PAE pozwala na adresowanie 64GB na systemie 32 bit (PAE + 64bit to max 64-128 TB jeśli dobrze pamiętam), ale dla całości pamięci. Dla Windowsa jest to zależnie od wersji od 1 do 64gb (np w W7 obsługuje maksymalnie 4gb).
Program jednak nie może użyć więcej niż niewiele ponad 3gb - powodem tego jest arch 32bit gdzie można adresować tylko 4GB pamięci na proces (tego nie zmienia PAE - ono robi tylko z pamięci warstwy i wybiera na której będzie działać process (a process może już tylko korzystać z pamięci tej 'warstwy"), oraz tego, że x86_64 przeznacza na system 700mb (tego się nie pozbędziesz - tak działa x86 i nie zniwelujesz tego za pomocą PAE). Co więcej w przypadku Windowsa 32bit program potrafi się wywalić gdy potrzebuje więcej pamięci niż 1.3GB (max 2gb na proces ma ograniczenie minus 700mb dla systemu - tylko w systemie 64bit i programie 32bit korzystającym z LAA może użyć 4gb (a dokładniej trochę ponad 3 ;p)).

Podsumowując PAE tu nic nie zmienia (system więcej obsłuży pamięci, ale proces FF dalej będzie mógł używać max 3.3gb (w wypadku 64bit systemu i jeśli exe będzie LAA, a jeśli nie to 1.3GB - linux i jego format ELF 32-bit nie mają tego problemu)) - zmienia się tylko maksymalna ilość obsługiwanej pamięci, a nie ilość pamięci, na proces.


A co to niby tu zmienia? Programiści kompilatorów od powstania arch x86_64 pracują nad optymalizacją kodu dla tej arch - dzięki temu ten sam kod (np. w C++) kompilowany np. w GCC dla x86_32 i x86_64 jest zupełnie inny, i dużo szybszy w wypadku 64bit (dodatkowo można od razu ustawić SSE3 jako minimum w kompilatorze (akurat tu dużo nie przyspieszy bo słabo kompilatory optymalizują z użyciem sse, i aby byl dobry skok to trzeba recznie, ale minimalnie może przyspieszy)). Nie trzeba specjalnie optymalizować kodu pod x86_64 skoro robi to za nas kompilator (w taki sam sposób jak robi to dla x86_64 od lat - mało kto dziś pisze w asm, a jeśli już to przeważnie dlatego, że musi lub nie ma dobrego kompilatora na dany arch żeby odwalił robotę za programistę ;p).

PAE gowno daje za przeproszeniem

http://www.phoronix.com/scan.php?page=arti...2_pae&num=1
kilka stron testow, zapraszam do czytania

Jak widać na przykładzie linuxa,co z tego że przeglądarka jest 64bit,jak takie popularne pluginy jak flash nie są......

Ekhm śmiem się nie zgodzić z tym stwierdzeniem bo akurat flash x64 dla linux'a jest. Sam używałem go kiedyś (hmmm 2 lata temu?).

64bit flash pod linuksa masz tu:
http://download.macromedia.com/pub/labs/fl...86_64.so.tar.gz
Adobe nie wydał oficjalnie, ale dał wersję prerelease na swoich stronach labs.


Akurat na przykładzie linuksa adobe wydało wersję dla 64bit (co przekonało dużo osób, aby przestali korzystać z 32bit przeglądarki i NSPluginWrapper (program umożliwiający korzystanie z bibliotek 32bit pod przeglądarką 64bit)). Gdyby NSPluginWrapper nie istniał 64bitowe przeglądarki nie byłyby popularne... a adobe nie miałoby powodu aby pracować nad wersją 64bit.
Na windowsie nie ma podobnego narzędzia do NSPluginWrapper dlatego dalej praktycznie 100% to 32bit przeglądarki i adobe nawet nie myśli o wydaniu wersji specjalnie dla x86_64.
Podsumowując gdyby nie możliwość wykorzystania pluginów 32bit w przeglądarce 64bit pod linuksem dalej wszyscy korzystaliby z 32bit przeglądarki (czy nawet systemu). To pokazuje, że te pluginy jak flash mają olbrzymią popularność i nie można jej lekceważyć.

A mi nie. Sprawdź dodatki.