Nové číslo časopisu Raspberry Pi zdarma ke čtení: Raspberry Pi Official Magazine 161 (pdf).
Po delší době vývoje vyšla nativní linuxová verze virtuálního bubeníka MT-PowerDrumKit 2 ve formátu VST3. Mezi testovanými hosty jsou Reaper, Ardour, Bitwig a Carla.
Desktopové prostředí Budgie bylo vydáno ve verzi 10.10. Dokončena byla migrace z X11 na Wayland. Budgie 10 vstupuje do režimu údržby. Vývoj se přesouvá k Budgie 11. Dlouho se řešilo, v čem bude nové Budgie napsáno. Budgie 10 je postaveno nad GTK 3. Přemýšlelo se také nad přepsáním z GTK do EFL. Budgie 11 bude nakonec postaveno nad Qt 6.
OpenChaos.dev je 'samovolně se vyvíjející open source projekt' s nedefinovaným cílem. Každý týden mohou lidé hlasovat o návrzích (pull requestech), přičemž vítězný návrh se integruje do kódu projektu (repozitář na GitHubu). Hlasováním je možné změnit téměř vše, včetně tohoto pravidla. Hlasování končí vždy v neděli v 9:00 UTC.
Byl vydán Debian 13.3, tj. třetí opravná verze Debianu 13 s kódovým názvem Trixie a Debian 12.13, tj. třináctá opravná verze Debianu 12 s kódovým názvem Bookworm. Řešeny jsou především bezpečnostní problémy, ale také několik vážných chyb. Instalační média Debianu 13 a Debianu 12 lze samozřejmě nadále k instalaci používat. Po instalaci stačí systém aktualizovat.
Na stránkách Evropské komise, na portálu Podělte se o svůj názor, se lze do 3. února podělit o názor k iniciativě Evropské otevřené digitální ekosystémy řešící přístup EU k otevřenému softwaru.
Společnost Kagi stojící za stejnojmenným placeným vyhledávačem vydala (𝕏) alfa verzi linuxové verze (flatpak) svého proprietárního webového prohlížeče Orion.
Firma Bose se po tlaku uživatelů rozhodla, že otevře API svých chytrých reproduktorů SoundTouch, což umožní pokračovat v jejich používání i po plánovaném ukončení podpory v letošním roce. Pro ovládání také bude stále možné využívat oficiální aplikaci, ale už pouze lokálně bez cloudových služeb. Dokumentace API dostupná zde (soubor PDF).
Jiří Eischmann se v příspěvku na svém blogu rozepsal o open source AdGuard Home jako domácí ochraně nejen před reklamou. Adguard Home není plnohodnotným DNS resolverem, funguje jako DNS forwarder s možností filtrování. To znamená, že když přijme DNS dotaz, sám na něj neodpoví, ale přepošle ho na vybraný DNS server a odpovědi zpracovává a filtruje dle nastavených pravidel a následně posílá zpět klientům. Dá se tedy používat k blokování reklamy a škodlivých stránek a k rodičovské kontrole na úrovni DNS.
AI Claude Code od Anthropicu lépe rozumí frameworku Nette, tj. open source frameworku pro tvorbu webových aplikací v PHP. David Grudl napsal plugin Nette pro Claude Code.
Zdar odbornici! Mam problem s vykonem disku virtualni masiny a uz nevim jak dal.
Stalo se mi to postupne u vice stroju. Nainstaloval jsem virt. masinu a nejakou dobu vse slapalo jak ma. Rychlost zapisu v rozmezi od 40 MB/s do 100 MB/s jak kdy a jak kde (samozrejme testovano na hodne velkych souborech, protoze ze zacatku se to nekde po ceste kesuje a ukazuje to z pocatku uplne nesmysly). Disk hostitele ukazuje podobne rychlosti (atop -d 1) a disky hostitele nejsou pretizene.
Obcas se stane, ze virtualni disk zacne byt velmi pomaly a virtualka zapisuje uz jen rychlosti kolem jednoho az maximalne tri MB/s (vetsinou jen 1 az 1,5 MB/s) a disky hostitele jsou vytizene na nejakych 97 az 99%. V tom okamziku se cela virtualka uvnitr zadrhava a cely system uvnitr je beznadejne pretizeny. Procesor hostitele ani procesor hosta vsak vytizeny neni a flakaji se. Tento stav pak zustava trvale - tedy neni to obcas lepsi a pak zase spatne, ale je to spatne uz stale.
Vedlo me to nejprve k problemum s diskem hostitele, ale to se ukazalo jako chybna stopa.
Zapis i cteni disku hostitele je stale kolem 120 MB/s.
Overuju to takto:sync; time sh -c "dd if=/dev/zero of=./__testdata__ bs=1024k count=1000 oflag=direct; sync"sync; time sh -c "dd if=./__testdata__ of=/dev/null bs=1024k count=1000 iflag=direct; sync"
Konfigurace hostitele i hosta:
Hostitel: debian; jadro 2.6.32-5-amd64; SW RAID1; planovac dedline na oba odisky (sda,sdb z nich je jestaven raid); virtualky lezi v LVM oddilu a pouzil jsem FS XFS; QEMU emulator version 1.1.2 (Debian 1.1.2+dfsg-2~bpo60+1)
Virtualka: format obrazu RAW; cache NONE; IO rezim NATIVE; OS windows i linux (stalo se mi to uz na vice strojich, ale tento zkoumany stroj ma aktualne w2k8r2)
Na stejnem hostiteli jsem provedl jeste i dalsi testy.
- po instalaci jsem si ulozil cely virtualni disk do zalohy a kdyz jsem zkusil vytvorit virtualku (dumpxml te aktualni bezici) stejnou jakou pouzivam na ostro a pripojil jsem do ni tento disk ze zalohy, tak stabilne dosahuju kolem 60 MB/s - na stejnem hostiteli, stejna konfigurace, jen trochu mladsi a jina sitovka aby nebyla kolize MAC.
- ten stejny virtualni disk na jinem hostiteli s obdobnymi parametry bezi dobre
- abych vyloucil, ze neni problem s definici virtualky (nejaky bug), tak jsem zkusil v jiz existujicich virtualkach (te ostre, kde to zlobilo, bylo pomale a pretezovalo to disk hostitele; i v te testovaci, kde zalozni image z pradavne doby funguje i ted spravne rychle) oba obrazy prohodit. “Spatna” virtualka se zacala chovat “dobre” a “dobra” masina zacala delat problemy, takze to me vede k tomu, ze to nejak souvisi s konkretnim obrazem a ne s definici virtualky
- zkusil jsem “spatnou” virtualku nabootovat z live cd abych vyloucil problem s bezicim os a bylo to opet spatne, takze os uvnitr virtualky taky skrtam (ted to resim na windows, ale pod linuxem jsem zaznamenal ten problem z drivejska taky)
- zjistil jsem, ze kdyz zdravy image zapisuje rychle a na stejnem hostiteli zacnu zapisovat do “spatneho” image (2 soubezne bezici virtualky), tak se razantne zpomali i ten zdravy image (rychlost klesne z 60 MB/s a zacne kolisat nekde kolem 3 az 8 MB/s). Po zruseni kopirovani v te “spatne” virtualce se da “dobra” virtualka opet rozbehla naplno.
- zkusil jsem vytvorit novy obraz a pomoci clonezilly (device-to-device) jsem se tam pokusil vykopirovat data ze “spatneho” obrazu. Cele to trvalo asi do 5 hodin (disk ma jen 50 GB - uz to bylo podezrele, ale nevedel jsem zda to neni jen tim, ze ten “spatny” image pretezuje celeho hostitele a tak jsem to nechal dobehnout). Vysledek je, ze i ten novy image ma stejne problemy s vykonem.
- v cirem zoufalstvi jsem zkusil prejmenovat ty obrazy (kdyby slo o nejaky bug navazany na jmeno - nekde neco zapsane nebo buh vi co...), ale vysledek stejne spatny
- pokud ma byt problem s obrazem, tak jsem zkusil zkonvertovat obraz z raw na qcow2, ale vysledek byl temer stejny... Byl sice zapis 2x rychlejsi s qcow2 nez s raw, ale stale se to pretezovalo a jen to poukazuje na nejaky bordel, protoze by to spravne melo byt obracene. Kdyz jsem ten samy image jeste zkonvertoval zpet na raw, tak jsem doahnul stejny vysledek jako pred konverzi. Check na tom qcow2 obrazu tvrdi, ze no error.
- zkusil jsem i zmenit device z IDE na VIRTIO a dodal jsem drivery, ale vysledek byl (prekvapive) jeste horsi
- ac by nebyl opravneny duvod k fragmentaci, tak i to jsem zkusil, ale fragmentace je jen nejakych 7%, tak jsem to hned vyloucil.
Nevim co dalsiho zkusit, nebo co dal merit, nebo co je tohle za bordel? Prosim pomoooc!
Řešení dotazu:
Jednak resync v dobe testu nebezel, ted nebezi a druhak mam resync pod kontrolou i z jinych duvodu.
Jelikoz je resync jen read only operace, tak vsechny hostitele mam navic nastavene tak, aby resync nebyl narocny (dev.raid.speed_limit_min = 100).
1) proc mate na LVM vytvoreny FS a v nem raw soubory tech virtualek ?
Kdyz uz pouzivate LVM, tak kazde virtualce dejte jeden LV.
2) Neswapuje vam nahodou ten hostitel? Vypnout swap !
Tiskni
Sdílej: