Zobrazit příspěvky

Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.


Příspěvky - Filip Jirsák

Stran: 1 ... 255 256 [257] 258 259 ... 375
3841
Sítě / Re:IPv6 ease of use
« kdy: 18. 08. 2017, 12:02:15 »
Když router odejde a nahradíte ho jiným, na delegaci IPv6 sítě od ISP se nic nezmění, pořád dostanete ten stejný blok IPv6 adres.

To ale platí jen při ruční konfiguraci.Při použití DHCPV6-PD bez zásahu ISP dostane jiný blok.
To nezávisí ani na způsobu konfigurace (ruční/automatická) ani na výměně routeru. Závisí to na tom, jak to má smluvně ošetřené s ISP – zda ISP garantuje statické IPv6 adresy, nebo zda je přiděluje dynamicky. Pokud je přiděluje dynamicky, mohou se změnit i tehdy, když router zákazníka zůstane stejný.

Přičemž ISP se bude snažit IPv6 adresy přidělené zákazníkovy měnit jen velmi výjimečně, protože má nějaké povinnosti, které znamenají, že potřebuje vědět, které IP adresy patří kterému zákazníkovi. Když IP adresy zákazníkovi změní, musí si pamatovat, kdy ke změně došlo a jaké bylo přiřazení před změnou – to je jen zbytečná komplikace.

3842
Sítě / Re:IPv6 ease of use
« kdy: 18. 08. 2017, 11:36:47 »
Precetl, potesila, jsem spokojen. Ja ji prece nerozporuji, jen se mi zdalo, ze nekolika lidem zde pripadaji puvodni pozadavky nepotrebne
Takové komentáře jsem nezaznamenal.

haluzili s nesmyslama jako DNS. Proto jsem doplnil, ze za sebe vidim jako extremne dulezite jet na stabilnich a nikdy v budoucnu nemennejch adresach bez DNS.
DNS není nesmysl, DNS byla odpověď na uživatelsky přívětivé řešení. Nikdy v budoucnu neměnné veřejné adresy jsou PI adresy, stejně jako u IPv4. Nikdy v budoucnu neměnné adresy v lokální síti jsou link local adresy, které jsou integrální součástí IPv6. V IPv4 jsou také, ale moc se nepoužívají.

3843
Sítě / Re:IPv6 ease of use
« kdy: 18. 08. 2017, 11:32:26 »
Pokud je požadavek na co nejjednodušší náhradu routeru/firewalu v případě jeho výpadku současně se zachováním IP ve vnitřní síti, tak je pravda, že v IPV6 to není tak jednoduché jako v případě IPV4, kdy se použije NAT schovávající provoz za jednu IP adresu.
Nesmysl, IP adresa s routerem/firewallem vůbec nesouvisí. Když router odejde a nahradíte ho jiným, na delegaci IPv6 sítě od ISP se nic nezmění, pořád dostanete ten stejný blok IPv6 adres. Jediné, co potřebujete, mít zazálohovanou konfiguraci toho routeru, abyste zařízením v síti znovu přiděloval stejnou IPv6 adresu – ale to platí i pro IPv4.

Pokud jste nemyslel výpadek routeru, ale výpadek internetové přípojky, tam je to s IPv6 ještě mnohem jednodušší, než s IPv4. IPv6 počítá s tím, že každé zařízení má víc přidělených IPv6 adres, takže pokud máte víc uplinků, každé zařízení má IPv6 adresu od každého z nich.

Původně byl NAT v IPV6 úplně zatracován, ale je snaha ho prosadit,
Holt si to někteří lidé potřebují vyzkoušet, že jim NAT bude akorát překážet, a pak konečně skončí na smetišti dějin. Nebo možná zůstane v některých velmi okrajových případech, pak to ale stejně nebude NAT 1:N, jaký známe z IPv4.

nejlépe se asi využije pro rychlé přesměrování za záložní linku do Internetu
S IPv6 nepotřebujete na záložní linku nijak přesměrovávat, protože zařízení v síti už mají IPv6 adresy z obou linek. Čímž jste se zároveň zbavil toho, že by router byl single point of failure. Jediný „problém“ je v tom, že router na záložní lince musí umět detekovat, že hlavní linka je nepoužitelná (ať už kvůli výpadku linky, ISP nebo kvůli výpadku routeru), a poslat do sítě oznámení směrovače, že hlavní brána je teď on.

3844
Sítě / Re:IPv6 ease of use
« kdy: 17. 08. 2017, 20:27:43 »
Pridavam se k puvodnimu tazateli, tohle je dle meho nazoru naprosto legitimni a casto zadouci stav. Vnejsich poskytovatelu muze bejt i vic, muzou se dynamicky stridat a je i platnej stav, kdyz zadnej vnejsi poskytovatel neni. Provoz zarizeni (napr. kriticka prumyslova infrastruktura) by tim nemel mit ovlivnen a s DNS to nema co do cineni.
Jaký to má smysl přidávat se k dotazu, který už byl zodpovězen? Nebo tu odpověď chcete zopakovat?

3845
Vývoj / Re:Template on template v Javě
« kdy: 17. 08. 2017, 16:05:50 »
Fakt nechápu, proč když něco nevíš, tak se to prostě nedoučíš.
Já zas nechápu, jak jste na takový nesmysl přišel.

Začal jsi s ad hominem
No vidíte, a hned máte další termín na seznam toho, o čem byste si měl zjistit, co to doopravdy znamená.

Pro tvou informaci znám do hloubky Javu i Haskell a stačilo googlit "higher kinded types in Java", abych si ověřil, že to do Javy ještě nedorazilo.
Já si pod „znám do hloubky“ představuju podstatně vyšší úroveň znalostí, než že budete googlovat běžné vlastnosti jazyka.

Lidem, kteří zaslechli nějaké termíny, ale netuší, co znamenají, je těžké poradit, protože nedokážou popsat, jaký problém vlastně řeší. Tazatel se ptá na šablony šablon v Javě, což je poněkud problém, když v Javě nejsou ani šablony. Vy hned víte, že chtěl určitě higher kinded types, protože jste sice někde zaslechl ten termín, ale nemáte představu, co se za tím skrývá a k čemu by se to mohlo použít.

Občas se stane, že někdo shání nějakou vlastnost jednoho řešení (jazyka nebo klidně IPv4) v jazyce jiném (nebo třeba v IPv6), navíc s dodatkem, že to cílový jazyk (IPv6) určitě neumí, protože je blbý. Pokud se podaří z dotyčného vypáčit, jaký problém vlastně řeší, v 99 % případů se najde v cílovém nástroji řešení daného problému, přičemž v 80 % případů je to stejně elegantní řešení, jako v tom vzorovém nástroji, zbývající případy jsou půl na půl, zda je to řešení dokonce ještě lepší nebo horší než vzor. K takovým případům patří mimo jiné mnoho dotazů, kdy se někdo sháněl po šablonách v Javě a jeho problém vyřešily generiky – po té, co dotyčnému někdo jejich existenci v diskusi prozradil.

3846
Vývoj / Re:Template on template v Javě
« kdy: 17. 08. 2017, 15:34:19 »
Java nic takového nemá, protože type erasure v generikách zabraňuje takovému použití. Java to řeší rozhraními, zde by kolektor musel dostat zvenčí instanci Collection. To je často omezující, protože ten, kdo tu třídu vytváří, nemusí vědět, co jí vlastně má předat do konstruktoru; v C++ jednoduše volá bezparametrový konstruktor. Řešit to v Javě lze pomocí továrny, ale vede to k typickému javovskému lasagna code.
Tenhle jednoduchý případ bude i v Javě stručný díky lambdám. Ale to je samozřejmě dané tím, že ten vnější typ má jen jeden typ události, což je přesně to, co dělají lambda výrazy.

3847
Vývoj / Re:Template on template v Javě
« kdy: 17. 08. 2017, 15:17:13 »
Pokud si někdo neumí vygooglit pojem, který nezná, tak je přinejlepším to, čemu zde někteří říkají "lopata". Přispěvatelé do fóra nejsou tvoje sekretářka. Doporučuji návrat do školy, pokud Google nevyhovuje.
Nechápu, proč sem píšete poznámky, které nijak nesouvisí s touhle debatou. Nebo on se tu objevil někdo takový, o kom píšete? A mimochodem, je hezké, že googlení pojmu doporučuje ten, kdo předtím tvrdil, že používání špatných pojmů nevadí, protože přeci všichni vědí, o co jde.

Pochopils to špatně. Doporučuji obrátit se na M.Prýmka  ;)
Klidně se na něj obraťte, já vám v tom nijak nebráním.

To je zásadní neznalost terminologie. Swift taky nemá šablony, jen generika, a přitom proměnné pro vyšší typy má.
To je právě ten problém, když někdo jenom zaslechne nějaké termíny, ale vůbec netuší, o co vlastně jde. Kdybyste těm termínům rozuměl, tak byste pochopil, že jsem nepsal nic o tom, že šablony jsou podmínkou pro „proměnné pro vyšší typy“. Šablony jsou jenom jeden z možných způsobů implementace, nikoli jediný. A Java prostě šablony implementované nemá, takže není dobrý nápad to šablony nazývat – i když se generiky v Javě často používají stejným způsobem, jako šablony v C++. Právě proto je dobré znát tu terminologii (ne jen slovíčka, ale jejich význam), protože to, že se dva různé nástroje mohou používat ve stejných případech, neznamená, že jsou stejné.

3848
Vývoj / Re:Template on template v Javě
« kdy: 17. 08. 2017, 13:49:13 »
Pokud někdo nedokáže odpovědět na jasně danou otázku ani nedokáže uvést konkrétní příklad, místo toho odkáže „na web“, většinou to bývá příznakem toho, že někde zaslechl pár pojmů, ale vůbec netuší, o čem je řeč.

Jestli jsem to ale pochopil správně, tazatel by v Javě chtěl napsat něco takového:

Kód: [Vybrat]
class Animal<T> extends T {
}

To v Javě opravdu napsat nejde. A mimochodem to ukazuje, proč je „šablona“ špatný název pro Java generiky. „Šablona“ je označení po kód, na základě kterého kompilátor vygeneruje správný kód pro všechny potřebné typy (proto šablona). A proto tohle v Javě nejde napsat, protože generika nejsou šablony pro vytváření kódu, a jsou to jen upravené běžné typy. V terminologii Javy tedy tazatel nechtěl generiku nad generikou, ale chtěl vytvořit potomka typového parametru.

3849
Vývoj / Re:Template on template v Javě
« kdy: 17. 08. 2017, 13:14:44 »
Já tam pořád ten rozdíl nevidím. Třeba tohle je podle mne šablona nad šablonou:

Kód: [Vybrat]
class StringMap<T> implements Map<String, T> {
}
Není, protože T v mapě je už vázaná typová proměnná. Map je funkcí nad dvěma typy.
A jak by to vypadalo, kdyby T nebyla vázaná typová proměnná? Jakou by to mělo funkci/význam? Jak by se to lišilo od stavu, kdy T je vázaná typová proměnná? Ideální by bylo ukázat to na nějakém konkrétním případu – mám tyhle tři třídy, chtěl bych udělat tohle, ale nemůžu, místo toho můžu jen zkopírovat kód.

3850
Odkladiště / Re:Zapamatovatelné heslo a slovníkový útok
« kdy: 17. 08. 2017, 13:11:49 »
Tohle je jediné spolehlivé řešení do doby, než autor password manageru dostane zálusk na vaše hesla nebo se mu tam někdo nabourá.
To, že autor password manageru ten program upraví, aby mu hesla poslal, ještě neznamená, že si tu upravenou verzi nainstaluju a že mu dovolím hesla odeslat. To samé platí, pokud by se někdo naboural autorovi do účtu a tu upravenou verzi vydal za něj.

Myslel jsem, že víte, že neexistuje žádné spolehlivé řešení...
Já jsem myslel, že tohle ví každý, a že to tedy není nutné psát do každého komentáře.

3851
Sítě / Re:IPv6 ease of use
« kdy: 17. 08. 2017, 13:04:19 »
Chci to udělat tak, abych nemusel zhoršovat parametry, které jsou pro mě důležité. Ty parametry jsou pro mě bezpečnost (vnitřní zařízení nejsou přímo přístupná, vždy musí jít přes prostředníka, který vytvoří jednu bezpečnostní vrstvu navíc), soukromí (vnější síť neví nic o uspořádání vnitřní), nezávislost (vnitřní síť neví nic o uspořádání vnější) a jednoduchost použití. Pokud to IPv6, jako novější a doufejme i lepší protokol, splňuje, tak chci vědět, jak to v něm mám udělat.
Dobře. A které parametry má tedy to řešení splňovat – tyhle, které jste vyjmenoval, a nebo ty nesmyslné parametry, které jste jmenoval, jako privátní IP adresy a NAT?

Proto jsem psal, "předpokládejme pro účely hledaného řešení, že náhrada za IPv6 proběhla a teď ta síť běží na nějakých privátních IPv6 adresách."
Budu tedy brát, že platí ty parametry, které jsem citoval výše. Takže žádné privátní IPv6 adresy, ale normální IPv6 síť – link local adresy a adresy od všech upstream providerů.

Otázka byla, která ty požadavky splňuje.
Routovat IPv6 bude umět každý IPv6 router – kdyby to neuměl, nebude to router.

Opět. Na to jsem se neptal. Ptal jsem se, která krabička to umí.
IPv6 firewall by měl umět každý domácí IPv6 router. Pokud to nějaký neumí, nekupujte ho. Pokud chcete konkrétní jména těch, co to umí, tak třeba Turris Omnia, Ubiquiti nebo Mikrotiky.

Citace
Ve vnitřní síti se změní prefix sítě.
To je pro mě zhoršení.
Proč? Link local adresy máte pořád stejné, adresy zařízení jsou pořád stejné, změnil se jen prefix sítě. Není to v rozporu s těmi vašimi požadavky, je to úplně normální. Pokud je to pro vás zhoršení, asi něco děláte špatně.

Je mi jedno, jak to bude udělané, ale chci, aby to splňovalo požadavky, které jsem popsal. Pokud to půjde bez NATu, klidně. Nastínil jsem řešení na bázi NATu, protože ho znám a vím, jak v něm požadavky vyjádřit. Pokud se to řeší jinak, tak to udělejme jinak, netrvám na NATu. Ale nechci se dostat do situace, kdy je nové řešení v důležitých aspektech zhoršením proti řešení starému, a už vůbec se nechci dostat do situace, kdy to zhoršení pozoruji ve všech důležitých aspektech.
Já jsem vám popsal řešení pomocí IPv6, které tu vaši první skupinu požadavků (kterou jsem citoval na začátku komentáře) splňuje. Nesplňuje to tu druhou nesmyslnou sadu požadavků.

Kdo bude to DNS spravovat? Co když DNS řešení z jakéhokoliv důvodu vypadne? Sorry, tohle je pro mě zhoršení.
Spravovat to bude router, tak jako to dělá při použití IPv4. Ptal jste se na user friendly řešení, tak jsem vám takové nabídl. Pokud z nějakého důvodu chcete uživatelsky nepřívětivé řešení, nikdo vás nenutí DNS používat.

Zatím se snažím (neúspěšně) zjistit, jaké to řešení je, potom ho rád použiju.
Problém je, že jste si vymyslel nějaké svoje nesmyslné řešení, a na tom trváte.

3852
Vývoj / Re:Template on template v Javě
« kdy: 17. 08. 2017, 12:16:46 »
Já tam pořád ten rozdíl nevidím. Třeba tohle je podle mne šablona nad šablonou:

Kód: [Vybrat]
class StringMap<T> implements Map<String, T> {
}

3853
Sítě / Re:IPv6 ease of use
« kdy: 17. 08. 2017, 09:32:52 »
Takže bych opravil, že nepotřebuji nutně, aby se IPv6 chovala stejně jako IPv4, ale určitě chci snadné použití v režimu "vnější síť se nedozví nic o struktuře vnitřní sítě, vnitřní síť je zcela nezávislá na síti vnější". Na rozdíl od mnoha diskutujících zde to považuji za přirozený požadavek. A upřímně řečeno mě docela překvapuje, že tolik lidí to jako přirozený požadavek nevidí.
Myslím, že drtivá většina lidí tenhle požadavek považuje za přirozený. A IPv6 ten požadavek splňuje. Vnější síť vidí akorát do, že daný síťový prefix je routován na daný router. Co s tím ten router dělá a jaká je struktura sítě za routerem už z venku nikdo nevidí (na základě IPv6 – samozřejmě to někdo může zkoumat na základě obsahu paketů, stejně jako u IPv4). Stejně tak je vnitřní síť nezávislá na vnější síti – každé zařízení má linkovou IPv6 adresu a pak několik veřejných IPv6 adres (typicky alespoň jednu pro každé upstream spojení, které daná síť má).

Zrovna tenhle váš požadavek má IPv6 řešeno podstatně lépe, než IPv4 – v IPv6 máte linkové adresy, máte k dispozici IPv6 mobilitu, máte k dispozici privacy extensions.

3854
Sítě / Re:IPv6 ease of use
« kdy: 17. 08. 2017, 08:52:02 »
předpokládejme pro účely hledaného řešení, že náhrada za IPv6 proběhla a teď ta síť běží na nějakých privátních IPv6 adresách.
Proč? Chcete to udělat správně tak, jak to má být s IPv6, nebo to chcete co nejvíc zašmodrchat, abyste dokázal, jak je ta IPv6 k ničemu?

1) IP adresy v lokální síti se nezmění.
To půjde těžko, když jste tam měl IPv4 adresy a teď chcete IPv6 adresy.

2) Všechny packety směřující ven budou mít IP adresu krabičky, ne vnitřních počítačů. Vnitřní adresy se nikde ve vnějším provozu neobjeví.
NAT můžete dělat i na IPv6. Ale asi to nebudou umět běžné krabičky koupené v Lidlu za 20 Kč v akci, protože pro domácí síť rozhodně není NAT s IPv6 potřeba.

3) Všechny příchozí packety jsou na krabičce zahozeny, leda že by byly odpověďmi na některý odchozí packet.
To záleží na nastavení firewallu.

4) Když budu potřebovat, aby některý vnitřní počítač přijímal vnější požadavky, tak krabičce řeknu, že packety se zadanými vlastnostmi má přeposílat na vnitřní IP adresu X a port Y. Není přímý přístup z vnější sítě do vnitřní, vše musí jít přes krabičku, a není jediný vztah mezi vnější a vnitřní IP adresou ani portem je uvnitř konfigurace krabičky.
Když pominu ten nesmyslný NAT, opět jen nakonfigurujete firewall, kde nastavíte, které IPv6 adresy a porty ve vnitřní síti mají být dostupné z internetu.


5) Pokud budu potřebovat změnit providera, tak v krabičce přenastavím konfiguraci vnější sítě a je hotovo. Nic jiného měnit nebudu a ve vnitřní síti se nezmění absolutně nic.
Ve vnitřní síti se změní prefix sítě. Nebo si můžete koupit PI adresy, ale proč byste to dělal…

Tj. klasický PAT, ale na IPv6.
Jak už jsem psal, musíte si vybrat, jestli to chcete dělat tak, jak to má být s IPv6, pak to bude i user-friendly – a nebo jestli chcete dokazovat, že to jde i s IPv6 udělat úplně blbě.

tedy že například výměna krabičky půjde snadno, ale změní se mi prefix IP adres. A to je z mého pohledu zásadní problém s IPv6 - není to user friendly.
User friendly je používání DNS, takže vás nějaká změna prefixu IPv6 adres vůbec netrápí.

Ale pevně doufám, že jsem sto let za opicemi a už to je vyřešené, protože dříve nebo později budu do IPv6 muset jít.
Ano, vyřešené to je. Akorát to řešení musíte použít.

Otázka je položená na to, jak mám s IPv6 zařídit splnění stanovených požadavků, a to, jestli jsou ty požadavky hloupé, nesmyslné, nebezpečné nebo cokoliv jiného, je off-topic. Díky.
To si musíte vybrat. Nemůžete zároveň chtít hloupé a nesmyslné požadavky, a zároveň chtít, aby řešení bylo user friendly. Hloupé a nesmyslné požadavky vždy vedou k hloupým a uživatelsky nepřátelským řešením.

3855
Vývoj / Re:Template on template v Javě
« kdy: 17. 08. 2017, 08:31:23 »
https://www.tutorialspoint.com/design_pattern/template_pattern.htm :-)
To je návrhový vzor šablona / template. To je něco jiného než template v C++ i než generiky v Javě. Dá se implementovat i bez C++ šablon i bez Java generik, jak je ostatně vidět na příkladech uvedených v odkazu.

Návrhový vzor šablona se zřetězit („šablona nad šablonou“) dá. Generika nad generikou se také udělat dá (alespoň s tím, co si pod „generika nad generikou“ představím já). Takže jestli se dá v Javě udělat „šablona nad šablonou“ se tu můžeme dohadovat do nekonečna, protože si každý může sám určit, co tím „šablona nad šablonou“ myslí. A nebo tazatel napíše, co vlastně řeší za problém.

Stran: 1 ... 255 256 [257] 258 259 ... 375