Byla vydána nová stabilní verze 24.05 linuxové distribuce NixOS (Wikipedie). Její kódové označení je Uakari. Podrobný přehled novinek v poznámkách k vydání. O balíčky se v NixOS stará správce balíčků Nix.
Byla vydána nová verze 1.48.0 sady nástrojů pro správu síťových připojení NetworkManager. Novinkám se v příspěvku na blogu NetworkManageru věnuje Fernando F. Mancera. Mimo jiné se v nastavení místo mac-address-blacklist nově používá mac-address-denylist.
Před 25 lety, 31. května 1999, započal vývoj grafického editoru Krita (Wikipedie). Tenkrát ještě pod názvem KImageShop a později pod názvem Krayon.
Farid Abdelnour se v příspěvku na blogu rozepsal o novinkám v nejnovější verzi 24.05.0 editoru videa Kdenlive (Wikipedie). Ke stažení brzy také na Flathubu.
David Revoy, autor mj. komiksu Pepper&Carrot, se rozepsal o své aktuální grafické pracovní stanici: Debian 12 Bookworm, okenní systém X11, KDE Plasma 5.27, …
Wayland (Wikipedie) byl vydán ve verzi 1.23.0. Z novinek lze vypíchnout podporu OpenBSD.
Craig Loewen na blogu Microsoftu představil novinky ve Windows Subsystému pro Linux (WSL). Vypíchnout lze GUI aplikaci pro nastavování WSL nebo správu WSL z Dev Home.
V sobotu 1. června lze navštívit Maker Faire Ostrava, festival plný workshopů, interaktivních činností a především nadšených a zvídavých lidí.
Webový server Caddy (Wikipedie) s celou řadou zajímavých vlastností byl vydán ve verzi 2.8 (𝕏). Přehled novinek na GitHubu.
Byla vydána verze 3.0 (@, 𝕏) svobodného softwaru HAProxy (The Reliable, High Performance TCP/HTTP Load Balancer; Wikipedie) řešícího vysokou dostupnost, vyvažování zátěže a reverzní proxy. Detailní přehled novinek v příspěvku na blogu společnosti HAProxy Technologies.
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: