Google Chrome 132 byl prohlášen za stabilní. Nejnovější stabilní verze 132.0.6834.83 přináší řadu novinek z hlediska uživatelů i vývojářů. Podrobný přehled v poznámkách k vydání. Opraveno bylo 16 bezpečnostních chyb. Vylepšeny byly také nástroje pro vývojáře (YouTube).
Byla vydána verze 11.0.0 knihovny libvirt (Wikipedie) zastřešující různé virtualizační technologie a vytvářející jednotné rozhraní pro správu virtuálních strojů. Současně byl ve verzi 11.0.0 vydán související modul pro Python libvirt-python. Přehled novinek v poznámkách k vydání.
Byla vydána nová verze 3.4.0 nástroje pro inkrementální kopírování souborů rsync (Wikipedie). Přehled oprav a vylepšení v souboru NEWS. Řešeno je 6 zranitelností.
V srpnu loňského roku byla vyhlášena RP2350 Hacking Challenge aneb oficiální výzva Raspberry Pi na prolomení bezpečnosti mikrokontroléru RP2350. Povedlo se. Včera byli představeni čtyři vítězové a jejich techniky.
Na čem aktuálně pracují vývojáři open source operačního systému Haiku (Wikipedie)? Byl publikován přehled vývoje za prosinec 2024. Vypíchnuto je začlenění webového prohlížeče Iceweasel, tj. alternativního sestavení Firefoxu.
Tetris a DOOM běžící v pdf. Proč a jak v příspěvku na blogu.
Společnost Oracle představila sadu nástrojů a skriptů pro sběr a analýzu dat o stavu linuxových systémů a jejich ladění pod společným názvem Oracle Linux Enhanced Diagnostics (OLED). K dispozici pod licencí GPLv2.
OpenZFS (Wikipedie), tj. implementace souborového systému ZFS pro Linux a FreeBSD, byl vydán ve verzi 2.3.0. Přináší RAIDZ Expansion, Fast Dedup, Direct IO, JSON a Long names.
Společnost PINE64 stojící za telefony PinePhone nebo notebooky Pinebook publikovala na svém blogu lednový souhrn novinek.
Baví vás bastlení, fyzika, IT a nebo prostě cokoliv technického? Proseděli jste celé Vánoce v záři obrazovky počítače a nebo jste o tom alespoň snili? Chcete se pochlubit technickými vánočními dárky? Pak doražte na Virtuální Bastlírnu - online pokec (nejen) techniků a bastlířů!
… více »
10.5.2007 16:30
Ilfirin | skóre: 32
| blog: ilfblog
| Liberec
(15.05 budu mít veřejnou IP a utíkám k SIPu)
SIP nepotřebuje veřejnou IP. Právě proto vznikl.
10.5.2007 22:15
Ilfirin | skóre: 32
| blog: ilfblog
| Liberec
tak to jsem ale ...
10.5.2007 22:30
Ilfirin | skóre: 32
| blog: ilfblog
| Liberec
Já jsem používal 2 roky SIP přes NAT a bez STUN. STUN je v běžných případech k ničemu. Poslouží jen u velmi složitých sítí, kde SIP nefunguje správně. To ovšem neplatí pro běžný NAT, jaký mají domácí routery nebo kabeloví provideři. S těmi si SIP poradí.
SIP přes NAT samozřejmě funguje a víc než dva roky ho tak používám. Jadrné výrazy si můžeš s klidem nechat od cesty.
STUN jsem nikdy nepotřeboval. I za dvěma routery funguje samotný SIP bez problémů. STUN je pouze hezký nápad, nic víc. Nevím o tom, že by ho někdo skutečně podporoval a používal.
Při použití operátora mohou být volaný i volající klidně i za několika routery. (Operátor nemusí nutně být veřejný a komerční - může to být jejich známý s veřejnou IP nebo třeba zaměstnavatel, který má rychlou síť.) Bez operátora je situace mírně složitější, nicméně volající nemusí mít veřejnou adresu nikdy.
Nepoužíval jsem ani outbound proxy, ani STUN. Nejsem trouba, abych nevěděl, co používám. Samozřejmě používám operátora, ale to není totéž jako používat outbound proxy. Jeho použití mám ve všech klientech zakázáno, protože nepřináší nic jiného než zbytečné zpomalení s občasnými výpadky.
Přes NAT projde bez potíží téměř libovolný protokol, pokud má alespoň jeden z komunikujících veřejnou IP adresu. Mají-li oba neveřejnou, pak stačí existence jednoho centrálního prvku s veřejnou adresou - operátora. Ten jejich propojení zajistí bez ohledu na počet routerů. (Fungují-li routery správně.)
Operátor může být veřejný a komerční. Nebo může jít o čistě soukromou záležitost, jako například počítač s veřejnou IP adresou někde v zaměstnání nebo u známého. Mám tu zkušenost, že přes SIP v 90% případů komunikuji s běžnými telefony. Proto používám veřejného operátora a veřejné nebo soukromé IP adresy mě nemusí vůbec zajímat.
Raději toho nechte dokud je čas :D
A tím jako chcete říct co? Že můžete šířit fámy a nikdo to nesmí uvést na pravou míru? Dobře víte, že žádný peer-to-peer protokol neprochází NATem sám od sebe. Každý (ICQ, Skype, Jabber, BitTorrent) k tomu využívá nějaký server, jehož úkolem je asistence při navazování spojení. Chete pak tvrdit, že zmíněné protokoly nefungují za NATem? Mně fungují všechny a SIP není výjimkou.
Nerad bych se vas dotknul, ale nerikate tu nebo neznate celou pravdu.
Neříkám, že znám celou pravdu. Myslím si ale, že má osobní zkušenost je pravdivá víc než dost.
Mezi tyto mechanismy patri STUN, SIP/RTP proxy, keep-a-alive pakety a dostatecne predvidatelny NAT.STUN nepoužívám. SIP ani RTP proxy nepoužívám. (Obojí je explicitně zakázané u všech mých klientů, hardwarových i softwarových.) Null-pakety samozřejmě používám, protože ne každý NAT si pamatuje mapování portů až do konce SIP register intervalu. To ale není až tak složitý mechanismus.
Předvídatelný NAT - na ten mám štěstí. Doma mám vlastní routery a všichni mí poskytovatelé zatím měli velmi tolerantní NAT (například Karneval). Jiné to může být někde ve firmě nebo ve škole. Protože SIPem telefonuju doma, může mi to být jedno. Prostě mi to funguje, jak jsem popisoval.
Nezpochybnuji, ze za jistych stastnych okolnosti staci sdelit klientovi verejnou IP (nebo si ji zjisti STUNEM ci podobnou sluzbou) a ono vse funguje, ale toto neni absolutni reseni.
IP adresami se vůbec nezabývám. Mám veřejného operátora a používám pouze telefonní čísla. Pár lidí z rodiny má stejného operátora, takže internet-only hovory s nimi se dají (zcela zdarma) uskutečnit taktéž pomocí čísel. I když jsem na veřejné IP adrese, bývám i přesto (dobrovolně) za NATem a porty pro SIP a RTP nemám do vnitřní sítě vůbec přesměrované. Přes IP adresu se mi pak nikdo zvenku nedovolá a tak mi to vyhovuje. Má-li ale mé číslo, je to bez problémů.
Hlavne kdyz uvazim, ze SIP klient se ma byt schopen spojit s libovolnym jinym SIP serverem (napr. jinym telefonem), coz je presne ta svoboda, ktere se telefonni operatori boji jako cert krize.
Tu svobodu mi operátor nebere. Má-li volaný veřejnou IP adresu, můžu mu z každého rozumného (i hardwarového) klienta volat přímo na IP adresu, chci-li. Nemá-li ji, pak prostě může používat operátora, stejně jako by ho použil u ICQ, Jabberu... Mnozí operátoři poskytují registraci nezávazně a zdarma. Jsou-li oba účastníci za NATem, bez prostředníka se neobejdou a svoboda musí jít stranou.
Nechce se mi tu delat prednasku na tema SIP, ale verte, ze o tom neco vim (rok jsem se zivil testovanim, instalaci a konfiguraci sipovych ustreden a klientu).
Nepochybuji nijak o vašich vědomostech. Chci říct jediné: Tvrzení, že SIP nefunguje za NATem, je poněkud neopatrné. Drtivá většina domácností (zdůrazňuji domácností) s neveřejnou IP adresou může SIP (za pomoci operátora) používat, aniž by museli o IP adresách vůbec něco vědět. Zvěsti o tom, že to „prostě nejde“, dělají víc škody než užitku. To říkám z vlastní zkušenosti - sám jsem jim kdysi věřil, než jsem SIP opravdu vyzkoušel a přesvědčil se o opaku.
S prominutim hovorite jako misionar (nic jsem nemusel, vse funguje samo, je, to je uzasny).
Ale kdepak. Neříkám, že něco funguje samo a že je to ideální. Má to spoustu chyb, o kterých jsem tu nepsal - v drtivé většině případů na straně operátorů. Nemám zájem něco propagovat. Jen říkám: Není obecně pravda, že SIP nefunguje za NATem. Pro valnou většinu domácích uživatelů funguovat bude. To je celé.
Jen poznamka o svobode: PSTN operatora jste vymenil za SIP operatora. Takhle ja si svobodu nepredstavuji.
A jak si ji tedy představujete? Až jednou nebudou v naší společnosti žít dvě třetiny počítačově negramotných lidí a až bude mít každý svou vlastní IPv6 adresu pro každé své zařízení, bude situace jiná. Ale co mi zbývá dnes? Chci volat za rozumné ceny na pevné linky do zahraničí (pod 1 Kč za minutu) a chci volat i do všech „neinternetových“ sítí v ČR. Chci, aby bylo možné volat mně. Neznám lepší řešení než SIP a operátora. Vy ano? Rád se poučím, existuje-li nějaké.
Děkuji že již netvrdíte, že SIP nepotřebuje veřejnou IP a že kvůli tomu že ji nepotřebuje vlastně vznikl.
Máte pravdu, že jsem to napsal příliš stručně a nepřesně. Jelikož definice operátora je součástí protokolu SIP, dá se (zjdenodušeně) říct, že SIP nevyžaduje na straně účastníka veřejnou IP adresu. Celá tahle diskuze je spíš o pohledu na věc. Každý protokol vyžaduje alespoň jednu veřejnou IP adresu. Otázka je, kdo ji musí mít.
Dříve velmi populární protokol H.323 měl s routingem často vážné problémy. Z toho důvodu začali operátoři cca před třemi lety nabízet SIP, který těmito neduhy netrpí. Mnoho operátorů uvádí jako hlavní důvod nasazení protokolu SIP jeho lepší použitelnost z neveřejných podsítí. Měl jsem tedy napsat, že SIP byl kvůli bezproblémové podpoře uživatelů na NATem operátory zaveden, ne že kvůli ní vznikl.
Když si uvědomíte funkci operátora, tak vám i dojde, že pouze supluje úlohu té chybějící veřejné IP, bez které (veřejná IP nebo náhražka v podobě operátora) se telefonování prostřednictvím SIP opravdu neobejde.
Ale tu veřejnou IP adresu má server operátora, který mě vůbec nezajímá. Já jako účastník ji mít nemusím a dokonce ji dobrovolně nemám - jsem za routerem a vyhovuje mi to. Chce-li běžný zákazník, který hledá náhradu za PSTN, používat SIP, pak prostě nepotřebuje veřejnou IP adresu.
Při telefonování prostřednictvím operátora máte "veřejnou IP". Je to ten váš operátor a dokud jste s ním ve spojení, máte možnost telefonovat, skoro jako kdybyste měl tu veřejnou IP.
Samozřejmě. Koneckonců, proč bych telefonoval bez operátora? 90% hovorů mám na pevné linky a mobily, takže jako levná náhrada PSTN je to skvělé. Nic víc od toho nechci. Když si chci zavolat bez operátora, přesměruju si na routeru porty 5060 a 10000 na svůj IP telefon. Ale něco takového jsem už zruba rok neudělal. Prostě není důvod.
Nechtějte zažít, až v serverovně vašeho operátora dojde k nečekané události :) Pak uvidíte SIP ve své nahotě. Tedy v jeho.
Takové události se jistě stávají, stejně jako se mohou stát u mobilního nebo PSTN operátora. Kdybych měl na takové věci myslet, asi bych netelefonoval vůbec.
To, že ICQ či Skype funguje také s centrálním "operátorem" je sice hezké přirovnání, ale ono to ICQ také třeba vždycky nefunguje :) právě proto, že potřebuje toho centrálního operátora...
No jasně, ale jak jinak byste to řešil, dokud není IPv6 povinný?
Jestli to chápete jako výhodu, tak řada lidí to chápe jako "lepší než nic", protože s NATem se moc muziky vážně hrát nedá
No nedá, ale SIP s operátorem přes něj funguje. Jiným řešením tohoto problému může být třeba architektura typu Skype, kde všichni přihlášení účastníci s veřejnou IP adresou slouží jako prostředníci pro navazování spojení. Spolehlivost je pak solidní, ale otázkou zůstává, jak je to s bezpečností.
Tvrdit že SIP vznikl kvůli tomu, že nepotřebuje veřejnou IP je nesmysl, děkuji že jste toho tedy nechal
To bylo chybné tvrzení. Měl jsem to formulovat jinak a přesněji, jak už jsem psal výše.
Takže pokud si místo openSUSE 32 bit nainstaluju openSUSE 64 bit, co mi to kromě možného zvýšení výkonu* a dobrého pocitu přinese?
*) existuje nějaké porovnání, jaký dopad to má na běžné desktopové aplikace? Web browser, kancelářský balík, přehrávač videa, nějaké to IDE. Jestli je ten nárůst jen v řádu 2-5%, tak to asi za tu námahu stejně nestojí…
Zatím ještě nemám, ale zajímalo mně, zda má smysl 64 bit instalovat. Pokud je to opravdu 10-25%, tak to smysl každopádně má.Ahoj Honzo! clanek o vyhodnosti pouziti 64bit OS vysel na root.cz a urcite se vyplati. Rozdil (desitky procent) se projevy u vypocetne narocnejsich operaci. U kancelarskeho PC kde je procesor vytizen priblizne na 0,01% je realny prinos diskutabilni - ale diskutabilni je i to zda idealni kancelarske pc neni 386stka s vi...
Zase se mi zdá divné už jen z principu používat 32 bit OS když mám 64 bit procesor. Ale obávám se že jiný důvod než "dobrý pocit" asi mít se svou skladbou nejvíce používaných programů (Opera, OpenOffice.org, Quanta+, Amarok, Konqueror a nějaký ten xterm) pro použití 64 bit nebudu.
A stojí to zato, nárust výkonu mi někdy připadá více jak 80% sice je to blbost, pač to z hlediska fyzikálních zákonů nejde
Mohl byste naznačit, ze kterého fyzikálního zákona (a jak) vyplývá, že to není možné? Já bych totiž řekl, že u některých úloh bude naprosto přirozené, bude-li výkon 64-bitové aplikace více než dvojnásobný oproti 32-bitové verzi.
nesmíš mít distro, jako fedora, která má 64 bit i 32 bit knihovny v jednomNejsou "v jednom". Jsou v oddělených balíččích, které můžou být nainstalované současně. Není důvod, proč by nepoužívané 32-bitové knihovny ležící na disku měly systém zpomalovat.
12.5.2007 14:23
Ilfirin | skóre: 32
| blog: ilfblog
| Liberec
Ak mám pravdu povedať, skôr nad tým Debianom špekulujem preto, lebo drvivá väčšina softu čo som pre Slackware kompiloval ručne, je u Debianu v repozitároch... A pre Slackware 64 je toho na linuxpackages.net podstatne menej ako pre 32bit.
12.5.2007 18:09
Ilfirin | skóre: 32
| blog: ilfblog
| Liberec
aha. No, s tím repozitářem je to pravda. Většina (až na neopen aplikace) balíčků je v repozitářích duplicitně (pro 32bit a 64bit). Problém že linuxpackages.net je 64bitových balíčků míň bych nepovažoval za podstatný. Protože vše máte v repozitářích.
existuje nějaké porovnání, jaký dopad to má na běžné desktopové aplikace? Web browser, kancelářský balík, přehrávač videa, nějaké to IDE.
Především je potřeba si uvědomit, že na rychlost odezvy běžných desktopových aplikací má dnes procesor jako takový relativně malý vliv a že podstatně významnější efekt má dostatek paměti nebo rychlost disku. U procesorově náročných aplikací (překladač, zpracování obrazu, videa, kryptografické algoritmy) je ale situace úplně jiná.
13.5.2007 00:57
Dalibor Smolík | skóre: 54
| blog: Postrehy_ze_zivota
| 50°5'31.93"N,14°19'35.51"E
13.5.2007 12:54
Ilfirin | skóre: 32
| blog: ilfblog
| Liberec
14.5.2007 00:27
Dalibor Smolík | skóre: 54
| blog: Postrehy_ze_zivota
| 50°5'31.93"N,14°19'35.51"E
Jak je dělán 64-bit Linux? Bude pro 64-bit verzi v repozitářích JENOM software pro 64-bit, nebo to bude jakou u Win, že 90% software je 32-bit a ta 64-bit verze sebou tahá knihovny pro 32-bit?Jak bylo řečeno výše, většina software opravdu JE 64-bitových, tj. načítá 64bit knihovny a moc se mu nechce kamarádit s 32bit pluginy (je také výše řešeno) a kodeky pro mplayer. V repozitářích (alespoň u SUSE) je ale i 32-bit software, který lze po doinstalování knihoven pro podporu 32bit aplikací též používat. Dlouho jsem takto používal i386 Firefox na x86_64 SUSE. To vede asi k jediné nevýhodě x86_64 linuxu, jakou jsem zatím nalezl - ve výsledku systém zabere o něco vícemísta na disku než jeho 32bit verze, může i zabírat více místa v paměti při paralelním běhu 32bit a 64bit programů.
Tiskni
Sdílej:
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
10.5.2007 23:43
12.5.2007 01:22
14.5.2007 08:40
12.5.2007 11:40
14.5.2007 12:11