A szoftvergyártókat nem érdekli a RAM-fogyasztás; ESR szerint az open source OS-ek jobbak ebben

HUP cikkturkáló

Aakash Gupta:

A szoftver ugyanazért eszi a RAM-ot, amiért a gyárak régen vegyszereket öntöttek a folyókba. A költséget kiszervezik.

Minden egyes, modellfuttatáshoz, vagyis inferenciához kapcsolódó számítási terhelés megjelenik egy engineering manager AWS-számláján, centre lebontva, negyedévente felülvizsgálva. Minden egyes, a TE gépeden elfogyasztott RAM-mennyiség sehol nem jelenik meg senki költségvetésében. A Chrome holnap 60%-kal csökkenthetné a memóriahasználatát, és a Google bevétele egyetlen bázisponttal sem mozdulna.

A Docker 2 GB-os üresjárati lábnyoma a Docker Inc.-nek pontosan 0 dollárba kerül. Az Electron 500 MB-os teendőlista-alkalmazása az Electron csapatnak pontosan 0 dollárba kerül. A RAM-ot a felhasználó fizette ki. Az áramot a felhasználó fizeti. A ventilátorzajt a felhasználó viseli el. A cég gyorsabban szállít, mert azt a technológiai alapot választotta, amellyel a leggyorsabban és legkisebb erőfeszítéssel lehet szállítani.

A tokenoptimalizálási megszállottság ezt még világosabbá teszi. A cégek az inferencia költségét optimalizálják, mert az inferencia költsége közvetlenül rontja a nyereségességüket. El fognak tölteni hat hónapot azzal, hogy lefaragjanak 200 ms-ot egy modell válaszidejéből. Nem fognak eltölteni hat napot azzal, hogy csökkentsék egy desktop kliens memória-lábnyomát, mert az a memória valaki más hardveréhez tartozik.

Ezért csapda a 16 GB vs 32 GB vita. Azt kéred a fogyasztóktól, hogy drágább hardvert vegyenek, hogy szubvencionálják a szoftveripar vonakodását attól, hogy optimalizáljon egy olyan erőforrásra, amiért neki soha nem kell fizetnie.

A piac ezt magától soha nem fogja megjavítani. Azok, akik a csekkeket írják, és azok, akik kifutnak a RAM-ból, a tranzakció ellentétes oldalain állnak.

(forrás)

Eric S. Raymond:

Természetesen, ez igaz, és ez az egyik oka annak, hogy a nyílt forráskódú operációs rendszerek jobbak. Mert azok az emberek, akik ezeket a szoftvereket írják, valami másra optimalizálnak: olyan szoftvert akarnak előállítani, amelynek kiadását nem szégyellnék.

Ez a motiváció varázsütésre nem teszi őket jóvá UX-ben, amit nehéz optimalizálni, mert a UX-siker nehezen mérhető. A bloat és a lag viszont könnyen mérhető, és a nyílt forráskódú fejlesztők érzik ezt a fájdalmat, ezért elég hatékonyan küzdenek a bloat és a lag ellen.

(forrás)

  • 1576 megtekintés

( buccaneers v | 2026. 04. 01., sze – 16:18 )

"olyan szoftvert akarnak előállítani, amelynek kiadását nem szégyellnék."

Ebbe a feliratba verném bele az orrát pl. M$ -nak

( persicsb | 2026. 04. 01., sze – 16:23 )

valami másra optimalizálnak: olyan szoftvert akarnak előállítani, amelynek kiadását nem szégyellnék.

Hát ez baromira nem igaz az open-sourcera. Pont ESR Katedrális és bazár írásában van meg az a gondolat, hogy release early, release often, tök mindegy, milyen a minősége, majd idővel kijavul, hiszen minden bugra ott lesz a manyeyeballs.

http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/ar01s04.html

Csak azt felejti el ESR, hogy mindenki akkor foglalkozik egy szoftverrel kód szinten, ha érdekében áll. Ha nem áll érdekében, akkor aztán az open-source kód lehet egy karbantartatlan fos is, senkit nem fog érdekelni, nincs manyeyeballs.

altalaban a zart kodu programoknak a fejlesztese is pont olyan fos, mint amit irsz. Csak azok meg blackboxok is. 

A nagy cegek is minel elobb ki akarjak adni a programjukat akar bugosan szarul is, de jojjon be a penz (ugyanugy vannak a release early-vel is csak meg nagyobb a befekltetoi nyomas). Sot kinyomnak MVP-ket is teljes erteku program aron, tele bugokkal. Csak mint mondtam itt meg a kodot sem ismerheti meg az ember. :D

( Friczy v | 2026. 04. 01., sze – 16:40 )

Akárhogy nézem, nem látom, hogy a Docker üresjáratban ennyit enne.

( snq- | 2026. 04. 01., sze – 16:46 )

gupta hozott is 3 open source példát

( pink v | 2026. 04. 01., sze – 16:50 )

A szoftveripar arra optimalizál, hogy átlagos, darabra vásárolható programozókkal jól skálázhatóan, kiszámíthatóan tudjon fejleszteni. Ezért születnek a különféle keretrendszerek is.
A szoftverek életciklusa is sok esetben rövidebb, nem éri meg többet feccölni a fejlesztésbe. A lessons learnt megy majd a következő projektbe. Lehet, hogy már nem is annál a cégnél.

Kicsit pontosítanék, amire itt gondolnak az a tipikus desktop szoftver (és annak ipara), a szoftveripar ennél lényegesen szélesebb.
A desktop szoftvereknél a memóriaigény növekedése tény. Általában ennek sztem az az oka hogy nincs se igény se idő az optimalizálásra. A felhasználók elenyészően kevés részét érdekli ez, fel se fogják. Az újabb és újabb feature-ökért hajlandóak fizetni, természetes hogy az effort oda megy.

Nem azt mondom, hogy nem fizettek ennek vagy annak a vendornak. Azt mondtam, hogy vannak igenyek, amikhez vagy tartoznak, vagy nem tartoznak penzugyi forrasok (es hajlandosag ezen forrasok atadasara).

Mennyivel fizetnetek tobbet, ha a Microsoft faszabb W11-et gyartana? Elarulom, az atlag ceg valszeg semennyivel. Ha ti ennel galansabbak vagytok, akkor az szuper, de a MSFT reszvenyesek nem fogjak a sajat zsebukbol attenni a penzt a masokeba.

Mégsem váltasz. Mert neked (is, személy szerint) ez a legkényelmesebb, legolcsóbb.
Esélytelennek is látod hiszen "senki más nem akarja".
Esélytelennek is látod mert "azért még senkit nem rúgtak ki mert Microsoft-ot vásárolt". 
Esélytelennek is látod mert "minden más úgyis szar, legföljebb máshogy".

Ez a tanult tehetetlenség.

A Microsoft miért mondana le egy cent profitról is, ha ez marad? 
Meg vagy mérve, nincs okuk változtatni.

Azon gondolkozom, hogy a Microsoft ezt mennyire direkt csinálja, hogy egyre rosszabb és lassabb appokat ír? Hogy ami működött, azt is elrontja? 

Van valaki, aki előáll, hogy akkor írjuk újra Windows 11 esetén a nyomtatás kezelést, mert az a Windows 10 esetén egész használható volt. Majd akkor eldöntik: jó, akkor csináljunk pár úgy nézetet, de lehetőleg a régi nyomtatók random ne működjenek, ok? Erre csillogó szemekkel a programozók random késleltetést és random timeoutot kódolnak a meglévő kódba, a hibajavításokat kivágják és egy új felületen összetákolnak valamit, amit az Apple telefonjukon láttak.

Én így tudom elképzelni a Microsoft elmúlt 5 évét.

Vagy van egy szomorúbb lehetőség: a mostani programozók, akik ott dolgoznak, az átlagnál is rosszabb módon gányolják össze azt, amit nem is értenek. Az előző verzió sokkal szórakoztatóbb lenne, ha az eredmény ugyanaz is.

Nem kell foglalkozniuk vele, hogy jó alkalmazásokat írjanak. A corporate úgyis megveszi, mert nincs használható alternatíva, a részvényesek meg örülnek, egekben az árfolyam és a cégérték, azaz minden, ami fontos, az jó állapotban van.

Ha akár csak egy centtel többet fordítanának arra, hogy jobb appokat írjanak, az érintené a negyedéves pénzügyi jelentéseket, nem lenne ilyen magasan a részvényárfolyam. És csak a pénz számít, semmi más.

Nem arról van szó, hogy rossz emberek dolgoznának a Microsoftról, egész egyszerűen arról van szó, hogy szarnak bele, mert beleszarhatnak. A pénz megvan, minden más meg le van szarva.

Magára a Windows-ra is értettem. Lásd most is napok óta próbálom megjavítani a Windows 11et, de nem kerülök közelebb a megoldáshoz.

A Windows 11 semmilyen módon nem jelzi, hogy mi a baj, pedig szétfagy.

Vagy van ez a 

 A hiba oka: A pci.sys és a 0xc0000098 

hibaüzenet, ami mivel a file rendszer sértetlen, olvasható és ott van a pci.sys, a Gemini szerint:

"A hiba oka: A pci.sys és a 0xc0000098 (Boot Configuration Data hiba) gyakran akkor ugrik fel, ha a Windows a bootolás során elveszíti a kapcsolatot a tárolóvezérlővel. Lehet, hogy egy Windows Update felülírt egy Intel drivert, megsérült a fájlrendszer, vagy a BIOS/UEFI beállítások visszaálltak, és a rendszer nem tudja, hogyan kezelje a RAID 1 tömböt."

Tehát, hogy a Windows 11 a pci.sys-re hivatkozik, de közben az  Intel RAID (vagy Intel VMD) miatt van, mégis képtelen ezt kiírni? Hogy mennyire nincs ez sem jól megoldva, hogy legalább azt írja ki? A Taskbar óriási visszalépés, ha sok programot használsz, a játékok 10-15% lassabbak Windows 10hez képest azonos gépen a saját mérések szerint, de nem is sorolom.

Legális Windows 11, szólhatnál valakinek, aki a Microsoftnál ért a Windows 11-hez, hogy miként kell megjavítani.

Ha elindítom a Windows 11 setup részét pendriveról, akkor a régi Windows 11 meghajtót OEM reservednek látja, pedig be van töltve az Intel Raid hivatalos latest driver, hozzá van adva a pendrivehoz. Az is mekkora meló, hogy az intall.esd fájlt átalakítani install.wim fájlra, majd hozzáadni a drivert majd újra visszaalakítani esd fájlra és újra a pendrivera másolni, hogy alapból betöltsön egy drivert. Nem lehetne még komplexebben?

Nem is sorolom. Power userként a Windows 11 egyre távolodik a használhatóságtól. Óriási memóriaigény, sok cpu használat, csak hogy van egy gui. Windows xp vége után még a 7 jó volt a végére mielőtt megszüntették, de utána egy paródia ami van.

Hát, ez nem üzemeltetési oldalon dől ha kereskedelmi terméket fejleszt a céged a piacra. Ha a termék(ek) Windows kliensekre és szerverekre készül(nek), mert az arra való fejlesztési olcsó (lásd: költségek - pl. Windows licencek ára, RAM-bloat stb. kiszervezve a felhasználóra, erről szól a topik), akkor Windowst kell támogatni. Ilyen egyszerű ez. 

trey @ gépház

Mi faszom köze van a fejlesztőnek ahhoz, hogy a cég egy félkész fost akar kitolni, ha tetszik ez a fejlesztőnek ha nem. Sőt az ügyfelet sem érdekli sokszor, hogy működjön a szarja, csak tengerkék legyen az a kibaszott gomb és ha föléviszik az egeret csillagokat hányjon. A programozónak meg azért fizetnek hogy ezt megcsinálja. 

Maradj baszod a vmware meg Windows licenszeknél. :)

Mi faszom köze van a fejlesztőnek ahhoz,

Hát, mondjuk ha a fejlesztők úgy döntenek, hogy ők bizony csak Windowsra tudnak és akarnak kódolni ... mert szerintünk az a felsőbb szint ... ebbe beleértve a fejlesztésért felelős összes vezetőt ... hát kin múlik az akkor, hmm? 

Ha én 20+ éve pofázom segítő szándékkal - mert mondjuk nekem aztán semmi közöm nincs a fejlesztési divízióhoz, se annak stratégiai terveihez, meg úgy kb. semmijéhez -, hogy mondjuk Windowsról és MS SQL szerverről át kéne már állni Linux/Postgres kombóra, de süket fülekre talál, az kinek a hibája? Hmm? Mesélj, mesemondó! 

trey @ gépház

Az a baj, hogy most 90%-ban egyet értek Trey-jel.

Az én észrevételeim:
- Nálam a programozó != fejlesztő. A fejlesztő magasabb szinten áll az én értelmezésemben.
- Programozónak, fejlesztőnek tanácsot adni? Főképp a fejlesztők olyan magasan hordják az orrukat, mintha félistenek lennének.
- 1000-ből jó, ha 1 jó programozó, fejlesztő van.
- Utálom ismételni magam - nem tisztem 100x elmondani, hogy mi a baj a programmal. Fárasztó.
- Megfordultam már pár cégnél. Elég jó rálátásom volt / van a programozók, fejlesztők munkáinak minőségére. Trehány.
- Sokszor olyan problémákat akarnak megoldani a programozók, fejlesztők, amik nem is léteznének nélkülük.

a bibi csak, hogy keveri a kontextust, mindig össze-vissza beszél. 

Ő maga is leírja, hogy üzleti döntés miatt windowsra fejlesztenek.
https://hup.hu/comment/3270028#comment-3270028

A munkavállalók meg azt csinálják, amit a vezetők akarnak. Aki nem akarja azt csinálni, az vállalkozhat, csak üzletileg lehet nem fog sikerülni, mert üzleti döntéseknél nem a tökéletes kézműves termék hoz sok pénzt, hanem a szükséges minimumot az elérhető legdrágábban eladni, avagy profitért. 

Nem a programozó/fejlesztő hozza a döntéseket üzleti termékeknél. Van, hogy kifejezetten megtiltanak megjavítani valamelyik hibát, mert üzletileg úgy jobb a vezetésnek. Az is üzleti döntés, hogy nem jó minőségre képes és drágább programozókat alkalmaznak, az is, hogy nincs minőségbiztosítás és tesztelés.

Trey direkt keveri a kontextust. Így (is) pörgeti az oldalt. Ez neki nyereség minden szempontból.

Ohh, a munkavállalók.... A munkavállalónak van szája, keze. Elvileg tudja is őket használni. Csak egyszerűbb nekik a pocsolyában ülni és megalkudni a gagyin. Hiányzik a kommunikáció.
Az egyik legnagyobb baj, hogy az üzlethez sokszor túl későn jut el, hogy baj van a termékkel. "Miért van annyi telefonhívás?" "Miért van olyan sok ticket a ticketrendszerben?" "Miért hagynak minket ott az ügyfelek?"
Versenytárs nélküli piacon működik a "gagyi termék arany áron". Csak amikor megjelennek a versenytársak, akkor szokott jönni a Pikachu nézés.

Nem a programozó/fejlesztő hozza a döntéseket üzleti termékeknél.

Viszont van, kell, hogy legyen beleszólása a termékbe, amit megoszt a vezetőkkel, üzleti oldallal.

Van, hogy kifejezetten megtiltanak megjavítani valamelyik hibát

Sajnos láttam ilyet közelről. Többször is. Lehet mögötte racionális indok. Csak számomra elfogadhatatlan, amikor 5-10 évig (nem vicc, saját szememmel láttam!) tudnak róla, csak nem foglalkoznak vele. Ez nálam egyből leértékeli az egész céget, vezetőséget.

Az is üzleti döntés, hogy nem jó minőségre képes és drágább programozókat alkalmaznak, az is, hogy nincs minőségbiztosítás és tesztelés.

Tehát gyártják a digitális szemetet.

Lehet sokkoló lesz: 
Láttam már ilyet, amikor még a termék nem volt kész, nem volt piacképes még. Persze később se lett piacképes - többek között eme fejlesztési metódus miatt.
Egy másik esetben meg annyira nem jöttek visszajelzések az ügyfelektől, hogy a fejlesztők így generáltak maguknak munkát.

A desktop szoftvernél a legnagyobb probléma, hogy már szinte kizárólag Electron, vagy hasonló beágyazott-böngészős platformra dolgoznak, mert...  erre lehet könnyen fejlesztőt találni, mindenki typescriptben tolja, így webre, vastagkliensbe, windowsra, macos-re, linuxra, sőt telefonra is ugyanaz a kódbázis megy stb.

Ennek a mellékhatása, hogy egy üres ablak egy darab Hello World gombbal is sokszáz MB méretű és sokszáz MB ramot eszik. És sajnos ahogy a böngészők és az aktuális kedvenc webes frontend platform funkcionalitása hízik, úgy hízik minden alkalmazás is. 

Régóta vágyok én, az androidok mezonkincsére már!

Nem csak a programozás, hanem a stílusozás (CSS) is problémás az egyéb platformokon, mert nem ismerik a designerek. Szívtam már meg, ezért elhatároztam, hogy csak webet csinálok mostantól én is. A RAM-ot meg leszarom, a fejlesztői gépemben nyilván van elég, a usernek meg legyen elég :-).

A Windowsos GUI-k csak Windowson működnek, nem tudok jó cross platfrom API-ról.

Vagy ott vannak a Java GUI frameworkök. Az SWT lemaradt az előző században. A JavaFX kikerült a JRE-ből, és harmadik féltől kell beszerezni. A Swing meg még benne van a JRE-ben, de ki tudja meddig, mindenki folyton temeti. És problémás a stílusozása.

Szóval a weben kívül, ha bármi mást választasz GUI framework-nek, akkor el fog jönni a pillanat amikor szívás lesz vele, valaki le fog hülyézni a döntésed miatt, és jogosan :-)

A webes app is szivas, kb fel kellene kotni mindenkit, aki nem nativ appot akar a nativ platformokra kesziteni. A crossplatform frameworkoknek mar a gondolatat is halalbuntetessel kellene sulytani, tok mind1, hogy Electron, vagy eppen "platformszeru kinezetre" skinezett QT vagy GTK. Az osszes ilyen crossplatform megoldast hasznalva totalisan platformidegen lesz a vegeredmeny. Sott, ha az egyik target platformot nem is hasznalja a fejleszto, akkor az adott platform lehetosegeit sem ismeri, igy igenye sem lesz arra, hogy az elkeszult valamije illeszkedjen az adott platformra. Ezeknek a technologiaknak kb soha nem lett volna szabad megszuletnie. Nem Windowsos appot akarok hasznalni Linuxon vagy Linuxos appot Macen, vagy Androidos appot iOS-en. Egy QT/GTK appon is latszik az elemeken, erzodik a widgetek mukodesen, ha a masik widgetrendszer ala tartozo kornyezetben fut.

Ahogy egyre több alkalmazás lett kliens-szerver megoldású, úgy haltak ki a vastagkliensek (elég sok munkát és szívást lehet megtakarítani, ha a kliensoldalt nem kell karbantartani, böngésző viszont minden gépen van). Így a technológia elterjedt (bármennyire nem igazán alkalmas a http protokol egy jó kliens-szerver megoldásra), onnantól már adott egy hasonló megoldás akár helyben futó appokra is.

Hogyhogy mi? Windowsra keszuljenek windows programok, amelyek Windowsosnak neznek ki, Windowsosnak erzodnek, macOS-re macOS appok amiket latod, hogy macOS appok, stb stb. 25 eve is hulyen nezett ki KDE alatt, ha elinditottal barmit, ami GTK-t hasznalt. Az ilyen "idegen" kornyezetben futtatott appoknal sikitofraszt kapsz, mert lehet, hogy a font smoothing is mashogy nez ki, ha ikonok vannak a widgeteken azok is masok. Minden szetesik, egyszeruen nem jo hasznalni. Ma ez annyival rosszabb, hogy 20 eve pl KDE-vel siman elvoltal ugy, hogy nem kellett soha GTK appot inditani, mindenbol volt KDE/QT megoldas, majd ha leultel egy Mac ele, akkor itt is minden amit hasznalni akartal Maces app volt. Mara sikerult ezt odaig innovalni, hogy egyre tobb multiplatform fos van, ami nem ugy multiplatform, hogy az app meg van irva 1x, majd platformonkent korerakva a platform sajat, nativ UI-ja, hanem az UI is crossplatform... Elinditod, aztan akkora hanyingert kapsz, a hasznalt platform latvanyvilagabol kiugrott apptol, hogy torlod le az egeszet a picsaba es felveszed a "na ezt se vagyok hajlando hasznalni" listara. A kinezet pedig, csak egy dolog. Pl. ha a rendszernek van sajat share panelja, akkor 99%, hogy ezek a multiplatform fosok implementalnak egy sajat share panelt, ami nem fogja azt tudni, amit a gyari, rendszer share panelja ad. Sott, mivel sajat implementacio lesz, ezert ugy fog kinezni, mint azon a rendszeren, amit az eredeti fejleszto hasznal a minednnapokban. Buszke is lesz magara, mennyire jol leutanozta az eredeti feluletet. Szoval nem, szerintem ennek igy, ki sem lett volna szabad alakulnia.

Szóval akkor az a megoldás, hogy ne legyenek olyan programok, amik több platformon futnak?

A win alattt csak a win, a gnome alatt csak a gnome, a kde alatt meg csak a kde? Én meg, ha esetleg nem csak egy eszközöm van, akkor szopjam keresztbe kasul az összes dolgomat? Hát köszi, inkább nézem az adaptált gombokat win alatt is a gimpben.

Mondom, értem a fájdalmat, valahol át is érzem, de az nem reális alternatíva, hogy ne legyenek cross platform programok. Az rosszabb.

20 eve, erre azt mondtam volna, hogy eseti hasznalatra, ez teljesen rendben van. De, mara oda jutottunk, hogy a dolgok nagy resze, ami az emberrel szembe jon, az a fos kategoriaba tartozo crossplatform szemet. Ugyhogy igen, szerintem az a megoldas, hogy nem leteznek tobbplatformos szoftverek.

Szerintem ez téves hozzáállás. Aki egy adott környezethez (GTK, Qt) ír programot, az annyit definiál, hogy legyen itt egy ablak, ilyen és ilyen widgetek legyenek rajta, ilyen elrendezésben, jöjjön fel egy modális ablak, amin legyen yesnocancel párbeszéd adott címmel és üzenettel. A konkrét megjelnést egyáltalán nem definiálja. Innentől kezdve a GTK/Qt/whatever fejlesztőinél a labda, hogy készítsék el az adott platform GUI stílusához illeszkedő widgeteket, ablakokat, és akkor nyugodtan lehet az alkalmazás crossplatform. Egyébként amikor próbálgattam némi Qt programozást Mac OS alatt, akkor az ablakok jellemzően Mac-szerűek voltak.

( denton | 2026. 04. 01., sze – 18:51 )

És valahol messze réges régen, egy távoli galaxisban felsír egy .kkrieger beta.

https://en.wikipedia.org/wiki/.kkrieger

Jó, mondjuk  öngól, mert itt pont a tárhely spórolásra inkább a többi erőforrást zúzta meg, de azért látszik, hogy mire képes az ember. Ha akar.

( bra | 2026. 04. 01., sze – 19:32 )

A bloat és a lag viszont könnyen mérhető, és a nyílt forráskódú fejlesztők érzik ezt a fájdalmat, ezért elég hatékonyan küzdenek a bloat és a lag ellen

Aha, 64 GB RAM-mal egy firefox, meg két vscode mellett már ne akarjak git clone-t indítani.

( n.balazs v | 2026. 04. 01., sze – 22:34 )

Az IT a 21. század mocska. Nincs rajta mit szépíteni. Digitális környezetszennyezés.

( kallaics | 2026. 04. 01., sze – 23:06 )

A szoftvergyártókat nem érdekli a RAM-fogyasztás

Valóban. Csak a profit érdekli őket.

Sajnos az IT-ban eltűntek azok az elvárások/szavak/kifejezések, hogy hatékony, egyszerű, igényes, minőségi. Ez egy igazán fájó pont azt gondolom.

Sajnos az IT-ban eltűntek azok az elvárások/szavak/kifejezések, hogy hatékony, egyszerű, igényes, minőségi. Ez egy igazán fájó pont azt gondolom.

Ezért utáltuk meg az IT-t. Amivé lett. Lesilányult megélhetési forrássá az egykori hobbi, szenvedély. 

trey @ gépház

( joco01 v | 2026. 04. 02., cs – 16:50 )

olyan szoftvert akarnak előállítani, amelynek kiadását nem szégyellnék

Csak az a baj, hogy egyes open source fejlesztők nem szégyellnek olyan kódot kiadni, amit mások szégyellnek :). Hát ez van, nem egyeznek az ízlések...

A Chrome holnap 60%-kal csökkenthetné a memóriahasználatát, és a Google bevétele egyetlen bázisponttal sem mozdulna.

Ez igaz, ettől még eljutnak hozzájuk a panaszok, és szoktak vele foglalkozni. Csak egy példa erre. Itt inkább érdemes megemlíteni a fos weboldalak készítőit, akik még egy lépéssel távolabb állnak a végfelhasználóktól.