Byla vydána nová stabilní verze 7.6 webového prohlížeče Vivaldi (Wikipedie). Postavena je na Chromiu 140. Přehled novinek i s náhledy v příspěvku na blogu.
Byla vydána verze 1.90.0 programovacího jazyka Rust (Wikipedie). Podrobnosti v poznámkách k vydání. Vyzkoušet Rust lze například na stránce Rust by Example.
GNUnet (Wikipedie) byl vydán v nové major verzi 0.25.0. Jedná se o framework pro decentralizované peer-to-peer síťování, na kterém je postavena řada aplikací.
Byla vydána nová major verze 7.0 živé linuxové distribuce Tails (The Amnesic Incognito Live System), jež klade důraz na ochranu soukromí uživatelů a anonymitu. Nově je postavena je na Debianu 13 (Trixie) a GNOME 48 (Bengaluru). Další novinky v příslušném seznamu.
Společnost Meta na dvoudenní konferenci Meta Connect 2025 představuje své novinky. První den byly představeny nové AI brýle: Ray-Ban Meta (Gen 2), sportovní Oakley Meta Vanguard a především Meta Ray-Ban Display s integrovaným displejem a EMG náramkem pro ovládání.
Po půl roce vývoje od vydání verze 48 bylo vydáno GNOME 49 s kódovým názvem Brescia (Mastodon). S přehrávačem videí Showtime místo Totemu a prohlížečem dokumentů Papers místo Evince. Podrobný přehled novinek i s náhledy v poznámkách k vydání a v novinkách pro vývojáře.
Open source softwarový stack ROCm (Wikipedie) pro vývoj AI a HPC na GPU od AMD byl vydán ve verzi 7.0.0. Přidána byla podpora AMD Instinct MI355X a MI350X.
Byla vydána nová verze 258 správce systému a služeb systemd (GitHub).
Byla vydána Java 25 / JDK 25. Nových vlastností (JEP - JDK Enhancement Proposal) je 18. Jedná se o LTS verzi.
Věra Pohlová před 26 lety: „Tyhle aféry každého jenom otravují. Já bych všechny ty internety a počítače zakázala“. Jde o odpověď na anketní otázku deníku Metro vydaného 17. září 1999 na téma zneužití údajů o sporožirových účtech klientů České spořitelny.
Používáte některé open-source řešení [protokol] pro šifrovaný instant messaging?
Matrix |
|
20% (83) |
Signal |
|
31% (125) |
Tox |
|
5% (20) |
jiné open-source |
|
11% (46) |
proprietární |
|
17% (69) |
jiné s šifrováním jako doplňkem |
|
5% (19) |
nešifruji |
|
13% (51) |
IM nepoužívám |
|
23% (93) |
Celkem 407 hlasů
Vytvořeno: 1.6.2020 12:25
Tiskni
Sdílej:
To není šifrovaný instant-messaging, protože IRC server všechno vidí v plain textu. Přece jen máme rok 2020, takže když se řekne šifrovaný instant-messaging, mělo by to znamenat end-to-end šifrování.
Jak může mít uživatel jistotu, že něco nesmrdí někde jinde v aplikaci?Android aplikace lze celkem dobře dekompilovat (i když to licence většinou nepovoluje). Ten výstup není zrovna hezké čtení, ale to konec konců mnoho open source zdrojáků taky ne.
Teoreticky by si to v budoucnu mohlo přes ten mail jen dohodnout jiný komunikační kanál, který by se pro ten hovor použil.Ano, dohaduje se jiný kanál např. pro audio/video konference a pro přenos obrovských souborů (větších než 10 MByte).
Já bych se hlavně spíš obával toho, aby to příliš nefloodovalo inbox (nebo nějakou složku, do které se to bude ukládat)DeltaChat by default vytvoří vlastní adresář "DeltaChat" a do inboxu pouze kouká a emaily pocházející z DeltaChat klientů přesouvá do toho adresáře "DeltaChat". Jinak se chránkou nedělá nic - takže žádný flooding atd. DeltaChat má přímo ve svých cílích pouze "nenápadně" využít stávající infrastrukturu a snaží se maximálně nepoškodit žádná existující "workflow" uživatelů.
aby zprávy neměly tendenci padat do spamuZatím jsem neviděl za těch několik let co se DeltaChat používá mezi tísícovkama lidí (myslím, že to nejsou ještě desetitisíce či více, ale snad brzy ano) s různými email servery, že by se to stávalo. Spam filtr nemá důvod je zahazovat protože jsou šifrované (a podle odesílatelů se dnes již prakticky nefiltruje kvůli příliš velkému množství false positives).
a aby mezi některými servery nebyly (měřítkem IM) příliš dlouhé latence.Praxe ukazuje, že většinou zprávy chodí až překvapivě rychle. Ale samozřejmě je to individuální.
Přecejen se e-mail primárně používá pro spíše méně spíše obsáhlejších zpráv a nejsem si jistý, jestli ohnutí této infrastruktury pro přenos kratších, často jednovětných zpráv, samostatně stojících odkazů apod. nebude způsobovat všelijaké problémy.Žádné mi nejsou známi. No a vzhledem k tomu, že je vše plně e2e šifrované, tak ani žádné neočekávám
Další věc je třeba garantované pořadí doručení, řeší to tam nějak?Ano, je to "nějak" chronologicky seřazené. Technicky myslím, že se "věří" časům, které uvádí odesílatel a nějak bez "skákání/trhání/posouvání" se upozorní na novou zprávů "výše v chatu". Bylo to ještě před pár měsíci hodně horké téma skoro po dva roky (je tam problémů spousta - od banálních typu "odesláno offline a doručeno až mnoho hodin/dní poté" přes nedůvěřování hodinám odesílatele ani žádným z "relay" SMTP serverů atd. až po user experience kdy nechceme linearitu diskuze bořit automatickým skákáním "nahoru" na nově přijatou avšak starou zprávu ale zároveň nechceme, aby diskuze zprávy byly úplně mimo kontext při zařazní "vždy na konec" atd.).
1. kdyz cilova osoba ma klienta, ale nema ho spustenej, prijde ji mail? nebo se nekde decentralizovane vi ze se v klientu nekdy v minulosti prihlasila a ceka se nez si klienta pusti? a doba cekani zalezi na cilovem mail server dle jeho timeout pro doruceni emailu nebo to muj client bude zkouset dokud se doruceni nepodari po tom co cilova osoba zapne klienta?Ano, email přijde vždy a okamžitě (tj. zcela nezávisle, zdali si ho nějaký MUA okamžitě/později/nikdy (ne)vyzvedne). Jakmile si pustí uživatel non-DeltaChat MUA (např. Thunderbird či Outlook), tak tam normálně uvidí nepřečtený email (zprávu od někoho, kdo ji odeslal z MUA DeltaChat) a pokud není šifrovaná, tak si ji může přečíst. Jakmile si ale spustí DeltaChat, tak ten tento email také uvidí (mělo by to být nezávislé na tom, zdali je či není přečtená) a rozšifruje (pokud byl zašifrovaný) a zobrazí (samozřejmě za předpokladu, že Thunderbird ten email nesmazal nebo nepřesunul do nějakého adresáře mimo inbox). Žádné čekání neexistuje, nýbrž pouze běžné "acknowledge received message" schéma. Zpráva tedy má více stavů - minimálně tyto: nejprve je "odeslaná lokálně" (tzn. pokud je DeltaChat offline; žádná indikace fajfkami u zprávy v UI), pak "odeslaná na odesílatelův SMTP" (indikace v UI jednou zelenou fajfkou) a pokud se tomuto SMTP podaří doručit ji a zároveň si ji vyzvedne adresát přes DeltaChat a zároveň si ji adresát přečte (tzn. otevře danou skupinu/chat), tak DeltaChat pošle okamžitě automaticky na pozadí "acknowledge" jako odpověď a potvrzení přijetí (indikace v UI druhou zelenou fajfkou).
2. chapu spravne ze lze mit klienty na pc a telefonu ktere oba budou dostavat notifikace i synchronizovat odeslane zpravy? (po tom co z prvniho prihlaseneho klienta udelam export a jinde import do nove pripravovaneho klienta)Ano, je to tak. Ten export a následný import je potřeba vzhledem k šifrování, resp. přenosu privátních klíčů a konfigurace DeltaChat-specific rozšíření nad rámec Autocrypt bezpečnou cestou. Aktuálně se to dělá exportováním na SD kartu (a rovnou se exportuje i historie zpráv, aby se nemusela na dalším zařízení stahovat), ale je rozpracovaná implementace přenosu těchto informací zcela na pozadí tak, že při přihlášení bude mít člověk možnost se přihlásit buď "bez synchronizace" a nebo prostě "se synchronizací" s tím, že tato druhá volba bude vyžadovat při prvním takovém přihlášení i&ndsp;OTP pro rozbalení dat pocházejících (a na pozadí automaticky se přenášejících) ze zařízení s klíči (tzn. "musím mít zrovna po ruce ten původní mobil, který mi zobrazí to OTP"). Odhaduji, že tento "intuitivnější" způsob bude dostupný zhruba za rok až dva (vzhledem k tomu, že jde o&nbps;"root of truest", tak je nutné delší testování než u ostatních features).
3. z principu vyuziti imap predpokladam nehrozi v budoucnu hlasove natoz video hovory, problem s tim nemam ale videl bych to jako castecnou brzdu pro pouziti u lidi ktere toto aktivne vyuzivajiDeltaChat už má experimentální podporu pro video a audio konference - cílem však není všechno hnát přes IMAP+SMTP (to by byl skutečně nesmysl, pokud ty protokoly nebudou výrazně vylepšeny v tomto ohledu v budoucnu), a tak se jedná spíše o integraci existujících služeb - aktuálně Jitsi Meet (který však již vyžaduje SPOF/centralizaci - konkrétně minimálně rendezvous server pro sestavení spojení přes WebRTC).
Používáte některé open-source řešení [protokol] pro šifrovaný instant messaging? proprietárníTak tomu nerozumim.
Jak vůbec může v možnostech chybět tradiční Jabber s OMEMO! (Pravda, implementace lurch pro Pidgin je… no… zkrátka, už jsem viděl lepší… Ale třeba v Gajimu je celkem dobře udělaná.)
Signal je teoreticky fajn. Prakticky…
In May 2016, Signal's lead developer Moxie Marlinspike requested that a third-party client called LibreSignal not use the Signal service or the Signal name. As a result, on 24 May 2016 the LibreSignal project posted that the project was "abandoned".
Vývojář LibreSignal: „If I finance running a TextSecure server for LibreSignal, will you federate with us?“
Signal (Moxie): „It is unlikely that we will ever federate with any servers outside of our control“
[zdroj]
Signal (Moxie): „federation and defined protocols […] no longer have a place in the modern world“ [zdroj]
„They have explicitly said that the only want their own builds of Signal using their server.“ [zdroj]
Říkám pořád, že pouhé „open-source“ nestačí. Svobodný software, svobodný ekosystém.