Neziskové průmyslové konsorcium Khronos Group vydalo verzi 1.1 specifikace OpenXR (Wikipedie), tj. standardu specifikujícího přístup k platformám a zařízením pro XR, tj. platformám a zařízením pro AR (rozšířenou realitu) a VR (virtuální realitu). Do základu se z rozšíření dostalo XR_EXT_local_floor. Společnost Collabora implementuje novou verzi specifikace do platformy Monado, tj. open source implementace OpenXR.
Byla vydána nová verze 0.38.0 multimediálního přehrávače mpv (Wikipedie) vycházejícího z přehrávačů MPlayer a mplayer2. Přehled novinek, změn a oprav na GitHubu. Požadován je FFmpeg 4.4 nebo novější a také libplacebo 6.338.2 nebo novější.
ClamAV (Wikipedie), tj. multiplatformní antivirový engine s otevřeným zdrojovým kódem pro detekci trojských koní, virů, malwaru a dalších škodlivých hrozeb, byl vydán ve verzích 1.3.1, 1.2.3 a 1.0.6. Ve verzi 1.3.1 je mimo jiné řešena bezpečnostní chyba CVE-2024-20380.
Digitální a informační agentura (DIA) oznámila (PDF, X a Facebook), že mobilní aplikace Portál občana je ode dneška oficiálně venku.
#HACKUJBRNO 2024, byly zveřejněny výsledky a výstupy hackathonu města Brna nad otevřenými městskými daty, který se konal 13. a 14. dubna 2024.
Společnost Volla Systeme stojící za telefony Volla spustila na Kickstarteru kampaň na podporu tabletu Volla Tablet s Volla OS nebo Ubuntu Touch.
Společnost Boston Dynamics oznámila, že humanoidní hydraulický robot HD Atlas šel do důchodu (YouTube). Nastupuje nová vylepšená elektrická varianta (YouTube).
Desktopové prostředí LXQt (Lightweight Qt Desktop Environment, Wikipedie) vzniklé sloučením projektů Razor-qt a LXDE bylo vydáno ve verzi 2.0.0. Přehled novinek v poznámkách k vydání.
Nejvyšší soud podpořil novináře Českého rozhlasu. Nařídil otevřít spor o uchovávání údajů o komunikaci (data retention). Uvedl, že stát odpovídá za porušení práva EU, pokud neprovede řádnou transpozici příslušné směrnice do vnitrostátního práva.
Řešení dotazu:
12.12.2016 15:24
vencour | skóre: 56
| blog: Tady je Vencourovo
| Praha+západní Čechy
U nás provider taky hraje mrtvýho brouka. Resp. na férovku přiznal, že do toho zatím nejde. Přitom jak by bylo krásný mít všechna zařízení na světě přímo routovatelný, krásně by to pročistilo ovzduší. 
Prostě taky to nechápu proč se nepřejde na IPv6 a IPv4 se nezruší, prostě pořád budeme udržovat dva systémy......IPv6 je aktualne cista tragikomedia. Nas najvacsi zakaznik nasadil na vsetko IPv6 a pri tom clovek zisti ako slabo su pripravene aj velke spolocnosti na IPv6. Pri tom, kolko Cisco bugov sme nasli, je na mieste otazka, ci to vobec testuju. Zakaznik ma tie najvacsie a najdrahsie switche a router od Cisca ... a ... obcas sa stracaju pakety, obcas nie su dorucovane v jednom smere a obcas niesu dorucovane vobec. Dlho sa to riesilo restartom NW komponentov, nez Cisco bolo schopne dodat fungujuci patch. Bohuzial ani enterprise Linux distribucie a storage na tom nie je nijak lepsie. Linux ako taky ma(l) niekolko bugov, kedy cely NW stack proste "zhasne" a IPv6 prestane fungovat. V takom stave sa necudujem, ze ludia co mozu, tak ostavaju stale pri IPv4. Po tom co som vsetko videl v praci, tiez radsej preferujem IPv4 ...
O třetinu? Nějak zaměňuješ počty adres a jejich logaritmy, že jo.
Kromě toho jim nic nebrání mít DHCPv6 a vybodnout se na EUI48/64 identifikátory.
O třetinu? Nějak zaměňuješ počty adres a jejich logaritmy, že jo.Nezaměňuje vůbec nic, jenom umí spočítat poměr mezi 32 a 24 bity. ;)
Kromě toho jim nic nebrání mít DHCPv6 a vybodnout se na EUI48/64 identifikátory.Přidělovat adresy přes DHCPv6 lze a EUI64 se používat nemusí, ale počty zůstávají stejné, 32 bitů přidělených, 32 bitů na členění sítě a 64 bitů na stroje na jednom segmentu. :)
Nezaměňuje vůbec nic, jenom umí spočítat poměr mezi 32 a 24 bity. ;)
Ale ano, zaměňuje. Když vynechám detaily jako broadcast a zákaz nulových posledních bytů v IPv4, poměr mezi počty adres je 256:1 a pokud je mi známo, 256 není o třetinu víc než 1. Takže si nepolepší o třetinu, nýbrž 256-krát, co se týká počtu podsítí.
Přidělovat adresy přes DHCPv6 lze a EUI64 se používat nemusí, ale počty zůstávají stejné, 32 bitů přidělených, 32 bitů na členění sítě a 64 bitů na stroje na jednom segmentu. :)
Ne, to není pravda. Můžu mít klidně segment s prefixem /120, když se mi zachce, a přidělovat v něm pomocí DHCPv6 adresy. Nevím, kde se pořád dokola bere pověra o magických 64 bitech. Rozsahy můžu přidělovat, jak chci, a routovat mezi nimi, jak chci, téměř bit po bitu. Téměř, protože (hlavně) kvůli DNS se používá konvence 4-bitových skupin (ip6-arpa podsítí), ale pokud jsem ochoten oželet kompletní stateless konfiguraci, žádných 64 bitů nikde rezervovat nemusím. Právě proto jsem psal, že se člověk může vybodnout na EUI64, pokud chce, a rozdělit si síť po svém.
Takže … počty adres nezůstávají stejné. Kdyby tohle někdo tvrdil v roce 2005, chápal bych, že je to nějaká přechodná neinformovanost. Jenže když už bude ten rok 2017, jak říká původní dotaz, přijde mi to spíš smutné.
Ale ano, zaměňuje.V tom případě nemá smysl, abych se tvými plky dále zabýval. Měj se dobře.
Jak nás učí kupecké počty, 32-bitových čísel je 256-krát víc než 24-bitových. Tak už to na světě chodí. S tím nic nenaděláš. Můžeš to označovat za plky, ale ono to tak bude pořád.
Jako bys předem předpokládal, že cílem je někoho „dostat“. To mě překvapuje. Mně nikdy o nic takového nešlo. (A nebyl jsem to já, kdo začal něco označovat za plky.)
Uvažujme tedy prakticky. Máme o třetinu víc bitů (32 místo 24). To je dost zásadní výhoda, protože lze výšku celé síťové hierarchie zvýšit o celé jedno 8-bitové „patro“, případně o dvě 4-bitová „patra“, když na to přijde. Protože těch 32 bitů, o kterých se bavíme, je v prvních 64 bitech IPv6 adresy a lze v podstatě vždy počítat s jejich statickým přidělením, jsou dvě 4-bitová patra věc snadno proveditelná a dokonce pro leckteré síťové topologie vhodná — faktor větvení 15, když se to tak vezme. Záleží na tom, k čemu ta síť má sloužit a jak se v ní nejčastěji routuje. (Síť typu kancelář bude mít velký faktor větvení, síť typu distribuovaný HPC systém bude chtít nižší.) Ale dá se říct, že každé 4 bity navíc jsou dost zásadní zlepšení.
Tohle^^^ omezení na 32 bitů flexibility ovšem platí pouze za předpokladu, že někdo striktně vyžaduje bezestavovou konfiguraci na základě EUI64. Bez tohoto požadavku (a za použití DHCPv6) je flexibilita v podstatě neomezená, protože i dalších 64 bitů se dá použít a rozdělit prakticky libovolně. Patra té hierarchie by měla být 4-bitová, pokud má na tu síť nějak logicky navazovat zpětné DNS mapování. Jinak se ale jejich počtu a uspořádání meze příliš nekladou.
Ano, jsou zařízení, která neumí nic jiného než trvat na EUI64 a vyžadovat (současnou podobu) privacy extensions. Jsou zařízení, která po velkém N let od standardizace DHCPv6 umí jen jeho zanedbatelnou podmnožinu a dokonce i router advertisement chápou jen tak zčásti, aby se neřeklo. Tohle je ale především problém vejce a slepice. Dokud někdo nezačne hlásit bugy a požadovat, aby zařízení implementovala rozumnou podmnožinu IPv6, nikoliv pouze „aby se neřeklo“ podmnožinu, a dokud se sítě budou snažit přizpůsobit neschopným zařízením, moc se toho nezmění.
To je dost zásadní výhoda, protože lze výšku celé síťové hierarchie zvýšit o celé jedno 8-bitové „patro“, případně o dvě 4-bitová „patra“, když na to přijde.No vždyť. IPv4, /8: můžeš mít 4 4bitová patra (/24 potřebuješ na koncovou síť) IPv6, /32: můžeš mít 8 4bitových pater. Takže uznávám, že mi nedošlo to s tou sítí, a polepšíš si dvakrát, ne jen o třetinu. Pořád to je podle mě docela málo. No a proto jsem se zeptal, jestli je v praxi bez problémů provozovat sítě menší než /64.
Takže pozdější změně přídělů se zejm. firemní zákazníci budou bránit jak čert kříži. Je fakt, že velkou část opruzu s přečíslováním řeší správné používání DNS a teoreticky by LANky měly být připravené na dual-homing, kde se změna používaného přídělu může dít pravidelně / automaticky / bezobslužně - ale i tak může být spousta jiných míst v konfiguraci aplikací apod., kde uvázne IPv6 adresa a po změně to přestane fungovat... čili nenutit zákazníky zbytečně do přečíslování. Tzn. přidělovat a routovat jednotlivé /64 ? Snese tohle OSPF ve /32 síti?
Modulo zákazník s geograficky zdvojenou konektivitou, ale to zabíhám do ohavných detailů. Navíc pokud je to v rámci AS, tak se moc neděje, OSPF to vezme, maximálně se lze dohadovat, zda ke každé konektivitě jeden nebo dva CPE routery = zákazník bude chtít CPE routery ve svém vlastnictví a ISP taky...
Mimochodem, jak vlastně ISP číslujou "spojovací" síť? Myslím poslední míli. Pokud je to multipoint L2 ethernet tak asi /64 jasná volba, ale pokud je to point to point? Unnumbered jako za starých časů na sériových linkách? To by mohlo zabrat třeba i na PPPoE/PPPoA. Přímou enkapsulaci IP do AAL5 VC-MUX tuším nad DSL nikdo nepoužívá... A co když je ta poslední míle point to point ethernet?
imochodem, jak vlastně ISP číslujou "spojovací" síť? Myslím poslední míli.V zasade jsou tri rozumne postupy: 1) Pouzit jen link-local adresy (a tedy defacto unnumbered linka). To funguje dobre s automatickyma nastrojema (napr. DHCP-PD nebo routovaci software), ale byva to neprakticke pri statickem routingu. 2) 'Vykousnout' jednu /64 z prefixu prideleneho zakaznikovi a pouzit ji na spojovacku. Myslim, ze je pro to i nejaka extenze do DHCP. 3) Pouzit na spojovacku /64 z ULA rozsahu. To je trochu hack, ale proti pouziti regulerniho rozsahu to ma tu vyhodu, ze i komunikace ze zakaznikova CPE ven pouzije jako zdrojovou adresu adresu pridelenou zakaznikovi, nikoliv adresu na spojovacce. Vsechny ty postupy funguji bez ohledu na technologii (multipoint ethernet, ptp ethernet, klasicka ptp linka, ...).
třeba "regionální bloček" rozumně malý, aby "ztráty z fragmentace" nebyly moc velké a přitom těch bločků nebylo moc, a ty "regionální bločky" v případě potřeby přidávat.Tohle je špatně, IPv6 bylo navrženo tak, aby se nějaké „ztráty z fragmentace“ vůbec neřešily. Vždyť se koncovým uživatelům má přidělovat minimálně /64… Pokud chcete mít regionální bloky, měl byste to naopak mít navržené tak, aby pro každý region byl jen jeden blok s takovou rezervou, aby pokud možno nikdy nebylo nutné přidávat další.
pokud bude mít zákazník "interní" LANku číslovanou veřejnými adresami, bál bych se, že bude řvát při jakémkoli pokusu o přečíslováníTo taky neodpovídá moc návrhu IPv6. Ano, přečíslovávat zbytečně není dobré. Ale IPv6 počítá s tím, že každé zařízení bude mít více IPv6 adres a že se budou měnit. Pokud chce zákazník v rámci sítě používat pevné adresy, má přece k dispozici link local adresy.
Ještě mi došlo, ohledně nápadu členit adresní prostor uvnitř AS regionálně... koncem devadesátých let, když jsme v mém bývalém zaměstnání prodávali placený dial-up, pokud si správně pamatuju, každý přilogovaný dialupista dostal na access routeru (Cisco) podle loginu /32 nebo /30 případně tuším i malý veřejný bloček routovaný dovnitř, dal se tak realizovat i dial backup třeba pro větší LAN nebo DMZ s veřejným Cčkem. (Na V.34 asi nic moc, ale byli mezi zákazníky borci, kteří měli dial backup přes ISDN PRI.) Statické příděly pro dial-in byly udržované v radiusové databázi (klasické schéma, jak jinak)... a takto vznikající jednotlivé drobné routy byly vidět v OSPF minimálně v rámci poměrně velkého OSPF area, nebo spíš na celém národním backbonu (bylo jedno, na který POP v rámci ČR se člověk přihlásí, dostal skrz IPCP a Radius pokaždé tutéž veřejnou adresu). Dokonce si snad matně vybavuju, že zpočátku byly IPv4 adresy uvnitř AS nějak regionálně rozparcelované mezi naše POPy, a v určitý moment je správci páteře sesypali na jednu hromadu. Pravda je, že jsme zákazníků měli řádově míň, než mají dnešní telecomy a kabelovky - ale taky se od té doby o dost posunula kapacita routovacích tabulek.
Chci říct, že bych si s nějakým hierarchickým regionálním členěním moc nelámal hlavu, protože uroutovat uvnitř AS i docela velký počet routů asi není problém. Spíš bych se snažil držet příděly rozdělené do velkých bloků nějak podle velikosti, aby mi během doby nedocházelo k fragmentaci (jako to dělá alokátor heapu v libc). Tzn. v takovém uspořádání je velikost routovací databáze přímo úměrná počtu zákazníků, na nějaké eleganci regionálního rozparcelování adresního prostoru vůbec nezáleží. Asi je na zvážení počet zákazníků, jejich charakter a last-mile technologie, kalibr routerů uvnitř AS.
Dál je to jistě otázka velikosti mé sítě a "struktury zákaznické báze" na startu IPv6, jaký očekávám další růst/vývoj. V tuhle chvíli je myslím trh už dost nasycený a konsolidovaný, LIRy dlouhodobě spíš fúzují než aby se štěpily, nové maličké LIRy neustále vznikají "na zelené louce", jednou za pár let se třeba vystřídá technologie připojování masového SoHo trhu, u firemních zákazníků s jednotlivě řešenou technologií poslední míle a zakázkovou adresací je to jedno...
Možná si konkrétní styl agregace adresního prostoru vynutí konkrétní použitá značka/model použité accessové technologie pro drobné zákazníky. U DSL operátora nebo v kabelovce jsem nikdy nepracoval, takže nevím. Zrovna u DSL a kabelu asi není moc co řešit, protože se nepočítá, že zákazník bude s modemem cestovat Ačkoli když se zamyslím u DSLka ještě nad LLU... jako že kde je ten L3 spojovák vlastně zakončený, ono to s geografií nemusí moc souviset - prostě bych asi přidělil blok/pool adres na accessový L3 router Naopak statická veřejná adresa na mobilu (SIMce) musí být z hlediska backbonu asi žůžo. Asi vím proč je to venku ve světě (na IPv4) spíš rarita. (Což mi volně asociuje, že bývala dost legrace třeba zařídit lokální peering mezinárodních mamutích sítí, které mají po celém světě jediné AS... ale to už je jiná pohádka.)
Ještě si matně vybavuju, jak jsme tady u nás řešívali místní vs. meziměstská volání, POPy v krajských městech... a když jsme se potkali s někým zvenčí, tak se nám smál, že celý ten náš státeček je jak venku jedno větší město = místní telefonní obvod. Možná se podobné srovnání nabízí v měřítkách DSL sítí a kabelovek, potažmo v měřítkách velikostí routovacích tabulek IGP.
Jako bys předem předpokládal, že cílem je někoho „dostat“. To mě překvapuje. Mně nikdy o nic takového nešlo. (A nebyl jsem to já, kdo začal něco označovat za plky.)Mě taky, nic takového jsem nepsal. Nicméně končím diskuzi a budu si pamatovat, že mám být příště opatrnější v reakci.
Když vynechám detaily jako broadcast a zákaz nulových posledních bytů v IPv4, poměr mezi počty adres je 256:1 a pokud je mi známo, 256 není o třetinu víc než 1. Takže si nepolepší o třetinu, nýbrž 256-krát, co se týká počtu podsítí.Tak ale tady se skutečně překonáváš a začínám váhat, jestli to z tvé strany není spíše sofistikovaný humor.
Humor (ne nutně sofistikovaný) jsou výše uvedené pověry ohledně dělení adres na 64+64 bitů. Opravdu, v roce 2005 by to bylo úsměvné, dnes už je to ohrané.
Fabulace o tom, co se nestane? Sítě mi fungují a opravdu si nemyslím, že bych potřeboval jakoukoliv radu ve zdejších diskusích. Pro účely routování existuje přesně to, co si nastavím, nikoliv to, co si někdo myslí, že bych si měl nastavit. Granularita je po 4 bitech (chci-li zpětné DNS mapování) a prakticky libovolná v jiných případech.
64+64 bitů je konvence, která se dodržuje v podstatě zbytečně, protože asi tak 99% výhod, které měla nabízet, buď nikdo nepodporuje, nebo je nikdo nikdy ani nenaimplementoval. Neexistuje žádný praktický důvod mít oddělený identifikátor sítě a identifikátor zařízení. To byly velké sny 90. let, ze kterých toho moc nezbylo.
Nemám v principu nic proti 64+64, samozřejmě. Jen mi přijde zbytečné šířit fámy, že to jinak nejde/nefunguje. Záleží na okolnostech a na implementaci IPv6 v zařízeních, kde software nemám úplně pod kontrolou.
Neřeším, v podstatě. Kde mám kontrolu nad softwarem, tam si dám libovolnou DHCPv6 šílenost. (Například virtuální switch s 10 virtuálními mašinami na něm.) Kde nad softwarem nemám kontrolu, tam musí být 64/64 konfigurace. (Například WiFi s Androidem, s Apple zařízeními a s dalšími nepřizpůsobivými občany.)
Nevím, k čemu tady kdo došel.
Zkrátka, IPv4 je nepoužitelná zastaralá věc, zatímco IPv6 je rozumně použitelný protokol. Ano, možná IPv6 nestojí za nic, protože už je taky hodně starý (1995), ale pořád je nesrovnatelně lepším řešením než IPv4 z roku 1975, ve kterém kdysi kdosi zvolil nedostatečnou délku adres jen tak od oka jako dočasný akademický experiment a pak už to tak nechal. U IPv6 je adresní prostor dostatečně velký a není potřeba se příliš vehementně zabývat tím, jestli má struktura adres nějaký hlubší smysl. Původně to měl být 64-bitový unikátní identifikátor místa a 64-bitový unikátní identifikátor zařízení, ale to se prostě neujalo a život jde dál.
Pokaždé, když se někdo v poradně už posté zeptá, jak může v tom IPv4 odpadu propojit dvě domácí sítě, aby mohl přímo komunikovat mezi jednotlivými počítači, je čím dál jasnější, že IPv6 je nezbytnost, ať už za něco stojí nebo ne.
O třetinu? Nějak zaměňuješ počty adres a jejich logaritmy, že jo.Nikoli. Kubeček píše o hierarchii.
Detaily neznám, ke mně se dostane jen to, co je podstatné pro řešení bugů. :-) (Tedy v jednom případě, ten druhý byla zmínka tady (čas 22:18, pokud by nefungoval správně ten link).)
Jinak je potřeba mít na paměti, že u IPv6 /32 neznamená 2^32 adres, ale 2^32 koncových sítí, což může být dost velký rozdíl.
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
14.12.2016 09:07
14.12.2016 16:50
14.12.2016 21:32
18.1.2017 12:20
10.a.b.c a 192.168.d.e, tedy 32 bitů na členění sítě a 8 bitů na stroje v rámci segmentu, ale dá se v případě potřeby ještě škálovat.
Naopak malí ISP často budou mít /48 a tudíž mají na členění sítě jen 16 bitů oproti 32 bitům na IPv6 při současném způsobu členění.
Ipv6 se dodnes řešilo jako projekt v rukách akademiků a potrefených nerdů. Na úrovni schopných techniků se to řeší asi tři roky
Nemáte pocit, že si trochu odporujete? (A je to určitě víc než tři roky.)
Představa, že iot šroty v současné podobě budou přímo kontaktovatelné přes internet
Kontaktovatelnost a adresovatelnost jsou dvě různé věci.
Navíc celý TCP/IP stack je projekt akademiků a potrefených nerdů. Naštěstí vyhrál nad RSCS, IBM SNA, DECNetem a podobnými protekty techniků z firem.Ipv6 se dodnes řešilo jako projekt v rukách akademiků a potrefených nerdů. Na úrovni schopných techniků se to řeší asi tři rokyNemáte pocit, že si trochu odporujete? (A je to určitě víc než tři roky.)
Představa, že iot šroty v současné podobě budou přímo kontaktovatelné přes internetKontaktovatelnost a adresovatelnost jsou dvě různé věci.
Lidé z Wedosu by myslím mohli vyprávět :3.To jsou takoví ti jak se rozhodli dávat do firewallu pravidla pro individuální adresy a pak vydali článek jak je IPv6 na prd, protože jim firewall přetekl?
vaše ip adresa
2a07:9c0:6701:0:bd1f:2c35:fd68:ee0f
17.12.2016 23:57
Luboš Doležel (Doli) | skóre: 98
| blog: Doliho blog
| Kladensko
18.12.2016 00:00
Luboš Doležel (Doli) | skóre: 98
| blog: Doliho blog
| Kladensko
Je tu snad někdo se stock telefonem, který neumí IPv6? Národní technické muzeum se hlásí… Ještě někdo?
Ale vážně, všechny mainstreamové rádoby-chytré telefony už pár let IPv6 bez problémů podporují. Přinejmenším tedy router advertisement a jiné klasické mainstreamové způsoby konfigurace.
Otázka je, jak se telefony vyrovnají například s IPv6-only sítí, ve které bude DHCPv6 přidělovat adresy z bloku /120. Tam si umím představit, že by to mohlo skřípat, pokud telefony trvají na privacy extensions nebo na nějakých dalších typech adresové anarchie s iluzí bezpečnosti.
21.6.2017 10:20
Max | skóre: 72
| blog: Max_Devaine
16.8.2019 13:55
Luboš Doležel (Doli) | skóre: 98
| blog: Doliho blog
| Kladensko
22.4.2017 08:39
ipv6.abclinuxu.cz has address 171.25.221.158
Původní adresa 2a01:430:10:ab::1 už asi nefunguje? (něco tam stále je, ale vypadá to na nenastavený web server)
Tiskni
Sdílej:
