OpenSearch (Wikipedie) byl vydán ve verzi 3.0. Podrobnosti v poznámkách k vydání. Jedná se o fork projektů Elasticsearch a Kibana.
PyXL je koncept procesora, ktorý dokáže priamo spúštat Python kód bez nutnosti prekladu ci Micropythonu. Podľa testov autora je pri 100 MHz približne 30x rýchlejší pri riadeni GPIO nez Micropython na Pyboard taktovanej na 168 MHz.
Grafana (Wikipedie), tj. open source nástroj pro vizualizaci různých metrik a s ní související dotazování, upozorňování a lepší porozumění, byla vydána ve verzi 12.0. Přehled novinek v aktualizované dokumentaci.
Raspberry Pi OS, oficiální operační systém pro Raspberry Pi, byl vydán v nové verzi 2025-05-06. Přehled novinek v příspěvku na blogu Raspberry Pi a poznámkách k vydání. Pravděpodobně se jedná o poslední verzi postavenou na Debianu 12 Bookworm. Následující verze by již měla být postavena na Debianu 13 Trixie.
Richard Stallman dnes v Liberci přednáší o svobodném softwaru a svobodě v digitální společnosti. Od 16:30 v aule budovy G na Technické univerzitě v Liberci. V anglickém jazyce s automaticky generovanými českými titulky. Vstup je zdarma i pro širokou veřejnost.
sudo-rs, tj. sudo a su přepsáné do programovacího jazyka Rust, nahradí v Ubuntu 25.10 klasické sudo. V plánu je také přechod od klasických coreutils k uutils coreutils napsaných v Rustu.
Fedora se stala oficiální distribucí WSL (Windows Subsystem for Linux).
Společnost IBM představila server IBM LinuxONE Emperor 5 poháněný procesorem IBM Telum II.
Byla vydána verze 4.0 multiplatformního integrovaného vývojového prostředí (IDE) pro rychlý vývoj aplikaci (RAD) ve Free Pascalu Lazarus (Wikipedie). Přehled novinek v poznámkách k vydání. Využíván je Free Pascal Compiler (FPC) 3.2.2.
Podpora Windows 10 končí 14. října 2025. Připravovaná kampaň Konec desítek (End of 10) může uživatelům pomoci s přechodem na Linux.
Řešení dotazu:
13.11.2012 21:39
xkucf03 | skóre: 49
| blog: xkucf03
víc věcí na jednom IP, kdy bylo potřeba jednu věc přesunout jinam...Tohle bych spíš řešil na úrovni DNS: V jednu chvíli to budeš mít třeba tak, že sql.example.com, www.example.com, smtp.example.com a imap.example.com budou směřovat na jednu IP adresu a později to můžeš rozdělit a dát poštu, databázi a weby na různé servery. DNS mi přijde ta správná vrstva abstrakce, na které by se to mělo řešit – naopak na IP adresu bych se dlouhodobě nijak nevázal – souvisí prostě s aktuálním fyzickým umístěním služby v síti a může se změnit s přechodem k jinému ISP nebo s přestěhováním serveru do jiné budovy. Rozhodně bych IP adresu nebral jako něco na celý život – doménové jméno klidně ano. Naopak jako náhrada virtuálhostů a SNI ten větší počet IP adres smysl dává a asi je to správná cesta, byť třeba může mít nějaké dětské nemoci v současnosti.
13.11.2012 21:53
xkucf03 | skóre: 49
| blog: xkucf03
13.11.2012 21:56
xkucf03 | skóre: 49
| blog: xkucf03
14.11.2012 01:50
pavlix | skóre: 54
| blog: pavlix
Tohle bych spíš řešil na úrovni DNS:Já bych to taky při tvorbě standardů a software řešil na úrovni DNS SRV záznamů, ale i kdyby byla vůle, tak se to bude prosazovat deset a více let.
14.11.2012 10:15
pavlix | skóre: 54
| blog: pavlix
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
getaddrinfo() - naštěstí už je tam v aktuálních verzích cache na výsledek.
# ifconfig vether0 create up # ifconfig vether0 description "potazmo" # ifconfig vethet0 inet6 alias "..." # ifconfig bridge0 add vether05) V Linuxu vam nikdo nebrani napsat si vlastni program, ktery s tim manipuluje pres netlink(7) a v textovem souboru drzi textove popisky. S pouzitim ip(8) to jde klidne v shellu. 6) Zopakujte si, co je referencni ISO/OSI model. Na sitove vrstve nereste multiplexing sluzeb.
Tak jsem se pro jistotu znovu podíval do e1000 driveru a trochu jsem vás mystifikoval. Tak, jak jsem popisoval, to funguje pro unicast adresy. U multicast je tam ještě hashovací tabulka (bitmapa), konkrétně u e1000 se z MAC adresy vezme 12-bitový hash (konkrétní blok 12 bitů) a nastaví se příslušný bit v bitmapě. Předpokládám, že karta pak přijímá multicasty, jejichž hash cílové adresy má bit nastavený.
V každém případě by ale mělo platit, že ať máte adres kolik chcete, neměl byste přijít o pakety, které máte dostat.
V datacentru máme střední tok okolo 300Mbit/s, tedy okolo 20 000 packetů/s (spodní odhad). Pokud by každý vyvolal IRQ... :)
)
Tak, jak jsem popisoval, to funguje pro unicast adresy.Jeste bych dodal (ac to je snad vsem zucastnenym jasne), ze tady se mysli unicastove MAC adresy, a pro vsechny zminovane IPv6 adresy se stejne pouzije jedina MAC adresa.
ad 3) síťová karta má hodně co do činění. Pro každou IPv6 adresu se musí přihlásit do ethernetové multicast skupiny,No, tohle ma dve mozne reseni: 1) (hloupe) pridelovat ty IPv6 adresy tak, aby se prislusne solicited-node multicast adresy vsechny mapovaly na jednu L2 multicast adresu. V jednom /64 prefixu je spousta mista, takze 24 bitu je mozne zafixovat. 2) (chytre) pridelovat ty 'sluzebni' IPv6 adresy nikoliv na ethernetovy iface (a z rozsahu dane ethernetove site), ale na loopback ci dummy iface (a ze samostatneho rozsahu). To koneckoncu lepe odpovida tomu, ze ty adresy nejsou adresy rozhrani ale sluzeb. Pak je mozne je nezavisle migrovat i mezi vzdalenymi stroji, akorat bude treba to osetrit v routovani.
14.11.2012 02:29
pavlix | skóre: 54
| blog: pavlix
14.11.2012 10:33
pavlix | skóre: 54
| blog: pavlix
Na druhou stranu, budu muset dělat routy /128 takže každý (kdo nebude dostatečně "daleko") bude muset mít několik tisíc routovacích pravidel versus ethernet, kde se to bude dělat v HW vrstvě se složitostí O(1) a v kernelu neighbor table (taky předpokládám O(1))Tak tohle tvrzení bych potřeboval nějak podložit. Že by směrovací tabulka byla by definition zpracovávána méně efektivně než neighbor cache. Nejsem hardwarář, ale třeba na úrovni té sítě je to přesně naopak Jak se budou předávat informace o směrování nastavím na routerech a nemusím ladit parametry na každém (i virtuálním) stroji. Můžu agregovat adresy a zase z nich separovat výjimky. Vtip je v tom, že třeba na virtuálech ty routy nebudu udržovat vůbec. Když to nebude dobře chodit, tak můžu fyzickým strojům předřadit nějaký slušný hardware (L3 switch s podporou OSPF). Já neříkám, že je řešení na L2 vrstvě špatné a dokonce ani že je horší… ale obě mají značně odlišné vlastnosti a hodí se asi na různé věci.
A co se týče více lokalit, tak tam si stejně moc nepomůžu, protože pokud nebudu mít pod kontrolou routování na dostatečné úrovni, tak se zbláznim*.Já bych se spíš zbláznil, kdybych mezi lokalitami tuneloval ethernet o řádově tisících až desetitisících individuálních adres. Nedej bože, aby tam byl ještě záložní tunel mezi jinými kusy hardware. Takže i v případě celých lokalit propojených na L2, bych volil OSPF a routing.
Tak tohle tvrzení bych potřeboval nějak podložit. Že by směrovací tabulka byla by definition zpracovávána méně efektivně než neighbor cache. Nejsem hardwarář, ale třeba na úrovni té sítě je to přesně naopakTo vyplývá ze selského rozumu. Routing table má složitější pravidla, takže se prochází docela hodně a až pak se cachuje to vlastní routing decision. Navíc v té routing table budou předem všechny routy, zatímco do neighbor table se budou dostávat jen stroje, se kterými se reálně komunikuje. A to, že ethernet směrování/forwarding je rychlejší, protože se dělá v HW vrtsvě switche snad není potřeba rozvádět.
Jak se budou předávat informace o směrování nastavím na routerech a nemusím ladit parametry na každém (i virtuálním) stroji.Výměny informací se bude muset účastnit každý, kdo bude mít nějaké ty adresy na svém loopbacku. Agregace by v principu moc účinná být neměla, protože jde právě o to mít možnost každou jednu adresu vzít a odsunout, takže časem by bylo vyjímek nezanedbatelné množství...
Já bych se spíš zbláznil, kdybych mezi lokalitami tuneloval ethernet o řádově tisících až desetitisících individuálních adres. Nedej bože, aby tam byl ještě záložní tunel mezi jinými kusy hardware.Ale vždyť já o ničem takovém nemluvím. Stěhování strojů mezi lokalitami je tak "složitá" věc, že odůvodní změnu DNS. Prostě celé co řeším je, mít v rámci jedné lokality, dokonce i jen jednoho eth segmentu pro každou instanci služby předem vlastní IP, tak abych minimalizoval zásahy do DNS, když už mám možnost mít tolik adres.... Dokonce ani neřeším, jestli stroje budou virtuální nebo reálné, to je na této úrovni irelevatní. Ale když už jsme u těch zajiímavých řešení problematiky více lokalit, virtualizace ethernetu je taky poměrně zajímavá věc, ale to jen tak na okraj...
15.11.2012 07:46
pavlix | skóre: 54
| blog: pavlix
To vyplývá ze selského rozumu.Právě.
Navíc v té routing table budou předem všechny routy, zatímco do neighbor table se budou dostávat jen stroje, se kterými se reálně komunikuje.Tak trochu jsem předpokládal, že ty služby budou převážně živé. Takže například router, který sloužý jako výchozí brána, by musel aktivně komunikovat se všemi.
A to, že ethernet směrování/forwarding je rychlejší, protože se dělá v HW vrtsvě switche snad není potřeba rozvádět.Uznávám, že určitý rozdíl v ceně tam bude :).
Výměny informací se bude muset účastnit každý, kdo bude mít nějaké ty adresy na svém loopbacku.s/musí/může/
Ale vždyť já o ničem takovém nemluvím. Stěhování strojů mezi lokalitami je tak "složitá" věc, že odůvodní změnu DNS.Už se to stalo součástí kontextu. V rámci jedné lokality se většina zajímavých vlastností řešení s OSPF neuplatní. Pokud by se vzal pouze případ fyzických serverů a jednoho jediného routeru, tak se nejspíš OSPF neuplatní vůbec. On každý z nás kromě faktů vychází rovněž i z praxe, která může pro každého vypadat trochu odlišně.
Dokonce ani neřeším, jestli stroje budou virtuální nebo reálné, to je na této úrovni irelevatní.Má to velký vliv na potřeby škálování a taky na odpovědnost za routing. U virtuálních strojů velkou část odpovědnosti přebírá hostitel, zatímco u fyzických to bude na separátním routeru. Ten rozdíl je natolik podstatný, že ho nemůžu ignorovat.
15.11.2012 07:24
pavlix | skóre: 54
| blog: pavlix
Huh... Routovací démon jako nástroj pro "automatizaci správy" to umí ten ptáček koukám víc než quagga, a tím nemyslím počet implementovaných směrovacích protokolů ;). No k tématuNetřeba se chytat každého slovíčka. Směrovací démon skutečně odlehčí administrátorům od správy směrovacích tabulek.
1. další služba na každém serveru a na zařízeních mezi servery.Která může plnit svůj účel lépe než obrovská ARP cache s přímým dotazováním.
2. v případě velké L2 (což datová centra většinou jsou) bude velká neighbor table v ospf a související problémy (hello paket s řádově stovkami neighbor).Celý smysl nasazení OSPF je v tomto případě omezit velikost spravovaných L2 segmentů. Snažíš se kombinovat nevýhody obojího.
3. routovací tabulka s /128 adresami (s nemožností agregace adres protože přece "migrace jednotlivých adres kamkoliv v rámci vlastní sítě") ... to jste někde implementoval? v datovém centru? Všiml jste si té takové "mírné" degradace výkonu routerů? Nebo je možné, že znáte router který se s tím popere, zkuste prozradit který to je :)Jako kdyby ta ARP cache agregovaná byla :).
4. musí se řešit nejen aby fungoval směrovací protokol, ale aby bylo jeho nastavení dobře synchronizováno s věcmi jako jsou privátní VLAN.To je snad samozřejmost.
Ono by toho bylo asi i více... ale už podle těch 4 věcí je to s praktičností na štíru.Ani bych neřekl.
Netřeba se chytat každého slovíčka. Směrovací démon skutečně odlehčí administrátorům od správy směrovacích tabulek.Ano, pro zjednodušení směrovací protokoly mimo jiné jsou... snížení náročnosti na správu a automatická reakce na změny v síti... ale "automatizace" je trochu silné slovo (o tom se mluví v souvislosti třeba s SDN) ... to už bychom rovnou mohli říct, že Switch má nástroj pro "automaticaci správy" a tím je tabulka mac adres.
Která může plnit svůj účel lépe než obrovská ARP cache s přímým dotazováním.jasně nebudeme chytat za slovo a v tichosti pomineme, že ARP cache u IPv6 není. ARP cache má jednu výhodu... schválně je rozdíl mezi vyhledáváním v tabulce (CAM např.) a v trie? Je rozdíl mezi aktualizací ARP cache a aktualizací trie? Nicméně jsem schopen připustit, že existuje nějaká hraniční hodnota počtu IP adres na jednom zařízení kdy už se vyplatí routing oproti přímé komunikaci v rámci subnetu.
Celý smysl nasazení OSPF je v tomto případě omezit velikost spravovaných L2 segmentů. Snažíš se kombinovat nevýhody obojího.Bohužel obrovské L2 domény jsou realitou datových center a serveroven a důvodem není nedostatek IPv4 adres. Vývoj v této oblasti (v oblasti L2) jenom naznačuje, že se toho jen tak nezbavíme. Schválně akademická otázečka, kolik je routerů a kolik switchů v serverovnách, čemu které z těch zařízení slouží a proč tomu tak je? Prostě kdyby se dalo L2 vyměnit za L3 s OSPF směrováním jenom mávnutím BIRDu tak tu nemáme věci jako TRILL. Změnit L2 doménu na L3 síť není jenom o nalezení adresy koncového zařízení... z nezmíněných věcí - co takhle multicast.
Jako kdyby ta ARP cache agregovaná byla :).Pochopil jsem správně že srovnáváte agregaci z důvodu velikosti ARP tabulky s agregací z důvodu zefektivnění směrování? Nebo má ARP cache nějaké výkonnostní problémy, které mi unikají?
To je snad samozřejmost.To jako z důvodu zjednodušení administrace se přidá jiná administrace minimálně v poměru 1:1?
15.11.2012 10:01
pavlix | skóre: 54
| blog: pavlix
Ano, pro zjednodušení směrovací protokoly mimo jiné jsou... snížení náročnosti na správu a automatická reakce na změny v síti... ale "automatizace" je trochu silné slovo (o tom se mluví v souvislosti třeba s SDN) ... to už bychom rovnou mohli říct, že Switch má nástroj pro "automaticaci správy" a tím je tabulka mac adres.Když se nutně vyžíváš v chytání za slovo, tak tabulka MAC adres je pouhá datová struktura.
jasně nebudeme chytat za slovo a v tichosti pomineme, že ARP cache u IPv6 není.Detail.
Nicméně jsem schopen připustit, že existuje nějaká hraniční hodnota počtu IP adres na jednom zařízení kdy už se vyplatí routing oproti přímé komunikaci v rámci subnetu.O vysokých počtech je i původní dotaz.
Bohužel obrovské L2 domény jsou realitou datových center a serveroven a důvodem není nedostatek IPv4 adres.Je to levnější, alespoň v tuto chvíli.
Změnit L2 doménu na L3 síť není jenom o nalezení adresy koncového zařízení...Tady se nebavíme o změně L2 na L3, ale o dvou možných návrzích sítě.
z nezmíněných věcí - co takhle multicast.A co takhle anglická královna?
Pochopil jsem správně že srovnáváte agregaci z důvodu velikosti ARP tabulky s agregací z důvodu zefektivnění směrování? Nebo má ARP cache nějaké výkonnostní problémy, které mi unikají?Poukazuju na to, že mezi vyhledáním čísla v tabulce a vyhledáním čísla v tabulce není až takový rozdíl. Jasně, směrovací tabulka má délku prefixu, ale pokud by single-address směrovací záznamy získaly velkou oblibu, nebyl by problém jejich vyhledávání optimalizovat stejným způsobem.
To jako z důvodu zjednodušení administrace se přidá jiná administrace minimálně v poměru 1:1?Ne.
2. v případě velké L2 (což datová centra většinou jsou) bude velká neighbor table v ospf a související problémy (hello paket s řádově stovkami neighbor).Tohle lze resit mnoha zpusoby. Tenhle use case je tak trivialni, ze OSPF je overkill, RIP by uplne stacil. V pripade pouziti OSPF je mozne pouzit pro dane rozhrani ptmp rezim namisto broadcast rezimu, tim odpadne prevazna vetsina problemu spojenych s mnoho neighbors na jedne L2 siti.
3. routovací tabulka s /128 adresamiNetusim, jak jsou na tom hardwarove routery s podporou /128 adres, je mozne, ze to maji implementacne odflaknute. Pro 'stredni zatez' (cca Gbps) je mozne bez potizi pouzit linuxovy sw router, kteremu je to jedno (protoze namisto TCAM pouzivaji route cache).
4. musí se řešit nejen aby fungoval směrovací protokol, ale aby bylo jeho nastavení dobře synchronizováno s věcmi jako jsou privátní VLAN.Pokud se bavime o tomto jednoduchem pripadu, kdy mame jedinou L2 sit, tak to je vcelku irelevantni.
14.11.2012 01:56
pavlix | skóre: 54
| blog: pavlix
Jedna z výhod této výhody by měla být to, že je možné každé službě přiřadit jednu IP adresu, kterou bude mít "na dosmrti".To je zajímavá teorie. Ale jo, adresu z rozsahu může mít napořád. Jinak nevidím důvod sypat hromadu adres na vnější rozhraní, ale když už tak opravdu na loopback a na eth rozhraní posadit toho BIRDa, jak píše ondra. Stejně tam ethernet jako mezivrstva bude, tak proč to zbytečně trápit.
Správa IP adres - na takové množství už asi obyčejné ip addr nebude moc pohodlné, ideální by bylo, kdyby se daly všecky tyto adresy nějak označit - něco jako "secondary", ale jen ve smyslu administraceZbytečné. Příkaz
ip umí vše, co je potřeba, tedy přidat adresu, smazat adresu či zahodit všechny. Shellovský či třeba Pythonovský for cyklus zařídí zbytek.
To je zajímavá teorie. Ale jo, adresu z rozsahu může mít napořád. Jinak nevidím důvod sypat hromadu adres na vnější rozhraní, ale když už tak opravdu na loopback a na eth rozhraní posadit toho BIRDa, jak píše ondra. Stejně tam ethernet jako mezivrstva bude, tak proč to zbytečně trápit.jak jsem psal, především mi jde o migraci v rámci různých strojů, klasický životní cyklus domén a doméniček... Na druhou stranu nevidím důvod, proč by tohle mělo být nějaké "trápení", pokud něco víceméně vyžaduje, aby síť měla minimálně 2^64 adres, tak mít na interfacu 2^10 adres mi nepřipadá zas tak divné... A z hlediska sítě je to přašť jako uhoď, jen ten interface může být trochu náročnější na provoz... A i pokud se s nějakou rozumnou síťovkou dostanu do stavu, že interface bude poslouchat všechny ethernet multicasty, tak to nebude nic tak extra šíleného...
Zbytečné. Příkaz ip umí vše, co je potřeba, tedy přidat adresu, smazat adresu či zahodit všechny. Shellovský či třeba Pythonovský for cyklus zařídí zbytek.Jestli je to nebo není zbytečné, to si posuzovat netroufám. Ale to, že to ip všecko zvládne, to je mi jasné. Stejně tak je mi jasné, že jako takové to moc přehledné nebude, takže bude třeba nějaký ten skriptík. A pokud by něco obdobného už bylo k dispozici, proč to dělat znovu, že? Nejde mi ani tak o nahozeni/shozeni jako o nějakou práci s tím (výpis, kontrola, atd...) Ale to je opravdu minimální problém něco na to sesmolit...
14.11.2012 10:42
pavlix | skóre: 54
| blog: pavlix
pokud něco víceméně vyžaduje, aby síť měla minimálně 2^64 adresPříliš bujná fantazie. Nikdo nevyžaduje, aby měla síť minimálně 2^64 adres, ale aby mohly být adresy odvozeny od EUI. Horní mez délky prefixu je důsledkem požadavku na zapouzdření 64-bitového EUI identifikátoru.
A i pokud se s nějakou rozumnou síťovkou dostanu do stavu, že interface bude poslouchat všechny ethernet multicasty, tak to nebude nic tak extra šíleného...Čistě mezi námi, pokud na fyzickém stroji provozuješ bridge a nefiltruješ multicastové skupiny, tak stejně použiješ promiskuitní režim a vše si zpracuješ na procesoru.
Nejde mi ani tak o nahozeni/shozeni jako o nějakou práci s tím (výpis, kontrola, atd...) Ale to je opravdu minimální problém něco na to sesmolit...Pak už poslouží Netlink a knihovny nad ním. Pracuje se s tím docela hezky. A do budoucna D-Busový interface NetworkManageru.
pokud něco víceméně vyžaduje, aby síť měla minimálně 2^64 adresJak je to dlouho, co to RFC je obsolete, už skoro rok? Ostatně těch diskuzí, zda používat /64 i tam, kde se EUI používat nebude bylo nespočetně, to nemá smsyl opakovatPříliš bujná fantazie. Nikdo nevyžaduje, aby měla síť minimálně 2^64 adres, ale aby mohly být adresy odvozeny od EUI. Horní mez délky prefixu je důsledkem požadavku na zapouzdření 64-bitového EUI identifikátoru.
Čistě mezi námi, pokud na fyzickém stroji provozuješ bridgeAle já nechci používat bridge (pokud to nebude potřeba), prostě eth0 a na něm tunu adres... Samozřejmě, pokud to ulehčí to, že si udělám bridge a do něj dam něco virtuálního, tak proč ne, ale podmínka to neni. Spíš naopak, dělal bych to, jen kdyby to za to stálo....
14.11.2012 11:28
pavlix | skóre: 54
| blog: pavlix
Jak je to dlouho, co to RFC je obsolete, už skoro rok?Nemám tušení, které z mnoha RFC máš namysli, ani jakou to má mít souvislost s tématem.
Ostatně těch diskuzí, zda používat /64 i tam, kde se EUI používat nebude bylo nespočetně, to nemá smsyl opakovatRovněž nevidím souvislost s tím, jak vzniklo pravidlo, že unicastové adresy budou dělené v půlce.
Ale já nechci používat bridge (pokud to nebude potřeba), prostě eth0 a na něm tunu adres... Samozřejmě, pokud to ulehčí to, že si udělám bridge a do něj dam něco virtuálního, tak proč ne, ale podmínka to neni. Spíš naopak, dělal bych to, jen kdyby to za to stálo....Proto taky ta věta začíná slovem pokud.
Tiskni
Sdílej:
