Ubuntu 26.10 bude Stonking Stingray (úžasný rejnok).
Webový prohlížeč Dillo (Wikipedie) byl vydán ve verzi 3.3.0. S experimentální podporou FLTK 1.4. S příkazem dilloc pro ovládání prohlížeče z příkazové řádky. Vývoj prohlížeče se přesunul z GitHubu na vlastní doménu dillo-browser.org (Git).
Byl publikován přehled dění a novinek z vývoje Asahi Linuxu, tj. Linuxu pro Apple Silicon. Vývojáři v přehledu vypíchli vylepšenou instalaci, podporu senzoru okolního světla, úsporu energie, opravy Bluetooth nebo zlepšení audia. Vývoj lze podpořit na Open Collective a GitHub Sponsors.
raylib (Wikipedie), tj. multiplatformní open-source knihovna pro vývoj grafických aplikací a her, byla vydána ve verzi 6.0.
Nové verze AI modelů. Společnost OpenAI představila GPT‑5.5. Společnost DeepSeek představila DeepSeek V4.
Nová čísla časopisů od nakladatelství Raspberry Pi zdarma ke čtení: Raspberry Pi Official Magazine 164 (pdf) a Hello World 29 (pdf).
Bylo oznámeno, že webový prohlížeč Opera GX zaměřený na hráče počítačových her je už také na Flathubu and Snapcraftu.
Akcionáři americké mediální společnosti Warner Bros. Discovery dnes schválili převzetí firmy konkurentem Paramount Skydance za zhruba 110 miliard dolarů (téměř 2,3 bilionu Kč). Firmy se na spojení dohodly v únoru. O část společnosti Warner Bros. Discovery dříve usilovala rovněž streamovací platforma Netflix, se svou nabídkou však neuspěla. Transakci ještě budou schvalovat regulační orgány, a to nejen ve Spojených státech, ale také
… více »Canonical vydal (email, blog, YouTube) Ubuntu 26.04 LTS Resolute Raccoon. Přehled novinek v poznámkách k vydání. Vydány byly také oficiální deriváty Edubuntu, Kubuntu, Lubuntu, Ubuntu Budgie, Ubuntu Cinnamon, Ubuntu Kylin, Ubuntu Studio, Ubuntu Unity a Xubuntu. Jedná se o 11. vydání s dlouhodobou podporou (LTS).
V programovacím jazyce Go naprogramovaná webová aplikace pro spolupráci na zdrojových kódech pomocí gitu Gitea (Wikipedie) byla vydána v nové verzi 1.26.0. Přehled novinek v příspěvku na blogu.
Ř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: