Společnost NVIDIA vydala verzi 13.0 toolkitu CUDA (Wikipedie) umožňujícího vývoj aplikací běžících na jejich grafických kartách. Přehled novinek v poznámkách k vydání.
Byly vyhlášeni vítězové a zveřejněny vítězné zdrojové kódy (YouTube, GitHub) již 28. ročníku soutěže International Obfuscated C Code Contest (IOCCC), tj. soutěže o nejnepřehlednější (nejobfuskovanější) zdrojový kód v jazyce C.
Na čem pracují vývojáři webového prohlížeče Ladybird (GitHub)? Byl publikován přehled vývoje za červenec (YouTube).
Konečně se ochladilo, možná i díky tomu přestaly na chvíli padat rakety jako přezrálé hrušky, díky čemuž se na Virtuální Bastlírně dostane i na jiná, přízemnější témata. Pokud si chcete jako každý měsíc popovídat s dalšími bastlíři, techniky, vědci a profesory u virtuálního pokecu u piva, Virtuální Bastlírna je tu pro Vás.
Ještě před ochlazením se drát na vedení V411 roztáhl o 17 metrů (přesné číslo není známé, ale drát nepřežil) a způsobil tak… více »Na čem aktuálně pracují vývojáři GNOME a KDE Plasma? Pravidelný přehled novinek v Týden v GNOME a Týden v KDE Plasma.
PixiEditor byl vydán ve verzi 2.0. Jedná se o multiplatformní univerzální all-in-one 2D grafický editor. Zvládne rastrovou i vektorovou grafiku, pixel art, k tomu animace a efekty pomocí uzlového grafu. Zdrojové kódy jsou k dispozici na GitHubu pod licencí GNU LGPL 3.0.
Byly představeny novinky v Raspberry Pi Connect for Organisations. Vylepšen byl protokol auditu pro lepší zabezpečení. Raspberry Pi Connect je oficiální služba Raspberry Pi pro vzdálený přístup k jednodeskovým počítačům Raspberry Pi z webového prohlížeče. Verze pro organizace je placená. Cena je 0,50 dolaru za zařízení za měsíc.
CISA (Cybersecurity and Infrastructure Security Agency) oznámila veřejnou dostupnost škálovatelné a distribuované platformy Thorium pro automatizovanou analýzu malwaru. Zdrojové kódy jsou k dispozici na GitHubu.
Ubuntu nově pro testování nových verzí vydává měsíční snapshoty. Dnes vyšel 3. snapshot Ubuntu 25.10 (Questing Quokka).
Společnost Proton AG stojící za Proton Mailem a dalšími službami přidala do svého portfolia Proton Authenticator. S otevřeným zdrojovým kódem a k dispozici na všech zařízeních. Snadno a bezpečně synchronizujte a zálohujte své 2FA kódy. K používání nepotřebujete Proton Account.
Pořídil jsem si WiFi SIP telefon Well ST100 a jal se ho zkoušet s domácím Asteriskem. Telefon se ale občas začal chovat dost podivně: v určitou chvíli se „zasekne“ a od té doby jsou všechny hovory „hluché“, tj. směrem do telefonu „nejde zvuk“. Zdá se mi ale, že jsem našel příčinu a workaround.
Nejdřív jsem se dlouze snažil hledat různá nastavení, jestli jsem něco nezvoral, ale všechno marně. Nakonec jsem překonal vrozenou lennost a spustil na to wireshark a nestačil se divit. RTP packety z lokálního serveru nešly ve chvíli závady na IP telefonu, ale byly směřovány na vnější IP celé sítě (ta je za NATem a některé porty má přesměrovány na specifické IP). Když jsem se podíval na začátek spojení, zjistil jsem, že už v prvním packetu tam telefon onu vnějšní adresu háže v rámci SDP.
Z toho mi vyplývá, že telefon má zřejmě naimplementován nějaký „geniální“ algortimus na obcházení NATu, který se aktivuje na první pohled nedeterministicky. Zřejmě to asi bude využívat nějaké cizí servery, ze kterých zjistí vnějšní IP adresu sítě a tu pak nabonzuje SIP serveru.
Jelikož hlásit to výrobci a požadovat po něm opravu je dost na dlouhý lokte (ale třeba si na to taky najdu čas), sáhl jsem prozatím k jednoduchému workaroundu - zakázal telefonu přístup do internetu. Takto nemůže zjišťovat, jaká je vnějšní IP adresa a tím ani dělat problémy. Zatím to vypadá, že to problém vyřešilo. Třeba to někomu pomůže, jinak je to docela sympatický telefon :=)
Tiskni
Sdílej:
Tenhle telefon to dělá bez ptaní a ještě jenom když „se mu zachce“. To je ten problém.Ono taky záleží na tom, kde a jak jsi to kupoval :). Jestli jsi vybíral obchod podle ceny, tak se nediv. Je to stále relativní novinka a když to koupíš někde se starým firmware, tak to prostě fungovat ani nemůže.
Jeden ze zásadních problémů SIPu je to, že neumí NAT.To není tak úplně pravda.
To nejsou problemy s NATem.Pak chceš jistě tvrdit, že by ty problémy bez NATu nevznikly, nebo se mýlím?
BTW, vsichni poskytovatele VOIP/SIP, co jsem zkousel, se s NATem umi dobre vyrovnat na zaklade server-side reseni).To je značně laický a konzumentský pohled. Kdybys o SIPu něco málo věděl, tušil bys, že je od začátku navržený tak, aby žádného prostředníka či poskytovatele nepotřeboval.
IPv6? Nechapu, k cemu by mi to melo byt dobre.Není potřeba, abys tomu rozuměl :).
S IPv4 mi nic nechybiKonzumentovi ani nic chybět nemůže. Konzumuje, co mu bylo předloženo. Když je úplně nejhůř, tak na to během konzumace nadává.
To nejsou problemy s NATem.Pak chceš jistě tvrdit, že by ty problémy bez NATu nevznikly, nebo se mýlím?
Bez internetu a počítačů by ty problémy taky nevznikly
BTW, vsichni poskytovatele VOIP/SIP, co jsem zkousel, se s NATem umi dobre vyrovnat na zaklade server-side reseni).To je značně laický a konzumentský pohled. Kdybys o SIPu něco málo věděl, tušil bys, že je od začátku navržený tak, aby žádného prostředníka či poskytovatele nepotřeboval.
No a k čemu je takový SIP dobrý? Pokud chce člověk, aby jeho hovory terminovaly ve veřejné telefonní síti, tak bez nějakého poskytovatele stejně neobejde...
IPv6? Nechapu, k cemu by mi to melo byt dobre.Není potřeba, abys tomu rozuměl :).
Nejsem tupá ofce, jako ty
IPv6? Nechapu, k cemu by mi to melo byt dobre. S IPv4 mi nic nechybiNo, internetová telefonie je v kostce o tom, že se dva lidí k sobě připojí a povídají si
To, ze Linux dela standardne symetricky NATJo, tohle mě zajímalo. Já jsem takové experimenty nedělal, ale vždycky jsem měl za to, že na Linuxu UDP NAT-T funguje a odchozí porty že se nesdílí.
To prvni lze snadno overit jednoduchym experimentem, videt to je napriklad i z toho, ze ruzni klienti za (linuxovym) NATem mohou sdilet stejny port na NATu (coz umoznuje AFAIK jen symetricky NAT).Tak ono je lepší vědět než jen otestovat, ale ani to jsem nedělal :).
Na druhou stranu ten linuxovy NAT se snazi nemenit porty pokud to jde, takze jeho chovani muze casto pripominat port-restricted cone NAT a muze byt tak detekovan a casto to muze i fungovat, ale podminka pro to, aby to tak fungovalo spolehlive (tedy ze NAT vyhradi port pro aktivni host:port za NATem), obecne splnena neni.To bude asi to, co mě uvedlo v omyl. Takže řekněme při pár strojích za NATem s náhodnými zdrojovými porty je to ještě celkem použitelné. A jestli to dobře chápu, tak to striktně nedodržuje ani ten symmetric NAT, protože u toho by nebylo možné port detekovat s tak velkou pravděpodobností. Takže to nejspíš nesplňuje ani definici symetrického NATu, ani definici restricted-cone NATu.
(zdroj a cil komunikace, C* za NATem, S* venku) CA1:CP -> SA1:SP NAT CA1:CP na port CP CA2:CP -> SA2:SP NAT CA2:CP na port CP CA2:CP -> SA1:SP NAT CA2:CP na nahodny port, CP nemuze pouzitTedy snazi se to zachovat zdrojovy port, i kdyz kvuli tomu zacne sdilet porty mezi ruznymi klienty. Oproti tomu restricted-cone NAT by uz v druhem kroku zvolil nahodny port a ten samy pouzil i ve tretim.
A jestli to dobře chápu, tak to striktně nedodržuje ani ten symmetric NAT, protože u toho by nebylo možné port detekovat s tak velkou pravděpodobností.To je otazka jak presne interpretovat tu definici. IMHO ta definice nepozaduje, ze by to mapovani muselo byt vzdy nahodne. Spis bych to videl tak, ze v cone NATech plati dodatecny axiom (zdroj:port za NATem je jednoznacne identifikovan portem (a IP) NATu), zatimco u symmetric NAT ten axiom neplati.