Organizace Open Container Initiative (OCI) (Wikipedie), projekt nadace Linux Foundation, vydala Runtime Specification 1.3 (pdf), tj. novou verzi specifikace kontejnerového běhového prostředí. Hlavní novinkou je podpora FreeBSD.
Nový open source router Turris Omnia NG je v prodeji. Aktuálně na Allegro, Alternetivo, Discomp, i4wifi a WiFiShop.
Na YouTube a nově také na VHSky byly zveřejněny sestříhané videozáznamy přednášek z letošního OpenAltu.
Jednou za rok otevírá společnost SUSE dveře svých kanceláří široké veřejnosti. Letos je pro vás otevře 26. listopadu v 16 hodin v pražském Karlíně. Vítáni jsou všichni, kdo se chtějí dozvědět více o práci vývojářů, prostředí ve kterém pracují a o místní firemní kultuře. Můžete se těšit na krátké prezentace, které vám přiblíží, na čem inženýři v Praze pracují, jak spolupracují se zákazníky, partnery i studenty, proč mají rádi open source a co
… více »Na čem pracují vývojáři webového prohlížeče Ladybird (GitHub)? Byl publikován přehled vývoje za říjen (YouTube).
Jeff Quast otestoval současné emulátory terminálu. Zaměřil se na podporu Unicode a výkon. Vítězným emulátorem terminálu je Ghostty.
Amazon bude poskytovat cloudové služby OpenAI. Cloudová divize Amazon Web Services (AWS) uzavřela s OpenAI víceletou smlouvu za 38 miliard USD (803,1 miliardy Kč), která poskytne majiteli chatovacího robota s umělou inteligencí (AI) ChatGPT přístup ke stovkám tisíc grafických procesů Nvidia. Ty bude moci využívat k trénování a provozování svých modelů AI. Firmy to oznámily v dnešní tiskové zprávě. Společnost OpenAI také nedávno
… více »Konference Prague PostgreSQL Developer Day 2026 (P2D2) se koná 27. a 28. ledna 2026. Konference je zaměřena na témata zajímavá pro uživatele a vývojáře. Příjem přednášek a workshopů je otevřen do 14. listopadu. Vítáme témata související s PostgreSQL či s databázemi obecně, a mohou být v češtině či angličtině.
Byl vydán Devuan 6 Excalibur. Přehled novinek v poznámkách k vydání. Kódové jméno Excalibur bylo vybráno podle planetky 9499 Excalibur. Devuan (Wikipedie) je fork Debianu bez systemd. Devuan 6 Excalibur vychází z Debianu 13 Trixie. Devuan 7 ponese kódové jméno Freia.
Společnost Valve aktualizovala přehled o hardwarovém a softwarovém vybavení uživatelů služby Steam. Podíl uživatelů Linuxu poprvé překročil 3 %, aktuálně 3,05 %. Nejčastěji používané linuxové distribuce jsou Arch Linux, Linux Mint a Ubuntu. Při výběru jenom Linuxu vede SteamOS Holo s 27,18 %. Procesor AMD používá 67,10 % hráčů na Linuxu.
Řekněme že jsem šel párkrát okolo, když takové věci stavěli jiní, a rád utrousím pár hraběcích rad... plus něco jsem přece jenom okusil na vlastní pěst.
Předně ta síť není zas až tolik rozsáhlá, aby bylo potřeba za každou cenu oddělovat jednotlivá patra na jednotlivých křídlech od sebe pomocí routerů - myslím v rámci jediné "skupiny uživatelů kteří se smí navzájem vidět". Routery bych uměle vkládal až v případě, že by Vám ta síť začínala klekat pod náporem broadcastů od jednotlivých pracovních stanic, nebo že by to z nějakého důvodu nebylo správcovatelné (lidi by si nastavovali IPčka podle svého, připojovali do sítě černé DHCP routery apod. - a zjišťujte pak skrz L3 a L2, odkud ten bordel přišel).
Jestli potřebujete optimalizovat počet boxů v infrastruktuře a přitom posloužit několika skupinám lidí (volný WiFi internet pro guesty, plus třeba nějaké privátní WiFi sítě, plus k tomu N navzájem oddělených sítí v LANce) tak se nestyďte vyrobit VLAN pro každou skupinu, kterou má smysl oddělit nebo přinejmenším odroutovat. Pokud jeden box oblouží více VLAN, tím líp. Více virtuálních sítí (zde ESSIDů) může servírovat taky jediné APčko na jediném rádiovém kanálu. Můžete mít jeden ESSID otevřený každému, jiné ESSIDy uzavřené = šifrované WPA2 (pro každý ESSID jiný klíč, ovšem v rámci ESSIDu klíč shodný na všech APčkách) a třeba ještě přihodit individuální autentikaci klientů přes 802.1x proti Radiusu (odhaduji že opět může mít každý ESSID svůj vlastní realm nebo i celý rádiusový server, kdyby si to chtěl nájemník servírovat sám, nebo si to nechat od Vás forwardovat podle realmu apod. - v rámci jednoho kampusu možná zbytečná složitost, a složitosti je třeba se pokud možno vyhýbat).
Pokud potřebujete routovat mezi LANkami, zvažte použití jednoho centrálního routeru (nebo několika málo), ten router nemusí být zježený fyzickými porty, můžete routovat mezi VLAN subinterfejsy (do routeru vede L2 trunk) = "router on a stick". Opět je cílem centrální správa.
Stejně tak by mohl být centrální DHCP server - pro VLANy, které ho od Vás budou potřebovat.
V síti téhle velikosti narazíte na problém, který není snadno řešitelný: administrativní evidence topologie sítě, konfigurací jednotlivých boxů, případně automatizované hlídání, kde jste udělal v konfiguraci chybu (neřku-li generování low-level konfigurací z nějakého klikacího toolu) - snažte se to vymyslet pokud možno tak, aby infrastruktura fungovala pokud možno hromadně a samospádem, s minimem individuální konfigurace, s minimem rutinní práce pro individuální konfiguraci (extrémem je zřizování a rušení individuálních úprav konfigurace pro jednotlivé uživatele). Např. pokud se APčka budou moci navzájem lišit v konfiguraci pouze svou vlastní IP adresou pro management, tak tím líp.
Další věc je management rádiového pásma. Máte jenom pár kanálů. Můžete se pokusit o něco na způsob buněčné struktury, tzn. aby aspoň sousední APčka (či nějaké ostrůvky APček v meshi nebo WDS) měly nepřekryvné kanály. Ale v takhle velkém objektu ve dvou rozměrech to bude problém
Optimální rozložení (kompromis typu "nejmenší zlo") bude záviset např. na tloušťce stropů mezi patry a přepážek v rámci patra (resp. na jejich schopnosti tlumit signál).
Virtuální ESSIDy nad sdíleným rádiovým kanálem šetří rádiové pásmo.
Viděl jsem tovární halu, kde v pásmu 5 GHz byly plné všecky rádiové kanály, na každém v průměru 4 APčka (fyzické boxy) a docela to i fungovalo. Fakt je, že tam jeli v podstatě telnet, netahali tam větší objemy dat - jinak by je rychle praštila "aloha".
Dál podle značek:
Cisco je Cisco. Pokud znáte Cisco, je to pro Vás ta správná stavebnice.
Může mít svoje mouchy... jako všecko. Cisco umí rychlý roaming podpořený sítí (tuším jak proprietární, tak 802.11r).
Mikrotik vypadá hodně zajímavě. Slyšel jsem drb, že zatímco holé routerboardy jsou spolehlivé, celé SoHo krabičky od Mikrotiku časem hnijou... to se možná týká spíš klientů, vy budete řešit AP.
Routerboardy umí většinou napájení přes 24V PoE - o starost míň, místo prašivých adaptérků všude možně po baráku můžete mít silnější a kvalitnější centrální měnič. Nemusí (nemůže?) se jednat zrovna o drahý PoE switch, pro nestandardní PoE na nižším napětí se dělají pasivní patch panely, ke kterým připojíte vnější zdroj, společný pro několik zásuvek.
Co do schopností je RouterOS hodně dobrý - a vzhledem k počtu uživatelů i relativně odladěný. Pro konfiguraci máte na výběr "QuickSetup" wizarda, obecné klikací rozhraní, nebo příkazovou řádku - a taky export+import konfigurace.
RouterOS umí VLANy a virtuální ESSIDy a mezi nimi virtuální bridge, umí autentikaci klientů přes 802.1x (kdyby bylo nedejbože třeba).
Pokud jsem schopen posoudit, RouterOS neumí 802.11r.
Pokud jsem měl možnost si všimnout, RouterOS nemá v oblasti WiFi problém naservírovat Vám v roli AP jakýkoli kanál - regulatory blázinec nechává v kompetenci admina.
OpenWRT zdědilo z Linuxu nemilou vlastnost zvanou CRDA, která Vám může docela házet klacky pod nohy co do volby rádiových kanálů (může vám tu množinu docela omezit). Pokud umíte CRDA vykostit, gratuluji. Jinak OpenWRT umí ve svém konfiguračním systému pobrat multi-ESSID konfiguraci včetně odlišných šifrování pro různé ESSIDy, umí i 802.1x proti rádiusu. Oboje jsou to zřejmě vlastnosti použitého hostapd. Tušímže hostapd v development verzi OpenWRT už umí i 802.11r (rychlý handover klienta mezi APčky podpořený sítí, dle otevřeného standardu) čímž je OpenWRT opět napřed před všemi možnými uzavřenými firmwary, které na SoHo APčkách chodí (a patrně i před Mikrotikem). Ale on ten handover chodí docela dobře i bez podpory sítě, klienti si prostě při přeskoku dohodnou šifru znova od začátku a pár vteřin jim to trvá (s "erkem" údajně 20 ms). Sledovat sílu signálu od více AP a patřičně reagovat umí klienti sami od sebe.
Pokud se bavíme o OpenWRT na TP-Linku, tak SoHo APčka TP-Link neumí od přírody PoE, dá se sice přidat splitter, ale nativní vstup APčka bere max. cca 12 V. Zas na druhou stranu minimum je asi 5V, uvnitř je spínaný měnič na 3.3V, takže lehký úbytek na vedení příliš nebolí.
Společné a závěrečné poznámky:
Souhlasím s podvozkem TP-Link pro OpenWRT. Aktuální generace TP-Linků má hodně úsporný SoC od Ahterosu - asi dva modely jsem nedávno pitval a hodně se mi líbilo, co jsem našel uvnitř. Úžasně čistá deska, málo součástek.
Bohužel TP-Link ani Routerboardy nepoužívají solid-polymer elyty, ale relativně obyčejné "vodnaté" (zajisté low-esr) - takže mají zabudovanou nejistou životnost. I když ten aktuální Atheros topí *opravdu* maličko, ona ta nejistá budoucnost taky může znamenat 5 let... V těch dvou pitvaných kusech jsem elyty preventivně vyměnil za solid-poly
Jsou jich tam asi 2-4 kusy.
TP-Link, Mikrotik i Cisco (na klientech) pokud vím používají hardware Atheros - zjevně vědí proč.
Jako omni antény na patro bych doporučil nějaké tyčové s velkým ziskem a úzkým "talířovitým" lalokem - velký výběr značky Alfa mají na Aspě. Kde to bude mít smysl tak případně sektorovou anténu. Nepoužíval bych příbalové bičíky. Příbalový bičík má relativně nižší zisk daný tím, že září "do celého kulového prostoru". Pokud použijete delší svislou tyč, bude Vám zářit jenom po patře - takže můžete mít větší dosah po patře a menší crosstalk mezi patry navzájem. Možná je to pitomost... záleží na přesném prostorovém uspořádání budovy, tloušťce zdí/přepážek apod. Chtělo by to předem test na místě.
V baráku větším než malém stejně bude muset být metalická strukturka svedena do několika lokálních "metalických rozvoden" s lokálními switchi, protože si to vynutí limit na 100 m délku kabelu. Pokud to má mít nějakou centrální podobu v celém baráku, bude tam navrch ještě nějaká optická páteř pro Ethernet mezi rozvodnami, plus nějaká metalická páteř pro staré metalické technologie (DSL, telefony apod.).
Ještě mě napadá, že "router on a stick" je sice hezká věc, a třeba L3 switch umí i routovat, ale L3 switche často neumí moc firewallovat... U obyčejné kancelářské LANky pro pár desktopů a malý server je router potřeba jenom k tomu, aby tu síťku připojil na internet. Někteří nájemníci třeba nebudou chtít sdílet router do internetu se sousedy, tzn. aby je od sousedů dělil jediný IP hop v cizí správě... Plus možná někdo by si rád nechal přivést vlastní L2 VPN... nebo i klasický VPN tunel, ale "po svém". Čili dalo by se uvažovat jednak o něčem ve stylu "firewall on a stick" (Linux, BSD i Windows dneska umí VLANové subinterfejsy na trunkovém rozhraní), druhak opět nechat prostor ve stojanech pro všelijaké krabičky, co si který nájemník přitáhne (a pak zase odtáhne).
Možná nakonec nějaká mohutná centrála pro celou budovu ani nebude potřeba, pokud se menší plochy pronajímají odděleně. Popravdě řečeno, spousta méně špičkových nájemních kancelářských prostor nemá pořádnou strukturku - počítá se s tím, že si to nájemníci nějak zařídí (třeba hodí po podlaze) a s konektivitou do světa může být taky problém. Pokud nemovitost nemá technicky osvíceného vlastníka a místní telco operátoři jsou nenažraní, není se čemu divit...
Možná nakonec těch pár sítí, které mají pokrývat celou budovu, nebude potřebovat silnou centrálu, spíš jenom 2-3 VLANy a na centrále třeba šestnáctiportový switch pro "rozbočení trunků po budově". Většina routování a firewallování může být distribuovaná po budově v pronajatých prostorách.
Nakonec zásadní věc: chtěl bych Vám popřát, ať má ten barák aspoň připravené svislé kanály pro slaboproudé stoupačky. Tohle je často zanedbáno i v novostavbách. Možná zejména v novostavbách. Držím palce.
Tiskni
Sdílej: