Byl publikován přehled dění a novinek z vývoje Asahi Linuxu, tj. Linuxu pro Apple Silicon. Fedora 43 Asahi Remix s KDE Plasma už funguje na M3. Zatím ale bez GPU akcelerace. Vývojáře lze podpořit na Open Collective a GitHub Sponsors.
Red Hat představil nový nástroj Digital Sovereignty Readiness Assessment (GitHub), který organizacím umožní vyhodnotit jejich aktuální schopnosti v oblasti digitální suverenity a nastavit strategii pro nezávislé a bezpečné řízení IT prostředí.
BarraCUDA je neoficiální open-source CUDA kompilátor, ale pro grafické karty AMD (CUDA je proprietární technologie společnosti NVIDIA). BarraCUDA dokáže přeložit zdrojové *.cu soubory (prakticky C/C++) přímo do strojového kódu mikroarchitektury GFX11 a vytvořit tak ELF *.hsaco binární soubory, spustitelné na grafické kartě AMD. Zdrojový kód (převážně C99) je k dispozici na GitHubu, pod licencí Apache-2.0.
Podvodné reklamy na sociálních internetových platformách, jako je Facebook, Instagram nebo X, vytvořily loni v Česku jejich provozovatelům příjmy 139 milionů eur, tedy zhruba 3,4 miliardy korun. Proti roku 2022 je to nárůst o 51 procent. Vyplývá to z analýzy Juniper Research pro společnost Revolut. Podle výzkumu je v Česku zhruba jedna ze sedmi zobrazených reklam podvodná. Je to o 14,5 procenta více, než je evropský průměr, kde je podvodná každá desátá reklama.
Desktopové prostředí KDE Plasma bylo vydáno ve verzi 6.6 (Mastodon). Přehled novinek i s videi a se snímky obrazovek v oficiálním oznámení. Podrobný přehled v seznamu změn.
Czkawka a Krokiet, grafické aplikace pro hledání duplicitních a zbytečných souborů, byly vydány ve verzi 11.0. Podrobný přehled novinek v příspěvku na Medium. Od verze 7.0 je vedle frontendu Czkawka postaveného nad frameworkem GTK 4 vyvíjen nový frontend Krokiet postavený nad frameworkem Slint. Frontend Czkawka je už pouze v udržovacím módu. Novinky jsou implementovány ve frontendu Krokiet.
Jiří Eischmann na svém blogu publikoval článek Úvod do MeshCore: "Doteď mě radioamatérské vysílání úplně míjelo. Když jsem se ale dozvěděl, že existují komunity, které svépomocí budují bezdrátové sítě, které jsou nezávislé na Internetu a do značné míry taky elektrické síti a přes které můžete komunikovat s lidmi i na druhé straně republiky, zaujalo mě to. Když o tom přede mnou pořád básnili kolegové v práci, rozhodl jsem se, že to zkusím taky.
… více »Byla vydána verze 0.5.20 open source správce počítačových her na Linuxu Lutris (Wikipedie). Přehled novinek v oznámení na GitHubu. Instalovat lze také z Flathubu.
Peter Steinberger, autor open source AI asistenta OpenClaw, nastupuje do OpenAI. OpenClaw bude převeden pod nadaci a zůstane otevřený a nezávislý.
Společnost Backblaze zveřejnila statistiky spolehlivosti pevných disků používaných ve svých datových centrech za rok 2025. Ke konci roku 2025 vlastnila 349 462 pevných disků. Průměrná AFR (Annualized Failure Rate), tj. pravděpodobnost, že disk během roku selže, byla 1,36 %. V roce 2024 to bylo 1,57 %. V roce 2023 to bylo 1,70 %. V roce 2022 to bylo 1,37 %.
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í.
5.6.2020 21:36
vencour | skóre: 56
| blog: Tady je Vencourovo
| Praha+západní Čechy
6.6.2020 01:39
k3dAR | skóre: 63
20.6.2020 14:01
k3dAR | skóre: 63
20.6.2020 18:41
Josef Kufner | skóre: 70
24.6.2020 22:22
k3dAR | skóre: 63
7.6.2020 14:29
|🇵🇸 | skóre: 94
| blog:
8.6.2020 09:31
|🇵🇸 | skóre: 94
| blog:
8.6.2020 21:23
|🇵🇸 | skóre: 94
| blog:
9.6.2020 13:45
|🇵🇸 | skóre: 94
| blog:
9.6.2020 14:57
Josef Kufner | skóre: 70
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.
6.6.2020 13:40
Josef Kufner | skóre: 70
21.6.2020 20:29
paul2no | skóre: 16
| blog: Paulovo doupě
| Praha
28.6.2020 17:51
k3dAR | skóre: 63
9.7.2020 01:07
k3dAR | skóre: 63
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.
31.7.2020 11:45
k3dAR | skóre: 63
31.7.2020 12:46
NUKE GAZA! 🎆 | skóre: 37
| blog: Grétin blogísek
| 🇮🇱==❤️ , 🇵🇸==💩 , 🇪🇺==☭
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.
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz