Thunderbird 114 "Supernova" kiadási útiterv

Címkék

A Thunderbird projekt kiadta Thunderbird levelezőprogramja 114-es verziójának útitervét és a bele tervezett nagyobb új funkciók, szolgáltatások részleteit, várható érkezési idejüket stb. A roadmap elérhető itt.

Hozzászólások

A sors iróniája, hogy Arch alatt mégis a 91-es a legfrissebb, mikor a 100-as verziók is kint vannak már egy ideje. Ezt azzal indokolja a csomagfenntartó, hogy a 9x-e verziókról nem lehet a 100-asra frissíteni, a fejlesztők csak később adnak majd ki patcht, amivel lehet. Bullshit természetesen, felraktam a Mozilla oldaláról a hivatalos binárist, ami most 102-es stable.

Azon kevés GUI-s programok egyike, amit még használok. neomuttnál a lassú indulást (feltartja az új levelek lekérése a szerverről a betöltési folyamatot, ami szekvenciálisan megy, addig nem lehet használni) nem tudtam megoldani, az aerc-nél meg azt, hogy a HTML-es formátumú leveleket ne fixre drótozva w3m-ben akarja megjeleníteni, hanem az alapértelmezett böngészőben is lehessen, így terminálos/TUI megoldást nem tudok erre használni, pedig nagyon szeretnék.

A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

Most komolyan, ki találja ki ezeket az elbaszott neveket és minek?

Melleselg TB-vel levelezek és szeretem.

Senkinek nincs köze világod belsejéhez, neked sincs közöd mások életéhez, csak az Irgalom útján van közöd, Istenektől rendelt kötelességed.

Vannak erre tartva ilyen öltönyös-nyakkendős bullshit-emberek az ilyen nagyobb projektekben. Nem viccelek, komolyan írom. Ez a munkakörük, ilyen bullshit-púderek gyártása, ráadásul elég jól meg is vannak fizetve, tehát nem ingyen, meg önként találják ki.

A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

Szerkesztve: 2022. 08. 17., sze – 12:49

Na, akkor 2023-ban lecsekkolom megint, ~4 év után. Talán végre lesz egy áttekinthető UI hozzá. Azért arra kíváncsi leszek, hogy

  • képes lesz-e Ms email címmel natívan működni
  • megoldják-e, hogy fusson daemonként, vagy kitalálnak-e végre olyan megoldást, (tray icon beépítetten (!) vagy valami) hogy értesítést lehessen kapni az emailekről akkor is, ha be van zárva az alkalmazás
  • ha nem daemon lesz, akkor egy i9-es 64GB RAM-mal ellátott gépen ne 20 perc legyen a betöltés
  • működjön a Nextcloudos calendarral, ha már van benne calendar, ne adj' Isten, lehessen abból egy kattintással továbbmenni a megfelelő app-ra, ahova egy meeting szól
  • ne crasheljen random

Jobban meggondolva a GNOME 40 óta, ezt mind tudja a hozzá lazán kapcsolódó 2 alkalmazás, szal mindegy is már. :))

It is our choices that define us.
Thinkpad X1 Carbon | Arch linux

Jó neked!

Arch linuxon nyomom, többé kevésbé a latest stable verzióval, egy ideig ment jól. A 7x-es verziótól kezdve állandósultak a problémák nálam. Az már csak hab a tortán, hogy pluginek nélkül sokszor használhatatlan a cucc, amiket persze szinte sosem fejlesztenek időben. (Nem, a fizetőseket sem.) Ettől függetlenül sokan használják itt is boldogan, örülök neki. Tényleg.

It is our choices that define us.
Thinkpad X1 Carbon | Arch linux

Miért használsz két levelezőt egymás mellet? Tényleg érdekel, nem kötekedés :)

Senkinek nincs köze világod belsejéhez, neked sincs közöd mások életéhez, csak az Irgalom útján van közöd, Istenektől rendelt kötelességed.

Próbáld leszedni, és a Mozilla oldaláról feltenni a 102-est. Nekem Archon egyébként nincs gondom a Thunderbirddel, azt leszámítva, hogy a 90-es verziókon ragadt. Azokat, amiket te akarsz, azt szimplán nem tudja a Thunderbird még, ahhoz semmi köze nincs az Archnak. A 20 perc indulási idő kicsit soknak tűnik így is, igen, komótos, ha sok leveled van, de annyinak nem kéne lennie, nálam kb. 2-3 mp. egy fiókkal, de abban több ezer mail-lel.

Egyébként ha csak értesítés kell, arra lehet futtatni a háttében valami másik progit, ami be van jelentkezve a mailfiókodba, és küld figyelmeztetést, ha új levél jön. Bármelyik olyan 3rd party mailfigyelő alkalmazás, ami támogatja azt a mailprotokollt, amit használsz, IMAP, POP3, stb..

A crasheket meg úgy kell megoldani mozillás programoknál, hogy újratelepíted, de egyben a régi profilt törölve újat kezdesz. Általában a profil mögötti SQLite adatbázis fossa össze magát egy idő után.

A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

A 20 perc gondolom képletes, nekem 24 GB méret mellett 2 mp amíg elindul a TB Kubuntu 22.04-en egy öreg dell notin. A levelek darabszámát meg fogalmam sincs hol kel megnézni :)

Senkinek nincs köze világod belsejéhez, neked sincs közöd mások életéhez, csak az Irgalom útján van közöd, Istenektől rendelt kötelességed.

Tény, hogy bloat a TB, de ez van, ha az ember normálisan akar e-mailezni, akkor ahhoz mindenképp bloat kell egyelőre. Amiben az a vicc, hogy az e-mail eredetileg egy szög egyszerű, plain text alapú megoldás, és mekkora bloatot csináltak belőle. Pedig nekem egy CLI megoldás is megfelelne, checkmail, downloadmail, sendmail parancsokkal, mindent shellben, scriptelhetően, minden e-mail egy egyszerű letöltött szövegfájl, ebből tudnék építkezni. Nem, nem kell SQL adatbázis, meg GUI, meg címjegyzék, és extra spamfilter. Legalábbis nekem nem. Csak kezeljen IMAP, POP3-at, meg SSL-t, és többi megoldom (GPG titkosítás, HTML-es mail-ek, stb. külön programmal). OpenBSD-n van hasonló, de az csak szerveroldalra gyúr, meg levélküldésre.

Egy ideig használtam neomutt-ot, az majdnem jó volt, de sok minden csak egy szálon, szekvenciális tud benne futni, és pl. a levelek lekérése a szerverről elég lassú, és addig nem tölt be a mailkliens, míg ez meg nem történt, így meg agyrém lassú az indulása. Így hosszú távon nem bizonyult használhatónak. Alpine-t még nem próbáltam. Az aerc is majdnem ott lenne a használhatóság határán, egy egész kevés hiányozna hozzá, de az a kevés hiányzik sajnos. Így addig marad a Thunderbird.

Esetleg még egy olyan megoldás is jó lenne nekem terminálban, ahol egy IMAP mailszervert fel lehetne úgy csatolni, mint egy hálózati meghajtót szokás mountolni, vagy eleve szerverről lekéréskor/vagy szinkronizáláskor, mountolás nélkül egy előre bekészített mappastruktúrába bemásolni, és ott lennének benne a plain text levelek, onnan lehetne böngészni (fzf-fel vagy Vifm-mel), mintha fájlok lennének, az IMAP mappák meg sima mappák. Levélküldés meg úgy menne, hogy az ember bemásolná ide (helyesebben a Send vagy Sent mappa alá) a kész mailt plain text fájlként. Backupnál meg csak az ember az egész felcsatolt mappastruktúrát lementeném tömörített tar-ral. Levéltörlésnél meg elég lenne vagy csak simán törölni, vagy a Trash mappába mozgatni. Levelekben keresés mehetne simán rekurzív grep-pel, a szinkronizálás meg egy syncmail paranccsal, így minden megoldható lenne a Unix-filozófia mentén.

A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

> Tény, hogy bloat a TB, de ez van, ha az ember normálisan akar e-mailezni, akkor ahhoz mindenképp bloat kell egyelőre.

bloat != feature-rich

> Pedig nekem egy CLI megoldás is megfelelne

Gondolom a mellékelt képek pedig ascii-artban. :)

> minden e-mail egy egyszerű letöltött szövegfájl

A '70-es években talán egyszerű volt, amikor csak angol ascii 7-bit volt az email-ek tartalma. (Ja, és most feltaláltad a Maildir-t.)

> downloadmail

Szerintem fetchmail az.

> HTML-es mail-ek

Csak azokra nincs szabvány. Pontosabban túl sok van.

> külön programmal

uudeview,html2text, ...  ez nem nem-bloat, még csak nem is minimal, hanem fapad. Gyakran összetéveszted.

> olyan megoldás is jó lenne nekem terminálban, ahol egy IMAP mailszervert (...) mountolni

Abszurd. Brutálisan lassabb lenne, valamint a szerver üzemeltetője kivágna.

> ott lennének benne a plain text levelek

20+ éve nincs olyan, hogy csak plain text email. Pl. a szöveges tartalom lehet quoted-printable, base64, ... Továbbá van a multipart. Na ezekben keresgélj grep-pel, böngészd fzf-fel. :)

> minden megoldható lenne a Unix-filozófia mentén.

Én is szeretem a Unix-filozófiát, rengeteg dolog megoldható vele, de közel sem minden. Megvan a maga helye, azaz a dolgokat arra kell használni, amire valók.

Na, most eddig úgy tűnhet, mintha kötözködni akarnék...pedig dehogy. Amikor nekem újdonság volt ('90-es évek vége), hogy minden megoldható shell(scriptek)ben, én is próbálkoztam az általad írt dolgokkal.

Nekem ez vált be: volt több email-accom: privát (naná hogy freemail), egyetemi, céges(ek). Ezek mind tudtak POP3-t. Az összes acc-t egy háttérben időízített fetchmail töltötte egyetlen mbox-ba. A gui (TB elődje, Mozilla suite) csak ezen a mbox-on keresztül fogadott email-t. A küldéshez persze kellettek smtp-k.

Azt már meg sem merem említeni, hogy a van-új-email jelzést a billentyűzet scroll lock led-je biztosította. Ezt még bőven tudnám/tudtam fokozni, de most csak arra akartam rámutatni, hogy a scriptek és a gui - jól megtervezve - remekül kiegészítik egymást.

De bloat a TB. Persze ekézni nem akarom, mert a többi grafikus mailkliens még bloatabb, és még szarabbak is sajnos, főleg az Electron-szutykok nagyon erőforrás-pazarlók. A CLI/TUI mailkliensek a képeket, HTML-mailokat, egyéb csatolmányokat természetesen grafikus programban nyitnak meg (vagy amiben te akarod, beállítod), szöveges nézetben csak egy link látszik. Az e-mailek nagy része viszont ma is plain text, és nem tartalmaz grafikus cumót. A HTML-es mailek a kivétel, de azokat meg általában hírlevelekben, meg kéretlen szutykokban szoktál tolni, esetleg ritkán cégesben. A HTML-es mailek is ugyanolyan mailek, mint a nem HTML-s, csak bele van kódolva csatolmányként egy HTML-es „melléklet”, amiben HTML-kód van. Továbbá de, még ma is minden mail plain text. A nem ilyen részek base64 kódolással vannak benne, ami szintén plain text. Ha nem hiszed el, nyisd meg akármelyik e-mailed forrását. Így lett RFC-kben rögzítve, és ez a jövőben sem fog változni, visszafelé kompatibilitás miatt.

A levélfiók felcsatolása helyi fájlrendszernek nem abszurd. Természetesen ebből a szerver üzemeltetője semmit nem lát, épp úgy csak annyit, hogy néha van szinkronizálás a szerverrel új levelekért, ahogy a többi mailkliensnél. Extra terhelést ez a koncepció nem okozna szerveroldalon, csak a letöltött levelek tárolása, rendezése történne más formában.

A downloadmail csak egy ötlet volt, egy elképzelést vázoltam, nem egy már létező programot, így annak hívjuk, aminek akarjuk. A GUI-val az a baj, hogy feleslegesen növeli a kódméretet. A mai modern mailkliensekben van egy csomó szutyok, SQL-kelezés, JS és webengine (hiszen lényegében egyben bújtatott böngészők is) sandboxinggal, Gtk-témázás, címjegyzék, naptárfunciók, biztonsági védelmek, meg még sorolni is nehéz lenne, simán több millió kódsor van bennük. Ezek közül nekem egyik sem kéne egy mailkliensben. Mondom, a neomutt meg is felelne, ha nem indulna olyan pokolian lassan, és nem a betöltési idő, mert az betöltődne pár ms alatt, hanem a levelek lekérése a szerverről lassú, és nem a háttérben történik. Továbbá a CLI/TUI-megoldásoknak, minimalizmusnak az is előnye a kis hardverigény mellett, hogy kevesebb biztonsági rés van benne, mivel kisebb kódbázis, továbbá nem futtat le mindenféle szutykot magától, ahogy a grafikus megoldások.

A Scroll Lockra jelzést meg össze lehet hozni nem GUI-s szoftvernél is. Nem mintha akarnám, egy desktop gép kivételével minden más gépemen (laptopok), nincs is ilyen led. A mostani elsődeleges notimon még Num Lock led sincs, elsőre kicsit furcsa volt, de meg lehetett szokni, meg csináltam rá workaroundokat.

Nekem már majdnem minden szoftverem, amit használok, CLI/TUI, még a lockscreenként szolgáló screensaver is (terminálban futó asciiquarium, ami transzparens alock-kal van lezárva). A mindenen azt kell érteni, hogy tényleg szinte minden, text editor, fájlkezelő, számológép, rendszerinformációs és rendszeradminisztrációs programok, zenelejátszó, konvertálók, tömörítők, task manager, szótár, csomagkezelés, naptár, időjárás, password manager, szedőprogram (XeTeX), torrentkliens, még a táblázat/adatbázis-kezelést is meg tudnám oldani, ha használnék ilyet. Már csak a mailkliens, böngésző (ezekben futnak az üzenetküldő szolgáltatások is), gaming szolgáltatások launcherei GUI-k. Továbbá a játékok nem GUI-k, de grafikusak, az mpv, sxiv, zathura szintén nem GUI-s, de grafikus bufferbe jelenitik meg, amit kell, ezt nem is lehet máshogy, különben nem lenne grafikájuk. A dmenu tartozik még ebbe a kategóriába, de lehet azt is kiváltom terminálban futó fzf-fel. Notification-t nem használok, de azt is terminálban oldanám meg. Böngészőnél, játéklaunchernél nem tudsz mit csinálni, azt csak így írják, csak így használhatók. A mailkliens így már csak, ami pengeélen táncol nálam. Igazából ha a böngésző megoldható lenne még, és lenne konzolon truecolor támogatás grafikus gyorsítással, és jobb Unicode-támogatás (valamilyen szinten támogatott, de a tty-fontoknak a nagy része nem túl sok Unicode glyphet tud), akkor ellennék tty konzolban is az idő nagy részében.

Vagyis még van egy GUI-s program nálam, de ezt is a böngésző indokolja. A file picker. Ugyanis a böngészők, mikor fájlt töltesz le adott helyre, vagy töltesz fel, akkor ahhoz nem drótozhatsz be saját kedvre akármilyen terminálos fájlkezelőt, egyszerűen nem kivitelezhető, pedig jó lenne. De ezt nem veszem külön kategóriának, mivel böngésző használja csak, annak a részének, opcionális függőségének tekintem. Továbbá van pár szoftvertípus, ami csak GUI-ban használható, bár nem használok ilyeneket, de pl. rajzolóprogramok, képmanipulálók, videóvágós szoftverek, DAW, CAD és 3D renderelős szoftvere, stb. nagyon nem lenne hatékony vagy kivitelezhető CLI/TUI alapon, de ilyet kevés átlag felhasználó használ. Átlagon itt azt értem, hogy nem ez a munkája, nem szakember ezeken a területeken, amikhez ezek a spéci szoftverek készültek, hanem csak hobbistaként használja.

A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

Mondom, a neomutt meg is felelne, ha nem indulna olyan pokolian lassan, és nem a betöltési idő, mert az betöltődne pár ms alatt, hanem a levelek lekérése a szerverről lassú, és nem a háttérben történik.

Íme a megoldás:

"szolgáltatásként" indítás, hogy a levelező megnyitásakor már le legyenek töltve a levelek: screen -dmS neomutt neomutt (ezután eltart egy ideig, míg a "szolgáltatás" kommunikál, és letölti az eddigi leveleket)

levelező megnyitása ezután: screen -r neomutt (itt azonnal "megnyílik" a levelező, nem kell várni a levelek letöltésére)

levelezőből "kilépés": ^a ^d billentyűk

"szolgáltatás" leállítása: a neomutt programból az eddig megszokott módon kilépve

Á lá vörkaround.

Működik natívan MS címekkel, nyilván nem ezt az idióta telepítővarázslós "Microsoft Exchange" hülyeséget kell használni, hanem meg kell adni a kimenő/bejövő kiszolgáló címét, mint minden más cím esetében.

Van tray ikon beépítetten.

1 mp a betöltés.

Egyszer nem crashelt az elmúlt ~ 2 évben.

A Nextcloud szinkronizáláshoz valóban kell egy addon, de miért pont ezt kéne natívan kezelnie? Nem is hallottam róla, amíg nem írtad. Nem hiszem, hogy az a jó irány, hogy minden kezel mindent.

Működik natívan MS címekkel, nyilván nem ezt az idióta telepítővarázslós "Microsoft Exchange" hülyeséget kell használni, hanem meg kell adni a kimenő/bejövő kiszolgáló címét,

Jó, majd szólj, ha a beépített ""Microsoft Exchange" hülyeség" is működik. Minek van benne, ha nem működik?

mint minden más cím esetében.

Egy címet sem használok már kigoogle-zva, hogy mik a beállítások és kézzel beállítgatva.

1 mp a betöltés.

Nem.

Egyszer nem crashelt az elmúlt ~ 2 évben.

De.

A Nextcloud szinkronizáláshoz valóban kell egy addon, de miért pont ezt kéne natívan kezelnie? Nem is hallottam róla, amíg nem írtad. Nem hiszem, hogy az a jó irány, hogy minden kezel mindent.

Minden más Calendarban, amiben próbáltam, műküdik, ebben nem. (natívan főleg nem) Örülök, h most már hallottál róla!

It is our choices that define us.
Thinkpad X1 Carbon | Arch linux

Nem hiszem, hogy az a jó irány, hogy minden kezel mindent.

Inkább az a szánalmas, hogy nincsenek szabványok, hanem minden vacak szolgáltatáshoz egyedileg kell mindent leprogramozni, mert van valami, amit valahogyan tud, de csak az és csak úgy.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE