Andreas Kling oznámil, že jelikož už se nevěnuje nezávislému operačnímu systému SerenityOS, ale výhradně jeho webovému prohlížeči Ladybird, přičemž vyvíjí primárně na Linuxu, SerenityOS opustí a Ladybird bude nově samostatný projekt (nový web, repozitář na GitHubu).
Po dvou měsících vývoje byla vydána nová verze 0.13.0 programovacího jazyka Zig (GitHub, Wikipedie). Přispělo 73 vývojářů. Přehled novinek v poznámkách k vydání.
Na čem aktuálně pracují vývojáři GNOME a KDE? Pravidelný přehled novinek v Týden v GNOME a Týden v KDE.
Před 70 lety, 7. června 1954, ve věku 41 let, zemřel Alan Turing, britský matematik, logik, kryptoanalytik a zakladatel moderní informatiky.
NiceGUI umožňuje používat webový prohlížeč jako frontend pro kód v Pythonu. Zdrojové kódy jsou k dispozici na GitHubu pod licencí MIT.
Open source platforma Home Assistant (Demo, GitHub, Wikipedie) pro monitorování a řízení inteligentní domácnosti byla vydána ve verzi 2024.6. Z novinek lze vypíchnout lepší integraci LLM (OpenAI, Google AI, Ollama) nebo podporu Matter 1.3.
IKEA ve Spojeném království hledá zaměstnance do své nové pobočky. Do pobočky v počítačové hře Roblox. Nástupní mzda je 13,15 liber na hodinu.
Alyssa Rosenzweig se v příspěvku na svém blogu Vulkan 1.3 na M1 za 1 měsíc rozepsala o novém Vulkan 1.3 ovladači Honeykrisp pro Apple M1 splňujícím specifikaci Khronosu. Vychází z ovladače NVK pro GPU od Nvidie. V plánu je dále rozchodit DXVK a vkd3d-proton a tím pádem Direct3D, aby na Apple M1 s Asahi Linuxem běžely hry pro Microsoft Windows.
Byla vydána (𝕏) květnová aktualizace aneb nová verze 1.90 editoru zdrojových kódů Visual Studio Code (Wikipedie). Přehled novinek i s náhledy a animovanými gify v poznámkách k vydání. Ve verzi 1.90 vyjde také VSCodium, tj. komunitní sestavení Visual Studia Code bez telemetrie a licenčních podmínek Microsoftu.
Byla vydána (Mastodon, 𝕏) nová verze 2024.2 linuxové distribuce navržené pro digitální forenzní analýzu a penetrační testování Kali Linux (Wikipedie). Přehled novinek se seznamem nových nástrojů v oficiálním oznámení.
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 No a něco takového by se už z definice na IPv6 realizovalo/realizuje mnohem líp než na IPv4...
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.