Google Chrome 125 byl prohlášen za stabilní. Nejnovější stabilní verze 125.0.6422.60 přináší řadu oprav a vylepšení (YouTube). Podrobný přehled v poznámkách k vydání. Opraveno bylo 9 bezpečnostních chyb. Vylepšeny byly také nástroje pro vývojáře.
Textový editor Neovim byl vydán ve verzi 0.10 (𝕏). Přehled novinek v příspěvku na blogu a v poznámkách k vydání.
Byla vydána nová verze 6.3 živé linuxové distribuce Tails (The Amnesic Incognito Live System), jež klade důraz na ochranu soukromí uživatelů a anonymitu. Přehled změn v příslušném seznamu. Tor Browser byl povýšen na verzi 13.0.15.
Dnes ve 12:00 byla spuštěna první aukce domén .CZ. Zatím největší zájem je o dro.cz, kachnicka.cz, octavie.cz, uvycepu.cz a vnady.cz [𝕏].
JackTrip byl vydán ve verzi 2.3.0. Jedná se o multiplatformní open source software umožňující hudebníkům z různých částí světa společné hraní. JackTrip lze instalovat také z Flathubu.
Patnáctý ročník ne-konference jOpenSpace se koná 4. – 6. října 2024 v Hotelu Antoň v Telči. Pro účast je potřeba vyplnit registrační formulář. Ne-konference neznamená, že se organizátorům nechce připravovat program, ale naopak dává prostor všem pozvaným, aby si program sami složili z toho nejzajímavějšího, čím se v poslední době zabývají nebo co je oslovilo. Obsah, který vytváří všichni účastníci, se skládá z desetiminutových
… více »Program pro generování 3D lidských postav MakeHuman (Wikipedie, GitHub) byl vydán ve verzi 1.3.0. Hlavní novinkou je výběr tvaru těla (body shapes).
Intel vydal 41 upozornění na bezpečnostní chyby ve svých produktech. Současně vydal verzi 20240514 mikrokódů pro své procesory řešící INTEL-SA-01051, INTEL-SA-01052 a INTEL-SA-01036.
Společnost Raspberry Pi patřící nadaci Raspberry Pi chystá IPO a vstup na Londýnskou burzu.
Google na své vývojářské konferenci Google I/O 2024 představil řadu novinek. Keynote byl věnován umělé inteligenci (DeepMind, Gemini, Responsible AI).
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.
Tiskni Sdílej: