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.
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
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í.
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.
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.
"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.
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.
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.
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í.