Taky mě to dostalo do kolen. Asi to má prostě znamenat, že nemají žádnou architekturu a lepí to jak plakáty na vrata...
V tomhle stavu to ale nechce přepsat do jinýho jazyka, v tomhle stavu to chce hloubkově refaktorizovat a důsledně testovat, aby se oddělilo jádro a to pak v poslední fázi vyměnit. Jinak můžou celý TB odpískat rovnou...
V XULu jsem delal, programoval jsem do nej XPCom componenty v C++. A popravde receno nic horsiho neexistuje. Puvodni Netscape bezel na spouste dnes jiz neexistujicich platformach. A z toho plyne rada omezeni. Vychazelo se z toho, ze fce jako malloc, read a write nejsou thread-safe. Takze aplikcace v XULu NESMI alokovat pamet mimo hlavni vlakno, dokonce ani nesmi cist ze socketu. Alokace pameti a komunikace se siti se smi provadet pouze pres nejakou mozilla knihovnu, ktere je obalkou nad Apache APR.
Komunikace se serverem musi probihat tak, ze nejaky bg thread ceka na socktetu a kdyz prijou data, tak posle zpravu do hlavniho UI threadu a teprve v kontextu tohoto threadu, muzete precist data ze socketu.
Pokud ma nekdo jiz tohovou knihovnu ktera komunikuje serverem na nejakem slozitejsim protokolu, tak ma smulu, musi si napsat novou knihovnu, ktera bude odpovidat dogmatum XUL.
XUL navic nema "extensible marshaller", tzn, nemuzete vytvorit nejaky novy typ zpravy, kterou byste posilal z bg threadu, a zpracovaval v hlavnim event-loopu.
Zatimco u ostatnich aplikaci je normalni, ze pro komunikaci se serverem pouzivate nejaky ovladac anebo knihovnu, a o implementaci protokolu se nestarate, v XULu si vse musite napsat znovu. Musite ten ovladac rozdelit na dve casti, jednu pro gb thread, druhou pro UI thread.
PS: docela me zarazi, ze Rust navrhli ti sami lide, kteri vytvorili tohleto. Napr. komunikace mezi C++ komponentou a JS enginem SpiderMonkey, probiha pres datovy typ "void**", ktery si musite vselijak divoce pretypovavat podle potreby.
> Komunikace se serverem musi probihat tak, ze nejaky bg thread ceka na socktetu a kdyz prijou data, tak posle zpravu do hlavniho UI threadu a teprve v kontextu tohoto threadu, muzete precist data ze socketu.
To je vcelku bezny design, ktery nesouvisi s XUL. Knihovna (v C/C++) nema co predpokladat, jak je resena aplikacni I/O loop, a tedy nemuze delat blokujici akce. Rozumna knihovna ma funkce, ktere to umoznuji osetrit (napr. aplikace zavola knihovni funkci, kdyz na socketu je mozne provadet I/O, a knihovna si I/O zpracuje, knihovna zavola hook, pokud je treba pridat dalsi socket do I/O loop).
No co by?
1. rok - budou diskutovat, jak bude vypdat architektura
2. rok - budou se hádat, jaký jazyk je nejvíc cool
3. rok - budou se usmiřovat a psát kompilátor TPL (Thunderbird Programming Language), na kterým se shodnou jako na kompromisu.
4. rok - půlka kóduje, druhá půlka řeší, jak oznámit uživatelům, že se to nestihne.
Jeste ti tam chybi: prijde nejaky debilo* (idealne takove, ktere nikdy nenapsalo ani radku kodu) a rozjede show na tema diskriminace.
* debilo = totez co debil, ale ve strednim rodu, abych nebyl diskriminacni a pokryl vsechny ty transky, buzny a ostatni "utiskovany" mensiny (ktery nikoho nezajimaji, ale strasne rvou)
Hmm, přesně tohle jsem si myslel také, ale OpenHub (AKA Ohloh) hlásí pro TB 63% v C/C++, v JS 22% kódu.
Pro srovnání FF má 48% C/C++ a 25% v JS, ale ten implementuje renderovací jádro a JS engine, jen UI je v JS, takže tam se podobný poměr dá čekat, u TB to je překvapivě hodně nativního kódu.
Nutno přihlédnout k tomu, že TB má výrazně menší code base, > 1 MB oproti > 20MB u FF. Několik málo XPCom v *relativně* ukecaném C++ proti *relativně* hutnému JS (žádné alokace paměti, typy, hodně deklarativního XUL XML kódu etc) může statistiku značně ovlivnit.
do Electronu je možné vsadit modul v c/c++, dá se s tím poměrně dobře pracovat, binding a vše okole je připravený a třeba řada node.js modulů takhle funguje. Používal to myslím i klient pro Tidal, aby zabezpečil stream dat. Stejně tak na tom stavíme tenké klienty pro různé technologie, řada zákazníků si to oblíbila pro pohodlnost a přenositelnost.
Podle diskuzí v jejich vlákně právě předpokládají, že udělají určitý most, aby většinu funkcionality jenom vzali a nechtějí vše psát od nuly. Do kódu TB jsem ale přispíval před mnoha lety a už mám jen mlžnou představu, jak kód vypadá.
No právě. Proto se obávám zvlášť o enigmail, kalendář a exquillu, bez kterých se neobejdu. Používám ještě pár rozšíření navíc, např. automatické zobrazení kontroly DKIM, což je užitečné, ale dá se to oželit. Ale jestli přijdu o ty důležité a Thunderbird zaměří své síly na "moderní" (nebo spíš módní) požadavky jako je podpora všelijakých cloudů a obligátních sociálních howadin, tak to bude katastrofa.
Jakmile vidím "inovativní rozhraní, " začínám mít strach o budoucnost další užitečné aplikace.
Takže i zde nakonec proběhne frikulínizace s výsledkem, který bude pro uživatele za trest? Zase už nějaký 20 letý kokůtek "inovuje" stejně jako se to přihodilo Firefoxu?
Nejhorší na tom je, že to vše může poškodit i projekt mé oblíbené Seamonkey :-(
Z posledních událostí si myslím, že má SeaMonkey na kahánku. Pokud budou Thunderbird a Firefox používat úplně odlišné technologie, tak asi nedává moc smysl je balit do jednoho balíku.
Navíc v blízké době přestane SeaMonkey kvůli Mozille podporovat jeden z mých procesorů, protože neumí instrukce SSE2. Taky zmizí podpora ALSy, což vůbec nevím, jaký bude mít na mě dopad, snad jen nepůjde zvuk, ale zkompilovat to půjde.
Vidím budoucnost webových technologií vcelku bledě. Jak jsem vyhledával, tak pokud chce člověk přístup na web, tak webkit, Gecko kašlou na uživatele a odebírají podporu pro dosud používané procesory, knihovny apod. Alternativa typu Elinks, Links taky nevypadá úplně použitelně, protože si tam člověk nejspíš nezobrazí ani jízdní řády.
Skoro to vypadá, že je na čase si napsat vlastní prohlížeč :(.
Historie se opakuje. Ono to bude ostatně necelé dvě dekády, co se nejmenovaný spolužák BLEK rozhodl, že si napíše vlastní prohlížeč a vznikl links. Tehdejší web vypadal úplně jinak, a prohlížeče trpěly jinou sadou problémů (která se projevovala stejně: zbytečný bloatware). Možná je na čase na nový projekt. Ale pokusit se dnes stavět jádro prohlížeče (HTML, CSS, JavaScript, media files) od začátku bude chtít asi víc než jen jednoho nadšence v prváku, tak aby to do páťáku jakž takž stihnul. (P.S., trochu tu historii linksu zjednodušuju).
Zkoušel jsem opravdu hodně mail klientů, protože jsem v práci dostal k počítači nepřátelské prostředí MS (spis SM) Office 2016 a tamní Outlook mi ubližoval. Schovával mi třeba tlačítka co jsem hledal do nepřehledných nabídek, zakázal mi měnit klávesové zkratky a na ty co jsem byl zvyklý namapoval nesmyslné akce nebo si jen tak z pleziru přestal stahovat postu a tvářil se, ze je jako všechno cajk, ze mi nikdo za celej den nenapsal. Thunderbird byl a je jediná spása, tak doufám, ze ho kluci nezk*rví.
To je těžké.
Současný Thunderbird nějak funguje na XULu a má nějaký zajímavý ekosystém rozšíření, byť se to moc nerozvíjí.
Pokračovat stejným směrem by kromě stagnace znamenalo taky nutnost udržovat něco, co dosud bylo od Mozilly bez práce. Znamenalo by to více úsilí než doposud.
Přepsat všechno najednou je dost riskantní krok. Na jednu stranu se těším na to, co to (snad) přinese, na druhou stranu vidím pár rizik. Zaprvé kompletní přepis bývá podceňovaná věc a ne vždy je výsledkem produkt v požadované kvalitě dodaný v plánovaném to termínu. Zadruhé, celkem jistě si to vyžádá přepis dnešních rozšíření, která fungují snad výhradně na XULu. Jsem dost zvědavý, kolik z nich zanikne a kolik bude přepsáno. V poslední řadě během přepisu se obvykle nevěnuje moc sil vylepšování starého kódu. Thunderbird se ale poslední dobou moc nemění, takže to bude asi celkem malá oběť.
Postupný přepis by možná šel, kdybychom měli něco jako Electron/Cordovu na Gecku. Pak by snad šlo rozumně kombinovat legacy kód s moderním. Třeba editor zpráv by byl přepsán, zatímco seznam zpráv by zůstal v původní podobě. Ale o ničem takovém nevím. A i kdyby něco takového existovalo (v požadované kvalitě), mohou tu být další bariéry, o kterých zatím nevím.
Ať už zvolí cokoli, je jisté, že tu bude početná skupina uživatelů, kterým se to líbit nebude. Řekl bych, že je to o hledání nejméně špatné volby.
Co mi na přechodu od XUL u Firefox/Thunderbird na "moderní technologie" vadí:
U Thunderbirdu po letech registruju jen 2 bugy: S/MIME nebo GPG zašifrované zprávy nelze prohledávat a po suspend/wake cyklu se rozpadne občas synchronizace u IMAP foldrů (musí se na ně explicitně kliknout). Zvláštní je, že RHEL 6 Thunderbird má nějaký patch, který tohle řeší, ale nenašel jsem který přesně.
1. No, nevím, jestli je na tom XUL o tolik lépe. (A blbě se to srovnává. Ideální by bylo porovnávat dostatečně podobné aplikace. Chrome vs. Firefox se liší už používáním procesů a přímé srovnání je problematické.)
2. Ano, toho se bojím. Odhadují tři roky, reálně po čtyřech letech vyjde nestabilní nedodělek. (Teda třeba ne, ale něco takového jsme tu už viděli tolikrát…)
3. XUL addons jsou kontroverzní. Ale nejde až tak o XUL, jako o overlays (které můžeme ale mít klidně i s HTML5). Na jednu stranu nejsme svázani poskytnutým API a můžeme si dělat, co nás napadne, na druhou stranu nemáme jasné API (problémy s kompatibilitou při upgradu Firefoxu) a rozšíření si mohou dělat, co autory napadne (není žádný sandbox, rozšíření může šahat kamkoli). V principu nemůžeme chtít všechno.
Mimochodem, ono to není buď-anebo. Můžeme mít XUL a WebExtensions vedle sebe. Nebo WebExtension může mít k dispozici API, kterým získá privilegovaný přístup, a pak je to podobná situace jako s XULem.
S Lightningem by snad nemusel být problém, to je skoro samostatná aplikace, nepotřebuje se nějak hluboce integrovat. S Enigmailem to může být horší, ale pokud bude podpora pro S/MIME, tak snad by to mohlo jít…
Myslím že kombinovat různé UI frameworky ("editor zpráv by byl přepsán, zatímco seznam zpráv by zůstal v původní podobě") nemá moc smysl. Spíš bych se soustředil na lepší oddělení front-endu a back-endu, a zachování maxima z toho back-endu. Front-end by bylo dobré napsat v nějakém vyšším jazyku, který nesvádí k chybám, a když už se vyskytnou, umožní je dobře odchytat. Z hlediska jazyka zní nejlépe C# a Java, jenže z praktických důvodů to první na Unixech není moc dobrý nápad, a to druhé není dobrý nápad nikde. Framework by měl být multiplatformní a podporovat mobilní zařízení. Nabízí se Qt s QML, otázkou je v čem psát kód. Alternativně Mono framework, i když si umím představit, že proti tomu by někteří uživatelé na Linuxu protestovali. V každém případě se dá čekat, že rozšíření bude potřeba přepsat.
Řešit to pomocí webových technologií bych považoval za dost nešťastné.
> Myslím že kombinovat různé UI frameworky ("editor zpráv by byl přepsán, zatímco seznam zpráv by zůstal v původní podobě") nemá moc smysl
Jako trvalé řešení určitě. Jako dočasné řešení pro přechod mi to smysl dává, pokud je to technicky/ekonomicky schůdné.
> v nějakém vyšším jazyku, který nesvádí k chybám, a když už se vyskytnou, umožní je dobře odchytat.
Souhlas, ale bohužel je tu spousta lidí, kteří to vidí jinak. Navíc toto nejde tolik dohromady s návrhem zachovat co nejvíce z backendu, který je z velké části v JS, což při volání z jiných jazyků může činit větší či menší obtíže.
> Z hlediska jazyka zní nejlépe C# a Java, jenže z praktických důvodů to první na Unixech není moc dobrý nápad, a to druhé není dobrý nápad nikde.
Proč? Takové Banshee (Mono) funguje dobře, aspoň na linuxu. A Java – pokud se nepoužije Swing (nebo pokud se Swing zkulturní, jako to udělali v JetBrains), nevidím v tom problém.
> Alternativně Mono framework, i když si umím představit, že proti tomu by někteří uživatelé na Linuxu protestovali.
Někteří ano. Ale najděte technologii, proti které nebude nikdo protestovat…
> Řešit to pomocí webových technologií bych považoval za dost nešťastné.
Na jednu stranu ano. Na druhou stranu, teď má projekt nějaké přispěvatele s nějakými znalostmi a zkušenostmi, které jsou webu blízko. A pokud nový Thunderbird má se starým mít společného i něco jiného než název a logo, hodilo by se nedělat radikální řez do týmu
Ad kombinovat různé UI frameworky nemá moc smysl; Jako dočasné řešení pro přechod mi to smysl dává, pokud je to technicky/ekonomicky schůdné - tam bude asi problémem ta schůdnost
Ad bohužel je tu spousta lidí, kteří to vidí jinak - takovým přeju, aby na podobném projektu pár let kódovali. Za následky na jejich zdraví neručím :)
Ad toto nejde tolik dohromady s návrhem zachovat co nejvíce z backendu, který je z velké části v JS - back-end v JS? Fakt? Někdo tu uváděl, že TB má 63% v C/C++ a 22% v JS. Tipnul bych si, že v C/C++ bude primárně back-end. Obsluhu tlačítek a zaškrtávátek bych naopak čekal v tom JS.
https://www.root.cz/clanky/vyvojari-navrhuji-prepsat-thunderbird-pomoci-web-technologii/nazory/918761/
Ad Banshee (Mono) funguje dobře, aspoň na linuxu - vím že projekt Mono udělal velký pokrok, ale nejsem schopný posoudit, jak si na Linuxu stojí. Jestli dobře, tak by to asi mohlo být řešení.
Ad Java, pokud se nepoužije Swing (nebo pokud se Swing zkulturní, jako to udělali v JetBrains), nevidím v tom problém - Java je pěkný jazyk, ale dost mizerná platforma. Vývoj Javy prakticky stojí, bezpečnost je hrozivá, a upřímně: HW náročnost Java aplikací je někdy dost překvapující.
Ad najděte technologii, proti které nebude nikdo protestovat - velký souhlas
Ad teď má projekt nějaké přispěvatele s nějakými znalostmi a zkušenostmi, které jsou webu blízko - v podstatě mohou udělat to co jsem popsal, nebo strávit léta ohýbáním a doděláváním nějakých frameworků... a nebo vymyslet lepší migrační cestu, která jim bude vyhovovat.
> Tipnul bych si, že v C/C++ bude primárně back-end.
Možné to je, potom by se situace trochu měnila.
> vím že projekt Mono udělal velký pokrok, ale nejsem schopný posoudit, jak si na Linuxu stojí. Jestli dobře, tak by to asi mohlo být řešení.
Nemám s Monem až tak velké zkušenosti, ale mám z něj pocit, že záleží, jestli s ním vývojáři počítali. Pokud ano, pak funguje dobře. Pokud ne (tzn. vývoj probíhal spíše pro MS .NET a s Monem se nepočítalo), pak ve složitější aplikaci skoro jistě najdeme problém. Problém Mona budou tedy spíše edge cases nebo feature parity s MS .NET než stabilita.
Ostatně na Monu se dělají i aplikace pro Android a iOS – vizte Xamarin.
> Vývoj Javy prakticky stojí
To bych řekl spíše v době Javy 6, ne dnes.
> bezpečnost je hrozivá
Pokud chcete v JVM spouštět cizí kód a uzavírat jej do sandboxu, pak ano – většina zranitelností Javy je právě o úniku ze sandboxu. Jinak mi to – s ohledem její rozsah – nepřijde jako tak velké množství zranitelností. Ne každá zranitelnost je zneužitelná s každou aplikací. Pokud jde ale o poštovního klienta, tam nepotřebujeme snad primárně sandboxovat Javový kód (i když, pro extensions by se to mohlo hodit, ale tam je menší riziko útoku) a ani z ostatních nebude zdaleka všechno aplikovatelné.
> a upřímně: HW náročnost Java aplikací je někdy dost překvapující.
S čím to srovnáváte? Pro jaké scénáře? Často takové srovnání vidím s nějakou o poznání jednodušší aplikací (typu IDEA vs. Vim). Nebo pro scénáře, které sice nejsou silnou stránkou Javy, ale ne vždy jsou podstatné (rychlost startu). Nebo 10+ let stará srovnání. Ano, žere to typicky více RAM než obdobná aplkace v C (pro CPU bych si s tím už nebyl jist), ale zase komfort vývoje a memory safety jsou někde jinde. A pokud budeme srovnávat s JS, tak Java nejspíš vyhraje. (Jasně, vždy lze najít dostatečně zpackaný kód…) Srovnání s .NET bych čekal celkem vyrovnané, možná až na cold performance.
Souhlas že u Mono může být problém s feature parity, ale když člověk píše přímo pro Mono, tak je mu to celkem jedno. Pokud je stabilita OK, tak není problém. Trochu zamrzí, že podle všeho není hotová podpora WPF.
Ohledně Javy a bezpečnosti: u mailového klienta je bezpečnost celkem klíčová. Vzpomeňte si na Outlook, když kdysi používal pro parsování HTML Trident engine: přijde nakažený email, uživatel klikne na preview, a je vymalováno. A tohle zrovna moc optimisticky nevypadá:
https://www.cvedetails.com/vulnerability-list/vendor_id-93/product_id-19117/Oracle-JRE.html
Pokud jde výkon, tak paměťová náročnost není nic moc, výkon jak a kde. Swing má vyjma té zmíněné necivilizovanosti problémy při běhu přes Remote Desktop (pokud si pamatuji, tak obsah okna je v podstatě obrázek, takže se proti ostatním aplikacím tahá relativně pomalu). A pokud jde o cold start time, tak to je u desktopové aplikace dost zásadní. Komfort vývoje je slušný (nakonec Java je opravdu pěkný jazyk), a memory safety rozhodně nesrovnatelně lepší, než u C/C++; přesně proto jsem Javu uváděl jako jednu z možností, s tím že bohužel má své mouchy, bez ohledu na hostitelskou platformu.
Nerad bych začal flame Java vs .NET, ale z mého hlediska Java za C# lehce zaostává z hlediska jazyka, a poměrně výrazně zaostává ohledně platformy, zvlášť pokud jde o desktop. Další problém je cold start time.
> u mailového klienta je bezpečnost celkem klíčová
Souhlas. Ale zdaleka ne každá zranitelnost Javy bude zneužitelná v e-mailovém klientu.
> A tohle zrovna moc optimisticky nevypadá:
https://www.cvedetails.com/vulnerability-list/vendor_id-93/product_id-19117/Oracle-JRE.html
Bohužel zranitelnosti Javy mají v NVD často dost generický popis. Někdy jde o relativně generický odstavec, někdy dokonce o „Unspecified vulnerability“ s minimem informací. Často pak máme hrozivě vypadající zranitelnosti s „network exploitable“ a celkově vysokým skóre, kde jde fakticky jenom o sandbox escape. V kontextu Java appletů to má opodstatnění, jinde je dopad často až nulový, protože celé JVM je stejná trust boundary a na sandbox nehrajeme. Tím, že Java má mizerný sandbox, tvoří takto hrozivě vypadající zranitelnosti s typicky nulovým dopadem snad většinu všech zranitelností. (Ostatně v Javě je challenge implementovat privilegovaný kód bezpečně, už kvůli memory modelu, který dává příležitosti pro race conditions, když se programátor posnaží.)
A jak vím, že velká část (od oka většina) těch zranitelností se týkají pouze sandboxu, když popisy jsou tak skoupé na slovo? Jsou tu dva zdroje, které typicky řeknou více informací:
* Critical Patch Update v sekci Java SE risk matrix sice moc detailní není, ale dozvíte se, jestli se to týká sandboxu nebo ne (sloupec Note). Ta tabulka je typicky plná zranitelností aplikovatelných pouze na sandbox.
* Pod zmíněným CVE lze zranitelnost najít na webu RedHatu, který má často lepší popis (někdy kratší a výstižnější), k tomu link do Bugzilly, kde je někdy o něco podrobnější popis, občas i s linkem na commit, který zranitelnost opravuje.
Co se týče ostatních zranitelností, ani ty nemusejí ovlivnit výslednou aplikaci. Standardní knihovna Javy je poměrně obsáhlá (snad byly plány to v Javě 9 rozdrobit), takže bude obsahovat zranitelné části, které ani nepoužijete. Obrazně řečeno, je celkem jedno, jestli máte deset knihoven s celkem deseti zranitelnostmi, nebo jednu knihovnu (ze které ale využíváte jen polovinu) s dvaceti zranitelnostmi.
> Swing má vyjma té zmíněné necivilizovanosti problémy při běhu přes Remote Desktop
Ano, psal jsem, že GUI ideálně v něčem jiném než Swing. RDP mě neštve, náročnost asi taky tolik ne, ale třeba jejich file dialog nebo podpora horizontálního rolování jsou věci, které mě vytáčejí. JetBrains to umí eliminovat, ostatní moc ne.
> A pokud jde o cold start time, tak to je u desktopové aplikace dost zásadní.
Jde hlavně o pomalejší běh krátce po startu, ale kolik dělá e-mailový klient CPU-bound úloh, kde by se to projevilo? Navíc mi typicky běží dlouhoďobě, nepouštím ho na každý e-mail…
Hurrá, z celkem stabilního projektu se zase dostaneme s Thunderbirdem na roky do stádia alfa. Celé rozhraní se překopá, funkčnost se zredukuje zhruba na 50%, pokročilejší funkce se zruší (vždyť přece stačí číst a odesílat mail, kdo by se se složitostmi babral). Přidá se i pár cool naprosto revolučních nepostradatelných změn jako jsou například tlačítka v záhlaví formulářů. Vůbec nic na co jsou uživatelé desetiletí zvyklí nemusí fungovat jak předtím, revoluce! Při přepisování ovládání do nových technologií se přizpůsobí i staré nemoderní ovládání se spoustou voleb a textu na současný styl typu - uživatel je přece idiot a potřebuje obrovská tlačítka a spoustu ikon a obrázků, nejlépe i poskakujících. Jako bonus se přidá tuna nových bugů. Vývojářské kapacity na revoluci nejsou, takže máme o zábavu postaráno na roky dopředu. A to se cení! :-) Jsem už asi fakt starý... :-)
Další problémy se ukrývají uvnitř, protože jsou striktně odděleny komponenty uživatelského rozhraní a například IMAP klienta
Mají vůbec nějakou zkušenost s vývojem software jinak než patláním scriptů v JavaScriptu ? Použití JavaScriptu pro klientské aplikace je z nouze ctnost pro ty, co neumí žádný normální striktně typový jazyk. Tohle by byl definitivní konec. Navíc to zavleče do počítače nějaký Google sajrajt.
konkrétně to ASM je generovaný přímo tím "JS jádrem", v době kdy v8 vznikla, vymoženosti jaké nabízí llvm ještě nebyly stabilní a tak běží nad gcc a musí si ASM generovat svépomocí.
Na UI aplikace JS není špatně navržený a je to jeho silná stránka, umožňuje řádně oddělit doménovou logiku od její reprezentace a díky pojetí asynchronního hlavního threadu mají pro uživatele dobrou odezvu s nulovou prací pro "programátory"
to těžko, oba jazyky jsou úplně na druhé straně použití a navzájem si nekonkurují. JS není možné vzhledem k architektuře a použití JIT zpracovávat přímo na CPU, potřebuje dost vysoký runtime bordel. Ze stejného důvodu neuspělo ani urychlování Javy na CPU, i Sun s PicoJava to zabalil brzo, PowerPC na tom byl trochu lépe vzhledem k návrhu některých širokých instrukcí, ale i tak to není žádná hitparáda.
hoši všakono to nějak nakonec půjde. To se takhle jednou za několik let sejdou lidi od it nadela elon munsk a mark zuckerman v googleplexu a poslepujou tam ty svoje ai dohromady do jedny a ta už se popere sčímkoliv. říšský ministr pro transgenderovou rovnost ahmed muller se nějak dozví že existují různý programovací jazyky a že ty lidi od it berou různý peníze zato že uměj jiný jazyky a řekne dost 8) 8) zvedne červený telefon a zavolá do duhového domu donaldu clintnovi. ten si zavolá ty svoje ajťáky a ty ztý svý ai nechají vyplivnout procík s jsu 8) pak už to všechno pojede jako pomásle. evropský it zakázky budou vyžadovat jenom js a procíky s jsu a většina lopat se prostě potáhne za $$$. pak se zileglalizují ato i v soukromým sektoru zakázky který nejsou s js jako diskriminační akdo neposlechne bude deně dostávat v unijních nekoncentračních netáborech europendrekem pohlavě tak dlouho dokud neuvidí hvězdičky 8)
noa jak půjde čas tak si nikdo na žádnej jinej jazyk ani nevzpomene a všichni budou žít šťastně až dosmrti 8) pokudse ovšem něco nepodělá protože to by lidi skočili rovnou zpátky do doby kamený 8)
hochu to si vážně myslíš že vbudoucnosti nebude ai co bude umět programovat navrhovat hárdwér a vůbec všechno líp než nějakej upatlanej it nerd se zamaštěnejma vlasama?? že výkon procíků v budoucnosti smete rozdíl jazyků a majoritní programovací jazyk bude totálně něco stupidního protože většinu práce za člověka odvede ai který bude skoro uplně jedno čim ji nakrmíš a všechno schroustá 8) 8)
a proč byses mazal snějakejmatěma nomádama a lamdbama když to bude navšechno obyčejnej stačit js 8) ty keci o ahmedoj mulleroj to byla jenom taková eurokaše okolo abyse ti to líp četlo 8)
HW již teď navrhuje program, pouze některé stěžejní části opravují nebo vylepšují lidé ručně. Ono umístit několik mld. transistorů do několika vrstev není reálné dělat člověkem.
Proč vynalézat kolo, on už jeden jazyk existuje, je jím ASM, všechny ostatní jazyk jsou nad ním postavený. Každý jazyk má jen jinou úroveň abstrakce, webový výjojář nechce řešit IO a alokace pamětí, naopak databázový vývojář přímo tohle potřebuje, aby udržel určitou efektivitu.
tak vidíš že to jde teť užjenom stačí říct "počítači sestav mi procík s jsu" a máš ho. jeto jenom otázka času 8)
důvod proč všechno stavět na js je že starej druh dědků programátorů vymře navšechno budou stačit jednoduchý skriptíky v js. budoucí programátoři budou chápat asm jako zbytečnej mezikrok kterej jim neumožňuje ovládat hárdwér přímo tím jejich js na kterej jsou zvyklí už od školky 8) a navíc proně bude asm srozumitelnej asi jako mě budou si ho muset kompilovat do js aby mu alespoň trochu rozuměli 8) z dnešního pohledu se vytvoření jsu zdá jako neekonomická hovadina ale pro ně to bude náročný jako pronás nechat vyměnit žárovku a přínos je snad jasnej 8) 8)
Tvůj optimismus s návrhem čipů bych chtěl mít.
Jenom blbý autorouter na plošňáky bývá v pr... a je to spíš hloupý učedník, než někdo, kdo by si mohl hrát na mistra. https://www.youtube.com/watch?v=sffuvnGhano Málo kdo mu svěří desku za litr na prototyp bez toho, že by po něm něco upravoval a prototyp čipu vyjde na 6-7 místný číslo v E-čkách (možná tak Atmel).
V reálu to funguje tak, že existují knihovny, kde je nějaké hierarchie - tranzistory, hradla/klopáky, funkční bloky, větší funkční bloky,... Pokud mám třeba ALU, tak navrhnu blok pro 1b, zkopíruju 64x, jako když sekám instance tlačítek do formuláře. To samý, pokud jde o osmijádrový CPU, nasekám tam osm instancí jádra, rozmístím je na čipu a propojím. Logaritmicky tak klesá množství práce.
Btw, věděl jsi, že příslušný SW na návrh čipů od Mentor Graphics na Win vůbec neexistuje a vždycky jsme to pouštěli na RHEL?
hochu nevim jestli bráníš svoje ekonomický zájmy nebo jestli jseš uvězněnej uvažováním v krabici 8) až bude mit procík kotel jader nebo bude dokonce kvantovej tak na to sedne asinchronní funkcionální jazyk jako prdelna hrnec. Celej js skript ti to sjede najednou a potrvá to stejně dlouho jako když dnešní procík udělá jednu instrukci 8) 8)
a co se týká ty ai tak věř žeto přijde a to jako vždycky dřív než bys to čekal 8)
před 300 lety jsme ještě upalovali čarodějnice před 200 lety jsme svítili svíčkama před 100 lety jsme chodili skoro všude pěšky a bosu před 50 lety programovali jenom ty největší nerdi ato jenom nějaký ty děrný štítky před 25 lety neměl iphone nebyl dotykáč a ani nebyl barevnej a neuměl se připojit na fb kterej ještě neexistoval pred 10 letyvětšina it lidí nevěřila v budoucnost js mysleli si že je to zbytečnej žrout procíku aže navšechno přeci stačí html php mysql a css a kdybys jim říkal že v js jednou budou psaný i aplikace na desktop tak by tě uškrtili na sériovým kabelu od myši který ještě tenkrát neměly wifinu 8)
no a před 5 lety všechny prohlížeče uměly js a většina it lidí si už myslela že je nemožný napsat webík bez js no a dneska jsou běžný desktopový aplikace v js a moc js bune už jenom dál rust 8) 8) 8)
pravdu ale mít nemůžeš, žádnou omluvu tedy nečekej.
mluvíš o žiliónu jader a o JS jako budoucnosti a přitom ten tvůj JS je single thread by design, bereš v potaz pouze růst webu a jeho pronikání na desktop a myslíš si, že to je celý svět vývoje a SW, pleteš se, tohle je jen vrchol pyramidy, o které ani nevíš, že existuje.
Jediné co budoucnost ukáže, že ve své dokonalosti nejsi schopný ani dostudovat VŠ, natož získat hlubší znalosti o tématech, v kterých si tak věříš.
Sice jsem kdysi používal Pine, ale k něčemu podobnému přecházet už nehodlám.Je to opravdu omezující a já potřebuju Lightning s Cal/CardDav.
To raději zůstanu u poslední normální verze TB nebo SM. Fungovat nepřestane...
Ale snad nebude tak zle. Frikulíni zmrvili Firefox, ale Thunderbird už není taková masovka - používají ho lidé, kteří vědí co chtějí. To by neprošlo.
Spíš rozumně pomalu přejde na jiný podvozek, ale bude vypadat i fungovat pořád stejně :-)
Nechci sýčkovat, ale aby to nedopadlo jako KMail při přechodu z KDE 3 na KDE 4(5) :-) Tam to borci dorazili ještě tím slavným Akonadi (store pro metadata) a tuším to bylo navázaný i na dnes už zase neexistující Nepomuk (indexace obsahu). Pořád si říkám jaká je to ostuda, že v roce 2017 neexistuje přívětivý a funkčně plnohodnotný e-mailový klient. Poslední dobou se přistihuji při používaní www rozhraní a už mi to skoro připadá i normální. Milý Ježíšku, prosím letos k Vánocům e-mailového klienta, který nepadá, lze v něm jednoduše napsat zprávu příteli i offline, ze schránky pohodlně přikopírovat text. Aby se choval svižně a i synchronizace s IMAP probíhala bez zaváhání. S konfigurací ukládanou do jednoduchých textových souborů. A aby i oku zalahodil jednotným GUI s mým KDE. :-D
Máš na mysli toto:
https://www.root.cz/vyhledavani/?qs=akonadi
?
Mi se zdálo, že se mi za tím KDE pořád na pozadí snaží vybavit nějaké nepěkné (potlačované) vzpomínky...
(i když, to je spíše nepříjemná asociace patřící k tomuto vláknu: https://www.root.cz/zpravicky/petice-za-zvoleni-kde-vychozim-prostredim-ubuntu/ )
Milý Ježíšku, prosím letos k Vánocům e-mailového klienta, který nepadá, lze v něm jednoduše napsat zprávu příteli i offline, ze schránky pohodlně přikopírovat text. Aby se choval svižně a i synchronizace s IMAP probíhala bez zaváhání. S konfigurací ukládanou do jednoduchých textových souborů.
Zkus claws-mail.
A aby i oku zalahodil jednotným GUI s mým KDE. :-D Chceš jednotné GUI, nebo chceš aby to fungovalo dobře a nebyl to bloatware? Obojí dohromady se dělá těžko, když ty programy píšou úplně jiný lidi.
Petře, děkuju za informativní článek.
Tak tedy čekám napjatě, co se z toho vyvine. Používám TB denně už tak asi 15 let. Chápu, že vývojáři jsou tlačení vnějšími okolnostmi a tím, jak je ten kód asi fakt těžko udržovatelný. Ale od MUA lidi očekávají zejména stabilitu. Tu TB nějak má, byť není bez chyb...
Aktivně mnou používané add-ony pro zajímavost:
Enigmail
Lightning
Nostalgy
Mail Redirect
ConfirmFolderMove
Display Mail User Agent
Není jich mnoho, ale chyběl by mi každý...
Také ho používám asi 15 let, ne-li déle, ale zase k srdci mi úplně nepřirostl a spousta věcí by na něm šla vylepšit. Bohužel od verze 2 nebo 3 mám pocit, že jediné změny jsou přechod na nové renderovací jádro a zvýšení čísla verze. Jediná výraznější změna byla dojeprasený GUI od verze kdy zmizelo menu.
Něco řeší doplňky, ale chtěl bych
- funkční minimize to tray
- podporu win10 notifikací
- v některých případech zobrazit vlákno skrz přijatou a odeslanou poštu (na způsob gmailu)
- aby to u vizitek nedávalo, že má zpráva přílohu ... pak má každá zpráva přílohu
- zobrazení příloh (měl postbox a když vím, že mi zhruba před týdnem přišlo PDF mezi 20ti majly tak se to hodí)
- synchronizaci kalendáře s googlem (a úkolů s gtasks)
Doufám, že někdy něco udělá Opera