Úřad pro ochranu hospodářské soutěže (ÚOHS) provedl v říjnu 2024 místní šetření u společnosti Seznam.cz. Úřad prověřoval důvodné podezření na možné protisoutěžní jednání, konkrétně zneužití dominantního postavení. Krajský soud v Brně v květnu 2025 konstatoval, že toto šetření bylo nezákonné. Nejvyšší správní soud (NSS) včera rozhodl, že šetření bylo provedeno v souladu se zákonem. Krajský soud bude muset případ posoudit znovu.
Byl představen skládací telefon Commodore Callback 8020. Ani hloupý, ani chytrý. Pro fanoušky Commodore a digitálního minimalismu. Bez webového prohlížeče a sociálních sítí. S předinstalovaným WhatsAppem. S operačním systémem Sailfish OS.
V OpenBSD byla objevena 27 let stará chyba v ppp pomocí níž lze vzdáleně obejít autentifikaci. Chyba byla nahlášena 12.6. a 14.6. byla opravena. Bližší info v článku A 27-Year-Old Authentication Bypass in OpenBSD's PPP Stack.
Odpověď Evropské komise (pdf) k evropské občanské iniciativě Stop Destroying Videogames, jež je součástí hnutí Stop Killing Games: "Komise se domnívá, že v této fázi nemůže navrhnout právní povinnost zachovat hratelnost videoher poté, co přestaly být poskytovány komerčně. Důvodem jsou i stávající práva duševního vlastnictví. Podle autorského práva EU mají nositelé práv výlučná práva ke svým výtvorům. Kromě autorských práv mohou být
… více »Byl vydán Mozilla Firefox 152.0. Přehled novinek v poznámkách k vydání a poznámkách k vydání pro vývojáře. Řešeny jsou rovněž bezpečnostní chyby. Nový Firefox 152 bude brzy k dispozici také na Flathubu a Snapcraftu.
Desktopové prostředí KDE Plasma bylo vydáno ve verzi 6.7 (Mastodon). Přehled novinek i s videi a se snímky obrazovek v oficiálním oznámení. Podrobný přehled v seznamu změn.
Hříčka xsnow, která na ploše spustí sněžení, je protestware. Pokud jste v Rusku (LANG=ru), zobrazuje ukrajinské vlajky.
UBports, nadace a komunita kolem Ubuntu pro telefony a tablety Ubuntu Touch, vydala beta verzi Ubuntu Touch 24.04-2.0. Nová verze již počítá s výřezy pro fotoaparát (notch) a zaoblenými rohy displeje. Webový prohlížeče Morph přešel z Chromia 87 na Chromium 134. Do shellu Lomiri byl přidán editor snímků obrazovky.
V Praze probíhá Flock 2026, tj. konference pro přispěvatele a příznivce Fedory. Přednášky lze sledovat také na YouTube.
Node-RED (Wikipedie, GitHub), webová aplikace postavená na Node.js pro vizuální programování a propojování hardwarových zařízení, API a online služeb, byl vydán ve verzi 5.0. Přehled novinek v příspěvku na blogu.
Zdravím,
po rozběhnutí OpenVPN systémem server-klient jsem narazil na jeden nepříjemný zádrhel. Stroj na kterém běží OpenVPN server je stařičký celeron 433 MHz, 128 MB RAM s přípojkou do internetu 50/12 Mbit, kterou pomocí NAT zvládá bez mrknutí oka. OS je Debian 4. Když se klient připojí k VPN serveru (ze srovnatelně rychlé linky jako má server) a chce tahat data (je celkem jednokolik), tak procesor serveru je OpenVPNkou vytížen na plný výkon a rychlost průtoku dat je cca 0,5 - 1 Mbit. Ptám se tedy jak rychlý procesor (a případně kolik MB RAM) je potřeba, aby přes VPN teklo alespoň 10 Mbit a procesor nebyl vytížen na maximum?
Jste si jisty, ze vam to nezere neco jineho, X a tak ? Jinak navrhuju zacit dodanim alespon 256-512 RAM, pripadne potom jeste procesto na takovych 1Ghz to musi stacit.
NN
možná to není z mého popisu jasné, tak to objasním. Popisovaný celeron 433 slouží jako maškarádovací stroj pro PC v privátní LAN, běží na něm DNS, DHCP a sem tam nějaké blbinky na měření kde čeho. Při tom všem si procesor pochrupával u zimního spánku. Tudíž nemá žádné X a podobné zbytečnosti. Zbytek je stejný jak sem popisoval, začnu-li přes VPN tahat data, dostanu se (dle grafu v hotsanicu) na maximálně 6OO kbit/s (75 kB/s), procesor je vytížen na 98 - 100 % a přesně tolik si bere openvpn (ověřeno v htop). V RAM zůstává při přenosu dat VPNkou pořád dost místa (prakticky se to neprojeví). Takže jen ten procesor. Proto mě zajímají praktické zkušenosti vás ostatních. Máte někdo vyzkoušeno k jakému dojde zlepšení, kdybych dal do routeru procesor PIII 1 GHz?
zkus si proti tomu stroji zahajit prenos pres scp ... to bude asi hodne podobna zatez - sifrovani. Celeron mel temer zadnou cache. Vse ostatni co popisujes je jen stehovani baliku dat mezi interfacy. (Muzu vecer zmerit koli da via C7 na 1.5GHz... pokud to nekoho zajima)
Zkusil jsem i SCP. To dovede využít pásmo down/up naplno. Problém by tedy mohl být v šifrování dat procesorem do VPNky. Jestli máte někdo možnost vyzkoušet průchod dat skrz server-klient VPN (spousta certifikátů - veřejné, tajné, klientské a 1024 bitový dh) na cca 1 GHz procesoru, dejte vědět jak rychle vám tam data sypal.
server via c7@1.5GHz (ub7.10 ; 1GB ram) , klient Intel P3@1GHz (F.10 ; 512MB ram), lokalni 100mbit sit
k testum poslouzila F10-i686-Live.iso , cca 700MB dat , wget
ze serveru na klienta 3.67 MB/s (dle topu: server 45% v idle ; klient 0-6% idle)
z klienta na server 4.90 MB/s (server 18% , klient 22% )
oba stroje bez dalsi vyrazne zateze. Httpd-apache.
Obě dvě síťovky mají čip Realtek 8139D
Realteky dost zatezuji procesor, pri prenosu 97Mbit mi to bylo schopne zatizit P4/2.4G temer naplno (jen prenos souboru prez sambu)
doporucil bych sehnat intelky, ty jsou podstatne mene narocne na procesor
Opravdu to bylo tím realtekem? Používáme je spoustu let (ještě v době PII/400MHz) a řekl bych, že 100Mbps zvládaly OK. Samozřejmě intel je lepší.
s Realtekem nemám problémy v řádu cca let. Aniž by to procesor poznal zvládají ty karty 80 - 100 Mbit. Kolovaly v různých strojích určených ke všemu možnému, tak to mám ověřeno hned několikrát
A kdyz to bude delat sitovka, zajdes do bazaru a za par korun koupis intel ;)
Možná jsem to nepopsal dostatečně už v úvodním popisu problému. Pokud jedu bez VPN tunelu, tak jsem schopen dosáhnout maximálních rychlostí síťových karet a procesor o tom ani neví. Problém nastane právě taháním dat přes VPN tunel, kdy proces openvpn vytíží procesor při downloadu 8,8 Mbit na 60% a při uploadu 2,8 Mbit na 25 - 30% (bráno z pohledu zařízení tap0).
Skús vypnúť kompresiu ak ju máš zapnutú, myslím, že ten stroj by tých 10Mbit mal zvládnuť.
Zkusil jsem vypnout komprimování dat, zkusil jsem různé typy šifrování a snad ještě něco. Tím jsem zjistil, že kamenem úrazu byl parametr verb, který byl nastaven na hodnotu "verb 9". Když jsem ho změnil na celkem rozumnou hodnotu "verb 3", stoupnul datový tok přes VPNku na cca 2,8 Mbit/s (350 kB/s). Všem zúčastněným děkuji za rady, bude stejně potřeba vyměnit procesor.
Tom
Tak ještě jedna podivnost mě zarazila. Při nynějším nastavení a průtoku dat 8,8/2,8 Mbit procesor není vytíže na 100% ale na cca 60/20%. To znamená, že by mohl i dávat vyšší propustnost, ale nějak se mu asi nechce. Možná to přeci jen bude chyba slabého HW, ale pokud vás napadne nějaká podstatná blbina, budu rád.
Tom
a je vsechno po ceste 100mbit? jestli dokazes udelat 8.8mbit, tak by to mohlo znamenat ze napr. nektera sitovka/switch jede jen na 10mbit, to by tak odpovidalo.
V linuxu muzes pouzit bud mii-tool a nebo ethtool. Ve windows to vidis ve statusu rozhrani.
Linku do internetu od poskytovatele mám 50/12 Mbit, což mám ověřeno měřením. Čili síťovka je na 100 Mbit
Jestli chces zkusit kolik ten stroj zvladne, tak zkus vsechny klienty odpojit, rozbehat tunel na lokalni siti a zkusit pustit netperf kolik to zvladne ...
Když už se v tom tak nimrám, všimnul jsem si ještě jedné věci. Když se podívám na zařízení pomocí ifconfig, tak u fyzických síťovek, je proti vpnkové jeden rozdíl. Někde u konce výpisu parametrů je položna Délka odchozí fronty. Ta má u fyzických rozhraní velikost 1000 a u virtuálního 100. Má to nějaký vliv? Dá se příkazem zjistit, jakou aktuální rychlost má virtuální síťovka tap0?
Všem děkuji za návrhy řešení. Řešení jsem vymyslel za pomoci testování i na jiném HW v kombinaci s radami od všech zúčastněných. Zjistil jsem následující:
1. Procesor Celeron 433 MHz je opravdu málo na dosáhnutí vyšších rychlostí přes VPN kanál
2. Na výkonnějším stroji (2x PIII 500 MHz, 512 RAM) a stejné lince do internetu se z pohledu virtuálního rozhraní tap0 na tom výkonnějším stroji byl download o cca 30% vyšší, upload zůstal stejný
Ještě jednou děkuji za rady, byly pro mne přínosem při hledání zádrhelu
Tom
Tiskni
Sdílej:
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
29.5.2009 08:20
29.5.2009 09:23
28.5.2009 20:38