2026 végén megszünteti a Mozilla a Firefox 32 bites verziójának támogatását

Mozilla

Ma azonban a 32 bites Linuxot már nem támogatja széles körben a Linux disztribúciók túlnyomó többsége, a Firefox karbantartása ezen a platformon egyre nehezebbé és megbízhatatlanabbá vált. Annak érdekében, hogy erőfeszítéseinket a lehető legjobb és legmodernebb Firefox szállítására összpontosítsuk, a Firefox 144-es kiadásával megszüntetjük a 32 bites Linux támogatását (másképp fogalmazva: a Firefox 145 már nem fogja támogatni a 32 bites Linuxot).

[...]

Azok számára, akik nem tudnak azonnal áttérni, a Firefox ESR 140 továbbra is elérhető marad — beleértve a 32 bites kiadásokat is —, és legalább 2026 szeptemberéig biztonsági frissítéseket fog kapni.

Bejelentés itt.

( carlcolt | 2025. 09. 07., v – 09:22 )

Na egy kiveteles topik, ahol nem fogok hajbival egyeterteni. ;)

Én meg egyet fogok. Kivételesen megint. Valami mainstream böngészőt meghagyhatnának 32 biten, nem baj, ha nem kap új feature-t, csak ne legyen sechole-os. Lehet az felőlem valami fork is, Pale Moon vagy hasonló, de ne zárjuk ki azért teljesen a 32 bites gépeket. Igen, muzeális retró, de akinek van, és akarja még járatni, az tudjon már valami böngészést is művelni rajta. Teljesen ne lehetetlenítsék el, egy 32 bites böngésző meg egy normális modern 32 bites OS az alap lenne azért. Mindennapos felhasználásra természetesen én sem ajánlom a 32 bitet senkinek, a 64 bites gépek is filléresek már, haladjunk a korral.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Mert miért? Írtam 4 és fél sort, nehogy az már sok legyen. Ez egy fórum, nem chat, hogy csak egy sorosakat, meg egy szavas reakciókat lehet írni.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Retrózásra minek modern OS meg secfix a böngészőbe? Ott nem a retrózás a lényeg? A retrózás pedig nem production, tehát tök mindegy, hogy modern-e az OS meg van-e biztonsági rés. C64-re meg Amigára sem ad ki senki folyton firssítést meg hibajavítást, mégis használja akinek van, arra amire anno szánták...

Aki ilyen régi gépen akar ilyesmit (friss rendszert), az nem retrózik, csak retrózásnak mondja a rettentő spórolást és lustaságot... Ugyanis vannak 15-20 éves 64 bites gépek kvázi ingyen, ha valakinek az fájna, hogy nem akar régi gépet kidobni/újat venni/stb.

Azért fontos a modern böngésző, mert a végén úgy jársz, mint a 98, ahol már meg se nyílnak a weboldalak, mert olyan új titkosításokat találtak ki, ami már nem elérhető, és visszafele nincs kompatibilitás - vagy csak nagyon kevés weboldalnál. Még az XP is necces asszem.

Sajnos az internet sokkal bonyolultabb lett, mint a retró idejében volt.

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

( blueghost | 2025. 09. 07., v – 10:50 )

Szerkesztve: 2025. 09. 07., v – 10:54

Emellett még hír, hogy az esr115 jövő márciusig támogatott. (windows 7,  8, 8.1)

( ggallo | 2025. 09. 07., v – 11:14 )

Felmerült bennem az a kérdés, hogy mivel a fejlődés elkerülhetetlen is, szükséges is és jó is (persze a túlpörgetett fejlődés nem jó, de ez más téma), ezért érdekelne, hogy aki szerint gond az ilyen régi technológiák támogatásának megszűntetése, azok szerint kinek kellene finanszíroznia ezek folytatását?

Merthogy valószínűleg eléggé sok erőforrást visznek el, azért szűntetik meg. Ha csak annyi lenne, hogy lefordítja a CI/CD automatikusan 32 bitre is, akkor örökre velünk maradhatnának, de biztosan nem így van.

Csak 22 éve, de amúgy jogos. Igazából csak teher a sok 32 bites csomag meg lib fordítgatása, és a cuccukat 32 biten hagyó lusta fejlesztőket próbálják motiválni a 32 bit ellehetetlenítésével. Sajnos a Valve is ott tart, hogy a Steam, meg sok újra lefordítható játékok 32 biten ragadt.

A másik, ami miatt a 32 bitet elkezdték egyre agresszívebben irtani, az a Y2038 problematikája, mikor túlcsordul az előjeles 32 bites unixtime. Erre nem kell 2038-ig se várni, mivel sok alkalmazás máris számol jövőbeli dátumokkal.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Az x86_64 valoban nem olyan regi. Viszont az Irix mar joval regebb ota 64 bites volt (persze azota megszunt).

In October 1991, MIPS announced the first commercially available 64-bit microprocessor, the R4000. SGI used the R4000 in its Crimson workstation. IRIX 6.2 was the first fully 64-bit IRIX release, including 64-bit pointers.

To secure the supply of future generations of MIPS microprocessors (the 64-bit R4000), SGI acquired the company in 1992[49] for $333 million[50][51] and renamed it as MIPS Technologies Inc., a wholly owned subsidiary of SGI.

Aztan ott volt a DEC Alpha, az 1992-es.

Szoval egy ideje mar vannak ilyesmik. Az AMD-fele 64 bites kutyuk persze ujabbak ennel. Az Intel az Itaniumban latta a jovot, aztan ok is atalltak erre. Az ARM64 meg ujabb.

A strange game. The only winning move is not to play. How about a nice game of chess?

Ja, 2003-as az x86_64, akkor jött ki az első AMD64 proci, de a specifikáció már 1999-től létezett. Előtte is volt valóban 64 bites proci, nem csak azok, amiket írsz, hanem az 1975-ös Cray1 is 64 bites volt már, meg még előtte IBM 7030, CDC Star 100. 

Az a baj, hogy x86 fronton nagyon lassan reagáltak a fejlesztők a 64 bitre, meg a többszálúságra is, hiába volt 2003-tól x86_64, sokáig nem támogatta semmi a Linuxon kívül, meg a 32 bites csotrogány gépek is lélegeztetőgépen tartották, főleg olcsó notebook, netbook, kevés, odaforrasztott fél-1-2 giga RAM-os hulladékok, amikben a proci hiába volt 64 bites, a kevés RAM-on nyögött a 64 bites rendszer. Nagyon sokáig az XP népszerűsége és a Vista népszerűtlensége is aláásta a 64 bit terjedését. Túl sok haladékot adott a 32 bitnek az is, hogy a MS a Win10-ig bezárólag támogatja most is, és csak a Win11-re avultatta ki, ezt az Apple már 13 éve meglépte.

Mostanra már minden dobta a támogatását, Linux kernel még támogatja, meg néhány nem mainstream Linux disztró (Gentoo, Slackware, Arch32, Void), illetve az Open/NetBSD támogatja és kifújt, a többiek mostanra szanálták a 32 bitet, nemrég a FreeBSD, Debian. Plusz az alternatív OS-ek, Haiku, ReactOS, stb. még támogatja.

A szoftveres ökoszisztéma is olyan bloat lett, hogy a 32 bites 4 gigás címtér, meg az azon belüli 2 gigás kernel és 2 gigás user space korlátba már sok minden nem fér bele, nem fog nyújtani túl jó felhasználói élményt amúgy se. Se a JS/node hegyek, se a konténerizált, virtualizált cuccok nem futnak jól annyi memóriával. Igen, van a PAE, egy csúnya hack, de azt se minden támogatja.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

... ami valójában még mindig tud 32 bitet, szóval szerintem meg nem. Azon felül, hogy pl ez az unix time-os cucc működik, nem sok különbséget látok a 32 és a 64 bites platform között. Ja, igen, egyre kevésbé támogatják - de igazi indoklást még nem láttam rá, hogy miért. Az, hogy régi, nekem nem érv.

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

Igen, bármit lehet csinálni, van a Linux kernelben is hack a túlcsordulás ellen, de nagyon sok legacy 32 bites program ezt nem támogatja (szerk.: mivel kézzel be van drótozva ezekbe, hogy 32 bites az időbélyegző, így a Linux kernel hiába is oldaná meg, nem tudja). Ez csak egy indok a sok közül, hogy miért irtják.

Persze, ezt nem is tagadta senki, 32 bites gépen, 32 bites rendszeren futó 128 bites emulátorban akár 128 bites OS-t is lehet futtatni, csak hát minek. Kérdés mennyire lesz használható, milyen overheadje van, stb..

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Azt a 128 bites emulált OS-re írtam. Nyilván egy 64 bites számlálónak nincs nagy overheadje, ezt a Linux és főbb BSD kernelekben meg is oldották már, viszont meg egyszer leírom, mert nem akarjátok érteni: nagyon sok régi alkalmazásban int32-ként van definiálva az időbélyegző, így van fixre drótozva, ezen a kernelhack nem tud segíteni. Ezért irtják a 32 bitet, mert a sok 32 biten ragadt gépen pont ilyen 32 bites gányolt, fixre drótozott megoldás fog gondot okozni, pont ezek miatt használják. Ha a 32 bites rendszert kilövöd alóluk, akkor kénytelenek más megoldás után nézni.

A másik meg az erőforrás-hatékonyság. Amíg sok 32 bites alkalmazás túlél, mert van neki 32 bites support, ha más nem 64 bites rendszeren 32 bit multilib, akkor sose fogják átportolni 64 bitre. Miattuk lehet a függőségi fában egy csomó csomagból 32 bites változatot is forgatni, fenntartani, meg 64 bites rendszerek ezek nem tudják a 64 bites függőségeket használni, hanem megduplázta az erőforrások felhasználását, betöltik a 32 bites változatát is a libeknek.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

>sok 32 biten ragadt gépen pont ilyen 32 bites gányolt, fixre drótozott megoldás fog gondot okozni

Erre azt mondanám, hogy ez legyen azoknak a problémája akik ilyen alkalmazásokat futtatnak. Szerintem sokkal kisebb munka egy alkalmazásban csak az időkezelést megjavítani, mint mindent 64 bitesíteni. És teljesen ésszerű és életszerű. Ráadásul van egy rakás lib, ami nem is kezel időt, azokat miért kell feltétlenül upgradelni.

Teljesen fals érv az, hogy egy lehetséges hibaforrás miatt töröljünk el egy egész architektúrát, amikor pontosan tudjuk, hogy ementáli sajt az egész mindenség PC-n, tele van hibákkal. Pont az a bajunk, hogy "el lehet rontani" az időkezelést, ha valaki akkora retardált, hogy 32 biten tárolja a másodperceket 2025-ben??? Ha valaki retardált, akkor bármilyen platformon bármilyen hibát tud okozni. Sőt, 64 bites architektúrán is beleteheti az időt egy uint32_t-be. Hiszen aki retardált, akármit megcsinálhat. Nehogy már ez legyen az ok.

>A másik meg az erőforrás-hatékonyság.

Sokszor a 32 bites program sokkal hatékonyabb. Azért mert a struct alignment 32 bites, illetve a pointerek fele akkorák. Így a program RAM használata jelentősen kisebb lehet. És ami még fontosabb, hogy a hot adathalmaz esetleg éppen ezért fér bele a cache-be, amiből 64 biten már kilóg. Ott pedig többszörös sebesség visszaesés lehetséges amikor hirtelen kevés lesz a cache.

Két dolog van amivel messzemenően nem értek egyet:

 * A 32 bit erőszakos eltüntetése. Nekem sokkal inkább politikai döntésnek látszik, mint ésszerűnek.

 * A gcc fordítóban mások az alapértelmezett int típus méretek 64 biten mint 32 biten. Szerintem ez volt az ősbűn. Ha megtartották volna az eredeti méreteket 64 biten is, akkor erőfeszítés nélkül lehetne portolni a programokat. Ha belegondolunk semmi értelme nem volt a típusokat megváltoztatni. Sőt IMHO a Microsoft nem is változtatta meg a saját fordítóival. Ebben szerintem jobb döntést hoztak.

Kb. ugyanazt írjuk. Én is erre akarok rávilágítani, hogy mi motiválja ezt a modern trendet, ez nem jelenti azt, hogy én egyetértek vele. Pont azt írom én is, hogy a 32 biteseket nem kéne teljesen ellehetetleníteni. Az nem baj, ha mainstream disztrók, kereskedelmi OS-ek dobják, de valami járható, másik utat (alternatív rendszert, használható böngésőt, stb.) hagyni kell a 32 bites usereknek, nem kéne őket teljesen ellehetetleníteni.

Abban is igazad van, hogy elméletileg 64 bites rendszeren is lefordul az a 32 bites gány kód, ami fixre drótozott uint32-őt használ időbélyegzőnek, de annak az esélye, hogy valaki ilyet próbál lefordítani-használni 64 biten, elég minimális, meg csak 32 bites programokra jellemző, de ha az egész 32 bitet dobják, akkor ennek az ügyeskedésnek az elejét veszik. Gyökerénél irtják ki a problémaforrást.

Az egyetlen, amiben nem értek egyet, hogy a 64 bit 64 bites rendszeren, szinte mindig hatékonyabb, nagyon kevés az a minimális, hello world méretű kód, ahol nem. Ugyanis 64 bites rendszeren hiába kétszer akkorák a pointerek, de a fordító jobban tud optimalizálni, mivel egy regiszterbe sokkal több adatot be tud gyömöszölni, és arra vektorutasításként hívni meg a műveletet. Ha egy 64 bites kód szuboptimális a 32 biteshez képest, ott a fordító nem végzett jó munkát.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

>a 64 bit 64 bites rendszeren, szinte mindig hatékonyabb

Mérted? Én úgy tapasztalom PCn, hogy ha egy programot elkezdenek optimalizálni, akkor a Ram sávszél és az Os hívások kontextusváltása a szűk keresztmetszet többnyire. Persze azon múlik mi a feladat, de ez a tipikus. Főleg objektum orientált cuccoknál, mint Java, Python stb ahol minden _is_ pointer.

Bár egy mono32 -> legújabb 64 bites dotnet átállásnál én is kimértem jelentős gyorsulást.

De ahol már eljutnak idáig, hogy ez számít, az már úgyis gyors. Ami meg elment egy 32 bites procin, az elmegy a maiakon is. A teljesítmény se valid érv a legacy 32 bit ellen.

Nem mértem, de javarészt így szokott lenni, nem csak a mono32-dotnet64bit esetén.

Ahogy most nézem, az OpenBSD-sek sem gondolják komolyan a 32 bites támogatást, az oldaluk azt írja, hogy: „only easy and critical security fixes are backported to i386. The project has more important things to focus on.” Tehát ők sem veszik komolyan, így már csak a NetBSD maradt, meg egyes nem mainstream Linux disztrók. De már a Linux kernel sem teljes értékűen támogatja, 386-486, korai nem Pentium 586-ok máris dobva lettek, csak Pentiumtól felfelé 586-686 az, amit támogat a kernel, de még sok 32 disztró ott is PAE-t, meg esetleg SSE2-t ír elő, azaz min P4, K8 Sempron és felfelé játszik. Ez nekem máris csak félig támogatás.

Sőt, már a NetBSD-sek is azt írták a redditen, hogy ők soha nem dobják, de csillagozott apró betűs részen megjegyezve, hogy feltéve, ha van hozzá karbantartó, aki vállalja, mert ahogy nincs, akkor náluk is bukta lesz.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

>Nem mértem, de javarészt így szokott lenni

Azt javaslom, hogy ne hidd el sose a lózungokat amit mások mondanak, és mérj! Az informatika tele van jól hangzó lózungokkal aminek a fele se igaz. És nem azt mondom ezzel, hogy ez nem lehet igaz, hanem azt hogy vagy igaz, vagy nem, meg kell mérni! És várhatóan a program természetén múlik, hogy gyorsabb-e a 64 bites.

A dotnet64 esetén igaz lehet, hogy a sok regiszter segít, de az is benne van a pakliban, hogy nagyon jó csapat van mögötte (állítólag - nem mértem :-) ), akik nagyon sokat foglalkoztak az optimalizálással. Ezzel szemben a Mono nagyon szépen megcsinált projekt, de nem volt annyira fókuszban az optimalizálás.

(Mivel ASM-et ad ki magából a dotnet VM elhiszem azt is, hogy 32 bitre is portolni az erőfeszítésüket legalább dupla munka lenne. Ez nem olyan, mint lefordítani ugyanazt a kódot -m32 kapcsolóval. Ezért a Linuxos dotnet esetében meg is bocsátom, hogy nincs 32 bites verzió belőle - bár egy darabig volt, de egy ideje nincs.)

Nem hittételi alapon megy. A 64 bites rendszer összességében gyorsabb, saját érzésre, évek tapasztalata. Mondom, ez amit írsz, ilyen hello world komplexitású programokra lehet igaz, vagy bare metal rendszeren, de pl. amikor dinamikusan linkelt függőségekről van szó, vagy jól optimalizáló fordítóról, ott a 32 bit szuboptimális lesz egy 64 bites rendszeren. A hello world komplexitású dolgok meg lehet pár %-kal nagyobb memóriát igényelnek, és lehet mondjuk 5%-kal lassabbak, de ezt úgy kell érteni, hogy 0,01ms helyett 0,0105ms alatt futnak le, amit emberi szemmel nem érzékelsz, viszont ahol meg a 64 bit gyorsabb, főleg komplex kódnál, annál meg jó eséllyel érzékelhető is lesz.

A 64 bitnek az egyetlen igazi hátránya, hogy valóban kicsivel több memória kell neki, de ez a 0,5-2 giga RAM-os gépek világában volt hátrány, ma már a 4 giga is ritka, minden gépben van 8-32 giga RAM. Ahol még a 64 bit hátrány, azok a régi procik, amiben még kevés cache volt, 0,5-1 mega, annál elképzelhető, hogy a 32 bites kód teljesen belefér, míg a 64 bitesnél nem. Ez is megoldott probléma ma már, a 8-192 mega cache-es procik világában.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Ezt a 32bites módot már a hw gyártók is elengedték, különben tudna a 64 bites cpu olyat 32bitre mint a HT, hogy egy 64bites szál két logikai 32bites szál lenne, a regiszterek alsó és felső 32bitjét használva, és akkor 32bites kóddal kétszer annyi thread lenne ;)

Benne van, de csak visszafelé kompatibilitásból. Mondom, 64 bites rendszeren ideális esetben 64 bites kódokat kell használni, amit normális 64 bitre fordító rendesen optimalizált, hogy a hardver ki legyen használva, a 64 bites libek rendesen meg legyenek osztva a futó 64 bites kódok között, és ne kelljen 32 bites változatot is külön betölteni belőlük. Mint írtam, a 32 bitet eddig is a hulladék, kevés RAM-os gépek, meg a zárt kódú 32 bites legacy szoftverek tartották életben, túl sokáig. Akinek kellenek még ezek, zárja emulátorba, virtuális gépbe, stb.. 

Most jött a hír a redditre is, hogy végre a Valve is összeszedi magát, és 2026 januárjától nem támogatja a Steam a 32 bites Windows-okat. Ez azt jelenti szerintem, hogy végre 64 bitre állnak át, így majd egy idő után Linuxon se lesz ez probléma, hogy a Steam miatt i386, lib32 kezdetű, 32 bites függőségekkel szívni.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Najah, nem mondom hogy nekem hiányozni fognak a friss böngészők 32bitre, de miért is nem annyi, hogy lefordítja 32 bitre is, egy böngészőben?

Egyszer nagyon rég jártam úgy, hogy öreg gép 32bites disztrib, ismerős megkért, hogy segítsek neki átköltözni 64bitre, hát hiába volt a firefox ugyanaz a verzió, csak 64 biten, nem tudta fájl szinten, se importálva átvenni a régi profilját. Persze nem most volt, de gyanakodni kezdtem a codebase-re:)

Mondjuk ami problémás, szerintem, hogyha még van támogatott OS 32bitre, akkor kéne hogy legyen rá támogatott böngésző is... de simán el tudom képzelni, hogy van a firefoxnak olyan függősége amiből 32biten már csak legacy build van, vagy már meg se csinálták, és innentől tényleg rajtuk kívül álló okok miatt macerás továbbvinni.

Különben ki finanszírozná? Hát a google. A firefox egyik legnagyobb bevétele, persze a mozilla foundationön keresztül, hogy a google az alapértelmezett kereső benne;)

( asch v | 2025. 09. 07., v – 11:21 )

Nen vagyok képben, fog maradni ezután támogatott x86 32 biten működő böngésző?

links2, dillo és hasonszőrűek. Ha nincs más lehetőség és le kell tölteni valamit vagy kell az infó a netről és csak és kizárólag 32 bites vasad van (elég nehezen elképzelhető edge case), akkor ezekkel még lehozod úgy ahogy. Normális böngésző ilyen gépen a mai teleszemetelt weben annyi eséllyel indul mint a 3 lábú sün a 2x3 sávos autópályán. 

Tudom, meglepő lehet, de egy Atom N570-es cpu-n, 2 GB rammal, 64 bites debian 13.1-el köszöni szépen, de egészen jól megy a webezés. Nyílván ismerem a gép korlátait, így nem várom el a fénysebességet tőle, de azért egészen kivárható mire betölt a chrome 140-es verzióval egy oldalt, sőt még Facebookot is szoktam nézegetni vele.

Na igen, de az N570 64bites, 2011-es proci. Amikről itt szó van azok 32 bites gépek, athlon xp-k, korai P4-esek és elődeik.

2003-ban már jött az első 64 bites amd proci, fogalmazzunk úgy hogy azok a gépek amelyek szembesülnek ezzel a problémával azoknak csókolommal köszön az N570 ;)

Nem, itt nem csak a 32 bites gépekről van szó, hanem sok odaforrasztott, kevés RAM-os vagy limitált, nem bővíthető tárhelyes 64 bites gépre is 32 bites disztrót szokás tenni. Pont ez utóbbiak, meg sok lusta fejlesztő tartotta el eddig a 32 bitet. Most pont ezeket akarják szanálni, lusta fejlesztőket meg rászorítani, hogy portolják a műveiket 64 bitre. Ami meg túl régi, zárt, 32 bites legacy szoftver, az menjen emulátorban.

Athlon XP egyébként sem érdekes, mivel azon rég nem lehet böngészni, SSE2 hiányában. P4-en attól függ. A koraiakon, s423-s478-asokon igen, de olyan lassú, hogy használhatatlan lesz úgyis (jó, talán a nagyobb órajeles, HT-s s478-asokon lehet), s775-ös, kései P4-eken azért még lehetett eddig, nem villám, de kivárható.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

2 giga ramos atom n450 netbookom köszöni szépen remekül érzi magát 64 bites debianon i3 ablakkezelővel, picom-al, abiword/gnumeric kombóval (LO-t is vinné de nincs szükségem rá, legalábbis ezen a gépen), moc viszi a zenét és a netrádiót, mpv a videót, links2/dillo-val van net (iso letöltés, random valami keresése ha kell), qview mutatja a képeket, xpdf a doksikat.

Nyilván nem elsődleges gép, de ha szükségem van egy olyan környezetre ahol zavarmentesen koncentrálhatok egy doksi megírására akkor ezt szoktam elővenni, fura mód a billentyűzetét is nagyon kedvelem.

Megfelelő feladathoz a megfelelő eszközt kell választani és működni fog, forrasztott 2/4 giga rammal bármelyik mai mainstream ablakkezelő kb az önszopatás kategória, csak valami light alternatívát érdemes beizzítani (innentől átlag usert ki is lökted a gép elől). De ha még az ablakkezelő nem is eszi meg az egész gépet vacsorára akkor a böngésző fogja, ha a mai webre ki akarsz engedni olyan gépet egy fullos böngészővel ami 4 giga ramot tud csak címezni akkor 3-4 izmosabb tabbal már el is vérzik a cucc, de egy kellőképpen legörgetett social media akár egymagában is fel tudja zabálni az egészet.

Azok a gépek amik tényleg csak 32 bitet tudnak azokat vagy be kell rakni egy elszeparált hálózatba célgép esetén, vagy retro érdekességként kirakni a polcra/teletömni korabeli játékokkal és örülni neki amíg nem pukkan el rajta valami amit már tényleg hülyeség cserélni.

( Sanya v | 2025. 09. 07., v – 12:47 )

Nem tudom, hogy mit fejlődött a böngészők az elmúlt 5 évben.  Valamilyen GPU támogás eddig is volt, most sincs igazi, de cryptobányász weboldalak léteznek.

Tiltják a reklámblokkolókat.

Ez a 2 hetente kiadok egy új verziót és annyi történik, jobb görgetés a bookmarkok közt...

https://www.firefox.com/en-US/firefox/142.0/releasenotes/