Doplňky desktopového prostředí a jejich vliv na stabilitu

V posledních dnech oživla diskuze o tom, jaký vliv mohou mít doplňky na stabilitu desktopového prostředí. Jiří Eischmannn nejprve popsal situaci kolem rozšíření GNOME Shellu, kde Shell je pevně svázán se správcem oken Mutter, který na Waylandu slouží jako kompozitor, a tak chyba v rozšíření Shellu může vést k pádu celého prostředí. Také na blogu KDE vyšel zápisek, který pro změnu vysvětluje situaci v prostředí Plasma, kde doplňky shodit celé sezení nemohou a do budoucna je v plánu jejich izolace, aby nemohly ovlivnit stabilitu ani Plasmy.

3.8.2018 18:44 | |🇵🇸 | Zajímavý článek

Komentáře

[deda.jabko]

Vzpomnel jsem si na blogy od Bystroushaaka o Self/Smalltalku a o tom, jak se mu libi, ze je v techto prostredich propojeno, jde to libovolne upravovat a menit... a tady je ucebnicovy doklad, jake dusledky to muze mit, kdyz se podobny pristup pouzije i u skutecne pouzivaneho softwaru.

[koroptev]

gnome ani kde neni skutecne pouzivany sofware..

tam, kde ma linux sweetspot (na androidu, na serverech), se nic z toho nepouziva..

ostatne staci to zapnout a do deseti minut je. davat pozor, je to zabugovany oboje ad absurdum

[Petr Ježek]

Proč jen nic takového dlouhá léta na desktopu ani na thinkpadech nepoužívám a mám klid?

[debian]

Překvapení, pythoní bastlič něco nedomysel

[Petr Tomášek]

Propojeno to může být, ale musejí být jednotlivé komponenty rozumně oddělené

[mirec]

Nie je to tak jednoduché oddeliť. Príkladom budiž chrome, ktorý používa na taby samostatné procesy. Stačí pár otvorených tabov a minie prakticky celú dostupnú RAM. Oddeliť extensiony každý do samostatného procesu by malo asi rovnaké účinky. Jediné rozumné oddelenie, ktoré ma napadlo je rozdelenie na windowmanager a shell (tak, ako to robí KDE), ale ani to nie je 100% účinné.

Zakázanie rozšírení po páde je len logickým dôsledkom toho, že rozšírenia nebežia v samostatných procesoch. V prípade pádu rozšírenia nie je možné spoľahlivo určiť vinníka a jediný spoľahlivý postup je zakázať rozšírenia kompletne.

[Petr Tomášek]

Typický příklad dementnosti, která se projevuje v GNOME v posledních tak 15 letech.

Extensions used to be disabled when the Shell crashed hard (couldn’t be restarted). Since on Wayland it’s the result of every crash, we should do that after every GS crash

No, pánové, tak to je teda logika! Zhebnul nám shell, tak potrestáme uživatele vypnutím extensions!

Připomíná mi to "fungování" NetworkMagora, který ve chvíli, kdy se naráz ztratí signál (např. je natvrdo odpojen router od napájení) to nejprve vyhodí dialog s (uloženým) heslem. Ve chvíli, kdy člověk dialog od"eskejpuje", nebo klikne na "cancel" to smaže uloženou passphrase, takže když se router za chvilku vzpamatuje, tak se nejde připojit, protože uživatel si passphrasi nepamatuje... Takovýto způsob řešení mohl vymyslet jen totální debil...

Decoupling GNOME Shell and Mutter or/and other steps that would bring back the same behaviour like on Xorg: GS crash would not take everything down.

Další příklad toho, jaká sračka je ve srovnání s Xorg-em Wayland. Přesně tenhle typ problémů se dají očekávat, když se místo pořádné server-klient architektury nasadí posraný trochu lepší framebuffer.

Discontinuing the unlimited extensions, introducing a limited API they can use instead of hot patching the GS code itself.

No, problém samozřejmě je, když se na začátku neudělá pořádná architektura, pak z toho vznikne takovýto bastl...

[ikar]

Tesat do kamene! 100% souhlas.

[Grunt]

Další příklad toho, jaká sračka je ve srovnání s Xorg-em Wayland. Přesně tenhle typ problémů se dají očekávat, když se místo pořádné server-klient architektury nasadí posraný trochu lepší framebuffer.

Nenapsal bych to tak barvitě ale tak nějak. Wayland je opravdu jen knihovna a kreslení v ní jsou volání. Když se zasekne aplikace, vlastně se zasekne kompletně obraz. Tohle by se mělo nějak dořešit. Ony ty Xka nebyly zas tak úplně špatně vymyšlené.

[RB]

To je nesmysl a jestli je nějaký Wayland compositor tak hloupě napsaný, tak je to jeho problém a ne návrhu Waylandu. Když se zasekne aplikace, tak se samozřejmě zasekne jenom vykreslování obsahu daného okna. Stejně tak Wayland nikoho nenutí, aby měl rozhraní desktopu a compositor v jednom procesu. Plasma+Kwin budiž příkladem, takže dávat toto za vinu Waylandu, je opět trochu mimo.

[benda]

Myslim, ze byste si nejdriv mel ujasnit co dela GNOME Shell a co dela NetworkManager. Pokud popisujete graficke dialogy, tak ty asi nebudou NM, tohle je implementovany v GS, ktery jen vola NM.

Zkuste napriklad:

nmcli connection show your_wifi_profile --show-secrets

Ony tam ty hesla velice pravdepodobne budou ulozeny. No ne?

Navic, pokud mate na wifi profilu autoconnect, tak se rozhodne po znovu objeveni wifi NM opet pripoji, dela to tusim nekolikrat za sebou, a pak vzdy v 5 minutovych intervalech, aby prilis nezatezoval. Pokud mate two factor overeni tak to muze byt lehce jinak.

[Petr Tomášek]

Debilní výmluvy mě nezajímají, pardon.

Jde tu o přístup k uživateli, takže zda-li se jedná o Gnome Shell, NM, nebo cokoliv jiného není podstatné, podstatné, že to funguje zkripleně a to ne kvůli nějaké technické chybě, ale celkovém přístupu k uživatelům...

[|🇵🇸]

Post hoc ergo propter hoc.

[Michal]

To musela být teda geniální hlava, která vymyslela, že WM má být propojený se shellem :-p

[Peter Golis]

Súhlasím, bol to geniálny ťah. A vynesie im 300k$ v blízkej budúcnosti.