Vlákno názorů k článku
Rychlejší emulátory terminálu od Doli - Nepamatuju se, že by mě někdy brzdila rychlost...

Nepamatuju se, že by mě někdy brzdila rychlost terminálu... Většinou zdržuje buď spuštěný process, nebo nesmyslně velký výstup, který stejně nikdo reálně nečte, takže ho stačí poslat do /dev/null.

Třeba nedávno propíraný Midnight Commander dokáže při mazání milionů malých souborů pěkně vytížit procesor. Prosím o zdržení se od flame, že to lze efektivněji provést na příkazové řádce pomocí find a rm. Lze, ale víc radosti mi přináší brouzdat po disku v "modrém terminálu", hotl stará škola.
Druhým sw je třeba iptraf nebo cokoliv co sype mraky dat na stdout.

Stará škola sú tie príkazy. Keď sa počítače ovládali ďalekopisom, tie nevedeli midnight commander vykresliť.

To už je liga veteránů. Já jsem padesátník - a dálnopisy šly pryč než jsem nastoupil na vš. GUI pro Unix jsou z roku 1984, XFree jsou z 86. NextSTEP v 88 zobrazoval grafiku v postscriptu. Dálnopisy jsou první polovina 70 let. To je 40 let.

Ja mám 42, používal som také tie zelené terminály. Teda najmä z dôvodu, že boli vždy voľné :)

Jasné, pro každého je stará škola něco jiného, Trochu odcházíme od hlavního tématu. Můj letitý workspace je okno thunderbirdu, web browseru a několik desítek instancí gnome-terminálu, nyní testuji konsole. Často tento počet jen z lenosti zavírat staré okna, Tedy za mne dává smysl trávit čas na vývoji dobrého a ještě lepšího terminálu. Nic víc.

Vypni si Configuration->Verbose operations. Ja to tedy mam zapnute, me to nevadi, kdyz pracuje, at je to videt ;)

Problem aplikaci, ktere vytezuji procesor nejakym vypisovanim rychlejsim, nez je kognitivni rychlost uzivatele je hlavne v tom, ze by mely ty informace nejak rozumneji davkovat na terminal/GUI. Tohle mi prijde vylozene jako upadek IT, ze to resime a neni to standardem.

To, ze se resi pomalost terminalu (nebo jeho vytezovani CPU) je dalsi zvrhlost, ukazuje to jak nedomysleny dnesni svet zacina byt. Nejake historicke Suny (M68K) mely framebufferovou radku delsi nez zobrazitelne pixely na konci pak mohl system ulozit vzorky bitmap. Prikazem slo pak prekopirovat casti framebufferu mezi sebou hardwarove, takze se tam dal ulozit napr. font a ten sypat rychle do framebufferu.

Ono asi ani nejde o to, že by to bylo neoptimálně naprogramované - problém už je samotný design protokolu - od variabilní délky příkazu po velké množství redundantních příkazů. Dost velkou brzdou je konfigurovatelná kompatibilita, a to jak v ncurses, tak v terminálu. Máte několik vrstev, které se chovají dynamicky podle nastavení TERM. Do toho se používá kódování, které má dynamickou velikost, a dynamické zobrazení - 0, 1 nebo 2 znaky.

Terminálové prostředí je žumpa, kterou nikdo 40 let nečistil a režie zpětné kompatibility je brutální. Samotné zobrazení fontů, bitmap nehraje roli.

No nemam pocit, ze by problem byl primarne v "protokolu", i kdyz souhlasim s tim, ze dnesni svet by zaslouzil neco lepsiho.

Podle meho nazoru lze i s tim "co mame" delat efektivni aplikace. Ale je to oboji.

Ted jsem resil hardwarovy programator jednoho vyrobku. Shodou udalosti jsem na to pouzil desku urecenou k uplne jinemu ucelu. Ma to LCD na SPI (+tlacitka), pohani to bohuzel trosku zkripleny SoC, ale i tak se mi povedlo optimalizaci zobrazovani zrychlit refresh tak, ze se ani to seriove rozhrani vlastne ani neda poznat. Ne ze by to byl cil, ale kazda usetrena vterina obsluhy se (mozna) vrati :). Takhle jsem stahnul cas programovani/tes­tovani z cca 25 vterin na 10, opet-pouze upravami kodu kdy se co dela, vymazem zbytecnych prekresleni, odesilani dat, atd.

U některých operací je to solidní brzda. Že si to nepamatujete vy opravdu neznamená, že na to někdo jiný někde nenarazil.

Když všechen výstup přesměruješ do /dev/null, je to samozřejmě řešení. Podobně jako když Tě bolí oči a tak pracuješ s vypnutým monitorem. Akorát to teda má pár nevýhod, jako že třeba nic nevidíš.

Parsovanie wall of text voľnými očami je úplne najlepšia činnosť, vtedy sa využijú výhody rýchleho terminálu. Môže sa človek hrať na hackera z filmu z 90-tych rokov.

Ale na niečo to asi predsa len bude dobré mno. Len si robím blbé vtipy.

> U některých operací je to solidní brzda. Že si to nepamatujete vy opravdu neznamená, že na to někdo jiný někde nenarazil.

Neřekl jsem že takové operace neexistují, jen že na ně já osobně nenarážím. Rád se nechám poučit nějakým příkladem ze života.

> Když všechen výstup přesměruješ do /dev/null, je to samozřejmě řešení. Podobně jako když Tě bolí oči a tak pracuješ s vypnutým monitorem. Akorát to teda má pár nevýhod, jako že třeba nic nevidíš.

Pokud je výstupu tolik, že ho nestíhá terminál vykreslovat, tak bych to rozhodně nestíhal číst. Pokud mě zajímá jen něco, tak si to pošlu do less, grep nebo do souboru. A pokud mě výstup nezajímá (např. mi stačí zkontrolovat exit code), tak je /dev/null zcela adekvátní řešení.

Jo, určitě se to dá různě obejít, ale pokud někdo vyřeší/zmírní primární problém, je to za mě velká pomoc.

Dokazu cist scrolujici text logu rychle ocima uz od davneho pocitacoveho detstvi. Celkem rychle rozpoznavam patterny a je to nejrychlejsi prvotni diagnostika. I pres ruzne inteligentni filtrovaci opensearche,splun­ky,kibany,gre­ylogy a wtf ceho jeste je tohle rychlejsi.
Clovek je na rozpoznavani patternu lepsi jak AI.

Pokud mam pres remote terminal nejakou appku ktera diky nejake zahadne implementaci hloupe prekresluje terminal graficky po blocich, tak je to solidni brzda.Laskavy odbornik na low level graficka rozhrani aplikaci necht promine a vysvetli mi to, ale rozdily v terminalech jsou a ne male. Lisi se to uz libka od libky.

Některé terminály jsou docela pomalé, zvláště ty staré, ale ani Gnome Terminál, který dennodenně používám není, co se týče rychlosti (a dneska i funkcí) extra výhra. Rychlost terminálu se může ukázat například při skrolování v textovém editoru, a pokud terminál nestíhá, může se rozhodit synchronizace a začne problikávat. Pokud bych měl standardní velikost 80x25 znaků, tak asi nikdy nebudu mít problém, ale když mám terminál přes celou obrazovku a používám 10pt písmo což je cca 250x60 tak už je rychlost terminálu poznat.

Taky je potřeba rozlišovat propustnost a latenci, třeba VTE bylo vždycky nejrychlejší v benchmarcích typu "cat bible.txt", zatímco při pohybu kurzorem v mc zvládlo překreslit sotva každý druhý řádek.

Docela solidne to vie zabrzdit rsync. V terminaloch beziacich pod akcelerovanym gui to nemusi byt az tak viditelne, ale na konzole s vesafb/efifb to moze byt dost zasadna chyba.

Obist sa to da aj pomocou screenu.

Jak tohle řeší použití screenu?

pustíš to přes screen a ten odpojíš od terminálu. Potom operaci nebrzdí pomalý terminál.

OK, dík.

S pomalostí jde ruku v ruce spotřeba. Čím rychleji se provede update pixmapy okna, tím dřív se GPU vypne, tím dýl baterie vydrží.

Dnes dělám většinu textové práce s PineBook Pro, což je ultra low power ARM notebook, který umí pracovat (= dobrý jas, hraje hudba přes bluetooth, pár terminálů s nvimem nebo helixem, prohlížeč) v jednociferných Wattech. Když v GNOME Terminalu (nebo libovolné jiné libvte implementaci) v neovimu držím mezerník, spotřeba vyleze na 10 W. Když udělám totéž v terminálu Foot (GPU wayland), spotřeba z klidových 6 W měřitelně nestoupne. V obou případech je rychlost kurzoru (~framerate) stejná.

Z klávesnice jdou události konstantní rychlostí, a pokud terminál stíhá, tak framerate musí být stejný. Něco jiného je počet na obsloužení jednoho znaku.

Vždyť to píšu, framerate v obou případech stejný. Lišilo se to ve spotřebě, tedy jak dlouho se každý frame počítal.