Společnost Valve aktualizovala přehled o hardwarovém a softwarovém vybavení uživatelů služby Steam. Podíl uživatelů Linuxu dosáhl v březnu 5,33 % (Windows -4,28 %, OSX +1,19 %, Linux +3,10 %). 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 24,48 %. Procesor AMD používá 67,48 % hráčů na Linuxu.
Společnost Apple slaví padesáté narozeniny. Založena byla 1. dubna 1976.
FreeTube, desktopový klient pro YouTube využívající lokální API, byl vydán ve verzi 0.24.0. Toto velké opravné vydání implementuje SABR (Server-Based Adaptive Bit Rate), což řeší část nedávných problémů s načítáním videí z YouTube, a aktualizuje základní komponenty jako Electron nebo přehrávač Shaka Player.
Je tu opět apríl. O víkendu zmizel kamion s 12 tunami tyčinek KitKat. Firmy to využívají k aprílovým žertům. Groupon má super akci. Koupíte 1 tyčinku a dostanete 100 zdarma. Ryanair si přelepil letadla. Šéf Outlooku se ptá, proč mají v baráku 14 beden tyčinek KitKat (𝕏). Prusa Research představuje Prusa Pro ACU a vysvětluje proč přílišné sušení škodí vaším filamentům. Telefon Sony Xperia má miliónnásobný zoom (𝕏). PC.net představil Super Ultrabox 2600 se zajímavými parametry. Další aprílové novinky například na April Fools' Day On The Web.
Společnost OpenAI, která stojí za chatovacím robotem s umělou inteligencí (AI) ChatGPT, získala od investorů 122 miliard USD (2,6 bilionu Kč). Hodnota společnosti tak dosáhla 852 miliard dolarů (více než 18 bilionů Kč). Nejnovější kolo investování se stalo největší, jaké zatím firma uskutečnila, a peníze mají posílit ambiciózní plány rozšíření výpočetní kapacity, datových center a nábor talentů.
Nástroj k identifikaci občanů v on-line komunikaci s úřady byl dnes dopoledne zhruba dvě hodiny částečně nedostupný. Problém se objevil kolem 09:00 a podařilo se ho vyřešit kolem 11:00. Částečně nedostupná byla služba Národní identitní autority (NIA), problémy podle DIA (Digitální a informační agentura) ovlivňovaly přihlašování například i přes bankovní identitu. „Dostupnost NIA byla plně obnovena, přihlášení k digitálním službám
… více »Eben Upton oznámil další zdražení počítačů Raspberry Pi kvůli růstu cen pamětí a představil Raspberry Pi 4 s 3 GB RAM za 83,75 dolarů.
Anthropic patrně omylem zveřejnil celý zdrojový kód svého CLI nástroje Claude Code prostřednictvím přiloženého sourcemap souboru v npm balíčku. Únik odhalil doposud nijak nezveřejněné funkce jako je například režim v utajení, autonomní agent 'KAIROS', orchestrace multi‑agentů, režim snění nebo dokonce virtuální mazlíček Buddy. Zajímavostí je detekce naštvání uživatele pomocí obyčejného regexpu. Anthropic rychle odstranil sourcemap a vydal opravu, nicméně kopie kódu se již stihly na GitHubu rozšířit mezi prostým lidem.
Copilot automaticky vkládal do pull requestů 'propagační tipy', reklamní text se na GitHubu objevil ve více než jedenácti tisících pull requestech. Po vlně kritiky byla tato funkce zablokována a produktový manažer Tim Rogers připustil, že umožnit Copilotovi upravovat cizí pull requesty bez vědomí autorů byla chyba.
Je 31. března a tedy Světový den zálohování (World Backup Day). Co by se stalo, kdyby Vám právě teď odešel počítač, tablet nebo telefon, který používáte?
Zdravim,
bezi mi samba na debianu, a tvari se jako dva sitove disky, pro jednoduchost rekneme A a B.
Mam tam dve sitovky a potreboval bych kvuli rychlosti aby se na disk A pristupovalo pres ip eth3
a na disk B pres ip eth4. V etc/network/interfaces mam tohle:
iface eth3 inet static
network 192.168.11.0
netmask 255.255.255.0
address 192.168.11.220
gateway 192.168.11.1
broadcast 192.168.11.255
iface eth4 inet static
network 192.168.11.0
netmask 255.255.255.0
address 192.168.11.221
#gateway 192.168.11.1
broadcast 192.168.11.255
problem je ze porad jedou oba A i B pres eth3 (bez ohledu na # pred gateway). Tzn kdyz si pripojim
sitovy disk s ip 11.221 (coz by melo byt eth4) tak to funguje jen kdyz je pripojeny kabel k eth3 a jede to pres nej.
Pres eth4 nejspis nic nejede, kdyz ho odpojim nema to na nic vliv. Firewall tam neni, policy na ACCEPT.
Je nejaka finta jak to udelat funkcni, tzn. aby sitovy disk na .11.220 sel pres eth3 a .11.221 pres eth4?
Nebude problem ze u obou je stejna network? ip 192.168.11.1 je router v te siti.
Vsem dik za napady..
Co skusit spustit 2 instance(konfigurace)samby, kazdou na jinem rozhrani pres:
[global] interfaces = eth3
A v kazde instanci odkazovat na jiny disk?
NN
to zni dobre, nicmene tohle je problem spis systemu nez samby, to co jsem psal plati i pro ping - tzn kdyz jede ping na ip .11.221 (eth4)
a vytahnu kabel z eth3 tak uz si nepingnu ani tu 11.221. Uprimne receno bych cekal ze se ten system bude chovat naopak
tzn ze pres obe sitovky si pingnu libovolnou adresu (a pak by tohle bylo reseni), ale bohuzel to tak neni.
net.ipv4.conf.all.arp_ignore=1net.ipv4.conf.eth3.arp_ignore=1net.ipv4.conf.eth4.arp_ignore=1net.ipv4.conf.all.arp_announce=2net.ipv4.conf.eth3.arp_announce=2net.ipv4.conf.eth4.arp_announce=2
>Route vypise tohle:Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.20.8 * 255.255.255.252 U 0 0 0 eth0
192.168.21.8 * 255.255.255.252 U 0 0 0 eth1
192.168.11.0 * 255.255.255.0 U 0 0 0 eth4
192.168.11.0 * 255.255.255.0 U 0 0 0 eth3
default my.router 0.0.0.0 UG 0 0 0 eth3
default my.router 0.0.0.0 UG 0 0 0 eth4
a >ip route show table local scope host
local 192.168.20.10 dev eth0 proto kernel src 192.168.20.10
local 192.168.11.221 dev eth4 proto kernel src 192.168.11.221
local 192.168.11.220 dev eth3 proto kernel src 192.168.11.220
local 192.168.21.10 dev eth1 proto kernel src 192.168.21.10
local 127.0.0.1 dev lo proto kernel src 127.0.0.1
local 127.0.0.0/8 dev lo proto kernel src 127.0.0.1
a >ip route show table local
broadcast 127.255.255.255 dev lo proto kernel scope link src 127.0.0.1
broadcast 192.168.11.0 dev eth4 proto kernel scope link src 192.168.11.221
broadcast 192.168.11.0 dev eth3 proto kernel scope link src 192.168.11.220
broadcast 192.168.20.8 dev eth0 proto kernel scope link src 192.168.20.10
local 192.168.20.10 dev eth0 proto kernel scope host src 192.168.20.10
broadcast 192.168.20.11 dev eth0 proto kernel scope link src 192.168.20.10
local 192.168.11.221 dev eth4 proto kernel scope host src 192.168.11.221
local 192.168.11.220 dev eth3 proto kernel scope host src 192.168.11.220
broadcast 192.168.11.255 dev eth4 proto kernel scope link src 192.168.11.221
broadcast 192.168.11.255 dev eth3 proto kernel scope link src 192.168.11.220
broadcast 192.168.21.8 dev eth1 proto kernel scope link src 192.168.21.10
local 192.168.21.10 dev eth1 proto kernel scope host src 192.168.21.10
broadcast 127.0.0.0 dev lo proto kernel scope link src 127.0.0.1
broadcast 192.168.21.11 dev eth1 proto kernel scope link src 192.168.21.10
local 127.0.0.1 dev lo proto kernel scope host src 127.0.0.1
local 127.0.0.0/8 dev lo proto kernel scope host src 127.0.0.1
x.
ok, jeden default smazu, ale mel jsem za to ze routovaci pravidla v local s konkretni ip (tedy .11.220 a .11.221) by to mely odfiltrovat drive nez default. Princip myslim ze matne ale chapu, ale je tam nekde nejaky hacek ktery nemuzu najit. Uprimne receno me trochu prekvapuje proc to nejde, myslel jsem si ze proste budou 2 rozhrani s 2 ip, kazda prijme to co ji je urceny a taky sama odpovi.. jde o to ze to budou 2 sitovy disky, na ktery se budou pripojovat ruzny klienti z toho rozsahu a tak nemuzu natvrdo urcit odchozi ip.. chtelo by to nejaky pravidlo ze to co na sitovku prijde po ni taky odejde a ne po jiny.. co sem tak cet o nastavovani ARP tak to vypadalo nadejne ze to je ono ale furt no neni funkcni.. a takovy masakry jako arp flux jsem radsi preskocil a doufam ze to pujde nejak jednoduseji :)
Pro tuto situaci je podle mého nejvhodnější ty dvě síťovky hodit do etherchannelu (Cisco terminologie), respektive bondingu (Linux terminologie). To je technologicky nejlepší způsob, jak řešit vámi požadované výkonnostní zlepšení.
Toto chování podporuje snad každý (managovatelný nebo smart) switch, se kterým jsem se kdy potkal, včetně modelů za pár stovek. Třeba tomu říkají "port group" nebo ještě nějak jinak, ale určitě to půjde nastavit.
Řešit to na L3, tak jak se o to snažíte, bude asi docela opruz a hlavně to prostě není "ta správná cesta".
Kdybys chtěl si hrát s vrrp, tak vidim v linuxu možná dvě implementace ... http://www.ucarp.org a http://www.keepalived.org/. Takže by šlo udělat dvě vrrp skupiny, každou s primárem na jedný síťovce. Jinak jan na L3 jednoduše nevim. No, možná udělat dva subnety, na každé síťovce jeden.
Tiskni
Sdílej: