Ad Termy: vypadá to zajímavě, ale vážně by někdo chtěl používat elektronový terminál?
to by chtelo zjistit kolik to v ramce zere. nejak jsem nepochopil to napojeni na vscode - bez toho to nefunguje?
Pravděpodobně využívá jeho LSP implementaci a s tím spojené doplňky ...
Tak jsem to zkusil.
Startuje to 5 sekund. Spoustim appimage a mam rotacni hdd. Konsole se spousti do 1 sekundy.
RAMky to zere 175 MB, pricemz Konsole zere 25 MB. Jojo, ja vim, sdilene pameti atd, ale resit to nebudu.
Jinak to reaguje svizne a mozna by to bylo i zajimave. Ale to je jedno, protoze to ignoruje moje desktopove prostredi (KDE), a ma to vlastni (zadny) spodni a pravy ramecek okna a tudiz mam problem poznat kde jeste je terminal a kde uz ne. Vypada to hezky, ale je to nahouby.
Vážně uživatelé řeší, jaká je na pozadí technologie? Nezajímá je spíš, jaké funkce ta aplikace poskytuje, jak je chybová, jak se používá?
Neřeší. A pak se diví, proč jejich zánovní počítač (nadstandardní konfigurace) "nefunguje". A to maji spuštěný "jen" prohlížeč, korporátní kecátko a videokonferenci...
A pak se diví,
Muzou se jen divit kdyz ta technologie je pouzita nespravne nebo teprve kdyz neco nefunguje protoze technologie na to neni vhodna.
Já od terminálu chci aby to fungovalo rychle a bralo málo. Kdyby to umělo karty, používal bych Alacritty.
Uživatelé emulátorů konzolí asi nebudou běžní uživatelé a je dost možné, že řeší i to. Když tak namátkou zašátrám v paměti, tak i zde na root.cz je běžné řešit na čem to běží, proč se to někomu líbí, proč ne a tak ... ostatně i o tom je toto vlákno ...
Já to třeba řeším a už několikrát jsem si něco nenaninstlaoval a hledal jiné alternativy, protože bych s tím musel instalovat hromadu bordelu. V mém případě často nějaká mini apka, která vyžaduje další desítky nebo stovky mega s knihovnami KDE ...
11. 3. 2021, 11:37 editováno autorem komentáře
Uživatelé, kteří ovládají svůj PC, zajímá, kolik zdrojů si ten terminál vezme. Jak se bude chovat, když se budou na výstup vypisovat desítky megabajtů textů.
Terminál pro mě musí být rychlý a nežrat STO mega jen co to zapnu.
Na sto mega nepotřebujete nekonečnou RAM. Naopak v případě profesionálů využívajících počítač je víc RAM mnohem levnější, než čas toho člověka.
Holt, na hloupou otázku hloupá odpověď. Ne každý je profesionál, ne každý má tolik RAM kolik potřebuje, a i velká RAM má své limity.
A taky ne každý potřebuje používat terminál. Nicméně to, že existují lidé, kterým aplikace nevyhovuje, neznamená, že neexistuje nikdo, komu by vyhovovala.
Pro mne třeba terminál v posledních letech zase získává na důležitosti, a docela mi vadí, že vývoj terminálů docela ustrnul – poloprůhledné pozadí a emoji nejsou vrchol toho, co bych od terminálu v roce 2021 čekal. Takže tenhle terminál určitě vyzkouším. Například proto, že si myslím, že moderní terminál musí být silný v možnostech UI a také snadno rozšiřitelný laiky – což obojí mohou aplikace pod Elektronem splňovat mnohem snáz, než aplikace napsané v C/C++.
Že terminál po přihlášení startuje 5 sekund mne fakt netrápí, 5 sekund jednou za čtrnáct dní snesu a IDE i prohlížeč startují déle, takže terminál pořád nastartuje jako první.
Teď už jen doufejte, že máte vhodné desktopové prostředí, do kterého ten terminál bude dobře pasovat, a poznáte kde končí okno terminálu a kde začíná jiné.
Moje RAM bude použita na skutečně důležité věci, kompilační artefakty, výpočetní mezivýsledky atp atp.
Opravdu nepotřebuji, aby terminál startoval 5 sekund a žral 250+ MB jenom to mlaskne. Proto používám terminál efektivní a nenáročný (a zároveň featurově lepší).
Ale uživatelé snad řeší a měli by řešit věci jako bezpečnost. Electron nepodporuje sdílený runtime a obecně skoro všechny runtime knihovny se bundlují do jednoho balíku. Je to jen na vývojáři aplikace, aby řešil všechny security patche a co nejrychleji vydával nové releasy. Oproti tomu "tradiční" terminály v linuxu se updatují s operačním systémem včetně všech závislostí. Tak je asi na každém, jestli mu ta jednoduchost použití stojí za to. U přehrávače hudby, který může běžet v sandboxu asi problém není, ale u terminálu bych dost váhal.
To, že se aplikace nesou vše s sebou, je dnes už běžná věc, a distribuce se s tím musí umět vypořádat. Bez ohledu na to, zda je to Elektron, aplikace napsaná v Go, v Javě, Flatpak nebo Docker image.
Co se týče opravy bezpečnostních chyb, je naivní myslet si, že se to obejde bez vývojáře aplikace. Bez vývojáře aplikace se obejde oprava implementace, bez změny rozhraní a sémantiky. Jenže zdaleka ne všechny chyby jsou takové – a pokud jsou to různé buffer overflow, je ostuda, že se vůbec ještě někde takové chyby vyskytují. Spousta bezpečnostních chyb je ale přímo v návrhu knihovny nebo protokolu a opravu takové chyby pak musí zapracovat i autor aplikace. Takže nemá smysl vymýšlet, jak se při opravách chyb obejít bez vývojářů. Naopak je potřeba řešit, jak opravu od vývojáře co nejrychleji dostat k uživatelům.
Například pokud je chyba v JVM, tak to podle tebe mají řešit autoři všech javovských programů, místo abych si prostě do počítače nainstaloval opravenou verzi? Zkrácení doby k instalaci opravy se právě udělá tím, že to nebude závislé na jednom člověku.
Do počítače si klidně nainstalovat opravenou verzi můžete, ale to neovlivní verze zabalené v Docker obrazech. A Docker obrazy jsou nejsnazší způsob, jak šířit serverové aplikace napsané v Javě.
Na vývojáři to závisí tak jako tak, jak už jsem psal v předchozím komentáři. Novou verzi stejně vydává, takže jde o to, aby se ta nová verze co nejrychleji dostala do distribucí. Tj. aby to nečekalo, až nějaký jiný jeden člověk bude mít čas udělat z toho distribuční balíček.
Jasně, instalace interaktivního terminálu je stejný use case jako deploy javovského backendu. Měl jsem si dřív uvědomit s kým diskutuju.
Netušil jsme, že se stále bavíme jen o interaktivním terminálu. Když jste se ptal na aktualizaci Javy, který interaktivní terminál je napsaný v Javě?
"Jenže zdaleka ne všechny chyby jsou takové"
A tedy některé chyby jsou takové, neboli některé opravy chyb knihoven nemusí autor aplikace vůbec řešit. A tedy aplikace šířená distribučními kanály má výhodu oproti elektronu atd.
Což je to, co měl KubaV na mysli, a ten Váš sáhodlouhý výplod byl celkem zbytečný.
Ale hlavně - už jste ten terminál/shell konečně zkusil?
Pokud autor aplikace neřeší opravy knihoven, ta aplikace stejně nebude bezpečná. Elektronová aplikace klidně může být šířena distribučními kanály. Pokud si s takovou aplikací neumí distribuce poradit, je to problém té distribuce. Pokud byste chtěl porovnávat výhody a nevýhody způsobu šíření aplikace, musíte porovnávat všechny případy – ne si vybrat jeden, který se vám zrovna hodí.
Ale hlavně - už jste ten terminál/shell konečně zkusil?
Co je na tom hlavního? A proč konečně – já nejsem povinen vám hlásit, kdy jsem to zkoušel. Ano, Termy jsem zkusil.
Výborně. Zajimaly by mě zkušenosti. Povinen nejsem, ale získal jsem dojem že o ten program máte zájem.
Zkoušel jsem to asi 5 minut a zatím to vypadá, že funkcionalita odpovídá té deklarované verzi 0.málo – tj. k používání to ještě moc není.
"To, že se aplikace nesou vše s sebou, je dnes už běžná věc, a distribuce se s tím musí umět vypořádat"
Aha, a jak se s tím tedy mají vypořádat? Ona se s tím nějaký distribuce v konstruktivním smyslu umí "vypořádat"?
ne, vyporada se s tim uzivatel, tak ze nebude instalovat kazdou kravinu v elektronu ;-) a zrovna terminal v alektronu je jeden z NEJhorsich pripadu pouziti do praxe (pro autora to muze byt prinosna "skola")
druhej stejne blbej je pred casem v sklizni predstavanej color picker v elektronu :))
Umí se s tím vypořádat ta distribuce, která se nebude pokoušet ten balíček od autora rozbít na prvočinitele, ale použije celý ten balík od autora a zabalí ho do distribučního balíku.
Ono to třeba s Elektronem ani moc jinak dělat nejde. Ale vím, že dříve se některé distribuce takhle pokoušely rozbíjet javovské aplikace a místo JARek (knihoven) dodávaných spolu s aplikací použít distribuční JARka.
Mozna to vadi, mozna ne. To ukaze praxe.
Webove aplikace maji potencial byt zrychlovany pomoci WA. A kdyby ne a skutecne z teto vecicky byl lenochod pomaly, pak muze porad poslouzit alespon jako uzitecny proof of concept. A dalsi iterace muze byt cela napsana v Rustu.
Samozřejmě, že nechtěl. Elektron je zlo. Někde si to dokážu představit, ale zrovna u terminálu fakt ne.
Aale. Takych terminalov je kopec, napr https://github.com/Eugeny/terminus (pouzivam pod woknami)
Ja mám z takových konsolí poněkud rozpačité pocity. Asi většinu podstatného dokážu pomoci zsh a ohmyzsh, intelisense funguje v podstatě velmi dobře a běží to i v SSH a “tupém” terminálu a podpoře git v promptu ani nemluvě. Jediná zajímavá fičura je ten embedded editor, ale na druhou stranu to samé lze dokázat i pomoci tmux a spacevim (zvláštně lang layers jsou super easy nastavit).
RE: Termy
Když už nějaké vytuňování terminálu, není lepší cesta přes kombinaci s REPLem nějakého vyššího jazyka. Např: https://xon.sh/
Tak neviem co vsetko teda chcete robit z toho terminalu ale kedysi bola myslim aj instalacia Oracle urobene ako shell script.
No a pokial teda urobit nieco co uz naozaj shell nezvlada, napriklad parsovat a filtrovat JSON, YAML, ...vtedy kludne siahnem po Java shebang 'scripte'. Nejaku Javu spustam asi este pred terminalom takze rychlost je bez problemov.
Ono nejde ani tak o to, co shell zvládá a co nezvládá (dají se z něj spouštět externí programy, takže prakticky zvládá cokoli). Jde o to, jak snadné je ten kód spravovat. Shell se na rozsáhlejší kód nehodí – má spoustu temných zákoutí syntaxe i chování, různé interprety se liší, syntaxe složitějších konstrukcí je nepřehledná, nemá podporu ve vývojových nástrojích…
Ja nechápem na čo niekto používa Electron toolkit, keď aj v JavaScripte je možné využiť toolkity ako QT, GTK a pod. Pri čom vyžaduje omnoho menej prostriedkov, menej výkonu, pamäte, a ešte navyše sa vedia prispôsobiť systému "by default". Viď napríklad NodeGUI, dokonca s podporou pre frameworky ako React, Vue a Svelte.
Můžete uvést příklad nějaké aplikace, která má UI napsané v HTML, funguje pod Windows, MacOS a Linuxem, je napsaná v JavaScriptu a používá Qt nebo GTK?
To ale nemá UI napsané v HTML nýbrž v Qt. To je dost velká bariéra. Vtip elektronových aplikací je právě v tom, že se používají webové technologie, které zná spousta lidí a mají nízký vstupní práh.
Ono vieš písať UI v HTML a reálne to pak beží nie v Chromiu ale v QT, pozri detailnejšie ten NodeGUI
Díval jsem se na to a žádné HTML jsem tam nenašel. Vidím tam akorát možnost používat React nebo Vue se speciálními komponentami NodeGUI. Když už nějakou knihovnu komponent používám, mám smůlu. Kdybych chtěl použít Svelte, mám smůlu.
Vidím jediný případ, kdy dává smysl to použít – už mám napsané nějaké aplikace v Qt, chci pokračovat v psaní Qt aplikací a z nějakého důvodu je chci začít psát v JS. Ale opačná cesta – píšu v JS a začnu používat NodeGUI – nedává žádný smysl. Nemá to žádnou výhodu, jen samé nevýhody.
Ale v JavaScripte je v GTK viacero aplikácií v Gnome čo sú defaultne predinštalované sú zväčša práve v JavaScripte. Niektoré z týchto: https://wiki.gnome.org/Apps ale aj tie používajú skôr XML než HTML na UI... ale že sa dá UI napísať v HTML a reálne sa využije GTK/QT namiesto Chromia je možné. Akurát nejak nikto to nerobí.