A Firefox sajnálja a problémát és további infókat ígér ... hamarosan

Mozilla

Amit lesz további infó a felfordulással kapcsolatban, cikkünket frissítjük ...

( sz332 v | 2022. 01. 13., cs – 17:38 )

Én már átálltam Edge-re Win11-en... nagyon sajnálom, mert a kezdetektől használom.

( Chain-Q v | 2022. 01. 13., cs – 18:16 )

Én alapból kikapcsolok mindig minden intergalaktikus innovációt amíg csak lehet, pl. a DNS over HTTPS nevű nettó agyhalált, meg HTTP3-at, telemetriát, meg ilyesmiket, szóval nálam nem volt semmi... Elég sajnálatos, hogy már a Mozillában sem lehet bízni ebből a szempontból (és ez nem is most kezdődött, anyáztam én is eleget miattuk) de az FF még mindig a kisebbik rossz.

-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-

( dyra | 2022. 01. 13., cs – 19:51 )

háát, engem meg nem érdekel. Mit használjak? Valami Chromium származékot? Toljam a Google, Microsoft meg a többi nagy majom szekerét? Ráadásnak Linux alatt mind rosszabb mint a Firefox. Látszik, hogy nekik csak nyűg ez a platform.

( TCH | 2022. 01. 14., p – 19:54 )

Ha valakinek végképp tele a puttonya a mozzarella szemétségeivel, de egyik BigTech kompánia szemetére se szeretne átállni, akkor annak álljon itt pár alternatíva: - PaleMoon: XUL alapú, 28-29-es Firefoxra épülő konzervatív fork. Baromi gyors, de vannak olyan - többnyire JS-heavy - oldalak, amik nem, vagy bugosan mennek vele. - IceWeasel-UXP: szintén XUL alapú, az utolsó sane - 52.9-es - Firefoxra épülő progresszív(ebb) fork. Valamivel lassabb, de "maiweb-kompatibilisebb", mint az előző. - Ungoogled Chromium: A Chromium browser forkja, amiből minden a google-hez köthető cuccot és minden trackert, spyware-et, vagy privacy-szempontból aggályos szemetet kihajigáltak. - Iridium Browser: Chromium alapú browser, amiből dettó kiebrudaltak minden privacy-ellenes és google-ös szemetet, sőt még egyéb security tweak-eket is kapott (pl. WebRTC IP-leak ellen), de állítólag a krómos extension-ök közül nem mindegyikkel kompatibilis. - Falkon: Leánykori nevén QupZilla; a KDE project browsere. - Otter Browser: A régi Presto-s Opera Qt5 alapokra építkező klónja; WebKit-es és Blink-es backenddel is tud működni. Az egykori Midorit sajnos már nem tudom ajánlani, mert átírták electronosra. :(
Oldschool Computer - http://oscomp.hu

( locsemege v | 2022. 01. 14., p – 22:43 )

átírták electronosra

Ez mitől rossz? Semmit sem tudok róla, szóval lehet, hogy szerintem is rossz, de nekem az elektron egy -1.602e-19 C töltésű elemi részecske. Szóval miről van szó?

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Az Electron egy webes technológiákra (HTML, CSS, JS) épülő asztali alkalmazások "fejlesztésére" "alkalmas" framework. És ezzel azt hiszem mindent is elmondtam, hogy miért kell tűzrehajítani az egészet, a kiötlőjét pedig leginkább a gumiszobában, vagy egy versenyzongora alatt tárolni...
Oldschool Computer - http://oscomp.hu

Tényleg nem értek hozzá, de egy keretrendszer nem lehetne akár jó is? Ez nem egy library lényegében, hogy ne kelljen karakterek diszkutálásával html parsert írni, meg képek, szövegek renderelését megírni, input mezőket leprogramozni a nulláról? Valószínűleg én is utálnám, csak nem értek hozzá.

off

Úgy adódott, hogy életem első gtk-s alkalmazását írtam meg - GTK4 egyébként - natív C-ben, de valahogy nem lopta a szívembe magát. Nekem fura az, hogy a layout kialakítása egy nagy inicializálás, aztán meg kell hívni a fő végrehajtó ciklust, amelybe nem látok bele, csak eseményekhez vannak callback függvények, s adott esemény bekövetkeztekor így kapom meg a vezérlést. Az eseményeket is az elején kell inicializálni. A másik, hogy nagyon könnyű memory leak-es alkalmazást írni, mert nem te foglalod a memóriát, hanem egy adott objektum létrehozásakor ő, s ha figyelmesen olvasod a doksit, meg nézel példákat, akkor esetleg kiszúrod, hogy kell valami destroy, amelyben ott lesz a free() hívása. Szóval undorító az egész.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Az Electronos appok tulajdonképpen weblapok: HTML-ben építed a GUI-t, CSS-ből díszíted, JS-ből vezérled és az egészet egy Chromium+NodeJS browser fogja neked megjeleníteni és működtetni, amit a programodba ágyaznak. Ez sehogyan sem lehetne jó. Zabálja a memóriát, a CPU-időt és olyan bugos lesz, amilyen bugos egy browserben futó jávaszkriptes szeméthegy csak lehet; vagy, hogy megfordítsam: olyan bugos lesz, amilyen bugos csak egy browserben futó jávaszkriptes szeméthegy lehet.
Oldschool Computer - http://oscomp.hu
Nem, itt a GUI-ról volt szó, nem a belsejéről, ami magukat a weblapokat jeleníti meg. Megpróbálom elmagyarázni, de sajnos szar tanár lennék, de azért igyekszem. Szóval a browserek alapvetően két részre oszlanak. Az egyik a GUI (amin keresztül a júzer tkp. irányítja a motort), a másik maga a motor. (Ami egyébként megint csak két alapvető részből áll: az egyik a HTML+CSS-ből álló struktúrák rendermotorja, a másik meg a JS VM.) Ezekhez még kapcsolódhat több más cucc is, pl. multimédia, hálózat, stb. de alapvetően ahhoz, hogy egy "standard" (HTML+CSS+JS) weblapot megjeleníts - hogy magát a weblapot megjelenítsd - ahhoz erre a kettőre van szükség (a hálózat is opcionális; egy weblap lehet offline is: file:///home/locsemege/example.html). A Chromium eleinte a WebKit motort használta, aztán a kugli forkolta és azóta Blink van benne. E motorok köré építettek fel először GTK2-ben, majd GTK3-ban egy GUI-t, annak a saját lehetőségeivel, kiterjesztéseivel és természetesen a hálózati, multimédiás és egyéb beleintegrált cuccaival. Tehát a Chromium az egy Blink motoros böngésző, aminek saját GTK-s GUI-ja van, tehát nem egy weblap. Az összes Chromium-deriváns (Vivaldi, újkori Opera, Brave, Edge, stb.) tkp. ezt a kombót örökli meg és módosítgat rajta ezt-azt, de belül mind egy Blink motor + egy GTK-s GUI, meg a kapcsolódó hálózat/multimédia/stb. rétegek. Az electronos appok, mint mondtam, úgy néznek ki, hogy fogják a Chromium motorját, arra rákúrják a NodeJS környezetet, ezt beleintegrálják a programodba és utána a programodban a GUI tulajdonképpen úgy néz ki, hogy elindul egy GUI-less browserwindow (illetve a GUI annyi, hogy egy darab renderwindow), amiben megjelenik a te programod GUI-ja. Egy weblap. Ez az Electron koncepciója. De ez nem egy Chromium, csak annak a motorja; a Chromiumhoz hozzátartozik a GUI, a network, a multimédia és a többi cucc is. Ez itt egy pure webpage renderer/VM, ami a Chromium motorját - a Blinket - használja, de ez nem ekvivalens az egész browserrel. Namármost, a Midori korábban úgy nézett ki, hogy volt a WebKit browsermotor, ami köré GTK2-ben (illetve, amikor a 0.5.11 után kijött a 6.0 (igen), onnantól GTK3-ban) építettek egy saját GUI-t, annak a saját lehetőségeivel. És ezt állították át Electron alapokra, tehát itt már a GUI is egy weblap, viszont a benne megépített GUI-nak semmi köze a Chromium GUI-jához, hiszen a Chromiumé nemcsak, hogy teljesen más, de még csak nem is Electronos, hanem még mindig GTK-s. Azt nem tudom, hogy a browser motorját is lecserélték-e WebKit-ről Blinkre, de az mindegy, mert még attól sem lesz valami Chromium, hogy a motorja ugyanaz lesz, mint a Chromiumé; ld. Otter Browser, az nem csak WebKites, hanem Blinkes is tud lenni, mégsem Chromium, mert az összes többi teljesen más. A Midori - és tkp. bármely electronos browser - úgy néz ki, hogy van egy GUI-less minimálböngésződ és abban futtatsz egy weblapokból álló böngészőt, ami belül weblapokat tud megjeleníteni. Ez történhet úgy is, GUI-t és a renderelendő weblapokat is ugyanaz a motor jeleníti meg, de akár úgy is, hogy kettő darab browsermotorod van, amiből az egyik a GUI-t intézi, a másik a megjelenítendő weblapokat. (Nem tudom, hogy a Midorinál ez hogy van, de nem is nagyon érdekel.) Egyszóval nem Chromium, csak annak a motorjával jeleníti meg a saját GUI-ját; a Chromium maga ilyet nem csinál. Tehát electronos browser === browserben a browser, weblapban a weblap, vagy még pontosabban: browserben lévő weblapban a browser és abban a weblapok. Van még kérdés, hogy ezért miért járna atomrakétás tarkólövés?
Oldschool Computer - http://oscomp.hu

Köszönöm, teljesen világos, érthető, amit írtál. Szóval egy bloat sz.r lett a Midori, ha jól értem, mert futásidő meg RAM van rogyásig. Mondjuk az új gépemben tényleg - Ryzen 7, 8 mag, 4.6 GHz, 32 GiB RAM -, de azért ne már! Amúgy csak vész esetére van fenn a Midori, ha hirtelen megdöglene a Firefox.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Az. Bloated szar lett. Minden, ami electronos az egy bloated szar. És nem csak bloated, hanem lassú is és bugos is; tkp. a programod megörökli egy browser rendermotorjának és JS VM-jének az összes bugját és sérülékenységét. Mikori az a Midori, ami nálad fennt van? Én tartok tőle, hogy az még a 2019 előtti 6.x-es széria valamelyik tagja.
Oldschool Computer - http://oscomp.hu
Hát, akkor ha szükséged van egy backup browserre, akkor a fenti kínálatot jó szívvel tudom ajánlani. Akár a szépen lassan tönkretett róka helyett is. A GTK CSS-e, az nem az a CSS. CSS a betűszó feloldásának szó szerinti értelmezésében, de semmi köze a webes CSS-hez. A szintaxis és a koncepció nagyjából fedik egymást, de ennyi, a selectorok, a tulajdonságok és az implementáció eltérnek. Nem is kompatibilis vele, meg nem is ugyanazt csinálja és nem is ugyanúgy.
Oldschool Computer - http://oscomp.hu

Nem, nem jó. Ahelyett, hogy az alkalmazások használnák az OS vagy valami natív komponens libraryt, helyette inkább hoznak egy komplett böngészőt magukkal. Mármint minden egyes kurva program. Van 6-8-10 ilyen electronos vagy hasonló elven megírt program, amit használnom kell, mindegyik lassú és kurva sok ramot használ.

Ha ugyanazt a executable-t és shared library-ket használják, akkor az OS nem csak egyszer tölti be a memóriába? Nem tudom, hogy a mai OS-ek elég okosak-e ahhoz, hogy felismerjék, hogy két eltérő helyről betöltött kód ugyanaz.

Vagy megoldás lehetne az Electronos appokról leválasztani a runtime-ot, mint Java vagy .NET esetén. Sőt, úgyis ott van a böngésző minden eszközön, csak azt kellene újra használi. Az alkalmazást sem kellene összecsomagolni egy telepítőbe, lehetne teríteni lazy loadinggal, fileonként, így a deploymemt és a software update is megoldott. Csak minimális metaadatot kellene elküldeni a felhasználónak, hogy ez a weblap valójában egy telepíthető alkalmazás, és el is jutottunk a PWA-hoz.

Ha ugyanazt a executable-t és shared library-ket használják, akkor az OS nem csak egyszer tölti be a memóriába?
A shared library-kat csak egyszer tölti be a rendszer, de nem azok zabálnak sokat, hanem a browsermotor, az pedig minden exe-be bele van gyúrva, viszont az exe-k nem ugyanazok, hiszen más-más van bennük lekódolva.
Sőt, úgyis ott van a böngésző minden eszközön
Ilyen browser egyik eszközön sincs, hogy egy darab renderwindow az egész és bele van drótozva egy darab specifikus weblap, ti. az alkalmazás maga.
Csak minimális metaadatot kellene elküldeni a felhasználónak, hogy ez a weblap valójában egy telepíthető alkalmazás, és el is jutottunk a PWA-hoz.
Az Electron offline cuccokat gyárt, by default nincs hálózat az exe-be gyúrt browserben.
Oldschool Computer - http://oscomp.hu

az exe-k nem ugyanazok, hiszen más-más van bennük lekódolva

Megnéztem pár Electronos alkalmazást a munkahelyi gépemen (macOS), a futtatható bináris mindegyik esetben 200-400 kB között van. Ami nagy az az app.asar file, ami a resource-okat (html, css, js, képek, stb.) tárolja.

Ilyen browser egyik eszközön sincs, hogy egy darab renderwindow az egész és bele van drótozva egy darab specifikus weblap, ti. az alkalmazás maga.

Dehogy nincs, régebben ez volt a kiosk mód, de PWA-k is ezt a módot használják, nagyobb browserek támogatják (pl. Chrome).

Az Electron offline cuccokat gyárt, by default nincs hálózat az exe-be gyúrt browserben.

Nyilván ez alkalmazás függő, de semi nem zárja ki, hogy egy PWA offline működjön. Csak az első használathoz kell a net, utána már működik cache-ből. Tény, hogy egy Electronos appot lehet teljesen offline is telepíteni, de ez szerintem nagyon ritkán szükséges. Legtöbb Electronos app eleve online szolgáltatások elérésére van kitalálva, amikkel net nélkül úgysem lehet mit kezdeni.

Megnéztem pár Electronos alkalmazást a munkahelyi gépemen (macOS), a futtatható bináris mindegyik esetben 200-400 kB között van. Ami nagy az az app.asar file, ami a resource-okat (html, css, js, képek, stb.) tárolja.
Hogy konkrétan hogy van felsplittelve - pláne macOS-en - azt most hirtelen nem tudom, de az egész az garantáltan nem 200-400 kB, hiszen viszi magával a függőségeit. Ha az ott annyi, akkor az valami speckó build nálad.
Dehogy nincs, régebben ez volt a kiosk mód, de PWA-k is ezt a módot használják, nagyobb browserek támogatják (pl. Chrome).
A kiosk módú Chrome az nagyon nem ugyanaz, az attól még egy teljes értékű Chrome browser marad. Az Electronos cuccokban egy lecsupaszított browser van, ami azt az egy alkalmazást fogja futtatni.
Nyilván ez alkalmazás függő, de semi nem zárja ki, hogy egy PWA offline működjön. Csak az első használathoz kell a net, utána már működik cache-ből. Tény, hogy egy Electronos appot lehet teljesen offline is telepíteni, de ez szerintem nagyon ritkán szükséges. Legtöbb Electronos app eleve online szolgáltatások elérésére van kitalálva, amikkel net nélkül úgysem lehet mit kezdeni.
Hogy mit lehet, meg mit szoktak, az két külön kérdés. Mondjuk egy online szolgáltatás esetében felmerül a kérdés, hogy mi a fárasnak emulálunk egy browsert, hogy futtassunk benne egy browsert, benne egy webappal, amikor egy online szolgáltatás alapból mehetne tényleg egy helyi browserben is...
Oldschool Computer - http://oscomp.hu

Hát, nem tudom, hogy ott hol nézted azt a binárist, jellemzően 100+ mb felett vannak nálam a telepített programok. Memóriafelhasználás szintén. Oké, hogy a tabletemet leszámítva minden gépemben van 32G ram, de azért nem arra, hogy 8 külön program 10 különböző böngészőt hozzon.

A Show Package Contents -> MacOS alatt néztem. Persze ez csak egy launcher, de a lényeg, hogy nincs belecsomagolva az összes statikus resource. A Frameworks -> Electron Framework.framework alatt valóban van egy 100+ MB-os bináris, ez feltételezem azonos framework verzió esetén ugyanaz mindegyik Electronos appban.