Fugleramme, v překladu 'ptačí rámeček', je open-source projekt postavený na Raspberry Pi, který pomocí lokální umělé inteligence BirdNET-Go rozpoznává ptačí druhy podle jejich zpěvu a na displeji následně zobrazuje koláž tvořenou odpovídajícími ilustracemi. Databáze obsahuje přes 800 ručně vybraných historických přírodovědných ilustrací více než 400 druhů ptáků.
… více »Unicode Consortium, nezisková organizace koordinující rozvoj standardu Unicode, oznámila vydání Unicode 18.0. Přidáno bylo 13 007 nových znaků. Celkově jich je 172 808. Přibylo 9 nových Emoji.
Nové číslo časopisu Raspberry Pi zdarma ke čtení: Raspberry Pi Official Magazine 169 (pdf).
Byla vydána nová verze 6.4 programovacího jazyka Swift (Wikipedie). Zdrojové kódy jsou k dispozici na GitHubu.
Německý kancléř Friedrich Merz (CDU) se během debaty s finalisty studentské vědecké soutěže Jugend forscht vyjádřil pro konec anonymity na internetu a vyslovil názor, že pro uživatele Internetu by měla platit podobná právní odpovědnost jako pro novináře tradičních médií. Na dotaz studenta, jak by se tedy povinnost uvádět pravé jméno slučovala s prací investigativních novinářů nebo ochranou jejich zdrojů, Merz neodpověděl, ve své
… více »Společnost Fujitsu představila FUJITSU-MONAKA CPU a Fujitsu MONAKA Server. Navrženo, vyvinuto a vyrobeno v Japonsku. Pro suverénní AI infrastrukturu.
Předprodej v květnu představených notebooků Googlebook, nástupců notebooků Chromebook, bude spuštěn v pondělí 21. září.
Byla vydána betaverze Fedora Linuxu 45 (ChangeSet), tj. poslední zastávka před vydáním finální verze, která je naplánována na úterý 20. října. S konzolí kmscon místo fbcon. Současně byla vydána betaverze Fedora Linux Asahi Remixu 45. S podporou čipů M3.
Po půl roce vývoje od vydání verze 50 bylo vydáno GNOME 51 s kódovým názvem "A Coruña" (Mastodon). Podrobný přehled novinek i s náhledy v poznámkách k vydání a v novinkách pro vývojáře. Videopředstavení na PeerTube a YouTube.
OpenAI spolupracuje s konkurenty Anthropic a Google DeepMind ze skupiny Alphabet na bezpečnosti umělé inteligence (AI). Globální obavy ohledně existenčních rizik umělé inteligence vzrostly poté, co se o víkendu sešli vedoucí předních amerických firem z odvětví AI a vyzvali k pozastavení vývoje technologie.
I have not contacted the authorities, though maybe I should have done that.Uvazujes o bonzovani?
a pak jsou schopny identifikovat kupceA k čemu jim to je? Resp. jak mohou dokázat, že si autor nezměnil text sám? Buď má kniha DRM a pak je to jedno, nebo je to prostě jen text a ten si může modifikovat kdo chce jak chce.
btw jak to pak resis v MUA, kdyz (regulerne) odpovidas na email a chces mit v "MAIL FROM" ten alias, na ktery mail prisel?V Thunderbirdu to jde dopsat ručně, ale mám pocit, že jsem to snad ještě ani jednou nepotřeboval. E-shopy jsou v pohodě s tím, když se zachová předmět (číslo objednávky) příp. message ID a From může být klidně jiná.
btw jak to pak resis v MUA, kdyz (regulerne) odpovidas na email a chces mit v "MAIL FROM" ten alias, na ktery mail prisel?V NeoMutte to rieším takto:
set reverse_name = yes set use_envelope_from = yes alternates ^regex_mojich_adries$
k hledání úniků asi jako dobrý ale si myslim že uplně nejvíc spamu stejně de přímo z těch samotnejch různejch služeb kde byl mail použitej při registraci :O :/
nóó a když ty adresy boti jakoby parsujou co tam třeba jako zkusit strčit uplně nazačátek slovíčko 'noreply' třeba by takovej mail zahazovali :O :O :D ;D byl by problém s registračníma formulářema nebo to neřešej?? :O :O
Náhodné/unikátní adresy používám už dlouho, mám je třeba i na blogu nebo na stránkách svých projektů. Jinak to používám hlavně pro obchody a různé služby. Pár postřehů:
abc.iug30cs5@def.example.com nikoli jen abc.iug30cs5@example.com a asi tak jednou se mi stalo, že to neprošlo přes validaci v nějakém formuláři a jednou mi obchodník volal, že adresa je neplatná – tak jsem mu řekl, že nemůže být neplatná, kdy mi na ni od něj přišlo potvrzení objednávky. Nakonec mi tam fakturu poslal ručně a to taky prošlo.info, sales, atd.Nápad na zlepšení, který jsem zatím neimplementoval: Občas by se hodilo mít možnost generovat si alias offline, aniž bych ho musel zakládat na poštovním serveru. Na to by stačilo sdílené tajemství a hash/hmac – měl bych offline aplikaci, které bych zadal vstup (název/doménu příjemce) a vrátila by mi platnou e-mailovou adresu. např. "franta.abclinuxu.cz." + hash("abclinuxu.cz", "tajemství") + "@example.com". Na poštovním serveru by bylo stejné tajemství a stejný algoritmus (jde to napsat v SQL), takže by server věděl, na jakých adresách má přijímat poštu. K tomu by byla samozřejmě černá listina adres, které sice algoritmu+tajemství odpovídají, ale přijímat na nich už nic nechceme.
Další věc je, jak tu hromadu aliasů dostat do e-mailového klienta, aby na ty zprávy člověk mohl odpovídat (u obchodů to obvykle není potřeba, ale jinak se to hodí). Tady by šlo udělat rozšíření do Dovecotu, ze kterého by si pak klient mohl přes zvláštní IMAP příkaz vytáhnout ty aliasy. U dnešních klientů je dost otravné a hloupé, že při odpovídání automaticky vyplní výchozí adresu (pokud daná adresa není nakonfigurovaná jako identita pro odesílání) a neupozorní uživatele na to, že odpovídá z jiné adresy, než na jakou zpráva přišla. Takže může dojít k nežádoucímu úniku soukromé/výchozí adresy k někomu, kdo měl znát jen tu unikátní, kterou měl přidělenou. Tohle by šlo řešit doplňkem do e-mailového klienta (provizorně je dobré si jako výchozí odesílací nastavit nefunkční adresu a účet, ze kterého nejde nic poslat).
Občas by se hodilo mít možnost generovat si alias offline, aniž bych ho musel zakládat na poštovním serveru.Tomu se rika domenovy kos - mam takhle definovany email spamy@ a vsechny maily ktere prijdou na nezkonfigurovany alias skonci "v kosi". Diky tomu do formularu na internetu muzu napsat pred zavinacem cokoliv a vim ze to ve spamy@ najdu (a muzu odtud i poslat odpoved prostym prepsanim From: hlavicky (coz umi treba mutt)).
Doménový koš je něco jiného. Já chci spam1 okamžitě odmítnout ještě v rámci SMTP relace2 a ne se jím pak prohrabávat v nějakém koši.
[1] což zahrnuje i zprávy přicházející na neexistující adresy – podstata doménového koše
[2] aby odesílatel věděl, že jeho zpráva nebyla přijata – mimochodem, tohle by měl být standardní přístup – nesnáším současnou praxi, kdy někteří poskytovatelé hází náhodné e-maily do spamu nebo je rovnou mažou a odesílatel se o tom nijak nedozví – tohle ničí e-mailovou technologii jako takovou a dělá ji to nepoužitelnou
aby odesílatel věděl, že jeho zpráva nebyla přijataTo je celkem problematické. Může se stát to, že se informace o odesílateli ztratí nebo pochází z nedůvěryhodného zdroje (odesílatel, mezilehlý SMTP server, …), takže potom může být i tato odpověď nevyžádanou poštou. I jedna zpráva na schránku informovaného by mohla informujícímu způsobit škodu – například okamžité mazání budoucích zpráv od informujícího – protože informovaní mohou mít jednoho provozovatele, který by to mohl považovat za spam. Příklad: Odesílatel posílá zprávu na SMTP server A, ten ji pošle na server B a ten doručí zprávu Vám. Pokud si server A a B nemohou důvěřovat, hlavičky identifikující odesílatele (např.
From) se potom na serveru B nemohou použít pro adresování zprávy skutečnému odesílateli. Signalizace po SMTP také často není realizovatelná – spojení může být uzavřeno ještě před doručením.
.
Pro představu, jak se to provozovalo na matfyzu, kde strašně chtěli mezilehlý SMTP server: bylo několik možností, jak SMTP serveru říct, pro jaké uživatele poštu přijímáme (ručně, soubor pravidelně stahovaný přes nějaké API), a on pak pro tyto přijímal a pro ostatní odmítal.
Trochu jsem se na tohle téma rozepsal ve vedlejší diskusi: Reputační systém a vratné zálohy + anti-spam
Teraz som z toho už úplne mimo, veď VoIP by malo mať v sebe priamu funkcionalitu SMS.Má. SIP umožnuje posielať plain text správu cez MESSAGE príkaz. A ktomu špeciálne kvôli VoLTE bol vymyslený spôsob ako poslať RPDU obsah SMS správy ako binárku cez SIP MESSAGE. Oboje sa dá teda chápať ako "priama funkcionalita vo VOIP". Ibaže nič z toho nie je poskytované pre geografické/nomadické čísla na VOIP linkách v ČR. Čo sa týka funkcionalít geografických a nomadických čísel na VOIP/SIP linkách v ČR, tak tam je proste iba preklopená analógová časť na nasamplovaný zvuk v RTP zabalený do UDP paketov. A keď služby na analógovej linke behali in-band cez modem (ako FAX alebo SMS), tak patričný zvuk je rovnako prenášaný ako zvuk na VOIP/SIP linkách. Je tu ale jeden menší pokrok v oblasti FAXu cez VOIP. Na prenos FAX po VOIP existuje protokol T.38. Definuje ako zabaliť binárny FAX do UDP a teda už nepoužívať modem v hlasovej časti cez RTP. VOIP brány po ceste ho zvyknú podporovať.
Ak to teda poskytovatelia neblokujú kvôli spamerom, ale to by blokovali odosielanieJa som zatiaľ písal iba o prijímaní obsahu. Posielanie je naozaj zablokované a neposkytované z geografických a nomadických čísel asi u všetkých operátorov (analógových aj VOIP) až na výnimku, monopol O2-CZ. Tzn. funguje to iba pre analógové pevné linky, kde si užívateľ platí "vysoký tarif". Proste ak chce niekto poslať SMSku na ľubovoľné české geografické/nomadické číslo (či už zo sim karty nejakého mobilného operátora alebo cez nejakú webovú/komerčnú službu), tak SMSku normálne pošle a jeho operátor ju doručí operátorovi O2-CZ, ktorý sa ďalej postará o doručenie na konkrétne geografické/nomadické číslo jedným z tých haluzných spôsobov. A to bez ohľadu na to akého operátora má príjemca.
Tiskni
Sdílej: