TypeScript (Wikipedie), tj. JavaScript rozšířený o statické typování a další atributy, byl vydán v nové verzi 6.0. Příští verze 7.0 je kvůli výkonu přepisována do programovacího jazyka Go.
Christian Schaller z Red Hatu na svém blogu popsal své zkušenosti s používáním AI při vývoji open source aplikací pro Linux. Pomocí různých AI aktualizoval nebo vytvořil aplikace Elgato Light GNOME Shell extension, Dell Ultrasharp Webcam 4K, Red Hat Planet, WMDock, XMMS resuscitated (aktualizace z GTK 2 a Esound na GTK 4, GStreamer a PipeWire) a Monkey Bubble. SANE ovladač pro skener Plustek OpticFilm 8200i se mu zatím nepovedl.
Americké firmy Tesla a SpaceX postaví v texaském Austinu moderní komplex na výrobu čipů pro umělou inteligenci (AI). Součástí projektu s názvem Terafab budou dvě moderní továrny na výrobu čipů – jedna se zaměří na automobily a humanoidní roboty, druhá na datová centra ve vesmíru. Uvedl to generální ředitel těchto firem Elon Musk. Projekt by podle odhadů měl stát 20 miliard USD (zhruba 425 miliard Kč).
Byla vydána nová stabilní verze 6.11 (YouTube) multiplatformního frameworku a GUI toolkitu Qt. Podrobný přehled novinek v poznámkách k vydání.
Ubuntu 26.04 patrně bude ve výchozím nastavení zobrazovat hvězdičky při zadávání hesla příkazu sudo, změna vychází z nové verze sudo-rs. Ta sice zlepší použitelnost systému pro nové uživatele, na které mohlo 'tiché sudo' působit dojmem, že systém 'zamrzl' a nijak nereaguje na stisky kláves, na druhou stranu se jedná o možnou bezpečnostní slabinu, neboť zobrazování hvězdiček v terminálu odhaluje délku hesla. Původní chování příkazu sudo
… více »Projekt systemd schválil kontroverzní pull request, který do JSON záznamů uživatelů přidává nové pole 'birthDate', datum narození, tedy údaj vyžadovaný zákony o ověřování věku v Kalifornii, Coloradu a Brazílii. Jiný pull request, který tuto změnu napravoval, byl správcem projektu Lennartem Poetteringem zamítnut s následujícím zdůvodněním:
… více »Nové číslo časopisu Raspberry Pi zdarma ke čtení: Raspberry Pi Official Magazine 163 (pdf).
Eric Lengyel dobrovolně uvolnil jako volné dílo svůj patentovaný algoritmus Slug. Algoritmus vykresluje text a vektorovou grafiku na GPU přímo z dat Bézierových křivek, aniž by využíval texturové mapy obsahující jakékoli předem vypočítané nebo uložené obrázky a počítá přesné pokrytí pro ostré a škálovatelné zobrazení písma, referenční ukázka implementace v HLSL shaderech je na GitHubu. Slug je volným dílem od 17. března letošního
… více »Sashiko (GitHub) je open source automatizovaný systém pro revizi kódu linuxového jádra. Monitoruje veřejné mailing listy a hodnotí navrhované změny pomocí umělé inteligence. Výpočetní zdroje a LLM tokeny poskytuje Google.
Cambalache, tj. RAD (rapid application development) nástroj pro GTK 4 a GTK 3, dospěl po pěti letech vývoje do verze 1.0. Instalovat jej lze i z Flathubu.
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