Byl aktualizován seznam 500 nejvýkonnějších superpočítačů na světě TOP500. Nejvýkonnějším superpočítačem zůstává El Capitan od HPE (Cray) s výkonem 1,742 exaFLOPS. Druhý Frontier má výkon 1,353 exaFLOPS. Třetí Aurora má výkon 1,012 exaFLOPS. Nejvýkonnější český počítač C24 klesl na 165 místo. Karolina, GPU partition klesla na 195. místo a Karolina, CPU partition na 421. místo. Další přehledy a statistiky na stránkách projektu.
Oficiálně byl vydán Android 16. Detaily na blogu a stránkách věnovaných vývojářům.
Byla vydána nová verze 14.3 svobodného unixového operačního systému FreeBSD. Podrobný přehled novinek v poznámkách k vydání.
CSIRT.CZ upozorňuje, že na základě rozhodnutí federálního soudu ve Spojených státech budou veškeré konverzace uživatelů s ChatGPT uchovávány. Včetně těch smazaných.
Ač semestr ve škole právě končí, bastlíři ze studentského klubu Silicon Hill neodpočívají a opět se jako každý měsíc hlásí s pravidelným bastlířským setkáním Virtuální Bastlírna, kde si můžete s ostatními techniky popovídat jako u piva o novinkách, o elektronice, softwaru, vědě, technice obecně, ale také o bizarních tématech, která se za poslední měsíc na internetu vyskytla.
Z novinek za zmínku stojí Maker Faire, kde Pájeníčko předvedlo … více »Na WWDC25 byl představen balíček Containerization a nástroj container pro spouštění linuxových kontejnerů na macOS. Jedná se o open source software pod licencí Apache 2.0 napsaný v programovacím jazyce Swift.
Do 16. června do 19:00 běží na Steamu přehlídka nadcházejících her Festival Steam Next | červen 2025 doplněná demoverzemi, přenosy a dalšími aktivitami. Demoverze lze hrát zdarma.
Apple na své vývojářské konferenci WWDC25 (Worldwide Developers Conference, keynote) představil řadu novinek: designový materiál Liquid Glass, iOS 26, iPadOS 26, macOS Tahoe 26, watchOS 26, visionOS 26, tvOS 26, nové funkce Apple Intelligence, …
Organizátoři konference LinuxDays 2025, jež proběhne o víkendu 4. a 5. října 2025 v Praze na FIT ČVUT, spustili přihlašování přednášek (do 31. srpna) a sběr námětů na zlepšení.
Po roce byla vydána nová stabilní verze 25.6.0 svobodného multiplatformního multimediálního přehrávače SMPlayer (Wikipedie).
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.