Po Canonicalu a SUSE oznámil také Red Hat, že bude podporovat a distribuovat toolkit NVIDIA CUDA (Wikipedie).
TrueNAS (Wikipedie), tj. open source storage platforma postavená na Linuxu, byl vydán ve verzi 25.10 Goldeye. Přináší NVMe over Fabric (NVMe-oF) nebo OpenZFS 2.3.4.
Byla vydána OpenIndiana 2025.10. Unixový operační systém OpenIndiana (Wikipedie) vychází z OpenSolarisu (Wikipedie).
České základní a střední školy čelí alarmujícímu stavu kybernetické bezpečnosti. Až 89 % identifikovaných zranitelností v IT infrastruktuře vzdělávacích institucí dosahuje kritické úrovně, což znamená, že útočníci mohou vzdáleně převzít kontrolu nad klíčovými systémy. Školy navíc často provozují zastaralé technologie, i roky nechávají zařízení bez potřebných aktualizací softwaru a používají k nim pouze výchozí, všeobecně známá
… více »Během tradiční ceremonie k oslavě Dne vzniku samostatného československého státu (28. října) byl vyznamenán medailí Za zásluhy (o stát v oblasti hospodářské) vývojář 3D tiskáren Josef Průša. Letos byly uděleny pouze dvě medaile Za zásluhy o stát v oblasti hospodářské, druhou dostal informatik a manažer Ondřej Felix, který se zabývá digitalizací státní správy.
Tor Browser, tj. fork webového prohlížeče Mozilla Firefox s integrovaným klientem sítě Tor přednastavený tak, aby přes tuto síť bezpečně komunikoval, byl vydán ve verzi 15.0. Postaven je na Firefoxu ESR 140.
Bylo oznámeno (cs) vydání Fedora Linuxu 43. Ve finální verzi vychází šest oficiálních edic: Fedora Workstation a Fedora KDE Plasma Desktop pro desktopové, Fedora Server pro serverové, Fedora IoT pro internet věcí, Fedora Cloud pro cloudové nasazení a Fedora CoreOS pro ty, kteří preferují neměnné systémy. Vedle nich jsou k dispozici také další atomické desktopy, spiny a laby. Podrobný přehled novinek v samostatných článcích na stránkách Fedora Magazinu: Fedora Workstation, Fedora KDE Plasma Desktop, Fedora Silverblue a Fedora Atomic Desktops.
Elon Musk oznámil (𝕏) spuštění internetové encyklopedie Grokipedia (Wikipedia). Zatím ve verzi 0.1. Verze 1.0 prý bude 10x lepší, ale i ve verzi 0.1 je podle Elona Muska již lepší než Wikipedia.
PSF (Python Software Foundation) po mnoha měsících práce získala grant ve výši 1,5 milionu dolarů od americké vládní NSF (National Science Foundation) v rámci programu "Bezpečnost, ochrana a soukromí open source ekosystémů" na zvýšení bezpečnosti Pythonu a PyPI. PSF ale nesouhlasí s předloženou podmínkou grantu, že během trvání finanční podpory nebude žádným způsobem podporovat diverzitu, rovnost a inkluzi (DEI). PSF má diverzitu přímo ve svém poslání (Mission) a proto grant odmítla.
Balík nástrojů Rust Coreutils / uutils coreutils, tj. nástrojů z GNU Coreutils napsaných v programovacím jazyce Rust, byl vydán ve verzi 0.3.0. Z 634 testů kompatibility Rust Coreutils s GNU Coreutils bylo úspěšných 532, tj. 83,91 %. V Ubuntu 25.10 se již používá Rust Coreutils místo GNU Coreutils, což může přinášet problémy, viz například nefunkční automatická aktualizace.
Nase 2 servery si navzajom rozumeju preco Apache si s nimi nerozumie?Otázka spíš je jaktože si ty dva servery rozumějí. Jak to máš nastavené? To se ti nějak podařilo opravdu nabindovat dva programy na stejný port? Když přijde nové spojení, jak se rozhoduje, který z nich ho dostane? Osobně jsem tohle vždycky řešil tak, že jsem servery nabindoval třeba na :8001, :8002 a :8003 a na portu 80 (443) spustil nějakou proxy (haproxy, nginx, lighttpd…), která podle domény, cesty atd. spojení předala na jeden z těch serverů.
<offtopic>
No, tohle by chtělo malé upřesnění pro úplnost.
Nabindovat dva programy na stejný port samozřejmě lze. Klíčová slova, jak toho docílit:
setsockopt(...)SOL_SOCKETSO_REUSEADDRTohle^^^ (na obou socketech) zajistí, že se dá pak zavolat bind(...) dvakrát na stejnou adresu.
Háček je „jenom“ v tom, že takové nastavení je irelevantní pro situaci popsanou v dotazu, protože neslouží / nemá sloužit ke sdílení portu několika servery (resp. nevím, jak je v takovém případě definované chování), nýbrž ke sdílení portu několika klienty, kteří pak volají connect(...) na různé adresy.
Protože TCP spojení je čtveřice (adresa, port, adresa, port), je jasné, že změnou jednoho prvku (kteréhokoliv) se dá vytvořit další spojení. Multiplexování na straně serveru je známější — accept(...) —, zatímco multiplexování na straně klienta (výše uvedený socket option) je méně známé / méně používané / méně snadno použitelné.
Otázka za 100 bodů by byla, co se stane, když se přes sockety se SO_REUSEADDR bind(...)nuté na stejnou adresu připojím dvakrát k témuž serveru (adresa, port). Odpověď neznám; vždy jsem klientský multiplexing používal jen s různými servery. Kdo zná odpověď, třeba ji sem pro zajímavost postne. 
</offtopic>
Ne, každý klientský socket je jiné spojení a směřuje jen na ten jeden server, kam vede. Spojení jsou rozlišitelná, protože jedno je [adresa_klienta, port_klienta, adresa_serveru_1, port_serveru_1] a druhé je [adresa_klienta, port_klienta, adresa_serveru_2, port_serveru_2].
Pojmem „multiplexing“ jsem myslel, že se na jednom portu dá udržovat víc oddělených TCP spojení, nikoliv že se něco rozesílá víckrát (což se neděje).
Je to v principu stejné jako psát na straně serveru do socketu, který předtím vrátil accept(...). Taky se to pošle jenom tomu jednomu klientovi, který je na daném spojení, přestože adresa:port serveru třeba zrovna obsluhuje naráz spoustu klientů.
Spojení od accept(...) nepotřebuju nijak poznávat, v tom okamžiku už je vše potřebné zařízeno a identifikováno.
Pokud otevírám víc spojení z jednoho klienta (stejná adresa a stejný port, pomocí SO_REUSEADDR), musím (jako vždy) při connect(...) vědět, kam se připojuju, a jednotlivá spojení by se měla lišit — jinými slovy, alespoň adresy serverů nebo alespoň porty serveru/ů by se měly lišit. (Pokud se neliší, k takové situaci směřuje kvízová otázka v mém posledním odstavci výše. Nikdy jsem takovou situaci nezkoušel. Tipuju, že kernel by měl tohle detekovat a vrátit chybu při connect(...).)
Mam na jednom porte pustene 2 HTTP serveryNemáte. (Musely by být každý na jiné IP adrese, a to podle dalšího textu nemáte.) Možná řešení jsou dvě: 1. Zjistěte, jak to doopravdy máte, a pro nový server to udělejte stejně. 2. Dát před ty servery reverzní proxy server (nejčastěji se používá nginx, případně HAproxy, šlo by pro to použít i Apache), který bude podle pravidel (doména, URL apod.) směrovat požadavky na příslušné backend servery. Ve skutečnosti jsou nejspíš řešení 1 a 2 ta samá.
Co takhle použít něco jako name-based virtual hosting z Apache jako „frontend + proxy + třetí server“ a ty dva C++ servery jako backendy k tomu? Pak by to mohlo fungovat všechno naráz a ještě k tomu by ty C++ servery mohly být klidně v plaintextu, protože TLS by za ně řešil ten frontend. Name-based virtual hosting na TLS a na stejném portu funguje bez nejmenších potíží, byť zastaralá dokumentace někdy mylně tvrdí opak.
Takhke^^^ jsem měl kdysi na jednom portu asi 20 „serverů“. Tak 10 z nich byly dynamické pseudo-rádoby-domény 3. řádu (hvězdička z pohledu DNS, podadresáře s různými vlastníky z pohledu Apache) a pak tam bylo pár fixních serverů/subdomén, dva byly v Javě, jeden byl v Ruby, pak tam byl taky nějaký Git frontend v nevímčem atd. Dokonce se dalo nastavit, že některé servery se představovaly wildcard certifikátem a jiné měly svůj vlastní certifikát od jiné autority a používaly/vyžadovaly autentifikaci certifikátem. Všechno na jednom portu. (TLS samozřejmě povinné; máme 21. století atd.)
Už dávno ten setup nemám v provozu, ale Apache tohle uměl vzájemně propojit už minimálně 10 let zpátky.
Dokonce mám dojem, že to matchování URL má mnohem jemnější granularitu než „celé“ domény, takže možnostem nastavení se meze nekladou.
Tiskni
Sdílej: