Vyšlo Pharo 12.0, programovací jazyk a vývojové prostředí s řadou pokročilých vlastností. Krom tradiční nadílky oprav přináší nový systém správy ladících bodů, nový způsob definice tříd, prostor pro objekty, které nemusí procházet GC a mnoho dalšího.
Microsoft zveřejnil na GitHubu zdrojové kódy MS-DOSu 4.0 pod licencí MIT. Ve stejném repozitáři se nacházejí i před lety zveřejněné zdrojové k kódy MS-DOSu 1.25 a 2.0.
Canonical vydal (email, blog, YouTube) Ubuntu 24.04 LTS Noble Numbat. Přehled novinek v poznámkách k vydání a také příspěvcích na blogu: novinky v desktopu a novinky v bezpečnosti. Vydány byly také oficiální deriváty Edubuntu, Kubuntu, Lubuntu, Ubuntu Budgie, Ubuntu Cinnamon, Ubuntu Kylin, Ubuntu MATE, Ubuntu Studio, Ubuntu Unity a Xubuntu. Jedná se o 10. LTS verzi.
Na YouTube je k dispozici videozáznam z včerejšího Czech Open Source Policy Forum 2024.
Fossil (Wikipedie) byl vydán ve verzi 2.24. Jedná se o distribuovaný systém správy verzí propojený se správou chyb, wiki stránek a blogů s integrovaným webovým rozhraním. Vše běží z jednoho jediného spustitelného souboru a uloženo je v SQLite databázi.
Byla vydána nová stabilní verze 6.7 webového prohlížeče Vivaldi (Wikipedie). Postavena je na Chromiu 124. Přehled novinek i s náhledy v příspěvku na blogu. Vypíchnout lze Spořič paměti (Memory Saver) automaticky hibernující karty, které nebyly nějakou dobu používány nebo vylepšené Odběry (Feed Reader).
OpenJS Foundation, oficiální projekt konsorcia Linux Foundation, oznámila vydání verze 22 otevřeného multiplatformního prostředí pro vývoj a běh síťových aplikací napsaných v JavaScriptu Node.js (Wikipedie). V říjnu se verze 22 stane novou aktivní LTS verzí. Podpora je plánována do dubna 2027.
Byla vydána verze 8.2 open source virtualizační platformy Proxmox VE (Proxmox Virtual Environment, Wikipedie) založené na Debianu. Přehled novinek v poznámkách k vydání a v informačním videu. Zdůrazněn je průvodce migrací hostů z VMware ESXi do Proxmoxu.
R (Wikipedie), programovací jazyk a prostředí určené pro statistickou analýzu dat a jejich grafické zobrazení, bylo vydáno ve verzi 4.4.0. Její kódové jméno je Puppy Cup.
IBM kupuje společnost HashiCorp (Terraform, Packer, Vault, Boundary, Consul, Nomad, Waypoint, Vagrant, …) za 6,4 miliardy dolarů, tj. 35 dolarů za akcii.
Protokol IPv6, stejně jako IPv4, potřebuje posílat pakety s chybovými zprávami a režijními informacemi. Používá se k tomu protokol ICMPv6 (RFC 4443). Objevování sousedů a routerů (RFC 4861) a na něm založená automatická konfigurace adres (RFC 4862) jsou realizovány právě pomocí ICMPv6 paketů.
Ve světě IPv4 jsou linkové adresy (adresy z rozsahu 169.254.0.0/16, RFC 3927) spíše na okraji zájmu. Je to z toho důvodu, že IPv4LL adresy nejsou dostupné vždy, ale používají se pouze když stroj nemá přidělenou řádnou IPv4 adresu. Slouží tedy jen jako dočasná náhražka.
Naproti tomu linkové IPv6 adresy jsou nedílnou součástí protokolu IPv6 a
jsou specifikovány přímo v RFC
2460. Stroje si je přidělují samy při aktivaci síťového rozhraní, a
ponechávají si je až do jeho deaktivace. Vznikají složením prefixu
fe80::/64 a 64bitového identifikátoru síťového rozhraní,
stroj si tedy linkovou adresu přiděluje zcela samostatně. O výběru
identifikátoru síťového rozhraní a řešení duplicit bude řeč
později.
Linkové adresy se dají používat i pro běžnou komunikaci po místní síti, jen je potřeba, aby aplikace vždy kromě IP adresy znala i síťové rozhraní (všechny používají stejný prefix). V ideálním případě si aplikace obě informace zjistí bez ručního zadávání.
K čemu tedy takové adresy slouží? Jednak je můžete použít k přímé komunikaci mezi dvěma zařízeními, které propojíte například ethernetovým kabelem. V mnohých případech bude jedno z těch zařízení běžný počítač a druhé bude jednoúčelové zařízení (například tiskárna). Nebo ad-hoc wifi sítě jsou na linkové adresy jako dělané. Síťaři využijí link-local adresy ke konfiguraci síťového prvku, který není zkonfigurován pro lokální síť a byl by jinak na IP vrstvě nedostupný. A jistě najdete další. Na linkových adresách funguje mnoho infrastrukturních protokolů jako NDP, DHCP, ale třeba i OSPF.
Ke komunikaci po LL adresách je potřeba, aby komunikující počítače znaly MAC adresy odpovídajících síťových rozhraní. K tomu se používají pakety neighbor solicitation (NS) a neighbor advertisement (NA). Jedná se o variaci na klasický model dotazu a odpovědi, s možností rozesílat oznámení (NA) při změnách. Oba typy zpráv jdou posílat pomocí unicastu konkrétnímu stoji i rozesílat pomocí linkového multicastu všem (obdoba IPv4 broadcastu).
Objevování sousedů pomocí protokolu NDP je víceméně přímou náhradou protokolu ARP z IPv4. A stejně jako ARP, se NS+NA hodí pouze k překladu L3 (tedy IPv6) adresy na L2 adresu. NDP v jeho základní podobě nenabízí žádné zabezpečení proti lokálním útokům, stejně jako IPv4 ARP. O možnosti jak toto změnit se dočtete v sekci o CGA a SEND.
Chcete-li objevování sousedů obohatit o jména počítačů a dostupné služby, je potřeba použít další protokol. V prostředí Linuxu (ale také Applu a mnoha dalších zařízení) se nejčastěji používá Multicast DNS (mDNS), implementovaný například sadou nástrojů Avahi.
Obdobným způsobem se získávají informace o routerech. K tomu se používá dvojice paketů router solicitation (RS) a router advertisement (RA). U routerů se počítá s tím, že jednou za čas informace o sobě do sítě rozešlou samy pomocí nevyžádaného oznámení. Oznámení se zpravidla posílá pomocí linkového multicastu, ale můžou se posílat i unicastem, například kvůli testování.
Objevování routerů je také základem pro všechny metody automatické konfigurace adres. Na to je potřeba myslet kdykoli chcete nasazovat IPv6 na jakékoli síti. V závislosti na tom, co obsahují oznámení routerů se koncový stroj teprve dozví, jakým způsobem bude získávat svoji globální IP adresu. Součástí oznámení routeru jsou také informace o lokálních prefixech, routách do jiných sítí a DNS (RFC 6106). Není žádný problém mít na síti více než jeden router (například kvůli redundanci).
Běžné objevování routerů trpí problémem falešných routerů. Do jisté míry tomu pomáhají programy jako ramond nebo rafixd, ale nemůžou zachytit vše. Finálním řešením je buď RA Guard na síťových prvcích (RFC 6105), SEND na routerech a koncových strojích (RFC 3971) nebo jejich kombinace.
Bezstavová autokonfigurace (SLAAC, RFC 4862) je specifická metoda pro IPv6. V IPv4 sice něco podobného existuje, ale použitelnost je opět velmi omezená. Koncové stroje při připojení do IPv6 sítě kontaktují router pomocí RS. Router odpoví oznámením síťových prefixů s příznakem, že si koncový stroj smí sám nastavit IP adresu doplněním identifikátoru rozhraní. K automatické konfiguraci je potřeba jeden nebo více routerů a jeden nebo více síťových prefixů s příznakem samostatné konfigurace (AdvAutonomousFlag).
Pokud některý router pošle informace o síťovém prefixu s tímto příznakem, koncový stroj si sám zvolí 64bitový identifikátor pro dané rozhraní (interface identifier). Síťový prefix dohromady s identifikátorem dávají celou adresu. Je tedy potřeba, aby i síťový prefix byl 64bitový. Příznak AdvOnLink určuje, zda koncový stroj může stroje ze stejné podsítě kontaktovat přímo pomocí objevování sousedů.
V SLAAC se počítá s tím, že se každému stroji, který má komunikovat s vnějším světem, oznámí alespoň jeden globální prefix. Oznamovaný prefix je opatřen i dobou platnosti a dobou upřednostňování před jinými prefixy, která přechází na automaticky konfigurované adresy. Zkrácením těchto hodnot lze zajistit, že koncové stroje budou neustále sledovat, jestli router i nadále oznamuje jejich prefix a v případě změny prefixu se automaticky přizpůsobí a začnou používat adresy z nového prefixu. Při plánovaných odstávkách je můžete dokonce nechat přejít na nový prefix postupně, bez narušení služeb.
Stejným způsobem, jako se konfigurují globální adresy, se konfigurují i unikátní lokální adresy. Hodí se především pro prostředí bez připojení k Internetu, prostředí, kde je připojení k internetovým službám realizováno pouze přes aplikační proxy nebo prostředí, kde se můžou střídat globální prefixy. Na testování bez globální konektivity rovněž doporučuju používat ULA. V globálním DNS by se ULA neměly vyskytovat vůbec.
ULA se na lokální úrovni ve všech ohledech chovají jako globální adresy, proto je ve zbytku článku nebudu ani uvádět jako samostatný případ.
Tvorbě identifikátorů rozhraní jsem se rozhodl vyčlenit samostatnou sekci, protože se týká linkových adres, globálních adres i unikátních lokálních adres. Připomínám, že ve všech případech bezstavové konfigurace si identifikátor rozhraní určují koncové stroje samy.
Nejjednodušší a administrativně nejpříjemnější možností je nechat
počítače, ať vždy používají stejný identifikátor uložený v hardware.
Obvykle se používá 64bitová varianta identifikátoru EUI, který jde
odvodit například z ethernetové (MAC) adresy ve formátu EUI-48 (doprostřed
se doplní dvojice bajtů ff:fe). Identifikátor rozhraní se pak
vyrobí z EUI-64 negováním patnáctého bitu (aby se ručně konfigurované
adresy nepletly s těmi založenými na EUI). To vše je popsáno v RFC
2464.
Adresy založené na EUI se používají jak pro linkové, tak i pro globální adresy. Její největší výhodou je, že se automaticky chovají jako statické adresy (alespoň při zachování prefixu a MAC adresy). Tím v mnohých případech odpadá potřeba ručně konfigurovat adresy či mapování mezi MAC a IP, které je zde automatické. Vyhnete se tím i použití dynamického DNS a podobným věcem.
Duplicitní adresy se řeší metodou „moudřejší ustoupí“, což s sebou přináší svá rizika. Linkový segment lze zabezpečit filtrováním na switchi, ale jen částečně. Lze určit, na kterém portu smí sídlit router a vůči linkovým i globálním adresám vést politiku typu „kdo dřív přijde, ten dřív bere“. V mnoha sítích se ochrana proti útokům na tabulku sousedů neřeší ani v případě IPv4. Tyto sítě budou typickým místem pro nasazení takto jednoduchého způsobu konfigurace adres.
Použití statických globálních adres pro odchozí spojení vás samozřejmě připraví o proměnnou složku, která má určitý význam z hlediska bezpečnosti a soukromí. To se projeví hlavně při pohybu mezi sítěmi. První polovina adresy obvykle určuje vaši polohu a druhá identitu. Při pravidelné komunikaci může kterákoli protistrana z vaší IP adresy vysledovat kudy se pohybujete. Nicméně podobnou „službu“ poskytují třeba cookies protokolu HTTP.
Problémy se soukromím a sběrem statistických dat z MAC adres řeší rozšíření nazývané privacy extensions (RFC 4941), které přidávají ke stávajícím adresám dočasnou náhodnou globální adresu.
Protože náhodné adresy řeší pouze tento problém se soukromím, nemá smysl používat je pro linkové adresy. To by přineslo jen zbytečné komplikace. Snad jedině že při případné duplicitě se může zvolit nová náhodná adresa. Touto podle mého nešťastnou a zbytečnou cestou se jak se zdá vydaly nové verze Microsoft Windows. Dočasná adresa se používá pro všechna odchozí spojení a čas od času se změní (běžících spojení se změna netýká). Náhodná adresa už sama neumožňuje sledování pohybu, získání informací z MAC adresy. Dočasnost adresy výrazně ztěžuje odhady počtu zařízení v síti.
Privacy extensions tak dávají daleko širší a hlavně spolehlivější možnosti skrývání vnitřních adres než NAT. Zbývá jen to, že protistrany, které znají dočasnou adresu, můžou zkoušet známé porty či skenovat porty. To se dá řešit velmi jednoduchým stavovým firewallem (po cestě nebo na stroji samotném). Nebezpečí samozřejmě zůstává v cestách, které koncový stroj aktivně otevírá.
Při použití náhodných adres se ještě více projevuje zahození klasického předpokladu, že koncový stroj používá pouze jednu IP adresu. Není neobvyklé, když má notebook jednu link-local adresu, jednu automaticky konfigurovanou statickou adresu, náhodnou adresu pro dříve otevřená spojení a další náhodnou adresu pro nová spojení.
Toto schéma už z principu nemůže poskytnout statické globální adresy. Pokud byste chtěli mít v rámci každé sítě statickou adresu a zároveň nebýt sledovatelní pomocí IPv6 adres, museli byste jako identifikátor interface používat hash sestavený ze síťového prefixu a nějakých neměnných údajů z vašeho počítače. Technicky velmi jednoduché, ale nikde jsem podobnou funkci neviděl.
Na linuxových distribucích se dočasné adresy zapínají pomocí
sysctl (hledejte
use_tempaddr).
Protokol pro objevování sousedů a routerů je podobně zranitelný jako protokol DHCP používaný v IPv4. Tím, že je celá konfigurace jednodušší je i o něco jednodušší tyto zranitelnosti využívat. Kryptografická varianta tohoto protokolu se snaží tuto situaci zlepšit na úroveň, která s IPv4 nepřipadala v úvahu.
Základním pilířem jsou kryptografické adresy (RFC 3972) chráněné soukromým klíčem a ověřitelné veřejným klíčem. Protokol SEND (RFC 3971) zavádí podepisování zpráv protokolu NDP, čímž brání jejich falšování a zabraňuje tak některým typům útoků. Koncová zařízení si můžou vzájemně kontrolovat NDP zprávy a řídit se jen těmi podepsanými. K ověření, jestli je stroj oprávněným routerem, se používají certifikáty a řetězec důvěry. Do koncových strojů stačí instalovat certifikát kotvy důvěry, router pak musí koncovému zařízení ke kontrole předložit celý řetězec. Nezabezpečené NDP a SEND spolu mohou koexistovat. Stroje pak dávají vždy přednost zabezpečené informaci před nezabezpečenou.
Tento protokol je relativní novinka a na jeho implementaci zatím běžně nenarazíte. Existují ovšem experimentální projekty, které fungují na Linuxu a FreeBSD. I bez použití certifikátů lze na SENDu postavit velmi zajímavé řešení, pokud ho zkombinujete s filtrováním na switchi. Uvidíme, co se z toho vyvine.
Je vcelku pochopitelné, že bezstavová automatická konfigurace nevyhovuje všem a za všech okolností. Proto ohlášení routeru může bezstavovou konfiguraci nepovolit a místo ní povolit koncovým strojům konfiguraci stavovou čili řízenou (AdvManagedFlag). Narazíte ale na dva zásadní problémy, které vás donutí se blíže zabývat obsahem RA. Jednak nemůžete konfigurovat linkové adresy pomocí externího serveru, což znamená, že se nevyhnete problémům s lokálním zabezpečením. A druhak o oznámení výchozí brány se vždy starají routery samy.
DHCPv6 (RFC 3315) tedy
slouží k řízenému přidělování adres koncovým strojům (oproti situaci,
kdy si adresy přidělují samy). Vychází z protokolu DHCP pro IPv4 (RFC 2131). Uzly se můžou
účastnit stavové konfigurace ve třech různých rolích. Klient je koncové
zařízení, které komunikuje pomocí linkové adresy a pokouší se získat
konfigurační parametry od dhcp agenta nebo serveru na linkové multicastové
adrese ff02::1:2. Agent je zařízení, které komunikuje pomocí
linkové adresy s klientem a zprostředkovává mu komunikaci se serverem.
Server dodává konfigurační parametry na základě žádosti klienta (ať už
přes agenta, nebo přímo po linkové
vrstvě).
V celku bezúdržbové konfigurace se dá dosáhnout tak, že se DHCP server nastaví, aby přiděloval adresy dynamicky z nějakého menšího rozsahu. Klienti dostanou propůjčenou adresu, kterou si musí po nějaké době obnovovit. Server má navíc možnost požádat klienta o rekonfiguraci kdykoli. Server může spolupracovat s DNS serverem a s jeho pomocí zveřejňovat údaje o aktuálně připojených strojích.
Na požádání klienta může server generovat dočasné náhodné adresy. Oproti samostatně generovaným náhodným adresám je tu možnost automaticky předávat IP do nějaké databáze (například pro firewall nebo interní DNS).
Protokol DHCPv6 zavádí jednoznačné identifikátory klientů a serverů
(DUID) a lokální identifikátory rozhraní IAID. Klientský identifikátor
DUID se dá spolu s IAID použít mimo jiné ke svázání se statickou IP
adresou. Tyto mapování se konfigurují na straně serveru. Za pomoci
přeposílacího agenta lze veškerou konfiguraci centralizovat napříč
linkovými segmenty. Výchozí adresou DHCP serveru v agentech je
ff05::1:3, tedy místní multicastová adresa, která má vést na
všechny servery, které se na síti starají o
DHCP.
Je třeba zdůraznit, že DHCPv6 vychází z toho, že DUID je jediným unikátním identifikátorem klienta a dvojice DUID+IAID tudíž jediným unikátním identifikátorem klientského rozhraní. To znamená, že DHCPv6 nepodporuje přidělování IP adres podle MAC adres ani podle názvů počítačů, což je jedna z těch podstatnějších změn oproti DHCPv4. To jednoduše znamená, že staré postupy přestávají fungovat.
Myšlenka DUID jako stabilního identifikátoru napříč restarty se zdá být velmi dobrá. Zatím ale pokulhávají některé implementace, zvláště pak ty, které generují DUID a ukládají ho do diskového souboru. Vzhledem k tomu, že naprostá většina klientů jsou desktopy či laptopy s integrovaným síťovým rozhraním, nic nebrání tomu, aby se jako DUID počítače používala MAC adresa této síťové karty. Stačí k tomu donutit implementátory.
Ale ani v ideálním případě, kdy DUID je stálý identifikátor, nelze přidělování IPv6 začlěnit do běžného workflow IPv4, kde spojujete IP adresu vždy s MAC adresou připojovaného rozhraní (třeba bezdrátového). Pak nezbývá, než překopat workflow, získat MAC adresu nějakým šikovným trikem, nebo přesvědčit IETF k doplnění standardu (a následně implementátory k doplnění implementací). Zajímavý popis situace najdete například na mailing listu dhcp-users.
Než se implementace (a možná i standardy) více usadí, můžou se vám stávat různé neočekávané průšvihy, jako je změna DUID po reinstalaci či dokonce během síťového bootování. Hodně špatná implementace DHCPv6 klienta může měnit DUID po restartu či dokonce za běhu. Obecně narazíte častěji na problémy s klienty než se servery (i kdyby jen proto, že server se lépe mění).
I koncový stroj konfigurovaný bezstavově nebo dokonce ručně může použít služby DHCP serveru. Posílá pak jednoduchý dotaz na informace (information request), na který server odpovídá a požadované informace pošle. Někdy se tomu říká bezstavové DHCP (aby v tom byl ještě větší guláš).
DHCPv6 řeší i problém, který přichází s návratem k veřejným adresám v době IP maškarády. Koncoví uživatelé jsou zvyklí, že na internetovou přípojku zapojí router a ono víceméně vše funguje. Rozsah na vnitřním rozhraní je nastavený stejně jako u mnoha dalších uživatelů a na routeru je překládaný na jednu vnější veřejnou adresu.
Na IPv6 bez IP maškarády je vždy potřeba nastavit vnitřní síti nějaký prefix, ať už je dále poskytován pomocí SLAAC nebo DHCP. Delegace prefixů (prefix delegation, RFC 3633) je doplněk DHCP, který se používá na vnějším rozhraní routeru. K běžné konfiguraci, jako je vnější IP adresa, DNS a podobné, přidává možnost konfigurace prefixů pro vnitřní rozhraní.
Umím si představit docela pěkný redundantní centralizovaný systém přidělování adres postavený na DHCPv6 PD, relay agentech, centrálních serverech a třeba i OSPF.
Ač na adresu SLAAC padá hodně kritiky jak kvůli bezpečnosti (to se to najednou řeší po mnoha letech s IPv4), tak kvůli slabší kontrole nad samostatně konfigurovanými adresami, rozhodně bych ho nezatracoval. Naopak, nový vývoj jako SEND a RA Guard ukazují, že se na SLAAC stavět dá. A linkových adres, které jsou na samostatné konfiguraci závislé, by byla velká škoda se vzdávat (a začínat v podstatě odznovu).
DHCPv6 má své nedostatky, když se na něj díváme z pohledu stávajících IPv4 sítí, ale stále se ještě může ukázat jako dlouhodobě lepší řešení. Nakonec nám stejně nezbyde nic jiného než vzít zavděk tím, co je, a snažit se o různé drobné opravy a vylepšení.
Příště se podíváme blíže na routování v sítích na protokolu IPv6. Nápady a náměty pište do diskuze.
Pavel Šimerda je lektor a konzultant z oblasti Internetu, počítačových sítí a Linuxu. Podívejte se na seznam jeho kurzů pro firmy a zvláště pak na IPv6-ready školení z oblasti sítí TCP/IP.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
22.6.2011 19:48
pavlix | skóre: 54
| blog: pavlix
Ale autor zdá se ano,Divím se ti, že máš potřebu pod článkem předvádět, že umíš lidem podsouvat věci, co neřekli ani nenapsali.
23.6.2011 15:17
pavlix | skóre: 54
| blog: pavlix
64-bitového indentifikátoru
24.6.2011 11:45
Nicky726 | skóre: 56
| blog: Nicky726
24.6.2011 23:58
pavlix | skóre: 54
| blog: pavlix
25.6.2011 15:09
Nicky726 | skóre: 56
| blog: Nicky726
25.6.2011 23:22
Luboš Doležel (Doli) | skóre: 98
| blog: Doliho blog
| Kladensko
26.6.2011 10:09
Nicky726 | skóre: 56
| blog: Nicky726
26.6.2011 21:01
pavlix | skóre: 54
| blog: pavlix
Pokud místo čísla použijeme zástupná písmena x nebo n, je ustálený způsob psaní se spojovníkem: x-stupňový, n-tá odmocnina apod.dovolím si tvrdit, že je zbytečně přísné. Ale divím se, že mi neporavuješ životné klienty a takovéhle věci, které jsou podle ÚJČ taky jinak než je píšu (pravda, ony jsou podle ÚJČ jinak než je píše většina lidí v oboru. Takže... na 64-bitový versus 64bitový nemám až tak vyhraněný názor. Budu dál psát to první, protože se mi to líbí víc, a korektura (Luboš), ať si s tím udělá, co potřebuje. Jinak, komentáře typu
Hlavně 64-bitového. To bolí! A je to tam víckrát…v mojí hlavě často vyvolávají anglické slovní spojení „grammar nazi“. Neřeknu, kdyby to bylo napsáno jinak. (Když už jsme u toho, jaké uvozovky použiješ, když v českém textu dáváš do uvozovek anglické sousloví, jaké když je to české sousloví v anglickém textu, a co na to ÚJČ?)
26.6.2011 21:27
Nicky726 | skóre: 56
| blog: Nicky726
26.6.2011 21:43
pavlix | skóre: 54
| blog: pavlix
S líběním je to těžký, holt ty časy, kdy se líbilo to správné, zdá se minuly. Spíš mi trochu vadí postoj: „vím, jak je to dobře, ale udělám to špatně.“Takový postoj naštěstí nezastávám.
Člověk by se, dle mě, měl snažit o dokonalost. Asi jí ze své podstaty nemůže dosáhnout, ale to neznamená, že by se neměl snažit. Ale chápu, že to každý takhle nevidí. I když si myslím, že to je škoda.Snažit se o dokonalost s poučkami z ÚJČ je zhola nemožné. Navíc dávám přednost jiným božstvům.
Řekl bych, že do českého textu patří české uvozovky. Ale jestli to je jinak, rád se poučím a své chyby napravím.Jestli jsem tě správně pochopil, tak bys uvozovky řídil podle vnějšího textu. S tím bych souhlasil.
26.6.2011 21:48
pavlix | skóre: 54
| blog: pavlix
Člověk by se, dle mě, měl snažit o dokonalost.Jinak, pokud bych se snažil o dokonalost, trval bych na svojí verzi, se kterou jsem spokojený a nedovolil bych publikovat článek jinak do té doby, než změním názor :). Takže... ono to trvání na dokonalosti má taky své nevýhody. Ale kdysi mi tu na Abc někdo zkorigoval text ve stylu děkuju→děkuji, nacož jsem vyloženě alergický. Tenkrát jsem slušně upozornil, že to už je přehnaný zásah do stylistiky a že si to propříště nepřeju (ale ani tak jsem netrval na navrácení do „dokonalé“ podoby).
22.6.2011 11:26
msk | skóre: 27
| blog: msk
Multicast se většinou používá automaticky (místo broadcastu nebo pro mDNS, Avahi ap.), ale třeba doma jsem jej používal i pro vysílání televize. Anycast je spíše pro Google a spol.
na adresu SLAAC padá hodně kritiky jak kvůli bezpečnosti (to se to najednou řeší po mnoha letech s IPv4),Ne, u IPv4 tohle nikomu nevadi, protoze takove pripady maji frekvenci (v me siti) jednou za nekolik let, a ma tedy cenu toho jednoho konkretniho uzivatele dohledat a jemne ho upozornit. Navic takovy problem vznikne vzdy chybou uzivatele nebo zlym umyslem, takze je korektni striktne po uzivateli pozadovat napravu. U IPv6 je to jine kafe - tam tenhle problem generuji kazde druhe Windows, ktere maji zapnuty connection sharing. A to u mnohych siti fakt nemuzete resit pripad po pripadu, protoze ti uzivatele neudelali nic spatneho - maji implicitni konfiguraci svych Windows (tedy: to je spatne samo o sobe, ale to je jiny problem
.
Cili nejde (az tak) o problem bezpecnosti, ale o to ze tento problem je u IPv6 v polovine Windowsovych notebooku, ktere vam prijdou do site.
-Yenya, http://www.fi.muni.cz/~kas/blog/
U IPv6 je to jine kafe - tam tenhle problem generuji kazde druhe Windows, ktere maji zapnuty connection sharing.To zní jako kdyby Windows neuměly connection sharing IPv4.
protoze ti uzivatele neudelali nic spatneho - maji implicitni konfiguraci svych WindowsS tím bohužel nemůžu souhlasit.
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz