Společnost Perplexity AI působící v oblasti umělé inteligence (AI) podala nevyžádanou nabídku na převzetí webového prohlížeče Chrome internetové firmy Google za 34,5 miliardy dolarů (zhruba 723 miliard Kč). Informovala o tom včera agentura Reuters. Upozornila, že výše nabídky výrazně převyšuje hodnotu firmy Perplexity. Společnost Google se podle ní k nabídce zatím nevyjádřila.
Intel vydal 34 upozornění na bezpečnostní chyby ve svých produktech. Současně vydal verzi 20250812 mikrokódů pro své procesory řešící 6 bezpečnostních chyb.
Byla vydána nová verze 1.25 programovacího jazyka Go (Wikipedie). Přehled novinek v poznámkách k vydání.
Byla vydána beta verze Linux Mintu 22.2 s kódovým jménem Zara. Podrobnosti v přehledu novinek a poznámkách k vydání. Vypíchnout lze novou XApp aplikaci Fingwit pro autentizaci pomocí otisků prstů nebo vlastní fork knihovny libAdwaita s názvem libAdapta podporující grafická témata. Linux Mint 22.2 bude podporován do roku 2029.
Provozovatel internetové encyklopedie Wikipedie prohrál v Británii soudní spor týkající se některých částí nového zákona o on-line bezpečnosti. Soud ale varoval britského regulátora Ofcom i odpovědné ministerstvo před zaváděním přílišných omezení. Legislativa zpřísňuje požadavky na on-line platformy, ale zároveň čelí kritice za možné omezování svobody slova. Společnost Wikimedia Foundation, která je zodpovědná za fungování
… více »Byla vydána verze 2.0.0 nástroje pro synchronizaci dat mezi vícero počítači bez centrálního serveru Syncthing (Wikipedie). Přehled novinek na GitHubu.
Americký prezident Donald Trump se v pondělí osobně setkal s generálním ředitelem firmy na výrobu čipů Intel Lip-Bu Tanem. Šéfa podniku označil za úspěšného, informují agentury. Ještě před týdnem ho přitom ostře kritizoval a požadoval jeho okamžitý odchod. Akcie Intelu v reakci na schůzku po oficiálním uzavření trhu zpevnily asi o tři procenta.
Byl vydán Debian GNU/Hurd 2025. Jedná se o port Debianu s jádrem Hurd místo obvyklého Linuxu.
V sobotu 9. srpna uplynulo přesně 20 let od oznámení projektu openSUSE na konferenci LinuxWorld v San Franciscu. Pokuď máte archivní nebo nějakým způsobem zajímavé fotky s openSUSE, můžete se o ně s námi podělit.
Byl vydán Debian 13 s kódovým názvem Trixie. Přehled novinek v poznámkách k vydání.
V zásadě ani nemusíte, protože to co potřebujete vy, toho tím nedosáhnete. Na bridgovaném rozhraní můžete provozovat řekněme lokální firewall a filtrovat provoz pro stroj, na němž ten bridge běží. Ale nemůžete (běžným způsobem) filtrovat provoz forwardovaný z jednoho rozhraní na druhé - ta mašina totiž neroutuje a nic neví o 3. síťové vrstvě, takže iptables si nepřijdou k lizu. Existují paketové filtry i pro bridge, ale ty fungují na 2. vrstvě a můžete filtrovat tak jako podle MAC adres a tím to hasne.
Vy se snažíte udělat switch chovající se jako router a zároveň router chovající se jako switch, pokud možno z každého trochu. Výsledek jaksi z podstaty věci nebude uspokojivý.
Ano, mezi bridgem a dalším rozhraním iptables samozřejmě fungují. Ale to jaksi nijak nesouvisí s prostým faktem, že nefungují mezi dvěma rozhraními spojenými do bridge.
Lepší nápad jak to vyřešit by se určitě našel. Ale, otázka zní, co je vlastně potřeba řešit? Co vás přivedlo k uspořádání mít dvě sítě se stejnou síťovou adresou? Pak to samozřejmě principiálně routovat nebude. Ne že by neexistovala řešení, jak to obchcat, ale spíš by mě zajímalo, proč si tímto způsobem vůbec začínat komplikovat život...
Pak je to ovšem velmi smutný příběh. Pokud nechci mít dvě sítě, ale chci mezi těmito dvěma sítěmi mít router, paketový filtr, řízení rychlosti a nevím co ještě, pak mám sakra problém.
Ocituju tady výrok tuším Pavla Kaňkovského z linuxové konfery - mám ho pověšený nad stolem, protože je velmi poučný: Spousta lidí stráví strašnou energii řešením problémů cestou, která je ve skutečnosti úplně úchylná, akorát se nějakým záhadným řízením osudu stala 'standardním řešením'. Na právě řešený problém se ten výrok vztahuje naprosto bezezbytku.
To chápu. A jsem stoprocentně přesvědčen, že vámi zvolená cesta vede do pekel, a že vytvoření nového síťového subnetu, změna nastavení QoS a tradiční routování bude v konečném důsledku podstatně méně práce, než se snažit zprznit bridge, aby dělal něco, co principiálně neumí a musí se k tomu přemlouvat celou soustavou vzájemně si zavazejících obezliček.
1. Kolega je zjevně vůl a žere psy. RFC 1912: Don't use CNAMEs in combination with RRs which point to other names like MX, CNAME, PTR a NS. ... [RFC 1034] in section 3.6.2 says this should not be done, and [RFC 974] explicitly states that MX records shall not point to an alias defined by a CNAME.
2. Říkáte-li, že RouterOS od Microsticu to umí, nemám důvod vám nevěřit. Moje žena umí vařit. Jak to všechno vzájemně souvisí?
3. Dobrá tedy. Pokud trváte na svém původním požadavku a původním zadání, pak použijte bridge-utils a ebtables. Přiznám se, že vůbec nevím, jestli na takovém řešení je možné provoz shapovat, ale za zkoušku nic nedáte.
Ale, jak nad tím tak přemýšlím, napadá mě řešení, které by mohlo být funkční a nemusíte vyrábět a routovat novou IP podsíť. Nastavte na rozhraní směrem k providerovi 10.1.1.12/28, s providerem se domluvte, ať na svém routeru (předpokládám 10.1.1.1/24) nastaví rovněž 10.1.1.1/28 + routing 10.1.1.0/24 via 10.1.1.12. Na druhém rozhraní svého stroje nemůžete nechat 10.1.1.13/24, ale nastavte tam 10.1.1.16/24 nebo vyšší. Strojům v té wireless síti musíte změnit def-gw ze stávající (asi) 10.1.1.1 na oněch 10.1.1.16 a mělo by to jet. Na tom routeru pak můžete naprosto běžným způsobem provozovat jakékoliv filtry a shapery.
Nebo samozřejmě nějak jinak podobně, ale předpokládám, že základní myšlenka je jasná, ne?
Tiskni
Sdílej: