Nem látom, hogy hol a probléma a K3b 100MB-tos memóriafogyasztásával (bár majd lemérem). Addig kibírod, míg lemezt írsz, még 1GB RAM-os gépen is, legfeljebb addig kevesebb mindent futtatsz a háttérben. Úgyse futtatod egész nap, legalábbis átlag usernek nem ez teszi ki az egész napját.
A parancssoros meg a TUI-felületes alternatívák is életképesek, sokkal minimálisabb erőforrást kérnek, ami neked szent, másrészt megvan az az előnyük, hogy paraméterekkel hívod meg őket, és nincs az a veszély, hogy valamire félrekattintottál. Egyébként meg ha most CD/DVD-t kéne írnom, Double Commanderhez lehúznám az .iso-plugint, kijelölném az anyagokat, amiket bele akarok tenni, létrehoznám az iso-lemezképet, amit valami parancssoros kis utillal kiírnék lemezre. Ha egy bloatware alkalmazást sokoldalúan használsz, több másik alkalmazást vált ki, így a rendszered összességében kevésbé lesz bloat. Ugyanez mondható el a Linux egészéről, az egész rendszer összességében sokkal kevésbé bloat.
Sokan ekézik a KDE-t meg a Qt-s alkalmazásokat a memóriaéhség miatt. Ha letiltod a KDE-ből az Akonadit meg a Nepomukot, felére esik vissza a memóriafogyasztása (némi desktop effect tiltásával meg még tovább csökkenthető). Másrészt a Qt-libek a KDE-vel alapból betöltődnek, shared libként vannak használva, az összes futó Qt-s alkalmazás ezeket használja (átfedések lesznek a használt memóriamennyiségben), így az összkép már sokkal kevésbé lesz bloat, a K3b fogyasztása is kisebbnek tűnik ezután, a fogyasztása jó része beleolvad a rendszer memóriafogyasztásába. Jó, nyilván, P3, P4, Atom CPU-s gépekre továbbra sem való, csak egy példa.
Ugyanez a helyzet a webappoknál. Bloat, kell hozzá memóriaéhes böngésző, de egyrészt fut minden gépen, és ha emellé nem kell új alkalmazásokat nyitogatni meg telepítgetni minden szarért, akkor az össz memóriafogyasztásra vetítve egyből jobb lesz az összkép. Továbbra sem P3-ra való megoldás, de nem annyira tré, mint amennyire leekézed, és a fejlesztők dolgát megkönnyíti, hogy nyílt szabványokkal dolgozhatnak (meg nem kell Asm-es optimalizációval kínlódni), és a produktum mindenütt ugyanúgy fog futni, függetlenül böngészőtől, OS-túl, architektúrától.
Ha ezt a gondolatmenetet tovább visszük, tovább látunk az XP-nél, meg a Nerónál, meg a GDI-nél, akkor arra is rájöhetsz, hogy manapság a sokféle fájlformátum, programnyelv, protokoll is anno azért jött létre, mert valaki azt gondolta, hogy a saját igényeire jobb, kevésbé bloatabb, egyszerűbb megoldást tud írni. És írtak is, a saját felhasználási területükön tényleg jól teljesítő megoldásokról van szó, de összeségében gányolások, amik ha nem koptak ki, ma már csak teherként vannak jelen, ha támogatni kell őket, akkor feleslegesen növelik a kódméretet, nehezítik a hibakeresést és karbantartást. Közben meg ha van egy rendes, univerzális szabványos formátum, nyelv, amiben minden szükséges építőelem támogatva van, mindenki tudja használni, senkinek nem kell megint feltalálni a kereket, meg házi gányolásokat írni, a szabványra írt megoldások egymással is kompatibilisek lesznek (pl. egyik szoftver addonjait vagy codecjeit egy másik is fogja tudni használni, vagy több program/platform is tud szabványos protokollal kommunikálni). Cserébe bloatabb lesz, lehet nem megy C64-en meg P3-on, de mégis ütőképesebb, komplexebben használható rendszert eredményez, mint a sok ASM-ben összegányolt, szerinted marha optimális tákolás.
Példa utóbbira a DOS-os Volkov Commander. Eleinte 63KB, majd 93 KB-ban hozta a Norton Commander funkcionalitásának nagy részét. Gondolom szimpatikus megoldás, de ha belegondolsz, evolúciós zsákutca, nem véletlen, hogy a szerző nem hozott ki újabb megoldást. Mivel ASM-ben íródott, ezért csak 16 bites DOS-t meg x86-ot támogat, meg FAT12-16-ot, semmi hálózati protokollt vagy plugint, 1-1 nyelven tudott a felülete. DOS-on sem maradt népszerű, mert jött a Dos Navigator, amiben Szásáék beizzították az OOP-t, emiatt könnyen fejlesztve verte funkcióban az összes korábbi megoldást, igaz bloatabb lett, de sokkal több mindent tudtál vele csinálni, majdnem egy TUI-s mini OS-sé nőtte ki magát. Hosszas sikere mégse volt, gyorsan jött a Windows térhódítása a DOS-os PC-ken, Windows alatt ott az OOP-s API a grafikus felülethez, fájlműveletekhez, sokkal könnyebb konzisztens kinézetű kétpaneles fájlkezelőt készíteni, ami jobban is néz ki, meg nem kell minden részét leprogramozni, az OS sok mindent nyújt hozzá, ideérte a hibakezelést is. Nem véletlen, hogy a Windows Commander meghaladta a DOS Navigator méretét, aztán ahogy fejlődött, több funkció került bele (FTP, kábeles adatátvitel, képnéző, stb.), több nyelvet támogatott, majd Total Commanderként ment át 32, majd 64 bitre, úgy lett egyre bloatabb, hasonlítsd össze tudásban a VC-hez képest. Persze még mindig ott a baj, hogy csak Windowst támogat, meg x86/x64-et (igaz van Androidra is, de annak csak a neve Total Commander, egész más a koncepciója meg a kezelőfelülete), a nem windowsos fájlrendszerek közül is csak néhányat támogat plugineken keresztül. Ezért rittyentettek megint csak Ukrán Igorovicsék (ez valami szláv hagyomány, úgy néz ki) Double Commandert, egyből kétféle frameworkre is ráépítve (Gtk/Qt), működésben a TC-t másolva, támogatja pl. a TC pluginjeit, amik ma már kvázi szabványnak számítanak, emiatt könnyű és olcsó hozzá plugineket, viewereket fejleszteni, így mások is könnyen beszállhatnak a fejlesztésbe, a nyílt forrás, bugtracker, verziókövető rendszer miatt a projecthez magához is könnyebben hozzájárulhatnak. Bloat, de minden platformon, architektúrán, rendszeres mountolható fájlrendszeren megy. Emiatt használhatod ARM-es okoskenyérpirítón, de nem lepődnék meg, ha androidos portja is lenne előbb-utóbb. Igaz mobileszközre meg tapiképernyőre nem való, ezzel csak a fejlődést akarom szemléltetni rugalmasabb irányba. A Volkov gyerek ezért nem ír újabb commandert, nem azért, mert elfelejtett programozni, hanem a mai megoldásoknál nem tudna egyedül jobbat írni, meg az ASM-es csodaoptimalizációval sem nyerne a mai gépeken semmit, cserébe sok ponton tökönlőné magát fejlesztésügyileg, nem bírná a versenyt. Biztos ezen a ponton mondod, hogy jó, de neked a Double Commander absztraktságára semmi szükséged nincs, P3-on, Windows alatt fusson gyorsan és kész, más nem érdekel. Na, ez a szűk látókör, az IT nem egyenlő windowsos PC. Lehet ezt a commanderkérdést még tovább fokozni. Nem lepődnék meg, ha a jövőben nem csak a pluginek felülete, meg az OS API-kon keresztül a GUI lenne szabványosítva, hanem létrejönne valami egységes commanderscript-nyelv, így egy plusz keretrendszerrel, némi alap scripttudással olyan commanderös fájlkezelőt rittyenhetnél össze, hogy kacsalábon forog, nem hogy 2-4, hanem akár 20 panellel, mindenféle protokollok közötti átvitellel, nézetekkel, regexpes szűrési lehetőségekkel, szabad makrózhatósággal. Ha neked ez sok, akkor csak azt tennéd bele, ami neked kell, úgy kicsivel gyorsabb lenne a nagyobb megoldásoknál. Persze az egész sokkal bloatabb lenne teljes funkcionalitás mellett, foglalna 100 MB memóriát, de micsoda lehetőségeket nyitna ki, és milyen messze jutunk a Volkov Commandertől. Ugyanez lezajlott plain text szövegszerkesztőknél, egy egyszerű nano-szinthez képest pl. milyen komplexitásig fejlődtek a nagyok (pl. Vim, CommodoEdit, vagy az egyes IDE-k), kész scriptnyelvvel, a Emacs konkrétan mindenféle scriptekkel és pluginekkel kvázi komplett OS-sé nőtte ki magát. Nem is véletlen ekézik azzal a Emacset, hogy túl bloat, és ezzel joggal vitatkoznak a fanjei, hogy mai gépeken már nem az, mai hardvereknek meg sem kottyan az a tétel. Nyilván, akinek ez sok, használ egyszerűbbet, de akinek több kell, mint a Nerós Winpisti1.0-nak, annak van mihez nyúlnia. Ezen a végső szálon pedig visszakanyaroduk a P3-hoz: ilyen hardveres és architekturális korlátozásokkal nem engedheted meg, hogy nagy igényeid legyenek, meg TC funkciód meg P3-on futó x265-öd legyen, mert nem lenne fenntartható a fejlesztésük P3-ra meg 256 MB RAM-ra (kivételes mázli, hogy a TC még támogatja az XP-t, de nagyon valószínű, hogy nem fogja már sokáig. ahogy már a Win3.x-et és 9x-et rég nem támogatja). Ha egy-két fejlesztő meg is próbálkozna optimalizált megoldásokkal, hosszú távon nekik sem érné meg ilyen alapokra fejleszteni, eleve bevételi forrás sincs egy ilyen régi platformból, nem gazdagék használnak ilyet, jótékonykodni, meg ingyen dolgozni meg nincs mindenkinek ereje.
A böngészők is rég kinőtték már azt a szintet, hogy http-n HTML-doksikat böngészgess rajta. Kisebb OS-ek lettek, scriptnyelvvel, mindenféle leírónyelves formátumot támogatva (XML, SVG, MathML), stream/médiaformátumokat, addonokat, plugineket (Flash, Java, Silverlight, VLC, DRM), különféle protokollokat támogatva, titkosítás, webfontok és tipográfiai megoldások, ráadásul ezekből párhuzamosan mindjárt több verziót is kell támogatnia, mivel hajbazer-félék eldöntötték, hogy nekik a HTML3 meg a nem szabványos, gányolt IE-kód is elég, mert az nem bloat, meg Netscape alatt még ment 1995-ben, annál kell maradni, másnak sincs szüksége többre, rohadjonmegahátéemel5. Aztán mérgelődsz, hogy a böngészők milyen bloatak, meg szemét idealistakapitalistaextraprofitosok, bezzeg az IE6 milyen gyorsan futott, miért nem optimalizálnak. Azért nem, mert nem fognak egy olyan platformra optimalizálni, amely már a weboldalba ágyazott 1080p-s videótól meg 10 ezer soros webes táblázattól letérdel, vagy adott esetben bele sem fér a memóriájába, és a háttértechnológiákat (amelyeket nem nyújt a régi OS) nekik kell egyenként beletenni. Ilyen rendszereket már csak álmodozó hobbisták használnak max (milyen szépek voltak a régi idők, belefért minden 64KB-ba című sóhajtozással), nincs vele komoly céljuk. Plusz ők azok a réteg, akik pénzben sem hozzák vissza a fejlesztési költségeket, nem csak új gépre, de szoftverre is sajnálják a pénzt.