Vývojáři OpenMW (Wikipedie) oznámili vydání verze 0.49.0 této svobodné implementace enginu pro hru The Elder Scrolls III: Morrowind. Přehled novinek i s náhledy obrazovek v oznámení o vydání.
Masivní výpadek elektrického proudu zasáhl velkou část České republiky. Hasiči vyjížděli k většímu počtu lidí uvězněných ve výtazích. Výpadek se týkal zejména severozápadu republiky, dotkl se také Prahy, Středočeského nebo Královéhradeckého kraje. Ochromen byl provoz pražské MHD, linky metra se už podařilo obnovit. Výpadek proudu postihl osm rozvoden přenosové soustavy, pět z nich je nyní opět v provozu. Příčina problémů je však stále neznámá. Po 16. hodině zasedne Ústřední krizový štáb.
Po více než roce vývoje od vydání verze 5.40 byla vydána nová stabilní verze 5.42 programovacího jazyka Perl (Wikipedie). Do vývoje se zapojilo 64 vývojářů. Změněno bylo přibližně 280 tisíc řádků v 1 500 souborech. Přehled novinek a změn v podrobném seznamu.
Byla vydána nová stabilní verze 7.5 webového prohlížeče Vivaldi (Wikipedie). Postavena je na Chromiu 138. Přehled novinek i s náhledy v příspěvku na blogu.
Sniffnet je multiplatformní aplikace pro sledování internetového provozu. Ke stažení pro Windows, macOS i Linux. Jedná se o open source software. Zdrojové kódy v programovacím jazyce Rust jsou k dispozici na GitHubu. Vývoj je finančně podporován NLnet Foundation.
Byl vydán Debian Installer Trixie RC 2, tj. druhá RC verze instalátoru Debianu 13 s kódovým názvem Trixie.
Na čem pracují vývojáři webového prohlížeče Ladybird (GitHub)? Byl publikován přehled vývoje za červen (YouTube).
Libreboot (Wikipedie) – svobodný firmware nahrazující proprietární BIOSy, distribuce Corebootu s pravidly pro proprietární bloby – byl vydán ve verzi 25.06 "Luminous Lemon". Přidána byla podpora desek Acer Q45T-AM a Dell Precision T1700 SFF a MT. Současně byl ve verzi 25.06 "Onerous Olive" vydán také Canoeboot, tj. fork Librebootu s ještě přísnějšími pravidly.
Licence GNU GPLv3 o víkendu oslavila 18 let. Oficiálně vyšla 29. června 2007. Při té příležitosti Richard E. Fontana a Bradley M. Kuhn restartovali, oživili a znovu spustili projekt Copyleft-Next s cílem prodiskutovat a navrhnout novou licenci.
Svobodný nemocniční informační systém GNU Health Hospital Information System (HIS) (Wikipedie) byl vydán ve verzi 5.0 (Mastodon).
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.