Microsoft zveřejnil na GitHubu zdrojové kódy MS-DOSu 4.0 pod licencí MIT. Ve stejném repozitáři se nacházejí i před lety zveřejněné zdrojové k kódy MS-DOSu 1.25 a 2.0.
Canonical vydal (email, blog, YouTube) Ubuntu 24.04 LTS Noble Numbat. Přehled novinek v poznámkách k vydání a také příspěvcích na blogu: novinky v desktopu a novinky v bezpečnosti. Vydány byly také oficiální deriváty Edubuntu, Kubuntu, Lubuntu, Ubuntu Budgie, Ubuntu Cinnamon, Ubuntu Kylin, Ubuntu MATE, Ubuntu Studio, Ubuntu Unity a Xubuntu. Jedná se o 10. LTS verzi.
Na YouTube je k dispozici videozáznam z včerejšího Czech Open Source Policy Forum 2024.
Fossil (Wikipedie) byl vydán ve verzi 2.24. Jedná se o distribuovaný systém správy verzí propojený se správou chyb, wiki stránek a blogů s integrovaným webovým rozhraním. Vše běží z jednoho jediného spustitelného souboru a uloženo je v SQLite databázi.
Byla vydána nová stabilní verze 6.7 webového prohlížeče Vivaldi (Wikipedie). Postavena je na Chromiu 124. Přehled novinek i s náhledy v příspěvku na blogu. Vypíchnout lze Spořič paměti (Memory Saver) automaticky hibernující karty, které nebyly nějakou dobu používány nebo vylepšené Odběry (Feed Reader).
OpenJS Foundation, oficiální projekt konsorcia Linux Foundation, oznámila vydání verze 22 otevřeného multiplatformního prostředí pro vývoj a běh síťových aplikací napsaných v JavaScriptu Node.js (Wikipedie). V říjnu se verze 22 stane novou aktivní LTS verzí. Podpora je plánována do dubna 2027.
Byla vydána verze 8.2 open source virtualizační platformy Proxmox VE (Proxmox Virtual Environment, Wikipedie) založené na Debianu. Přehled novinek v poznámkách k vydání a v informačním videu. Zdůrazněn je průvodce migrací hostů z VMware ESXi do Proxmoxu.
R (Wikipedie), programovací jazyk a prostředí určené pro statistickou analýzu dat a jejich grafické zobrazení, bylo vydáno ve verzi 4.4.0. Její kódové jméno je Puppy Cup.
IBM kupuje společnost HashiCorp (Terraform, Packer, Vault, Boundary, Consul, Nomad, Waypoint, Vagrant, …) za 6,4 miliardy dolarů, tj. 35 dolarů za akcii.
Byl vydán TrueNAS SCALE 24.04 “Dragonfish”. Přehled novinek této open source storage platformy postavené na Debianu v poznámkách k vydání.
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