Hyper a Black Screen, emulátory terminálů postavené na webových technologiích

OMG! Ubuntu! představuje emulátor terminálu Hyper (GitHub) postavený na webových technologiích (HTML, CSS a JavaScript). V diskusi k článku je zmíněn podobný emulátor terminálu Black Screen. Hyper i Black Screen používají framework Electron, stejně jako editor Atom nebo vývojové prostředí Visual Studio Code.

5.12.2016 06:00 | Ladislav Hagara | Zajímavý software

Komentáře

[R]

To je bomba - na emulaciu terminalu s 8-bitovym procesorom zo 70. rokov teraz potrebujeme 64-bitovy procesor a niekolko GB RAM. Tomu sa hovori "pokrok".

[Kate]

Ne že by se mi terminál napsaný ve webových technologiích líbil, ale těch několik GB RAM bych chtěla vidět a... Kolik terminálových emulátorů co se dneska používají by na tom CPU ze 70. let šlo zkompilovat? On má uživatel dnes přece jen trochu vyšší nároky na pohodlí práce, když to PC umožní.

[Rezervní Polská Kotace]

Vyšší nároky? Třeba aby se terminál nezahlcoval při výpisu většího množství textu. Nebo aby zapadal do zbytku GUI/desktopu (look and feel). Navíc tohle je ukázkový příklad bloatwaru - proč kvůli tak jednoduché věci, jako je terminál, do toho zatahovat jádro prohlížeče s miliony řádku kódu a spoustou dalších knihoven?

Za smysluplné to nepovažuji, spíš mi přijde, ze se někdo naučil používat kladivo (javascript, CSS, HTML) a ted mu každá úloha připadá jako hřebík.

[skunkOS]

+1

Stačí tilda.

[Kate]

Ale vždyť to vůbec nepopírám, aplikace v Electronu také nemusím. Osobně používám Terminix, protože mi vyhovuje ovládáním, je rychlý, má šikovný tiling a do prostředí zapadá skvěle. Jen mi přišel vtipný ten povzdech nad nutností mít moderní CPU. Z běžně používaných terminálů by jich třeba na 286 moc nefungovalo.

[hypvofxy]

To asi byl povzdech nad tim, ze vykon sice od te doby hodne narostl, ale misto toho, abychom ho vyuzivali, tak ho promrhavame. S tim normalne problem nemam, pokud to prinasi nejake jine vyhody, ale treba u HTML ty vyhody opravdu nevidim a jedinym dusledkem je, ze se renderovani brutalne zpomali a kvuli zvysene komplexite se potencialne zabuguje.

BTW, je fajn tu potkat linuxacku. Ahoj! ;)

[Kate]

Já jen nemám ráda to přehánění. Jinak by mě opravdu zajímalo v čem to má mít tu "killer feature", která by mě přesvědčila používat to. U Atomu a Visual Studio Code ještě chápu tu snadnou rozšiřitelnost editoru (U Atomu byla fajn, ale vyhrál to právě rychlostí Sublime). Ale u terminálu... Asi mám malou představivost.

[hypvofxy]

No, asi tak nejak. V ramci nejakeho experimentalniho projektu by urcite mohl byt zajimavy terminal, ktery umi na vystup produkovat obecne jakekoliv dokumenty - tedy nikoliv pouze text s jednoduchym formatovanim pres escape sekvence, ale i treba obrazky. Presne jako to ma TempleOS.

Na to ale v prvni rade musi existovat zpusob, jak z nezavisleho programu terminalu tyhle informace sdelit. Pak si umim predstavit, ze treba zadam prikaz viewimage, ktery nacte obrazek a posle ho na stdout jako nejaky stream bajtu, kteremu ten terminal rozumi a umi ho zpracovat a zobrazit.

Ani v tomhle pripade by ale HTML nedavalo smysl. Pro vystup z aplikace se da pouzit cokoliv jednodussiho na zpracovani/generovani (treba alespon validni XML, kdyz uz by to bylo textove) a pro zobrazeni se da pouzit primo nejaka GUI knihovna, kdyz ten vstup stejne nekdo musel predzpracovat...

[Kate]

To by zajímavé být mohlo. Třeba by to mohl zajišťovat speciální shell, který by ty informace doplňoval. Takže například ls s (hodně drobnými) náhledy obrázků a podobně.

Jistě že by na to byla dobrá nějaká normální GUI knihovna, ale v tom Electronu to je holt všechno po ruce. :) Uvidíme co se z toho vyvine, třeba se to na nějaké speciální využití hodit bude. A proč brečet nad tím že máme, i když ne pro každého zrovna dobrou, alternativu :)

[hypvofxy]

Aby se pak prave casem nestalo, ze uz jina alternativa nebude...

[Kate]

Tak toho bych se skutečně nebála :) Nebo ty už vidíš ty adminy tady, nahrazující své vymazlené terminály zapadající do DE za webovou věc? Nebo programátory existujících terminálových emulátorů, kteří tohle vidí, hodí flintu do žita a řeknou si "ANO! Tohle je cesta! Končíme s tím a přecházíme na Hyper!"? :)

[pavlix]

Přesně. Terminál není systemd. :D

[mirec]

Čo systemd-consoled?

[Kate]

To je něco úplně jiného. A jak si to tak pročítám, nemusela by to být úplně zlá myšlenka. Uvidíme jak to dopadne.

[hypvofxy]

Ne, ale staci, aby se objevily escape sekvence, ktere bezny terminal nezpracuje, a par vyznamnejsich programu, co je vyuziva. Pak staci, abys vlivem okolnosti (chybejici alternativa, firemni rozhodnuti) musela takovy program pouzit. Uz musis pouzit jiny terminal. A kdo vi, jestli za chvili misto Waylandu nekdo neprijde s Nodelandem, ktery z celeho desktopu udela jeden obri browser a vsechno bude na pozadi HTML/CSS/JS? Musime byt ve strehu proti temnym silam weboveho zla nez nejaky JavaScriptovy ninja na cernem koni prerenderuje vsechno kompilovane.

[mirec]

xterm už dávno podporuje sixel, ale akosi sa to nepoužíva.

[hypvofxy]

Sixel je od toho, co jsem mel na mysli - a co pouziva treba ten TempleOS - porad na hony vzdalene, nicmene jsem to neznal. Diky za info.

[Bystroushaak]

No, asi tak nejak. V ramci nejakeho experimentalniho projektu by urcite mohl byt zajimavy terminal, ktery umi na vystup produkovat obecne jakekoliv dokumenty - tedy nikoliv pouze text s jednoduchym formatovanim pres escape sekvence, ale i treba obrazky. Presne jako to ma TempleOS.

Tohle umí plan9 btw.

Jinak unixové terminály jsou neskutečná sračka plná bolesti a utrpení. To nejlepší, co by se s nimi dalo udělat je vyhodit je a už nikdy o nich nemluvit.

[xkucf03]

WTF? Na složitější věci a grafiku máš X, VNC, Spice… nebo [zvracející smajlík] HTTP/HTML/JavaScript.

Co všechno bys chtěl cpát do terminálu? Vždyť na tom je krásná právě ta jednoduchost a princip. O zobrazování obrázků a jiných dokumentů se starají jiné nástroje než emulátor terminálu (ale snadno se to naskriptuje dohromady).

[hypvofxy]

Mezi terminalem, editorem a prohlizecem dokumentu nemusi nutne byt rozdil. Misto terminalu v podstate muzes mit "virtualni" dokument a makro, ktere kazdy zadany radek podle urcitych pravidel vyhodnoti. Pochopitelne je otazka, jak to cele pojmout z hlediska UI, klientskeho softwaru apod. Proto jsem psal v ramci experimentalniho projektu.

[xkucf03]

Ono je to ale odvozené od toho, jaké rozhraní má proces: pole textových řetězců (argumentů), jeden vstupní proud, dva výstupní a proměnné prostředí. Terminál a shell je vlastně UI pro spouštění procesů.

[hypvofxy]

Tomu moc nerozumim. Na vstup a vystup/y muzou misto "suroveho" proudu bajtu chodit ty dokumenty a pokud s tim bude pocitat vsechen software, tak muzes pouzivat roury, presmerovani apod. stejne jako dosud.

[pavlix]

Od té doby, co stavím všechny osobní projekty nad JSON/YAML to dává dokonalý smysl. :)

[xkucf03]

Jak si u JSONu/YAMLu poradíš se spojováním proudů z více zdrojů? Příklad:

(příkaz1; příkaz2; příkaz3) | příkaz4 > soubor

nebo třeba:

cat *.xyz | příkaz

Výsledkem prostého spojení dvou JSONů není validní JSON; nevím, jak u YAMLu.

[Josef Kufner]

To je asi hlavní důvod, proč všechny pokusy o objektový shell (a že jich bylo) vždy skončily neúspěchem.

[xkucf03]

Není to nic principiálně nemožného, v hlavě to mám vymyšlené už dávno Jen ta implementace je pracná: 1) formát, který lze řetězit, to je ta lehčí část, 2) rozšířit spoustu unixových nástrojů, aby s tím formátem pracovaly + dopsat nějaké nové (obdoba projekce a restrikce z relačních databází).

[hypvofxy]

No, ja mam uz velmi dlouho zalusk co nejvic standardnich linuxovych nastroju proste nekompatibilne prepsat (zachovavat kompletni kompatibilitu, aby vystup nadale byl zpracovatelny stejnymi skripty apod., by bylo ukrutne prace). Kod vetsiny stavajicich je proste totalni hnus, do ktereho se mi nechce jakekoliv upravy zanaset. Jestli se k tomu nekdy dokopu, to nevim...

[R]

Mozes to potom poslat do systemd...

[hypvofxy]

OK.

[deda.jabko]

muzou misto "suroveho" proudu bajtu chodit ty dokumenty a pokud s tim bude pocitat vsechen software, tak muzes pouzivat roury, presmerovani apod. stejne jako dosud.

Kdybys to mel obecnejsi a misto dokumentu pouzil obecne objekty, mohl bys takto vynalezt Powershell.

[pavlix]

Dokument může obsahovat obecný objekt a tudíž to bylo vynalezeno dávno před powershellem.

[xkucf03]

Příloha:

• terminál - grafy.png (63743 bytů)

Tohle si chci někdy napsat – v podstatě spojení unixových rour a relačních databází… ale to je čistě o těch nástrojích, není potřeba kvůli tomu měnit nic v shellu natož terminálu.

Z předchozích příspěvků jsem nabyl dojmu, že by někteří chtěli, aby emulátor terminálu zobrazoval grafiku nebo nějaké „dokumenty“ a že text jim je málo. Jenže jak daleko by to mělo zajít? Má to zobrazovat JPEG, PNG, GIF? Má to přehrávat hudbu? (dnes umí terminál jen pípnout/cinknout – mohl by hrát melodie nebo dokonce mluvit) Bude to zobrazovat PDF, PS, vzorce z LaTeXu, ODF? Taky by to mohlo přehrávat video nebo 3D grafiku…

Podle mého je textový výstup, tak akorát, dál bych nešel (stačí unicode včetně rámečků a symbolů; i nějaké ty grafy se tím dají kreslit). Mohlo by to být ještě jednodušší/čistější, ale to už je ta historická zátěž (#27). Víc bych tam nepřidával – na jednu stranu by to bylo pořád málo, pořád by tam něco chybělo a na druhou stranu složitost (např. na implementaci terminálu nebo i jeho údržbu či audit) strmě poroste. Kdo chce grafiku a multimédia, ten má dostatek jiných protokolů; terminál bych nechal textový.

Když už obrázky nebo dokumenty v terminálu, tak unixový přístup podle mého je nastavit si proměnnou prostředí, která řekne, kam se má kreslit (třeba nějaké okno vedle terminálu) a pak nasměrovat výstupní proud přes rouru do programu, který dekóduje daný formát, přečte si proměnnou prostředí a obrázek vykreslí. Nebo – a to by bylo i celkem užitečné – mít puštěný WWW prohlížeč, který by naslouchal na unixovém soketu, do kterého bys mu (např. přes socat ze skriptu) mohl poslat (X)HTML a prohlížeč by ho hned vykreslil. V podstatě takové obrácené HTTP. Obrázky, styly, JavaScripty by tam šlo protlačit stejně, jako se to dělá v e-mailu (MIME). Ideálně tam mít i možnost inkrementálních změn, např. si zaregistrovat nějakou JS funkci, která se zavolá, když po soketu přijdou data s určitou hlavičkou. Opačným směrem by šlo zase volat JS, který by zapisoval do jiného soketu (na pozadí by sis spustil třeba socat, četl proud dat a posílal je třeba přes xargs dál) Pak by člověk mohl mít v jedné půlce obrazovky prohlížeč a v druhé terminál. To by v některých případech mohlo být užitečné, ale držel bych se toho, že každý nástroj dělá to svoje (relativně omezenou jednoduchou činnost – přičemž síla je v tom, že tyto jednoduché nástroje můžu kombinovat) a nespojoval bych terminál a WWW prohlížeč do jednoho programu. Nebo se na doménové sokety vykašlat a použít obyčejný HTTP server na localhostu + PHP skript nebo javovský servlet, který tu komunikaci zprostředkuje (pak není potřeba nijak upravovat prohlížeč a lze použít libovolný s podporou AJAXu).

[hypvofxy]

Jakmile tam umoznis pracovat s grafikou, tak uz konkretni formaty jsou naprosto nepodstatne. V podstate by se to dalo natolik zobecnit, ze uz zadna jina vrstva ani existovat nemusi, a neexistuje striktne jakykoliv rozdil mezi emulatorem terminalu a beznym oknem. Pokud vystup nejakeho programu, ktery neco vykresluje na obrazovku, nekam posles, tak ho muzes zaznamenat a nejak s nim pracovat. Zalezi jen na tom, zda s tim ten okolni SW svet pocita.

Ze bych si to umel predstavit fakt nejak konkretne, abych tu z fleku sepsal specifikaci, to urcite ne. Mozna se to ukaze jako technicky prakticky neproveditelne / neprakticke (tj. treba vykon dost dobry na provozovani her). Ale prijde mi to jako cesta, kam by se vyzkum mohl ubirat, takze jako ten experimentalni projekt by to obstalo.

[xkucf03]

1) Výhodou textu je, že ho můžu snadno zkopírovat, upravit a vložit jinam.

2) Zobrazování grafiky je stále polovičaté řešení – hodilo by se obsluhovat události, např. klikání myší do vykreslených obrázků.

3) Gratuluji, vynalezl jsi Xorg (Wayland, VNC, Spice atd.).

(další věc je zvuk, video, akcelerovaná 3D grafika)

[hypvofxy]

1) Výhodou textu je, že ho můžu snadno zkopírovat, upravit a vložit jinam.

O ruseni textu nebyla rec a zalezi opet jen na tom, co bude vystupem toho programu, resp. obsahem nejakeho dokumentu.

2) Zobrazování grafiky je stále polovičaté řešení – hodilo by se obsluhovat události, např. klikání myší do vykreslených obrázků.

Stejne jako vstup z klavesnice se i vstup z mysi muze posilat na stdin.

3) Gratuluji, vynalezl jsi Xorg (Wayland, VNC, Spice atd.).

Ja se predevsim nesnazim tady nic vynalezt, jen hrube rozvijim myslenky s odkazem na ten TempleOS, kde jsem videl neco podobneho, a porad si nejsem jisty, ze se na to nekdo zkusil podivat.

(další věc je zvuk, video, akcelerovaná 3D grafika)

To tam muze byt obsazene uplne trivialne. Zda to je technicky schudne by bylo predmetem toho vyzkumu.

[Bystroushaak]

Ja se predevsim nesnazim tady nic vynalezt, jen hrube rozvijim myslenky s odkazem na ten TempleOS, kde jsem videl neco podobneho, a porad si nejsem jisty, ze se na to nekdo zkusil podivat.

Já na to kdysi koukal. Znovu bych rád připoměl ten plan9, které tohle má vyřešené asi tak 26 let a linux už z něj spoustu věcí převzal.

[hypvofxy]

Tak ty jsi tusim ten, kdo mi o TempleOS puvodne rekl. Mel jsem na mysli spis ostatni diskutujici.

[mirec]

Mne by stačilo niečo také. Myslím, že interakcia s myšou nie je až taký problém.

[Bystroushaak]

Co všechno bys chtěl cpát do terminálu?

Záleží čemu říkáš terminál. Zrovna tty je mrdka plesnivá zatížená 40 lety historie, kde je problém snad úplně všechno, včetně takových blbostí, jako korektně asynchronně odchytávat stisky kláves. Někde jsem viděl dobrý článek, ale jsem líný ho hledat. A ta zábava s unicode a šířkou různých znaků, které se prostě nedají vypočítat, pokud je chceš zobrazovat v různých „dialogových oknech“, heh. Kill me.

[xkucf03]

Že je tam jakási historická zátěž, s tím souhlasím, ale to je cena ze evoluční přístup a zpětnou kompatibilitu (a dá se s tím celkem v pohodě žít). S tou šířkou znaků máš pravdu (to je obecně problém všech jazyků, platforem, formátů… vzniklých před vícebajtovým kódováním).

Ale podle předchozího komentáře (terminal, ktery umi na vystup produkovat obecne jakekoliv dokumenty - tedy nikoliv pouze text s jednoduchym formatovanim pres escape sekvence, ale i treba obrazky), na který reaguješ, mi přišlo, že bys tam toho chtěl nacpat mnohem víc – proto jsem psal, že od toho jsou jiné protokoly.

[mirec]

Lenže to omnoho viac sa používa už teraz napr. ranger s podporou náhľadov k súborom. Keby bola rozšírená aspoň podpora grafiky cez sixel menuselo by sa to riešiť takto hackoidne cez w3mimgdisplay.

[xkucf03]

Jaký má smysl to používat místo Xorg nebo Waylandu? Přijde mi to jako nějaký zvláštní fetiš – na jednu stranu textový režim, ale zároveň tam chtít mít obrázky.

[pavlix]

Nemá to spíše smysl používat když už tak spíše místo textového terminálu?

[xkucf03]

Tím „to“ jsem myslel kombinaci programu ranger a speciálního terminálu – to mi moc smysl nedává a podle mého to trpí nevýhodami obou přístupů – je to omezené textovým režimem* a zároveň to neběží všude (potřebuji speciální terminál). To už by bylo lepší to napsat nad Qt, GTK nebo jinou knihovnou a mít plnohodnotnou GUI aplikaci – ovládání jako vi/emacs/mc tam klidně může být taky, tomu GUI nijak nebrání.

*) GUI není zdaleka jen zobrazování obrázků někde v rohu, jde o barvy, řezy a velikosti písem, grafiku, barevné přechody, možnost ovládání myší, schránku…

[mirec]

Každý terminál, ktorý zvláda niektoré escape sekvencie je svojim spôsobom špeciálny. Otázka znie skôr, prečo grafika nie je súčasťou väčšiny emulátorov terminálu + vo framebufferi na linuxe.

Ak by to bolo de facto štandardom tak ako je teraz VT100 / VT102 mohli by sme bežne použíať príkazy rozšírené napríklad o náhľady k súborom.

[platYpu]

Tak většina těch opravdových zcela jistě:

ArcTel (asi nejrozšířenější český - viz http://www.fbl.cz/), Kermit (jeden z nejpoužívanějších a nejpřenositelněších vůbec http://www.kermitproject.org/), ... atd.

Který Vám chybí ... ?

[hypvofxy]

Narocnejsi to bude urcite, ale o to ani tolik nejde. HTML je sracka i pro pouziti na webu a zacit to tahat do vyvoje desktopovych aplikaci uz je fakt na hlavu. Prijde mi to jako sazet design programu v LaTeXu. Vzhled programu prece neni dokument, na jejichz stylovani bylo HTML urceno. O svem nazoru na JavaScript radeji pomlcim, nebo to tady se mnou svihne.

s/hyper/hipster/g

[hypvofxy]

Prasata.

[pacholik]

Když se kvůli tomu pár lidí naučí pracovat s terminálem tak proč ne.