Názory k článku
Emulátor Playstation 2 proti proudu: PCSX2 vypíná Wayland a stěžuje si na obrovské chyby
-
To je trochu clickbait. Vývojáři si tam stěžují na chybějící vlastnosti, protože používají více oken a oni je nemůžou na Waylandu pozicovat. Mají asi problém i s UI jako takovým, kde GNOME má nějaké standardy a jejich UI jde vyloženě proti nim. Wayland tam nikdo nevypíná, jen není výchozí, což je třeba něco, co oznámili i vývojáři Firefoxu, pokud by náhodou Wayland dělal problémy.
-
Nerozumim tomu, kde v te zpravicce vidite problem. Pokud v prostredi nefunguji vlastnosti a funkcionalita, kterou by clovek od takoveho prostredi ocekaval, je to asi problem. A uprime pozicovani okna je funkcionalita, kterou bych (alespon ja) ocekaval jako vylozene standardni funkcionalitu.
Navic uz v XOrg kazde prostredi zachazi s okny trochu jinak. Vzhledem k tomu, ze DE\WM jsou komunitni projekty tak si priznivci dane komunity nemusi niciho vsimnout. jenze ve chvili, kdy svuj projet pisete, tak aby nebyl zavysli na DE/WM pak casto narazite na tezko resitelne problemy, ve kterych jste vicemene sam - bo komunity. Pokud se to jich primo netyka, tak je to proste nezajima.
Komunity jsou alfou a omegou opensource a Linuxu obzvlaste. Jak toho dobrehe, tak i toho spatneho.
28. 11. 2023, 20:53 editováno autorem komentáře
-
> A uprime pozicovani okna je funkcionalita, kterou bych (alespon ja) ocekaval jako vylozene standardni funkcionalitu.
Pokial myslite len klasicky obdlznikovy displej, tak asi ano.
Pokial myslite displej, ktory moze mat iny tvar (kruh na hodinkach, oval na instrument clusteri pristrojovej dosky), tak uz moze vznikat problem, aby sa aplikacie nesnazili napoziciovat mimo viditelnu cast.
A potom tu mame zariadenia, ktore nemaju absolutny suradnicovy system: napr. taky headset. Tem ma niekde (0,0,0,0) a potom ide (-inf, inf) po 4 osiach.
Alebo iba taky stary dobry Doom compositor (https://www.youtube.com/watch?v=_FjuPn7MXMs).
Dovolit aplikacii pouzivat absolutne suradnice je zarobit si na dobry chaos.
Treba si uvedomit, ze protokoly Wayland tu nie su na to, aby sme urobili rychly fix na dnesny problem a kaslat na technicky dlh. Kazdy jeden protokol tu bude najblizsich 50 rokov, niekto to bude musiet udrziavat a bude to musiet fungovat s buducim zelezom.
Takze pozor na to, co je standardna funkcionalita a ako sa nou zabetonujete.
-
[ja]
Proto taky pisu o standardni funkcionalite prostredi, protoze na kazdem takovem zarizeni bych logicky ocekaval jine chovani. Vyvojari emulatoru PS evidentne necili svuj projekt na pristrojovy terminal ci hodinky. Pokud je (napr. ) Gnome schopne bezne fungovat i na vyse zminenych zarizenich, tak by to melo byt predevsim ono, kdo by mel v zavyslosti na tomto faktu prizpusobovat sve sluzby a davat to vhodnym zpusobem zpravovane aplikaci vedet - pokud to potrebuje. To je konec koncu jeho ucel.Krasnym prikladem je treba okenni parametr "gravity", ktery si jeden cas KDE* urcovalo jak se mu zachtelo, coz vedlo k padum NON-KDE aplikaci, pri manualni zmene jejich velikosti, protoze proste neocekavaly chovani KDE a kres;lily mimo kontext okna.
*Je to uz par let stara zalezitost, mam ten dojem ze z prvnich verzi KDE 3. Urcite to byl problem KWin. jestli ale jej zpusobovalo uz primo QT, to rict nedokazu. Na druhou stranu, sam z vlastni zkusenosti vim, jak blbe se stimto parametrem pracovalo.
-
No ale klasické obdélníkové displeje jsou stále jaksi dominantní a v dohledné době to nevypadá na nějakou zásadní změnu.
Průnik s aplikacema pro hodinky, nebo headsety je veškerý žádný. Takové aplikace musí mít celé uživatelské rozhraní navržené jinak. Jestli taková aplikace použije navrch i trochu jiné okenní api je už nepodstatný detail.A dál to už je úplný bizár. Opravdu se má brát ohled na 10 let mrtvé obskurní demo? Jestli je něco recept na technický dluh tak takovéhle úvahy. Podobné věci jsou cool demíčka, ale reálně se to k ničemu nehodí. A demíčka se dají nějak ohákovat, vlastně je to i součást zábavy.
> Kazdy jeden protokol tu bude najblizsich 50 rokov
Xka stihla beznadějně zastarat za necelých 40 let. Wayland už má 15. Kolik let zbývá jemu, než i jeho základní architektura neopravitelně zastará?
-
To obskurne demo bol ako priklad, ze predpoklady, s ktorymi niektori pracuju, nemusia byt spravne -- napriklad ze kompozitor nemusi mat absulutny, limiitovany 2d suradnicovy priestor, v ktorom pracuje.
Niektorym staci slovne vysvetlit, aby pochopili.
Niektorym treba ukazat (<= obskurne demo), potom pochopia.
Niektori nepochopia ani tak.
-
Aj vo VR sa daju pustat normalne 2d aplikacie. Je to proste textura orientovana v priestore, do ktorej sa zobrazuju.
Dalsi priklad: vzdialene aplikacie (RAIL, nie cely desktop). Na serveri sa vytvara headless session, kde framebuffer ma origin (0,0) a nema konecny rozmer. Jeho aktualny rozmer je identicky s rozmerom prenasaneho okna (t.j. surface klienta _je_ framebuffer).
-
Jo, pouštět se dají. Akorát používání je o dost horší v porovnání s normálním monitorem. Takže je tohle použití dost okrajová záležitost.
A u těch remote appek je ten framebuffer jen implementační detail. Na cílovém stroji má ta appka úplně normální pozici a rozměry. Jakékoliv požadavky na pozici nebo velikost okna stačí triviálně přeposlat.
Drhnout to začne až ve chvíli, kdy budu jednu appku chtít zobrazovat na víc vzdálených strojích. Ale tam těch problémů bude trochu víc. A zrovna u velikosti okna to najednou může vypadat skoro jako by ty požadavky posílala samotná aplikace. -
Jan HrachStříbrný podporovatelAle já používám standardní laptop se standardním obdélníkovým displejem tady a teď, a na něm zdá se Wayland nepodporuje základní a jinde běžnou běžnou funkci.
Ten váš argument ve stylu „NTP přestane fungovat až se bude lítat do vesmíru, tak radši nebudeme podporovat žádnou synchronizaci času, dokud se ten problém nevyřeší dokonale“ nechápu.
-
No a prave na migracii X11 -> Wayland mozeme vidiet, ze ked sa raz otvoria dvere, uz sa tazko zatvaraju.
Preto tie tazkosti so screenshotmi a screen castom: X11 klienti povazovali za dobry napad, ze si mozu zobrat obsah framebuffera, roky to tak fungovalo, tak kde je problem.
No problem je, ze v dnesnej dobe sa ocakava, ze lubovolna aplikacia nemoze len tak sahat na globalny framebuffer a musi ist cez nejake API, kde sa to da pouzivatelovi na vedomie, alebo schvalenie. Konceptualne je to podobne, ako ked prestal existovat globalny adresny priestor zdielany vsetkymi aplikaciami (ala DOS alebo Win16) a aplikacie dostali svoj vlastny virtualny; komunikovat s inymi musia cez IPC.
(A to uz nespominam to, ze globalny framebuffer s modernym hw uz nemusi existovat. Ked nejaky klient chce screenshot celeho desktopu, kompozitor mu ho musi poskladat offscreen rovnako, ako to vie urobit scanout hardware.)
A vidime, aky neskutocny problem tieto migracie su. Preto na to lietanie do vesmiru myslime uz teraz, aby sme nemuseli zase zacinat od nuly.
-
Jan HrachStříbrný podporovatel
> No problem je, ze v dnesnej dobe sa ocakava, ze lubovolna aplikacia nemoze len tak sahat na globalny framebuffer a musi ist cez nejake API, kde sa to da pouzivatelovi na vedomie, alebo schvalenie.
Ale já nemám problém s tím, že by to vyžadovalo schválení (to je naopak super), a že to nutně znamená, že bude potřeba nějaké jiné API. Já mám problém s tím, že to API neexistuje, případně existuje v několika nekompatibilních verzích, přitom se to už několik let tlačí uživatelům jako hotový výrobek a kdo na to upozorní je označen za „uřvanou menšinu“ a „chce spacebar heater“, a teď tu nově ještě někteří píšou, že to API ani jen tak existovat nebude, protože je to moc složité udělat správně aby to fungovalo s VR a Doomem a kulatými displeji a věcmi které možná přijdou v roce 2035.
-
Tak konkretne screenshoting a screencasting API existuje uz roky; akurat mnohi kritici, si to za tie roky neracili vsimnut a kritizuju dalej.
Podobne, nekompatibilne api (hovorime o screenshotoch, vsak?) -- kazdy kompozitor si urobil svoj prieskum, co je treba a co nie, preto tie api boli oznacene ako experimentalne (mnohi dodnes nechapu, co to znamena). Potom zobrali svoje skusenosti, a urobili jedno spolocne. Co je tna tom zle? Mali prist hned s dokonalym API, bez toho, aby mali nejaky feedback? To by zase boli kritizovani, ze rozhodli od stola a nesplna poziadavky...
Ako cokolvek, co skusia, je oznacene ako zle a nevyhovujuce -- lebo spacebar heating je velmi realny efekt.
-
Jan HrachStříbrný podporovatel
> Tak konkretne screenshoting a screencasting API existuje uz roky; akurat mnohi kritici, si to za tie roky neracili vsimnut a kritizuju dalej.
OK, díky moc za poučení, a pro ostatní kdyby taky nevěděli co univerzálního to podporuje, tak koukněte na flameshot. (a než existovalo, tak ti, co to požadovali, požadovali spacebar heating? :)
-
Tohle je pro Gnome typicky. Na jednu stranu se resi takovy veci jako ovalny displej. Na druhou stranu kdyz nekdo pozaduje moznost nastavit rychlost skrolovani koleckem mysi, tak se dozvi, ze je kteren, ze to neni potreba, za neco jako rychlost scrolovani Gnome nikdy implementovat nebude.
Gnome na totiz ma zabudovany vzorecek, ktery odvozuje rychlost scrolovani od uhlu pootoceni, vysky pismene v bodech a prumerne vzdalenosti oka od monitoru v zavislosti na vysce monitoru. A autor toho kodu je na svuj vytvor tak pysny, ze odmita cokoliv co by uzivatelum umoznilo rychlost scrolovani ovlivnit.
-
To ze Vy neco neocekavate jeste ale neznamena, ze to nekdo nebude pozadovat.
Ukolem spravce oken je sice spravat okna, to je pravda, ale take je potreba aby bral bral v potaz pozadavky aplikace. Autor takoveho programu fakt neni vsevedouci panbuh, aby byl shopen predikovat za jakych okolnosti a kdy bude nejaka funkcionalita potreba.
Samozrejme se muze stavet do role diktatora. Pak uz je otazkou jestli me (rozumejte autora timto diktatem dotceneho projektu) bude zajimat. Pak proste oznamim, ze pokud mozno ho nebudu respektovat a kdyz to nepujde, tak ani podporovat. A z tohoto hlediska mi prijde prohlaseni vyvojaru naprosto koser.
"Alfou a omegou open source jsou lidi, kteří na těch projektech pracují."
Kteri prave jsou nedilnou soucasti tech komunit kolem tech open source projektu. A rozhodne na to jak ten projekt vypada maji i velky vliv jeho uzivatele.29. 11. 2023, 00:27 editováno autorem komentáře
-
Uživatel si zvolí, že se nové aplikace mají otevírat na nejbližší volné polovině monitoru. Aplikace, kterou otevírá, ale požaduje dvě okna vycentrovaná uprostřed monitoru 5px od sebe o velikosti W a H. Co z toho má větší prioritu? Jsou to dvě pravidla jdoucí proti sobě, kde si jedno vyžádal uživatel.
GNOME je třeba také open source projekt se svou komunitou, která má stejné právo se rozhodovat, jakým směrem ho bude posouvat, stejně jako vývojáři aplikací.
Ono to je vesměs jednoduché. Pokud má mít desktopové prostředí nějaký řád, tak pravidla určuje prostředí a přizpůsobuje je uživatel. Pokud by pravidla určovaly aplikace, tak každá bude používat jiná menu, jiná dialogová okna, jiné barvy, jiné rozložení, jiná API pro přístup k hardwaru a tak dále.
-
> Co z toho má větší prioritu?
Tak ten odmítnutý pull request, o kterém vývojáři PCSX2 psali, to navrhoval jako doporučení. Takže zrovna priorita problém není.
> Pokud by pravidla určovaly aplikace, tak každá bude používat jiná menu, jiná dialogová okna, jiné barvy, jiné rozložení
Ono jim v tom nic nebrání. Uvnitř svého okna je každá aplikace svým pánem. A paradoxně čím víc základních funkcí nebude dostupných v nějaké standardní podobě, tím víc aplikací je bude implementovat tak nějak po svém a nekonzistentně.
I to chybějící absolutní pozicování jde jednoduše obejít. Prostředí tomu nemá jak zabránit. Řád tomu může dát tím, že tuhle funkcionalitu aplikacím poskytne samo. Jinak si to holt bude dělat každá jinak a po svém.
-
@JSH Když si ten "odmítnutý" pull request projdeš, tak zjistíš, že tam jsou vysvětleny důvody proč nebyl v současné podobě mergnutý. Je tam třeba hezká část o tom doporučení:
As written here before, the problem with hints is that as soon as someone successfully uses them, they start to rely on them, which then makes all other compositors that ignore the hints be "buggy" with the application from the end user perspective.
A jedna reakce:
I would expect a compositor that implements this protocol to also honor the hints if possible, otherwise the compositor shouldn't implement that protocol at all - maybe that is worth clarifying.
Takže z doporučení je najednou něco, čemu by se mělo vždy vyjít vstříc. Ty argumenty tam nejsou špatné, ale chápu, že ne každý to vidí stejně.
Fakt jde jednoduše obejít, když ho ten protokol nepodporuje?
-
[byCx]
Pokud si to tak uzivatel preje, pak by jednak dane prostredi by melo dat aplikaci vhodnym zpusobem vedet, ze nemuze jeji pozadavek obslouzit a z jakeho duvodu. Pokud se prostredi pokusi aplikaci nasilne (nebo rovnou bezohledne) vnutit sva pravidla vede to k obtizne resitelnym behovym chybam. Navic takovy pristup taky vede k tomu, ze se vyvojar dane aplikace absolutne nemuze spolehnout na to, co na danem typu zarizeni funguje a co ne.
A jednak spravce oken stejne musi delat vyjimky. Nemate jen jeden typ top-level windows. Nektere museji byt zobrazeny urcitym zpusobem uz z jejich povahy. napr. okna notifikaci.Jindy si zas aplikace usmysli, ze zrovna ted musi byt maximalizovana nebo hozena do fullscreen modu. A do toho se vam zacne na vrch stacku protlacovat okno ktere ma navic i pevnou sirku okna - napriklad nejaky dialog. Dalsi takovou srandu napr u dlazdic je otazka vetsiho mnozstvi otevrenych oken. Vsechna okna maji nejakou minimalni velikost, danou treba jejich layoutem a minimalni velikosti widgetu. Pokud to spravce oken nerespektuje, hrozi velmi realne riziko, ze neco zacne kreslit mimo kontext - a prusvih je na svete. Mimochodem, kdyz jsme u toho, ony i ty Gnome aplikace spustene na jinych spravcich maji zase sve pozadavky a ne nektere z nich musi proste WM reagovat jinak skonci treba s chybou BadWindow. Tohle se treba dost blbe hleda a jako dokumentace Gnome je v tomto ohledu... no dost skoupa.
Takze stejne musi spravce musi respektovat pozadavky aplikace, priorizovat, a neustale resit podobne radosti stacku oken a ne vzdy proste se mu dokonale musi darit dodrzet zvolenou strategii zpravy oken (napr. nejaky typ dlazdicoveho usporadani - volne plovouci okna to maji nejednodussi :-) ) Neni to snadne, to nepopiram, ale spravce oken by opravdu nemel byt diktator, jako spis strateg, ktery dela maximum proto, aby pokud mozno vyhovel co nejvetsi casti aktualnich pozadavku. To plati i pro dlazdicove zpravce oken, ale samozrejme zavisi na autorovi (autorech) daneho programu.
29. 11. 2023, 01:22 editováno autorem komentáře
-
@D.A.Tiger Samozřejmě je WM bude obsluhovat požadavky na notifikace a dialogová okna, ale nutně nemusí vycházet vstříc úplně všemu, co po něm aplikace chce. Navíc v tom v tom PR je vyloženě napsáno, že většina problémů neleží na bedrech protokolu jako takového, ale na QtWayland. Desktopové prostředí se pak může snažit jak chce, ale pokud se Qt tváří, že něco udělalo, ale ve skutečnosti to jen ignorovalo, tak se s tím nic dělat nedá. V tomhle případě Qt omezuje i možnosti ty problémy nějakým způsobem obejít. Konkrétně tam je třeba zmíněné, že není možné přepnout na X v době, kdy aplikace ví, že běží na Nvidia kartě. Ono to je logické, protože ten úvodní handshake, kdy se tohle řeší, se děje dlouho před tím, než se spustí první řádek samotné aplikace. Pokud si zvolím knihovnu, která nefunguje správně a někteří výrobci grafických karet konzistentně ignorují vývoj projektů, které ten jejich zázrak používají, tak takovéhle problémy vznikat budou.
Původně jsem ale reagoval na dost negativní tón zprávičky, která obsahuje i vyloženě lži jako "velmi málo pokroku v poslední dekádě" nebo "rozbitou/zabugovanou funkčnost prakticky pro jakékoli běžné scénáře použití". To druhé je dokonce vyvráceno uživateli, kteří to na Waylandu používají a pod to odkazované PR napsali. To jen abych odpověděl na otázku, kde je v té zprávičce problém.
-
Nechápu o co se snažíš. Prostředí řeší notifikace nějakým způsobem, který je společný pro všechny aplikace. Já si pamatuju dobu, kdy to tak nebylo a měl jsem na desktopu notifikace, kde jedna vyskakovala z dolního pravého rohu, další z horního pravého rohu a každá vypadala jinak. Notifikace vyskakují v režii prostředí. Vypadají stejně, vyskakují stejně a umlčují se stejně. To, kam si aplikace chce umístit své okno, s tím vůbec nesouvisí.
-
Jan HrachStříbrný podporovatel
V tom odkazovaném reportu máte pár příkladů. Většinou jsou to víceokenní aplikace, někdy využívající dva monitory.
Mimochodem ono to není o tom že „Já fakt neočekávám, že si aplikace budou vymýšlet kam se na ploše nastěhují.“ -- ten protokol je stejný když ho chce využívat uživatel. Třeba si můžete nadefinovat jak se mají okna po ploše rozházet podle toho co zrovna děláte.
A přidám jeden ze svých příkladů: když jsem s notebookem ve vlaku, letadle atd., kde je málo místa, a chci si číst třeba něco na webu, nejlíp se mi kouká na horní část displeje. Ale tam je lišta okna, menu prohlížeče, a následně často fixní (overlay při scrollování) menu té stránky (dobrý příklad jsou Google Docs). No a tohle řeším tak, že Firefox napozicuju tak, aby byl o 150px vyšší než obrazovka a přečníval nahoru. Ale tohle se blbě dělá myší, natož pak na touchpadu (musím okno chytit s modifikátorem, posunout mimo obrazovku, a pak roztáhnout; a když pak chci zvolit něco v menu nebo přepnout tab, tak to pak musím udělat znova). No a přesně na tohle mám zkratku - níže uváděný příkaz wmctrl. Ve skutečnosti je to modulárnější, aby to fungovalo s různými rozlišeními:
w=$(( `xrandr |grep -oE "current [0-9]+ x [0-9]+," | cut -d " " -f 2 | tr -d ,` + 4 )) h=$(( `xrandr |grep -oE "current [0-9]+ x [0-9]+," | cut -d " " -f 4 | tr -d ,` - 32 )) sleep 0.4 wmctrl -r :ACTIVE: -e 0,-40,-150,$(( $w + 30 )),$(( $h + 120 ))
-
Jan HrachStříbrný podporovatel
Moment, chápu správně, že ve Waylandu není ekvivalent
wmctrl -r :ACTIVE: -e 0,-40,-150,1200,1400
resp. tuto funkcionalitu si řeší kompozitor, takže to zase je různé pod GNOME, KDE, wlroots, někdo to nepodporuje atd.?
Mám klávesové zkratky, které mi nastaví okna na ploše, tohle nepůjde?
-
> Vývojáři si tam stěžují na chybějící vlastnosti, protože používají více oken a oni je nemůžou na Waylandu pozicovat.
Že si nějaká víceokenní appka zapamatuje rozložení a po startu bude vypadat tak, jak jsem ji vypnul? Tak jestli tahle samozřejmost jde proti standardům gnomu, tak je něco hodně špatně.
-
Nejde to proti standardom Gnome. Ide to proti tomu, ze aplikacia nemusi bezat na klasickom obdlznikovom desktope, vid moj komentar vyssie.
Rozlozenie medzi ukoncenim a novym startom aplikacie bude riesit session management; realnu geometriu ale aplikacia nedostane, pretoze vobec nemusi existovat, alebo moze mat viac suradnic, nez s kolkymi aplikacia pocita (a nedokaze spocitat sparse area, kde sa nic nezobrazi).
-
Jan HrachStříbrný podporovatel
> Aplikace si nemá co pamatovat svoje rozložení na monitoru. O to se má starat desktopové prostředí.
OK, na tom něco je. Tj. ty aplikace zmíněné v tom požadavku mají fungovat tak, že si to napoprvé uživatel roztahá po monitorech, a pak už si to pamatuje WM? Okna ale musí mít nějaký identifikátor, protože uživatel může jeden panel nástrojů zavřít a otevřít jiný, nebo si může hodit na chvíli obraz na fullscreen a pak bude chtít zase rozložení zpátky.
Nicméně nějaký způsob jak nastavovat velikosti oken jinak než taháním myší - ukázané wmctrl - by se hodil, čistě z uživatelského hlediska, třeba i pro to prvotní nastavení (abych třeba nemusel obcházet kiosky a přetahovat tam prohlížeče na správná místa a pak doufat že si to WM zapamatuje). (jenže pak už nemůžete aplikaci zabránit, aby si to wmctrl nespustila sama - alespoň dokud nebudou aplikace v brutálních sandboxech)
29. 11. 2023, 03:13 editováno autorem komentáře
-
Lenže bežnému užívateľovi je jedno, kto sa o to postará. Ja napríklad vôbec netuším, kto je zodpovedný za to, že mi vo Windows okná v rámci paint.net po reštarte aplikácie zostanú na svojom mieste. A úprimne ma to vôbec nezaujíma. Prečo by aj malo, veď to pokladám za niečo absolútne normálne. Pokiaľ toto vo Waylande (spoľahlivo) nefunguje a návrhy na implementáciu vyvojári vetujú (lebo chcú, aby GIMP fungoval na hodinkách a dívajú sa 50 rokov do budúcnosti), tak sa nedá diviť domu, že bežný užívateľ, ktorý na PC nepoužíva len browser sa do používania Linuxu moc nehrnie.
-
Tak ked to beznemu pouzivatelovi je jedno ako sa to udeje, tak preco sa stara do toho, ako to bude implementovane? Nema mu to byt jedno?
Bezni pouzivatelia sa kvoli waylandu nehrnu na linux? Zatial co pocas ery X11 sa len hrnuli, aby mohli rucne tunit konfiguraciu engligtenment wm a pisat shellove skripty s xdotool, az ich bolo treba vyhadzovat? Ci?
-
Tak uživateli je celkem jedno, jak je něco implementované. Ale není mu jedno, jak to funguje. A když to nefunguje, tak jde za vývojářem co mu přijde nejrelevantnější, bez ohledu na to, kdo za to doopravdy může.
No a tomu nejbližšímu vývojáři samozřejmě vadí, když za ním uživatelé chodí s problémy které jedna banda neřeší a druhá banda mu zase nedovolí, aby to mohl vyřešit sám. Obzvlášť pokud jde o základní věci, které všude jinde prostě fungují bez větších problémů.
-
Pointa predosleho prispevku bola, ze:
1) tvrdime, ze pouzivatelovi je jedno, ako je nieco implementovane, hlavne nech to funguje
2) napriek tomu sa dany pouzitel bije za konkretne riesenie.
Oba vyroky zjavne nemuze byt pravda. Bud je pravdivy prvy, alebo druhy, ale vzajomne sa vylucuju.
Co je horsie, pokial sa tvarime, ze oba sa nevylucuju, niektore aspekty pouzitelovi urcite budu jedno (napr. technicky dlh v bode 2), ale vyvojarovi nie, tak "jedna banda neresi".
"druha banda nedovoli" je zase nieco, co sa pozaduje po prvej bande; chapem, ze hrabanie sa v zdrojakoch nie je pre bezneho pouzivatela (keby som nemusel, ani ja to nerobim); ale prave to hrabanie v zdrojakoch a chapanie, ako veci funguju prinesu pochopenie, preco je to tak.
-
Z pohladu kompozitora su PCSX2 pouzivatelia; a biju sa za to, aby zahojili svoju aktualnu boliesku, pricom im je jedno, ze tym sposobia velku bolest niekomu inemu.
V daneho PR som pochopil obrovsku davku ignorancie o celej situacii; neskor, ked vysvitlo, ze dany vyvojar ani linux nepouziva, len pre neho nieco musi naportovat a zbuildovat, sa vela vysvetlilo.
-
Jan HrachStříbrný podporovatel
> napriek tomu sa dany pouzitel bije za konkretne riesenie.
On se tu někdo bije za konkrétní řešení? Kdo a jak by to řešení mělo vypadat a jaké řešení je to jiné?
-
Jan HrachStříbrný podporovatel
> Bezni pouzivatelia sa kvoli waylandu nehrnu na linux? Zatial co pocas ery X11 sa len hrnuli, aby mohli rucne tunit konfiguraciu engligtenment wm a pisat shellove skripty s xdotool, az ich bolo treba vyhadzovat?
Ano, přesně tyhle věci jsou důvod, proč Linux používám. Co dělají „běžní uživatelé“ je mi jedno, „běžní uživatelé“ taky třeba neprogramují, nekreslí v různých CADech atd., takže vlastně mít na Linuxu podporu pro tohle je zbytečné? :)
-
> Že deset let čtu jen nadávky, včetně této zprávičky.
Tak začněte číst třeba blogy a prezentace vyvojářů X (dnes vývojářů Waylandu).
> Je někdo z Waylandu vůbec nadšený?
Ano, např. lidé kteří viděli, kolik hacků a ošklivostí je v kódu v Qt aby X11 fungovalo a kolik výkonu toolkit obětuje na to, aby koncový uživatel měl pocit, že ty Xka fungují.
-
Jan HrachStříbrný podporovatel
Jenom jestli ta hlučná menšina nejsou power-useři co opravdu potřebují s počítačem něco dělat, a ta tichá většina lidi co si pustí browser na fullscreen a jsou happy. (přehnaně řečeno)
-
Jan HrachStříbrný podporovatel
Například ten tiše spokojený uživatel Waylandu před nějakou dobou asi nepoužíval žádný způsob připojení se k tomu Waylandu na dálku (a i teď je to docela tragické -- každý si to implementuje po svém - wayvnc pro wlroots věci, GNOME má něco, KDE má něco, naVNCčkovat se na přihlašovací obrazovku asi nejde vůbec), nepoužíval automatizaci myši (xdotool) a vyplňování kláves ze kterých teprve nedávno část implementoval wdotool a wtype (k čemu to je? no třeba pokud máte nějaký management serveru, který běží v nějakém příšerném appletu a nefunguje tam pastování ze schránky, nebo máte stránku co se brání aby tam někdo pastoval hesla z password manageru, tak tam můžete něco snadno pastnout tím, že uděláte
xdotool type "`xclip -out`"), a nyní nepoužívá že by si třeba naskriptoval, že podle toho, kde je, co dělá a kolik má připojených jakých monitorů, tak se mu okna automaticky rozhází po monitorech a virtuálních plochách. -
Jan HrachStříbrný podporovatel
Ne, ty diskutované problémy (VNC, xdotool/wtype, vytvoření screenshotu(!), posun okna klávesovou zkratkou/skriptem) nejsou spacebar heater. Ty první dva pozorováním, že to zjevně někdo implementoval a jsou to populární a udržované aplikace, které lidi používají.
29. 11. 2023, 11:48 editováno autorem komentáře
-
KDE aj Gnome uz nejaky cas[1] podporuju RDP; nie je to uplne dokonala podpora (nevie zatial headless session, handoff session medzi headless a konzolou -- ale pracuje sa na tom), ale stale je to lepsie, ako lubovolny VNC bastl kedy bol.
Vytvorenie screenshotu a hw-akcelerovany[2] screen casting uz tiez funguje nejaky rok; len si to kritici neracili vsimnut, ved co by potom kritizovali, vsak.
No a niektore kompozitory (napr. zrovna ten najskriptovatelnejsi) nedovoluje okna posuvat vobec ;).
[1] dost dlho, aby to bolo v aktualnom Ubuntu LTS
[2] co je nieco, co v X11 nikdy nebolo a ani nebolo mozne to tam dorobit
-
Jan HrachStříbrný podporovatel
> KDE aj Gnome uz nejaky cas[1] podporuju RDP
OK, můžete mě a ostatní čtenáře prosím poučit, až mě to zase potká (naposledy mě to potkalo v Ubuntu 17.10 kde poprvé udělali Wayland default a odpověď byla „to nejde“): jak se 1) připojím k běžící session na fyzickém monitoru, když jsem k počítači připojený přes SSH (to vím že jde, ale bylo to pro každý kompozitor jiné - pro wlroots wayvnc, pro Gnome/Mutter 1, 2, pro KWin nevím; na druhou stranu to gnomí ukazuje API před XDG desktop portal, tj. třeba se to taky někdy standardizuje), 2) připojím k běžícímu display manageru („GDM“) abych se tam mohl na té fyzické obrazovce přihlásit? Display manager by měl taky podporovat to XDG portal API a přes to by to mělo jít?
Vidím, že se situace zlepšuje -- já nemám nic proti Waylandu, až tam dodělají chybějící funkcionalitu, tak to jistě bude mnohem lepší než X (tím, že to není protokol z roku 1980, na který se lepí extensions). Ale sorry, to vaše „co Wayland ještě neumí je spacebar heating“ je mimo zejména pokud byste totéž tvrdil třeba před pár lety, kdy se ani ty dnes podporované věci neuměly.
> No a niektore kompozitory (napr. zrovna ten najskriptovatelnejsi) nedovoluje okna posuvat vobec ;).
O kousek níž píšete o „běžných uživatelích“ - takový běžný uživatel používá tiling WM? :)
29. 11. 2023, 21:01 editováno autorem komentáře
-
[ja.]
A ty jsi ta ticha vetsina? Ja bych byl s tim nalepkovanim pomerne opatrny.Ti uzivatele jsou mozna v mensine, ale v pomerne vyznamne mensine - o tom svedci treba i vytvoreni a udrzovani nekolika dister bez systemd - napr Devuan.
Dalsi treba jako ja, byl spokojen do te doby, dokud nezjistil, ze ne vse je tak pekne slunickove a jednoduchy pozadavek typu "Spust skript pri vypinani systemu pred odpojenim lokalnich disku a internetoveho pripojeni a pockej na jeji dokonceni" dopadne na ctyrech ruznych systemech ruzne, z toho na dvou selze, protoze je tvrdosijne z me neznamych duvodu spousti pozde (po odpojeni lokalnich diskovych jednotek). A kdyz k tomu pripocitam poemrne dlouhou dobu co to resim ....
Takovy uzivatel se pak stane hrube nespokojeny, a silne nedutklivy a myslet si neco zabanovatelneho na adresu autora tech nalepek.
29. 11. 2023, 05:37 editováno autorem komentáře
-
No tak konkretne Devuan ukazuje, ze je to fakt mensina; jej vyznam je porovnatelny s fan klubom Amigy.
A rovnako ako fanklub Amigy nema ziadny vplyv na dalsie smerovanie nicoho, podobne to bude aj s Devuanom. Budu to mat stale tazsie a tazsie, pretoze implementovat niektore ficury s ideologiou "a vyhnime sa systemd, nech to stoji co to stoji" bude coraz narocnejsie, az postupne ludia budu z projektu odpadavat a bude coraz minoritnejsi. Ale drzim im palce, aspon maju nejake hobby.
-
DannyStříbrný podporovatelTo ale neni chyba predictable iface names, ale toho jak vam to system toho dodavatele VM a jeho BIOS reportuje... :-) Za zprasenou implementaci BIOSu systemd fakt nemuze - aneb kdyz vam i na HW to po pridani sitovky presklada veci cislovani PCIe slotu, tak to je bordel na strane vyrobce...
-
To by me zajimalo, co ma bios spolecnyho s tim, ze do systemu pribudou dalsi PCI device a tudiz se vygeneruji jine nazvy, protoze ty se kupodivu (ja vim, to ty nemuzes vedet) generuji prave ze zbernicovych ID tech karet ...
A deje se to zcela samozrejme i u libovolne HW, kdyz se zmeni osazeni kartama.
Jediny zpusob jak to vyresit je napsat pravidla treba na MAC adresy ze? Jo to ty taky nevis ...a nektera distra ta pravidla generuji bydefault pri prvni startu, coz taky nevis ....
-
Jan HrachStříbrný podporovatel
> aneb kdyz vam i na HW to po pridani sitovky presklada veci cislovani PCIe slotu, tak to je bordel na strane vyrobce
Ale bohužel se s tím musíme naučit žít -- kdyby Linux neměl workaroundy na různá chybně se chovající zařízení, tak nefunguje snad nikde. A tohle se běžně děje, já konkrétně jsem to potkal na desce Asus Z10PE-D8 WS (tj. žádný lowend a fakt nevím co lepšího bych měl kupovat místo toho a jak to poznám), kam jsem přidal grafickou kartu a přejmenovaly se síťovky. Ono to možná ani o moc líp nejde -- dneska se běžně dělá, že když připojíte jednu kartu, tak se linky agregují do x16, a když obsadíte více slotů, tak se to rozdělí na několik x8/x4 a předpokládám, že tohle pak dělá ten nepořádek.
Já se na to vybodl, a na strojích, kde je jedna síťovka, to vypínám úplně (a jmenuje se tak navždy eth0 -- nemám zájem aby se přejmenovávala podle aktuálního počasí), na strojích, kde jich je více, nastavuji pojmenování podle MAC adres. A upřímně moc nechápu, proč pojmenování podle MAC adres zrušili, přijde mi to o dost stabilnější než „5. zařízení na 2. sběrnici“, u kterého stejně z manuálu desky těžko vyčtete, která to je, a mnohem rychlejší je bliknout si linkem a podívat se, která LEDka svítí.
-
DannyStříbrný podporovatel
Ano, s tim se musime naucit zit. Proste se po zasahu do HW muze prihodit, ze z enp3s0 se muze najednou stat enp5s0 pote, co se tam prida enp1s0. No a... to same se mohlo stat s eth0/eth1 schematem, kdy se ty sitovky proste prohodili po ekvivalentnim ukonu. Kvuli tomu fakt nemusim brecet na internetech a nadavat na zle systemd.
Pojmenovani podle MAC je zdanlive jevi jako skvele.... ale taky jen do chvile, kdy vam treba umre serverova deska a vy ve snaze system co nejrychleji rozjet vyndate disky z mrtveho stroje a prehodite je do typove stejneho spare chassis. Zrovna na tech serverech to funguje krasne - eno1 je vzdy prvni onboard sitovka, s tim MAC schematem mel clovek krasne eth0 - eth3 a po zapnuti mu tam vyskakali eth4 - eth7... navic se ani neresilo poradi na desce, zalezilo na tom ktery ovladac se probral driv (protoze ano, jsou desky, kde mate treba dva porty s ixgbe a dva s igb).
-
Jan HrachStříbrný podporovatel
> Zrovna na tech serverech to funguje krasne - eno1 je vzdy prvni onboard sitovka
Až na situace, kdy to nefunguje, a zhruba jednou za pět bootů se prohodí :)
> ale taky jen do chvile, kdy vam treba umre serverova deska a vy ve snaze system co nejrychleji rozjet vyndate disky z mrtveho stroje a prehodite je do typove stejneho spare chassis
OK, dobrý příklad, to mě nenapadlo (neměl jsem tento usecase, po přehození to byl typicky trochu jiný HW a tak jsem s nutností změny konfigurace automaticky počítal).
-
Mluvis o tech 99% uzivatelu tuxe, kterym kdyz se toto dostane pred oci, tak konstatuji ze jdou na windows, protoze tam to funguje blbe ale alespon porad stejne blbe? Nezname totiz nikoho, kdo by na tehle zhuverilosti neustale nenarazel na to, ze neco nefunguje. Mluvim o uzivatelich aplikaci kteri proste jen chteji spsutit svoji aplikaci. A ani to nefunguje.
Zadna ticha vetsina neexistuje.
-
Jan HrachStříbrný podporovatel
Já už mám se systemd problémy docela málo často, ono se to tím, jak se to vnutilo uživatelům, kteří v tom našli, nareportovali a opravili bugy, v posledních letech dost zlepšilo :D.
Teď čekám, jestli někdo stejným způsobem opraví systemd-journald, nebo mám jako psát vlastní.
-
Na odroid sbc co mam doma je mali gpu a hw akcelerace bohuzel podporovana jen pro wayland. S puvodnim ubuntu 20 je nepouzitelna pulka starsich gtk aplikaci a vetsina qt, na ubuntu 22.04 o neco lepsi, ale na debian12 bez wayland mi funguje vsechno.
Teda, vsechno krome dbus a pulseaudio - pri soucasnym prihlasenim stejnyho uzivatele na novym display pres xrdp to dela bordel neskutecnej.
Pritom env DISPLAY i *DBUS* se navzajem lisi.
Ohledne KDE, tam zhusta nenabehne plasma pri startu (pokud treba pouziju ext sdc a pri novym prihlaseni uz v systemu neni, ale neni to jedinej pripad). Mam OS nainstalovany z netu (petitboot) na nvme SSD disk, zadnou sd kartu.
Celkove kdyz porovnam s xorg pred 20-ti lety, tak zadny progres jako uzivatel nevidim, spis zhorseni. Narust konfiguraku je radovy, narust chyb taky.
