Společnost Espressif (ESP8266, ESP32, …) získala většinový podíl ve společnosti M5Stack, čímž posiluje ekosystém AIoT.
Byla vydána nová stabilní verze 3.5 svobodného multiplatformního softwaru pro editování a nahrávání zvukových souborů Audacity (Wikipedie). Přehled novinek také na YouTube. Nově lze využívat cloud (audio.com). Ke stažení je oficiální AppImage. Zatím starší verze Audacity lze instalovat také z Flathubu a Snapcraftu.
50 let operačního systému CP/M, článek na webu Computer History Museum věnovaný operačnímu systému CP/M. Gary Kildall z Digital Research jej vytvořil v roce 1974.
Byl zveřejněn program a spuštěna registrace na letošní konferenci Prague PostgreSQL Developer Day, která se koná 4. a 5. června. Na programu jsou 4 workshopy a 8 přednášek na různá témata o PostgreSQL, od konfigurace a zálohování po využití pro AI a vector search. Stejně jako v předchozích letech se konference koná v prostorách FIT ČVUT v Praze.
Po 48 letech Zilog končí s výrobou 8bitového mikroprocesoru Zilog Z80 (Z84C00 Z80). Mikroprocesor byl uveden na trh v červenci 1976. Poslední objednávky jsou přijímány do 14. června [pdf].
Ještě letos vyjde Kingdom Come: Deliverance II (YouTube), pokračování počítačové hry Kingdom Come: Deliverance (Wikipedie, ProtonDB Gold).
Thunderbird 128, příští major verze naplánovaná na červenec, přijde s nativní podporou Exchange napsanou v Rustu.
Byly vyhlášeny výsledky letošní volby vedoucího projektu Debian (DPL, Wikipedie). Novým vedoucím je Andreas Tille.
Po osmi měsících vývoje byla vydána nová verze 0.12.0 programovacího jazyka Zig (GitHub, Wikipedie). Přispělo 268 vývojářů. Přehled novinek v poznámkách k vydání.
Poslední měsíc byl plný zajímavých akcí, o kterých Vám bastlíři z projektu MacGyver mohou povědět, protože se na ně sami vydali. Kde všude byli, ptáte se? Objevili se na Installfestu, Arduino Day, Hackaday Europe a tajném srazu bastlířů z Twitteru. A z každé akce pro vás mají zajímavé poznatky.
… více »
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.czping fe80:......%eth0, jinak vracel ping chybu - možná to bylo jenom nějakou unstable/testing verzí, určitě to ještě zkusím na debian lenny. Dále je taky super, jestli jsem to dobře pochopil, prakticky každý (i soukromá osoba) si může požádat o vlastní IPv6 range. Samozřejmě jednodušší to bude přes nějakého providera, který zajistí i routing. A uživatel MUSÍ dostat minimálně síť /64 (tedy na vaše adresy máte 64 bitů) - super ne?
V IPv4 je člověk rád, když dostane jednu veřejnou IPv4 adresu, tady má rovnou síť s minimálně 2^64 IPv6 adresami.
Závěr je takový, že IPv6 není o moc složitější, resp. složitost oproti IPv4 je vyvážena novými funkcemi. Některé funkce z IPv4 jsou přesunuty jinam v IPv6 (např. IPv6 nepoužívá ARP, ale neighbor discovery, který je součástí IPv6; fragmentaci neprovádí routery, ale zdrojové stanice sami), spousta věcí se řeší pomocí multicastu (router discovery, IP collision, DHCP - IPv6 nepoužívá broadcast, ale mutlicasty s různou vzdáleností dostupnosti, ...). Nejsem si jistý, jak moc a jak kvalitně je IPv6 Internet již zaplněn, ale určitě je nutné stále ještě IPv4 udržovat v chodu. Je ale důležité začít s IPv6 experimentovat. Takže hurá do toho.
Tiskni
Sdílej:
27.3.2011 00:18
Luk | skóre: 47
| blog: Kacířské myšlenky
| Kutná Hora
Samozřejmě nepředpokládám, že každý nalezený odkaz bude dostupný přes IPv6, to je problém provozovatelů webů.Tohle by byl dobrý námět na feature request pro Google. V rozšířeném vyhledávání by mohlo jít zaškrtnout, že se mají zobrazit jen weby dostupné přes IPv6.
když je taková proti-atomová nálada, tak bychom měli počítače v době nečinnosti vypínat a šetřit proudŠetření proudem není (jen) záležitostí protiatomové nálady, ale je věcí zcela obecnou. Je mi jasné, že nejmíň polovina lidí tady na abíčku nechává počítač (myšleno desktop) puštěný nonstop, proto hovořit o vypínání vždycky znamená, že se někdo ozve. Přitom je to pitomost - pokud ten počítač nemá nic na práci, nemusí být zapnutý. Pro dálkový přístup to lze nezřídka řešit tak, že se v případě potřeby vzdáleně zapne.
27.3.2011 00:53
Jendа | skóre: 78
| blog: Jenda
| JO70FB
Nj, akorát že jeho zapnutá trvá cenné minuty v případě, že je to doopravdy potřeba...
[ 216.450600] Back to C! (…) [ 219.023173] PM: resume of devices complete after 1617.577 msecs [ 219.105466] PM: Finishing wakeup. [ 219.105470] Restarting tasks ...
Není lepší se snažit vynalézt způsob, jak tu elektřinu vyrábět efektivně s co nejmenší zátěží na životní prostředí, místo toho abysme se snažili ušetřit pár wattů kde to jen jde a spalovali kvůli tomu dál uhlí?Preferoval bych kombinaci obého. To šetření mnohdy stojí za to už jenom kvůli peněžence, případně tiššímu větráku v případě počítače.
27.3.2011 01:16
Luk | skóre: 47
| blog: Kacířské myšlenky
| Kutná Hora
Preferoval bych kombinaci obého. To šetření mnohdy stojí za to už jenom kvůli peněžence, případně tiššímu větráku v případě počítače.Jistě. Já nechci nikoho nutit, aby se svým počítačem nakládal tak či onak (nejsem Vladimír Špidla nebo Günter Verheugen). Ale ono těch "pár wattů" dělá globálně docela dost. Pokud by byl v ĆR milion desktopů, tak jediný watt příkonu dělá celkem 1 MW. Pokud by byl příkon bez monitoru třeba 70 W, pak je to 70 MW, což je například o něco více než jeden blok uhelné elektrárny Poříčí (55 MW). Když se k tomu přidá i monitor, mohlo by to zhruba odpovídat celé této elektrárně (2 bloky). To jen pro ilustraci...
27.3.2011 01:49
Luk | skóre: 47
| blog: Kacířské myšlenky
| Kutná Hora
Ono občas bývá problém jajít HW, kde suspend do RAMky vůbec funguje<rejp>A mít štěstí, aby fungoval i v Linuxu
</rejp>
kde jen tak mimochodem stejně musí běžet něco, co ten packet pošlePokud je to v síti, kde běží server dostupný zvenku, tak to může poslat právě ten server.
šetřit mermomocí jak se jen dá, jen aby se nemusela postavit další elektrárnaLidé, kteří budou mít tu elektrárnu (prakticky jakoukoli - uhelnou, plynovou, jadernou, větrnou...) u nosu, asi budou mít jiný názor
<rejp>A mít štěstí, aby fungoval i v LinuxuJo, taknějak :)
Pokud je to v síti, kde běží server dostupný zvenku, tak to může poslat právě ten server.Serverů je tam spousta, ale kancelářská L2 síť je oddělená (což z hlediska bezpečnosti je dost dobrý nápad :) ), takže by to musel umět tak možná router nebo switch (na který se samozřejmě z venku taky nedá dostat :)) ).
Lidé, kteří budou mít tu elektrárnu (prakticky jakoukoli - uhelnou, plynovou, jadernou, větrnou...) u nosu, asi budou mít jiný názorNo jo, ale lidi budou mít vždycky si na co stěžovat. Těm co bydlí u letiště se to taky nelíbí, lidi co si koupí byt 50m od magistrály si stěžujou, že tam je hluk a podobně... asi je to bohužel daň za pokrok; kdyby se všechno mělo líbit všem, tak ještě dnes lezeme po stromech
27.3.2011 14:45
Luk | skóre: 47
| blog: Kacířské myšlenky
| Kutná Hora
27.3.2011 23:32
Luk | skóre: 47
| blog: Kacířské myšlenky
| Kutná Hora
29.3.2011 13:54
kotyz | skóre: 25
| blog: kotyzblog
| Radnice
27.3.2011 23:35
Luk | skóre: 47
| blog: Kacířské myšlenky
| Kutná Hora
Nostalgicky vzpomínám na ty 386 a starší, které měly kolébkové spínače – když byly vypnuté, nežraly vůbec nic.Tohle bylo ještě o dost později, dokud žila platforma AT. Naposledy jsem to měl u Celerona 366 někdy z roku 2000. Deska byla obojetná (AT+ATX), ale protože byla ve skříni se zdrojem AT, vypínalo se to postaru.
28.3.2011 23:47
vencour | skóre: 56
| blog: Tady je Vencourovo
| Praha+západní Čechy
Co pozoruju, některé kondenzátory dřív vyschnou, když nejsou napájené. Aneb ani to vypínání neni 100% bez vedlejšího efektu.
29.3.2011 01:15
Luk | skóre: 47
| blog: Kacířské myšlenky
| Kutná Hora
Tohle by byl dobrý námět na feature request pro Google. V rozšířeném vyhledávání by mohlo jít zaškrtnout, že se mají zobrazit jen weby dostupné přes IPv6.To by ovšem Google musel indexovat IPv4 a IPv6 zvlášť. To, že jeden web běží na IPv4 i IPv6 je pohled uživatele a správce – z technického pohledu klienta jsou to ovšem dva různé weby, které mohou běžet na různých DNS názvech, nebo naopak mohou mít weby s stejným názvem jiný obsah přes IPv4 a přes IPv6. Navíc k čemu by dnes taková vlastnost byla jinému, než na hraní? Copak má dnes někdo jen IPv6 konektivitu?
27.3.2011 14:50
Luk | skóre: 47
| blog: Kacířské myšlenky
| Kutná Hora
To by ovšem Google musel indexovat IPv4 a IPv6 zvlášť. To, že jeden web běží na IPv4 i IPv6 je pohled uživatele a správce – z technického pohledu klienta jsou to ovšem dva různé weby, které mohou běžet na různých DNS názvech, nebo naopak mohou mít weby s stejným názvem jiný obsah přes IPv4 a přes IPv6.To sice ano, ale dříve či později se s tím Google stejně bude muset nějak vypořádat.
Navíc k čemu by dnes taková vlastnost byla jinému, než na hraní? Copak má dnes někdo jen IPv6 konektivitu?Dnes by se to hodilo (asi jen) k experimentům. Ale než by to implementovali, může být už situace jiná.
Pravda, to bylo byla zajimava vlastnost.Samozřejmě nepředpokládám, že každý nalezený odkaz bude dostupný přes IPv6, to je problém provozovatelů webů.Tohle by byl dobrý námět na feature request pro Google. V rozšířeném vyhledávání by mohlo jít zaškrtnout, že se mají zobrazit jen weby dostupné přes IPv6.
Problem je, kdyz se setreni navazuje zrovna na havarii atomove elektrarny, tak me to naprosto od setreni odrazuje. Osobne vypinam kazdy den monitor, ale oba dva moje pocitace nechavam zapnute a to ze dvou duvodu. Jednak je pouzivam pro vzdaleny pristup a spravu site - mam ze sveho pocitace pristup na vsechna mista bez omezeni a kdyz je nejaky problem, tak potrebuju pristup ihned a ne nejdriv resit, jestli svuj pocitac vubec dokazu vzdalene zapnout. Druhy duvod je ten, ze kdyz denne koncim v praci, tak nechavam dost prace "rozdelane" - spojeni na servery, otevrene soubory se skripty nebo konfiguraci, web prohlizec s ruznymi adresami a kdybych mel denne vsechno vypnout a druhy den znovu zapnout, tak bych ztratil mozna tak dalsi hodinu. O hibernaci mi nemluvte - to je dobry tak pro BFU, ja nechci kazdy den resit nenahozenou sitvoku nebo grafiku nebo tak neco, nehlede na to, ze spojeni na SSH servery by popadaly, takze nic. Bohuzel napr. kolega ve vedlejsi kancelari nechava svoje monitory zapnute (nebo mu spatne funguje uspavani), proste monitor tam vecer sviti snad kazdy den, kdyz odchazim. Osobne jsem pro setreni energie, ale (a) nezneuzivat pritom nejakou jinou udalost, (b) setrit s rozumem - jinak bychom mohli rict, ze kazdy po 20:00 ma jit spat a ma vypinat vsechny elektronicke pristroje vcetne TV (ani spaci mod), radio-budiku a mobilniho telefonu.když je taková proti-atomová nálada, tak bychom měli počítače v době nečinnosti vypínat a šetřit proudŠetření proudem není (jen) záležitostí protiatomové nálady, ale je věcí zcela obecnou. Je mi jasné, že nejmíň polovina lidí tady na abíčku nechává počítač (myšleno desktop) puštěný nonstop, proto hovořit o vypínání vždycky znamená, že se někdo ozve. Přitom je to pitomost - pokud ten počítač nemá nic na práci, nemusí být zapnutý. Pro dálkový přístup to lze nezřídka řešit tak, že se v případě potřeby vzdáleně zapne.
A pokud zakážeš keepalive, nezmění se ti IP adresa a server nebude chtít nic vypsat do terminálu, tak to spojení přežije. I když já bych na tohle radši vzal screen a ssh obalil obnovovacím scriptem, takže bych pak mohl počítač v klidu uspat.
Taky jsem se v poslední době s IPv6 začal opět trochu zaobývat (to je náhodička ) a musím říct, že sice některé věci jsou zajímavé, ale v globálu mám pocit, že celá ta IPv6 je taková "uděláme to lépe než to bylo, z historie se nepoučíme, a pak narazíme na problémy, na které se narazilo před 20ti lety". Upřímně řečeno, kdyby se jen zvýšil rozsah adres a trochu víc se dbalo na hiearchické routování, tak by to podle mně bylo lepší. Takhle tu máme systém, který umí spoustu, s prominutím, volovin, systém, který tu s námi je už deset let, ale stále není ani pořádná implementace DHCP serveru, systém který se téměř nerozšiřuje a všichni jen nadávájí na ty hrozné zlé korproace, které to nechtějí podporovat a proto se to nerozšiřuje...
Všude čteme, že IPv6 adres je, že by se dalo uadresovat /doplň něco velkého, třeba počet atomů na Zemi/ a ještě by nám hodně zbylo..., ale pak člověk zjistí, že se adresy rozdělují tak, že síť nesmí mít menší rozsah, než /64. Posledních 64 bitů má tvořit jakýsi ID, který ač osmi bajtový, se dělá například z 6ti bajtové MAC adresy. Takže síť o 5ti stanicích zablokuje 2^64-5 nevyužitých adres.. Pokud se nám to nelíbí, tak si můžeme posledních 64 bitů určit jak chceme, ale rozshah bychom si zmenšovat neměli...
Dále zjistíme, že na autokonfiguraci slouží dva protokoly (RA a DHCP), které se liší tím, že jeden z nich neumí poslat DNS servery, ale zato umí poslat informaci o tom, že na síti je k dispzoci DHCP infrastruktura. Člověku nedá si nepoložit otázku: "co je, kruci, tak složitého na protokolu: mám MAC adresu X:Y a potřebuju dostat nějakou IP adresu.... Tady máš IP adresu a.b...."?
Co se mi moc líbí, jsou linkové adresy. Tady je vidět, že v jednoduchosti je síla. Připojím nový stroj do sítě a ověřím, jestli mi funguje konektivita, aniž bych musel cokoliv nastavovat. Přes linkovou adresu se na stroj vždy dostanu a "hlavní" IP adresu pak můžu nastavovat, jak chci a kdy chci. Přivezu stroj na hosting, připojím, zapnu, pingnu router a ocházím. Později, v klidu domova, se na server bez problému přiSSH a konfiguruju bez obavy, že si pod rukama zmastím nastavení sítě...
Co nechápu je, přístup při (ne)fragmentaci packetů a jejich velikosti vůbec. Když už molochuju takového molocha, můžu si dovolit zvětšit packety (nepříklad ethernet umí jumboframy). Místo toho se naopak fragmentace zakáže a zavede se mechanismus, kterým se zjistí, jak velké packety se smí maximálně přenášet. De facto se z hop-by-hop přistupu udělá end-to-end, to zní logicky, že.... Ovšem pokud si člověk vzpomene, že byla kdysi myšlenka, že packety mohou chodit, kudy chtějí, tak se může snadno stát, že to jaksi nebude tak nějak fungovat... Nu nevadí, tak se zavede to, že packet může napovídat, kudy by byl rád routován. To zní jako skvělá věc. Jen se nikdo nepozastavil nad tím, že IPv4 podobný mechanismus má už od svého počátku, ale jaksi se kvůli bezpečnosti téměř nepoužívá. Takže se to s velkou slávou navrhne, jen aby se to za půl roku zobsoletovalo, protože to není moc bezpečné....
A co se nám ve finále stane? Oklikou se zbavíme všech slavných výdobytků a zůstane nám něco, co vlastně jenom zvětší IP adresy a zavede nové DNS záznamy. A pak se to možná začne rozšířovat. A nějaké argumenty pro toto téměř kacířské tvrzení? Kolik procent strojů s IPv6 konektivitou má nějak nastavený IPSEC? A kolik procent strojů ho nějak alespoň trochu smysluplně používá? Kolik procent sítí vám umožní správně použít IPv6 mobilitu? A jste si jistí, že když svůj notebook připojíte u souseda, že vám bude vše fungovat přesně tak, jako byste seděli doma? A když jsme našeho poskytovatele na hostingu požádali o IPv6, co jsme dostali? IPv6 rozsah, který máme nasměrovaný přes jeden transportní rozsah, ve kterém má jednu IP poskytovatel (.1 na konci) a druhou my (.2 na konci). Jak se to liší od IPv4 konetivity? Opravdu jen tou délkou adres, ani ta EUID64, či jak se to jmenuje, tam není praktické používat....
)
Btw: kdo vymyslí regulární výraz, který v oné knížce od pana Satrapy (mimochodem poměrně kvalitní) najde věty typu: "bylo rozhodnuto, že když už se to předělává, tak se to předělá pořádně"?
Jak to, že jste to nedostal? Co jiného je IPv6 než protokol, který řeší rozšíření adresního prostoru a snížení jeho fragmentace? Možnost komunikace s celým současným internetem máte přes tunely. Nativně to samozřejmě nejde, protože nemůžete splnit oba požadavky „rozšířit adresní prostor“ a „zachovat adresní prostor“ najednou.A co takhle možnost zachovat stávající prostor jako podmnožinu rozšířeného? To je všude možně, nejen v IT, docela oblíbená praxe. To je jen taková poznámka, o všech možných tunelovacích něco-over-něco (kterých je podle mně naopak až moc) vím.
Problém je asi v tom, že zatímco když se mluví o IPv4, každý za tím vidí jen IP protokol, a NAT, DHCP, firewall, DNS a další a další související technologie vnímá jako samostatné technologie, u IPv6 lidé bůhvíproč tyhle rozšířené technologie zahrnují jako součást toho základního protokolu.Tak napůl. DNS je opravdu oddělená technologie, zatímco firewall, NAT a DHCP jsou "přifařené" technologie. A jediná z techto technologií, kterou já jsem zmínil, je DHCP, což je podle mně dost důležitá technologie. Ale jak už jsem psal výše, IPv6 se snaží přímo do sebe zakomponovat lepší a bělejší Router Advetisment, který (možná z důvodů, že to do IP protokolu nepatří) neumí pár drobností, takže jako celek je to nepoužitelné...
Jak byste si to zachování stávajícího prostoru jako podmnožiny představoval? Počítač se podívá do IPv6 adresy, zjistí, že je to zakamuflovaná IPv4, tak paket pošle IPv4 protokolem. Jakou mu nastaví zdrojovou IPv4 adresu? Aha, žádnou nemá, tak tu bude muset řešit až nějaký prostředník, který světy IPv4 a IPv6 propojí. Takže tunel. To, co jste chtěl, tedy existuje.Já jsem nemluvil o propojení IPv4 a IPv6. Jen o rozšíření prostoru. To, jakým způsobem si to kdo zařídí, pokud chce, je jeho věc. A klidně tím tunelem a když ten tunelovací systém bude co k čemu, tak se uchytí...
Já tedy RA vnímám jako přidruženou technologii, stejně jako DHCP6. Nevidím ale žádné argumenty, proč by něco z RA nebo DHCP6 způsobovalo nepoužitelnost IPv6. Psal jste jen o nějakých problémech s konkrétní implementací – no mně se třeba nejrozšířenější implementace DHCP serveru od ISC taky vůbec nelíbí, ale to ještě není důvod, abych tvrdil, že je IPv4 nepoužitelné a nedomyšlené.To si asi úplně nerozumíme. Já nemluvím o IPv6 jako čistém protokolu. Pokud bych pod to zařadil opravdu jen to, co mi zajišťuje posílání packetů na již nastavených rozhraních, tak to se mi vcelku zamlouvá. Jenže já mluvím o IPv6 jako celku včetně těch přidružených technologií, které jsou potřeba pro masové rozšíření. A jestli jste si dobře všimnul, já nemluvím o špatné implementaci DHCP serveru. Já mluvím o špatně navržené technologii, která je de facto součástí IPv6* a která má v současné době minimum implementací, které jsou všechny problematické (ikdyž tady se stav zlepšuje, to musím přiznat). *) Navrhuje to stejná skupina lidi jako "samotný protokol", je to zásadní věc k masovému využití "samotného protokolu" a je to se "samotným protokolem" vzájemně propletené skrz naskrz.
Problém IPv6 je, že je prostě moc složité a chybí mu elegance.Nemůžu si pomoct, ale já tu složitost prostě nevidím... ip a a, ip r a, trochu čachrování s tunelem a ip6tables a funguje to. Ano jsou tu i další vlastnosti toho protokolu, ale těch jsem si s dovolením nevšímal a stejně všechno funguje.
e facto se z hop-by-hop přistupu udělá end-to-end, to zní logicky, že.... Ovšem pokud si člověk vzpomene, že byla kdysi myšlenka, že packety mohou chodit, kudy chtějí, tak se může snadno stát, že to jaksi nebude tak nějak fungovat...Doporučuju přečíst si knížku o IPv6, kterou si můžeš stáhnout od NIC.cz. Tuším, že to napsal Pavel Satrapa. Dočteš se tam například, že pokud si pakety najednou začnou cestovat jinudy a nevlezou se tam, dostane o tom odesílatel ICMP zprávu a podle ní velikost odesílaného paketu patřičně zmenší. Taky se tam dočteš, že jednou za čas má odesílatel zopakovat PMTU discovery, aby přišel na to, že se cesta změnila a MTU je na ní větší. Teda samozřejmě pokud ve firewallu neblokuješ ICMP...
A když jsme našeho poskytovatele na hostingu požádali o IPv6, co jsme dostali?Což je zcela jistě problém protokolu...
Tak tady pozor, já se nebavím o samotném protokolu, ale o celém ekosystému, jehož jádrem je tento protokol. Náš poskytovatel to IPv6 má dokonce certifikované, takže to určitě není nějaká chyba na jeho straně. Uváděl jsem to proto, že všechny ty ptákovinky okolo prostě ve skutečnosti potřeba nejsou, používají se v minoritě (jestli vůbec) a jen to celé brzdí a táhnou ke dnu....A když jsme našeho poskytovatele na hostingu požádali o IPv6, co jsme dostali?Což je zcela jistě problém protokolu...
Ke zbytku dodám jen pár postřehů, nebudu tu opakovat věci, které jsem napsal v mém prvním příspěvku (tam jsem zmínil pár těch věcí, které podle mně táhnou IPv6 ke dnu, další se dají snadno najít, stačí si prolistovat onu knížku od pana Satrapy). Ale přiznejme si, žádná zpětná kompatibilita neexistuje. Pouze se věci podobně jmenují, protokol umožňuje přenášet stejné protokoly vyšší vrstvy na stejných protokolech nižší vrstvy. Ale samotné IP je překopané od základů a společného zůstává poměrně málo.
A jen citace, jak rychle velcí hráči implementují IPv6? Spíše neimplementují a proč? Protože to je něco úplně jiného. Kdyby to mělo být něco podobného a zpětně kompatibilního, tak by se řeklo: přidáme IP hlavičku, která ponese dalších X bajtů adres. Kdyby to mělo být jen něco podobného, ale ne zpetně kompatibilního, tak řekneme: vezme se IP packet a pole pro adresu se rozšíří na dvoj/čtyř/x násobek.
A na závěr oblíbený argument, že když se mi něco nelíbí, můžu si to zkusit sám, ten nemínim komentovat
Takže pokud budu mít smůlu, tak každý hop bude mít menší MTU než předcházející. Pak budu jeden packet doručovat na poměrně hodně pokusů.No to je opravdu strašné, jeden paket se (teoreticky, hodně teoreticky) bude doručovat na několik pokusů. V porovnání s tisícovkami ostatních paketů je to opravdu velmi významné.
Mějme firmu, která má dvě připojení k Internetu a je dostatečně velká, že se účastní BGP ... Takže PMTU odchází po jedné lince a většina packetů pak třeba po jiné.A pak mějme 99% normálních lidí a firem, které žádný takový "problém" mít nebudou. A uvozovky píšu proto, že to ve skutečnosti žádný problém není. Pro první paket se zjistí MTU a všechny další jsou ok.
Jinak řečeno, ta myšlenka je špatnáMyšlenka je rozumná, protože odbourává nutnost fragmentovat data na routerech po cestě, tj. snižuje jejich vytížení a umožňuje větší provoz.
Tak tady pozor, já se nebavím o samotném protokolu, ale o celém ekosystému, jehož jádrem je tento protokol. Náš poskytovatel to IPv6 má dokonce certifikované, takže to určitě není nějaká chyba na jeho straně.Já taky neříkal nic o tom, že je to chyba - problém s tím máš zjevně akorát ty.
No ono to až zas tak jednoduché být nemusí. Představ si, že se v NIXu rozhodnou zavést nějaké VLANNG, které zmenší MTU na 1490. Podle toho RFC, můj server bude všem klientům začínát s MTU prvního hopu, tedy 1500. A pro každého klienta se to bude muset snižovat (pokud to já ručně nenastavím na 1490 pro všechny). A když se budeme bavit o serveru, který obsluhuje hodně různých klientů, třeba DNS server, tak ten poměr může vyjít i trochu jinak než jedna ku tisícům. A že DNS packety nejsou obvykle tak velké? No nejsou, ale kdo ví, co bude... Třeba se bude muset s DNS odpovědí posílat i certifikát serveru a je to....Takže pokud budu mít smůlu, tak každý hop bude mít menší MTU než předcházející. Pak budu jeden packet doručovat na poměrně hodně pokusů.No to je opravdu strašné, jeden paket se (teoreticky, hodně teoreticky) bude doručovat na několik pokusů. V porovnání s tisícovkami ostatních paketů je to opravdu velmi významné.
To je běžný argument, pro většinu to funguje, ostatní ať si škubnou...Mějme firmu, která má dvě připojení k Internetu a je dostatečně velká, že se účastní BGP ... Takže PMTU odchází po jedné lince a většina packetů pak třeba po jiné.A pak mějme 99% normálních lidí a firem, které žádný takový "problém" mít nebudou. A uvozovky píšu proto, že to ve skutečnosti žádný problém není. Pro první paket se zjistí MTU a všechny další jsou ok.
Jak už jsem psal níže, pokud někdo, kdo přenáší moje data, usoudí, že se mu to lépe bude přenášet fragmentovaně, je to jeho věc. Jediné, co by bylo od něj slušné, než to opustí jeho "hřiště", to zase srovnat.Jinak řečeno, ta myšlenka je špatnáMyšlenka je rozumná, protože odbourává nutnost fragmentovat data na routerech po cestě, tj. snižuje jejich vytížení a umožňuje větší provoz.
Ty jsi říkal, že je to problém:Tak tady pozor, já se nebavím o samotném protokolu, ale o celém ekosystému, jehož jádrem je tento protokol. Náš poskytovatel to IPv6 má dokonce certifikované, takže to určitě není nějaká chyba na jeho straně.Já taky neříkal nic o tom, že je to chyba - problém s tím máš zjevně akorát ty.
Což je zcela jistě problém protokolu...Já jsem to naopak použil jako příklad toho, že ve skutečnosti po deseti letech vývoje IPv6 je jediný rozdíl ve velikosti adres. A já jsem za to rád.
No ono to až zas tak jednoduché být nemusí. Představ si, že se v NIXu rozhodnou zavést nějaké VLANNG, které zmenší MTU na 1490.To je samé představit si tuhle, katastrofální varianta támhle... od reálného života se to ale maličko liší...
A když se budeme bavit o serveru, který obsluhuje hodně různých klientů, třeba DNS server, tak ten poměr může vyjít i trochu jinak než jedna ku tisícům.To nepochybně, ale DNS servery rozhodně v Internetu nemají na svědomí největší datové přenosy. Troufám si odhadnout, že majoritu tvoří videa přenášená přes HTTP (a obecně spojení s velkými datovými přenosy). Tam ten poměr vyjde naprosto bez problémů.
To je běžný argument, pro většinu to funguje, ostatní ať si škubnou...Ne, to je argument pro většinu to funguje bez jakýchkoliv problémů, pro ty ostatní občas ne a ani v takovém případě se to nepozná.
Jak už jsem psal níže, pokud někdo, kdo přenáší moje data, usoudí, že se mu to lépe bude přenášet fragmentovaně, je to jeho věc.Tak to bych rád slyšel nějaký rozumný důvod, proč by někomu mohlo víc vyhovovat fragmentovat všechny pakety než u jednoho z nich říct jejich odesílateli, že má posílat menší. Nebo v ještě jednodušších termínech: proč by někdo mohl chtít dražší a pomalejší hardware.
Místo toho se naopak fragmentace zakáže a zavede se mechanismus, kterým se zjistí, jak velké packety se smí maximálně přenášet. De facto se z hop-by-hop přistupu udělá end-to-end, to zní logicky, že.... Ovšem pokud si člověk vzpomene, že byla kdysi myšlenka, že packety mohou chodit, kudy chtějí, tak se může snadno stát, že to jaksi nebude tak nějak fungovatZrovna tohle je no-issue - IPv4 totiz podporuje oba rezimy (jak fragmentaci po ceste, tak zakaz fragmentace po ceste - don't fragment bit v IP datagramu) a od fragmentace po ceste se uz z velke casti upustilo i na IPv4 - klienti dnes prevazne nastavuji don't fragment bit, takze fragmentace po ceste se nedela.
No a to je přesně to, o čem mluvím. V IPv4 je možnost si zvolit, zda fragmentovat či ne. Není tam mechanismus na zjištění maximální velikosti na celé cestě, pouze ICMP zpráva typu "tos přepísk". Takže se de facto standardizuje MTU 1500 nebo 1496, protože s tím to většinou proleze. To máme stav, jak je. Pak přijde skupina, co navrhuje IPv6 a rozhodne se to vylepšit. Navrhne tedy, že povolení fragmentace nebude možné a přidá protokol na zjištění maximálního MTU. Zároveň ponechá ono ICMP "tos přepísk". Tedy celé se to zesložití a nepřinese to moc nového. Což ale tak moc nevadí, protože to časem vyšumí, path MTU discovery se časem přestane používat, udělá se stručné RFC typu "celé je to obsolete" a jsme tam, kde jsme byli. A přitom je velikost přenášeného pakcetu docela velký problém, který když už, tak by stálo za to pořádně vyřešit. Nebo budeme mít za 10 let IPv9k jen proto, že se přijde na to, že při dnešních rychlostech je vhodné mít větší MTU, s čímž předchozí protokol tak nějak nepočítal...Místo toho se naopak fragmentace zakáže a zavede se mechanismus, kterým se zjistí, jak velké packety se smí maximálně přenášet. De facto se z hop-by-hop přistupu udělá end-to-end, to zní logicky, že.... Ovšem pokud si člověk vzpomene, že byla kdysi myšlenka, že packety mohou chodit, kudy chtějí, tak se může snadno stát, že to jaksi nebude tak nějak fungovatZrovna tohle je no-issue - IPv4 totiz podporuje oba rezimy (jak fragmentaci po ceste, tak zakaz fragmentace po ceste - don't fragment bit v IP datagramu) a od fragmentace po ceste se uz z velke casti upustilo i na IPv4 - klienti dnes prevazne nastavuji don't fragment bit, takze fragmentace po ceste se nedela.
To znamená něco jako: když se vám to hodí, můžete to fragmentovat. A upřímně řečeno, pokud se někdo rozhodne můj příznak ignorovat (ať tak, či onak), já s tím asi prdlajs nadělám...
když se vám to hodí, můžete to fragmentovat#66, poslední odstavec
tak bychom měli počítače v době nečinnosti vypínat a šetřit proud.Podle mě by měli počítač, lednice, televize, světla, zkrátka všechno, co funguje na el. energii, vypnout všichni protijaderní aktivisté a na furt. Jaderná energie je totiž jediný zdroj, který je globálně schopen spolehlivě a ekologicky dodat dostatek energie, aby pokryl současnou spotřebu - když jsou proti tomu, tak ať nespotřebovávají. Další spolehlivý zdroj jsou elektrárny uhelné, ale ty už nám - hádám - způsobily větší ozáření než všechny Černobyly a Fukušimy dohromady (a to nepočítám další svinstvo, které taková uhelná elektrárna produkuje)
27.3.2011 14:56
Luk | skóre: 47
| blog: Kacířské myšlenky
| Kutná Hora
Další spolehlivý zdroj jsou elektrárny uhelné, ale ty už nám - hádám - způsobily větší ozáření než všechny Černobyly a Fukušimy dohromady (a to nepočítám další svinstvo, které taková uhelná elektrárna produkuje)Samozřejmě, že uhelné elektrárny vypouštějí do vzduchu nemalé množství radionuklidů, které způsobuje pravděpodobně v globálním měřítku mnohem větší ozáření než elektrárny jaderné. A to nehovořím o tom, že škvára z takových elektráren se používala (možná někde ještě používá) na výrobu tvárnic a na posyp vozovek. A právě v té škváře se koncentrují radionuklidy, před pár lety prováděl SÚJB měření na silnicích posypaných škvárou a měřícím pracovníkům úplně vstávaly vlasy na hlavě z hodnot intenzity záření, které tam naměřili.
Resp., proč anti-atomoví aktivisté ještě nepostavili takové elektrárny, které by vyráběli stejně nebo více elektřiny za stejnou nebo nižší cenu a nevytlačili tak atomové a tepelné elektrárny z trhu?Možná proto, že cena je dnes určena především nabídkou a poptávkou a ekologie v ceně není promítnuta dostatečně. Dnes vyrábíme elektřinu z jádra s tím, že vzniká odpad který tu bude, plácnu, několik tisíc let. Jsou náklady na jeho skladování, havárie, kontaminaci atd započítány do ceny elektřiny z tohoto zdroje, nebo ji vyrábíme levně, protože ji vyrábíme "na dluh"?
27.3.2011 16:15
Luk | skóre: 47
| blog: Kacířské myšlenky
| Kutná Hora
Jsou náklady na jeho skladování, havárie, kontaminaci atd započítány do ceny elektřiny z tohoto zdroje, nebo ji vyrábíme levně, protože ji vyrábíme "na dluh"?To nikdo neví. Nikdo nedokáže předvídat, do jaké míry bude ten odpad v budoucnu využitelný a jaká bude jeho ekonomická bilance. Samozřejmě, že při současných technických možnostech vychází ta bilance záporná, ale třeba za 50-100 let to může být výrazně jinak.
27.3.2011 18:12
Luk | skóre: 47
| blog: Kacířské myšlenky
| Kutná Hora
To jsou taky naklady, ktere musi elektrarna platit, takze je samozrejme zapocitava do ceny.Kromě toho existuje něco jako "jaderný fond", kam elektrárny platí na budoucí likvidaci odpadu. Čili nějaké náklady (podle Wikipedie 50 Kč/MWh) teď vstupují do ceny elektřiny, otázka samozřejmě je, jaká bude později realita.
Pokud by měl Linux zastávat funkci IPv6 routeru, musí se nainstalovat radvd.Nemusi. Jednak samotne rozesilani router advertisementu neni nezbytne nutna cinnost, druhak existuji i jiny software, ktery zajistuje rozesilani router advertisementu (napr. Quagga nebo BIRD).
Jako další mě překvapilo, že podobný zápis jsem musel použít i v Knoppixu pro pingání lokální linkové adresy, např. ping fe80:......%eth0, jinak vracel ping chybu - možná to bylo jenom nějakou unstable/testing verzí, určitě to ještě zkusím na debian lenny.No, to je vcelku samozrejme, ze je treba tam to rozhrani specifikovat - link-local adresy jsou jednoznacne jen v ramci linky a tak je treba specifikovat, o kterou linku se jedna (zrovna u ping6 ja pouzivam spis -I iface namisto %iface).
A uživatel MUSÍ dostat minimálně síť /64 (tedy na vaše adresy máte 64 bitů) - super ne?No, to je dost naivni predstava - pochybuju, ze jen na zaklade toho, ze to je nekde nejak napsane, k tomu ISPcka nekdo realne donuti. Tipuju, ze se casto bude vyskytovat pripojeni, kde dostanes tak jednu IPv6 adresu, a nikdo se s tebou o naroutovani prefixu bavit nebude. Na druhou stranu, pokud ISPcka budou dodavat rovnou koncove zarizeni (treba ADSL/wifi modem) s predpripravenym kompatibilnim sw, tak ono naroutovani jedne /64 bude asi jednodussi.
(A tady bude smůla to, že u IPv4 si člověk udělá NAT, kdežto u IPv6...)Kdežto u IPv6... si udělá NAT nebo SOCKS proxy, která toho umí víc jak NAT. V nouzi jsou k dispozici stejné technologie jako u IPv4. Fajn je, že obvykle nebudou potřeba.
Kdežto u IPv6... si udělá NATJak? Pokud je mi známo, NAT u IPv6 minimálně v Linuxu implementován není.
Jak? Pokud je mi známo, NAT u IPv6 minimálně v Linuxu implementován není.Kdežto u IPv6... si udělá NAT nebo SOCKS proxy.
To nijak neodpovídá na otázku, jak si udělá ten NAT.Fajn, tedy k NATu... udělá si ho stejně jako na IPv4 a použije k tomu krabičku s nějakým OS, který to bude umět, třeba nějakou verzi Linuxu. Snad mi nechceš zároveň trvrdit, že NAT na IPv6 bude nesmírně užitečný a potřebný a že nebude implementován.
takze proc by mel zakaznikovi davat jednu adresuProtože to je jednodušší, protože je to podobnější tomu, co se dělalo doteď, protože se to tak dělalo vždycky... blbej důvod se vždycky najde a blbej důvod většině ISP stačí.
v případě IPv4 se zařídili tak, že modem u zákazníka dělá NATU nás se ISP zařídil tak, že (alespoň v době, když se podepisovala smlouva) na tom připojení smí být jenom jeden počítač. Kontrolováno podle MAC síťovky, což zase nebyl takový problém obejít - prostě se ze starýho kompu udělal router a na něm ten NAT.
V případě IPv6 je nejschůdnější cesta přidělit domácnosti místo jedné IPv6 adresy nějaký rozsah.Souhlasím, ale když dojde na místa, kde není moc velká konkurence (a to tady moc není), nejsem optimista.
U nás se ISP zařídil tak, že (alespoň v době, když se podepisovala smlouva) na tom připojení smí být jenom jeden počítač.To ale podle mého není řešení technických problémů a nedostatku IP adres – tím se chrání, aby někdo nepřeprodával konektivitu ostatním – aby si např. dva sousedi neplatili jen jeden paušál – takhle můžou inkasovat od každé domácnosti, i když ten Internet využívají minimálně.
když dojde na místa, kde není moc velká konkurence (a to tady moc není), nejsem optimista.jj, někdy to není lehké, řešil jsem nebo ještě řeším podobný problém – a to bydlím v Praze.
To nema cenu dal o tomhle diskutovat. Precti si kapitolu 3.4 Globalni individualni adresy (str.55-57) knihy o IPv6 od Pavla Satrapy. Dalsi info je v anglicke wikipedii hesla IPv6. V kratkosti: bloky /32 dostavaji LIR, kteri pak tuhle sit rozdeluji na jednotlive ISP. Takze jede LIR dostane prefix, ve kterem je 96bitu=3 x pocet bitu IPv4. Z toho pak dostanou neco ISP, pravdepodobne /48. Kazdej ISP pak tedy bude mit 16 bitu na dalsi podsite, cili 65535 podsiti. Kdyz pak da kazdymu zakaznikovi POUZE JEDNU JEDINOU adresu, tak zakaznik bude mit dalsich 64 bitu na vlastni sit. Srovnani s IPv4: Provider ma k dispozici sit /16, coz je tak obvykla velikost nejakyho stredniho az mozna mensiho providera a prideli zakaznikovi jednu adresu a zakaznik tim ziska /64 sit. Opravdu bude ISP davat zakaznikovi pouze jednu /128 adresu? To sotva. Samozrejme velci ISP (to uz jsou spis sami LIRove) dostavaji /32, takze rozdeluji site /32 - cili maji pro sve zakazniky kompeltni velikost IPv4 a kdyz zakaznik dostane tuhle jedinou adresu, tak je to adresa zakaznikovi site /64. NAT opravdu neni treba a ISP budou resit vic problemu, kdyz budou chtit zakaznikum pridelit pouze jednu IPv6 adresu /128, nez kdyz prideli celou /64 sit.takze proc by mel zakaznikovi davat jednu adresuProtože to je jednodušší, protože je to podobnější tomu, co se dělalo doteď, protože se to tak dělalo vždycky... blbej důvod se vždycky najde a blbej důvod většině ISP stačí.
Precti si kapitolu 3.4 Globalni individualni adresy (str.55-57) knihy o IPv6 od Pavla Satrapy.Četl jsem...
Kazdej ISP pak tedy bude mit 16 bitu na dalsi podsite, cili 65535 podsiti. Kdyz pak da kazdymu zakaznikovi POUZE JEDNU JEDINOU adresu, tak zakaznik bude mit dalsich 64 bitu na vlastni sit....ale nevidím, jak z toho vyplývá to, co z toho vyvozuješ. Týká se jak citovaného textu, tak toho zbytku, co píšeš.
NAT opravdu neni treba a ISP budou resit vic problemu, kdyz budou chtit zakaznikum pridelit pouze jednu IPv6 adresu /128, nez kdyz prideli celou /64 sit.Tak třeba tohle... jak velké problémy si ISP nadělá, když koncovému zákazníkovi podle jeho MAC řekne, že tvoje IP adresa je 2001:bla:bla:bla::1:2345/96? A kde v tom vidíš, že ten zákazník automaticky získal /64 síť, když 2001:bla:bla:bla::1:2346/96 dostává jeho soused?
...ale nevidím, jak z toho vyplývá to, co z toho vyvozuješ. Týká se jak citovaného textu, tak toho zbytku, co píšeš.*** Eeee, no jo, bral jsem pouze jednu moznost, ze si klient udela vlastni sit a dostane od ISP /64.
*** Jasne, mas pravdu, ISP muze pridelit IP jak chce, ja bral v uvahu jenom RA a SLAAC. Jinak vychazim z aktualni situace. Opravdu nejaky ISP rika zakaznikum, kterou IP si maji nakonfigurovat? Pokud vim, casto se to resi tak, ze nejaky router/modem dostane z DHCP IPcko (v lepsim pripade verejny) a koncovy klient pak bud napoji vlastni router s NATem nebo jedno PC. ISP muze pak z DHCP pridelovat fixni IP na zaklade MAC, ale to by asi bylo dost drsny, kdyz by si zakaznik zapnul jinej pocitac nebo mobilni telefon, musel by porad hlasit novou MAC adresu ISP a ten menit DHCP. Pokud tohle ISP delat bude, tak asi brzo ztrati zakazniky, protoze (a) resit takhle IPv6 je prasarna, (b) neni NAT, takze zakaznik si za jedno IP vic zarizeni neschova. Hlavne ono to neni potreba. ISP by mel rict zakaznikovi, aby pouzival sit 2001:bla:bla:bla:bla:bla:2345::/112 (coz je stejny pocet zarizeni jako /16 v IPv4) a zakaznik si pak IP nastavoval sam nebo mu ISP do jeho site tyhle IP dodaval. Takze jsou dve moznosti, jak to ISP muze delat. (1) ISP bude pres DHCP pridelovat IPv6 adresy, kazdemu klientovi pouze jednu. Tam by mel ale asi dost brzo problem, protoze dneska uz ma obvykle kazdej vic zarizeni. Nyni je schovava za NAT, ale v IPv6 neni NAT. V lepsim pripade umozni ISP zakaznikum pripojeni vice zarizeni (pravdepodobne pouze v pripade klasickych siti LAN nebo WLAN, nevim, jestli je technicky mozny na nejaky DSL modemech prijmout vic IP), ktere si pak z DHCP vezmou verejne adresy. V kazdym pripade pridelovat v IPv6 zakaznikovi JEDNU JEDINOU adresu je podle me sebevrazda. (2) ISP bude zakaznikum pridelovat site (at uz bude velkorysej a da /64 nebo to nejak zmensi, protoze treba sam ma pouze /64) a zakaznik si ty IPcka bude pak sam pridelovat pres nejakej router nebo bude ISP zajistovat sam ty IPcka klientovi. Zpatky k puvodnimu problemu. NAT v IPv6 neni potreba, proto ho nezavedli. IPv6 adres je dost a pokud se nejakej ISP i se siti /64 bude chovat jako skrt a bude zakaznikum dodavat pouze jednu adresu, tak zakaznici budou zrejme odchazet ke konkurenci. On bude asi tezko vysvetlovat, proc nemuze mit zakaznik vic zarizeni soucasne v siti, zvlast zduvodneni "kvuli jedne IP adrese" bude znit dost blbe, kdyz IPv6 resi prave nedostatek IPv4 a vsude zni, jak je IPv6 tolik, ze kazde zrnko pisku na Zemi by mohlo mit vlastni adresu. A ISP bude zakaznikovi tvrdit, ze zakaznik muze dostat pouze jednu adresu? U takovyho ISP zustanou pouze zakaznici s jednim PC - to budou pravdepodobne chudsi rodiny, ktere si plati ten nejpomalejsi tarif, protoze stejne moc Internet nepouzivaji. Z takovych moc penez mit ISP nebude a kdyz zvedne ceny, tak i tihle radsi smlouvu zrusi a prejdou jinam.NAT opravdu neni treba a ISP budou resit vic problemu, kdyz budou chtit zakaznikum pridelit pouze jednu IPv6 adresu /128, nez kdyz prideli celou /64 sit.Tak třeba tohle... jak velké problémy si ISP nadělá, když koncovému zákazníkovi podle jeho MAC řekne, že tvoje IP adresa je 2001:bla:bla:bla::1:2345/96? A kde v tom vidíš, že ten zákazník automaticky získal /64 síť, když 2001:bla:bla:bla::1:2346/96 dostává jeho soused?
ISP muze pak z DHCP pridelovat fixni IP na zaklade MAC, ale to by asi bylo dost drsny, kdyz by si zakaznik zapnul jinej pocitac nebo mobilni telefon, musel by porad hlasit novou MAC adresu ISP a ten menit DHCP.Tak třeba můj ISP to tak dělá. A co jsem tak koukal, tak v dané lokalitě není jediný, pokud vím, kromě ADSL je to docela běžné. A pořád měnit MAC adresu se řeší jednoduše - za změnu dáš jednorázový poplatek.
Hlavne ono to neni potreba. ISP by mel rict zakaznikovi, aby pouzival sit 2001:bla:bla:bla:bla:bla:2345::/112 (coz je stejny pocet zarizeni jako /16 v IPv4) a zakaznik si pak IP nastavoval sam nebo mu ISP do jeho site tyhle IP dodaval.Což to jo, jenže pokud vím, samonastavovací domácí krabičky na tohle asi moc nejsou.
Zpatky k puvodnimu problemu. NAT v IPv6 neni potreba, proto ho nezavedli. IPv6 adres je dost a pokud se nejakej ISP i se siti /64 bude chovat jako skrt a bude zakaznikum dodavat pouze jednu adresu, tak zakaznici budou zrejme odchazet ke konkurenci.... pokud mají na výběr.
On bude asi tezko vysvetlovat, proc nemuze mit zakaznik vic zarizeni soucasne v sitiDovedu si živě představit zpoplatněnou službu další IP adresa pro připojení dalšího počítače v domácnosti. Vlastně si to ani nemusím představovat, už jsem to viděl a jednalo se o nesměrovatelnou IP adresu navíc. Jenom pro úplnost, rozhodně neříkám, že něco takového je dobře, sám bych samozřejmě byl pro to, aby koncový zákazník dostal rozsah a dělej si s ním, co umíš. Jenže mám moc informací na to, abych mohl být optimista.
Hmmm, tak to uz dal argumentovat nemuzuISP muze pak z DHCP pridelovat fixni IP na zaklade MAC, ale to by asi bylo dost drsny, kdyz by si zakaznik zapnul jinej pocitac nebo mobilni telefon, musel by porad hlasit novou MAC adresu ISP a ten menit DHCP.Tak třeba můj ISP to tak dělá. A co jsem tak koukal, tak v dané lokalitě není jediný, pokud vím, kromě ADSL je to docela běžné.
A pořád měnit MAC adresu se řeší jednoduše - za změnu dáš jednorázový poplatek.*** Jasne, kvuli odirani zakazniku to samozrejme budou delat porad. Ale nemaji pak nahodou ve smlouve, ze na tom jednom IPcku muzes mit pouze jeden pocitac a kdyz chces vic pocitacu, tak si prave musis koupit dalsi IP - to je totiz logicke, ze by to tak delali. Potom muzes sice NAT pouzit, ale porusujes smlouvu. No nic, kvuli inkasovani penez za IP se samozrejme NAT hodi.
*** Jasne, ale to se pak vubec nemusime bavit o IPv6, protoze to pak ISP nasadi IPv6 az uplne nakonec, az na IPv6 budou vsichni a IPv6 bude prazdny.Zpatky k puvodnimu problemu. NAT v IPv6 neni potreba, proto ho nezavedli. IPv6 adres je dost a pokud se nejakej ISP i se siti /64 bude chovat jako skrt a bude zakaznikum dodavat pouze jednu adresu, tak zakaznici budou zrejme odchazet ke konkurenci.... pokud mají na výběr.
*** Jasne, to si dokazu taky predstavit. Nicmene jsem se vzdycky domnival, ze ISP chteji poplatky za verejne IP proto, ze IP adres nemaji dost a radsi daji verejnou IP adresu zakaznikovi, kterej ji skutecne nutne potrebuje a rad si za ni zaplati. Proto jsem to predchazejici tak napsal. Cili s IPv6 uz ISP zadny nedostatek nema a tudiz muze IPv6 rozdavat na pozadani. Jenze pokud si uz ISP zvyknul kasirovat z lidi prachy za verejne IPv4 adresy, tak v tom zrejme neprestane.On bude asi tezko vysvetlovat, proc nemuze mit zakaznik vic zarizeni soucasne v sitiDovedu si živě představit zpoplatněnou službu další IP adresa pro připojení dalšího počítače v domácnosti. Vlastně si to ani nemusím představovat, už jsem to viděl a jednalo se o nesměrovatelnou IP adresu navíc.
Jenom pro úplnost, rozhodně neříkám, že něco takového je dobře, sám bych samozřejmě byl pro to, aby koncový zákazník dostal rozsah a dělej si s ním, co umíš. Jenže mám moc informací na to, abych mohl být optimista.*** No, pak uz tedy zbyva jedina moznost - IPsec. Bohuzel to vyzaduje mit nekde v IPv6 Internetu IPsec server a proste vlastni domaci sit schovat za to jedno IPv6 IPcko od ISP. Pak by to melo fungovat jako NAT.
V dalším kroku jsme IPv4 deaktivovali a zůstali pouze na IPv6. A právě to mne donutilo napsat tenhle článek. Sice je potěšující, že různé firmy začínají aktivovat IPv6, ale pokud to udělaji polovičatě, tak to spíš škodí.Pokud to firmy udělají polovičatě, vyjadřují tím zájem se IPv6 zabývat. Pak je potřeba je bombardovat hlášením chyb tak dlouho, dokud je neopraví.
Jako další mě překvapilo, že podobný zápis jsem musel použít i v Knoppixu pro pingání lokální linkové adresy, např. ping fe80:......%eth0, jinak vracel ping chybu - možná to bylo jenom nějakou unstable/testing verzí, určitě to ještě zkusím na debian lenny.Myslím, že není ani potřeba, aby v pingu, což je testovací nástroj, fungovaly tyto adresy bez specifikace rozhraní. V praxi bych to spíš viděl na ping(6) my-computer-hostname.local (pomocí například Avahi), kde už to funguje, používám to denně na ping6 i SSH.
Naopak mě velice potěšil Debian, který má IPv6 záznamy pro svůj web www.debian.org a protože jsem chtěl do Knoppixe doinstalovat wide-dhcpv6-server a client, tak jsem potřeboval i nějaký IPv6 mirror. Používám mirror.switch.ch, který naštěstí IPv6 adresu také má.Bohužel český mirror debianu ftp.cs.debian.org (debian.cz), ani přes má opakovaná upozornění, nefunguje na IPv6-only síti kvůli absenci IPv6 DNS serverů. Mirror na Silicon Hill má toto v pořádku (naopak nemá na IPv6 HTTP server, ale to slíbili opravit).
No, tak jsem mezitim zjistil, ze ono se to rozhrani psat musi a to zcela logicky-kdyz je na interfacech eth0, eth1, eth2... vzdy nejaka adresa fe80:..., tak se musi samozrejme nejak explicitne rict, na kterym iface se ma komunikovat. Neboli, ten interface se musi zadavat nejen v pingu, ale i v ostatnich, napr. webbrowser. ten ping a ssh na adresu .local pak pouziva fe80:... adresu nebo nejakou jinou? co pise ssh -v? a co ping6? jakou vypisuji IP adresu?Jako další mě překvapilo, že podobný zápis jsem musel použít i v Knoppixu pro pingání lokální linkové adresy, např. ping fe80:......%eth0, jinak vracel ping chybu - možná to bylo jenom nějakou unstable/testing verzí, určitě to ještě zkusím na debian lenny.Myslím, že není ani potřeba, aby v pingu, což je testovací nástroj, fungovaly tyto adresy bez specifikace rozhraní. V praxi bych to spíš viděl na ping(6) my-computer-hostname.local (pomocí například Avahi), kde už to funguje, používám to denně na ping6 i SSH.
ten ping a ssh na adresu .local pak pouziva fe80:... adresu nebo nejakou jinou? co pise ssh -v? a co ping6? jakou vypisuji IP adresu?Minimálně .local vrací nějakou adresu a k tomu i to rozhraní :). Tzn funguje to bez routeru. Zbytek vyzkoušej sám, není to těžké.
27.3.2011 22:36
27.3.2011 22:54
29.3.2011 14:00
5.4.2011 11:57
